FORM 2
The Patent Act 1970
(39 of 1970)
&
The Patent Rules  2005

COMPLETE SPECIFICATION
(SEE SECTION 10 AND RULE 13)

TITLE OF THE INVENTION

“Hardware based proactive monitoring system”

APPLICANT:

Name Nationality Address
Alcatel Lucent France 3 avenue Octave Greard 75007 Paris

The following specification particularly describes and ascertains the nature of this invention and the manner in which it is to be performed:-

TECHNICAL FIELD
[001] The embodiments herein relate to communication and  more particularly  to implementing hardware based proactive monitoring system.

BACKGROUND
[002] A communication network refers to association of various networks and associated user devices connected each other to share information. Internet  broadband access networks and so on are examples of such communication networks. This kind of networks comprises server systems which manage data transfer and communication to and from different networks and user devices. The communication networks may further comprise plurality of network elements which perform dedicated functions to facilitate data transfer across the networks.
[003] An edge switch is an example for network elements. Edge switches may cover devices such as routers  routing switches  multiplexers and so on. Basic functionality of an edge switch is to act as an interface or a connecting element between two networks. The user devices are connected to the network through the edge switch such as router. Further  in order to provide better services  each user is connected to the network through dedicated channels which are connected to the edge switches such as router.
[004] In the existing systems  each router handles tens of thousands of subscribers. In these systems  an edge router and an aggregation switch handles the access nodes present in the network. Further  the network service provider has to constantly monitor and check connectivity and service level agreement (SLA) corresponding to each of the subscribers. The active monitoring systems have to constantly monitor and check for faults in the networks. These systems have to further inform a network administrator or any such responsible person if any fault is detected in the network.
[005] Existing systems make use of IEEE 802.1a/g and ITU Y 1731 standards in order to define a way of checking connectivity  delay and loss to each subscriber connection. A major disadvantage associated with the existing systems is that all the existing systems are software based and the software based network testing mechanisms are not efficient in handling thousands of connections proactively. This results in increased fault generation which inturn results in increased customer complaints.

SUMMARY
[006] In view of the foregoing  an embodiment herein provides a method for monitoring a wireline access network in a continuous manner without software intervention  the method comprising of running at least one test between pairs of Maintenance End Points (MEPs) from a plurality of MEPs present in the network in a concurrent manner by a network detection engine; and generating an alarm by the network detection engine  on detecting a fault between a pair of MEPs. The at least one test is one of a loopback test; a continuity test; a loss test; and a delay test. The loopback test comprises of sending loopback packets to all pairs of MEPs; updating transmission time stamp and receiving time stamp  wherein the transmission time stamp and the receiving time stamp are the time of transmission of the loopback packets and receiving of responses to the loopback packets; and generating an alarm on detecting absence of receipt of responses to the loopback packets. The continuity test comprises of sending continuity check packets to all pairs of MEPs; updating transmission time stamp and receiving time stamp  wherein the transmission time stamp and the receiving time stamp are the time of transmission of the continuity check packets and receiving of responses to the continuity check packets; and generating an alarm on detecting absence of receipt of responses to the continuity check packets for a specified time interval. The loss measurement test comprises of sending loss measurement packets to all pairs of MEPs; updating a count of packets received in response to the loss measurement packets from the pair of MEPs; comparing the number of transmitted loss measurement packets and number of received responses to the loss measurement packets; and generating an alarm on detecting that the difference between the number of transmitted loss measurement packets and number of received responses to the loss measurement packets crosses a specified number. The delay measurement test comprises of sending delay measurement packets to all pairs of MEPs; updating transmission time stamp and receiving time stamp  wherein the transmission time stamp and the receiving time stamp are the time of transmission of the continuity check packets and receiving of responses to the continuity check packets; computing average delay for each MEP from the transmission time stamp and the received time stamp; and generating an alarm on the average delay exceeding a pre-defined threshold.
[007] Also  disclosed herein is a wireline access network  wherein the wireline access network is monitored in a continuous manner without software intervention  the wireline access network comprising at least one means configured for running at least one test between pairs of Maintenance End Points (MEPs) from a plurality of MEPs present in the network in a concurrent manner; and generating an alarm  on detecting a fault between a pair of MEPs. The test is one of a loopback test; a continuity test; a loss test; and a delay test. The wireline access network is configured for running the loopback test comprising of sending loopback packets to all pairs of MEPs; updating transmission time stamp and receiving time stamp  wherein the transmission time stamp and the receiving time stamp are time of transmission of the loopback packets and receiving of responses to the loopback packets; and generating an alarm on detecting absence of receipt of responses to the loopback packets. The wireline access network is configured for running continuity test comprising of sending continuity check packets to all pairs of MEPs; updating transmission time stamp and receiving time stamp  wherein the transmission time stamp and the receiving time stamp are the time of transmission of the continuity check packets and receiving of responses to the continuity check packets; and generating an alarm on detecting absence of receipt of responses to the continuity check packets for a specified time interval. The wireline access network is configured for running the loss measurement test comprising of sending loss measurement packets to all pairs of MEPs; updating a count of packets received in response to the loss measurement packets from the pair of MEPs; comparing the number of transmitted loss measurement packets and number of received responses to the loss measurement packets; and generating an alarm on detecting that the difference between the number of transmitted loss measurement packets and number of received responses to the loss measurement packets crosses a specified number. The wireline access network is configured for running the delay measurement test comprising of sending delay measurement packets to all pairs of MEPs; updating transmission time stamp and receiving time stamp  wherein the transmission time stamp and the receiving time stamp are the time of transmission of the continuity check packets and receiving of responses to the continuity check packets; computing average delay for each MEP from the transmission time stamp and the received time stamp; and generating an alarm on the average delay exceeding a pre-defined threshold.
[008] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES
[009] The embodiments herein will be better understood from the following detailed description with reference to the drawings  in which:
[0010] FIG. 1 illustrates a general block diagram of a communication network as disclosed in the embodiments herein;
[0011] FIGS. 2a and 2b are block diagrams which illustrates proposed network architecture as disclosed in the embodiments herein;
[0012] FIG. 3 is a block diagram which illustrates various components of the proposed network detection engine as disclosed in the embodiments herein;
[0013] FIG. 4 is a block diagram which shows a Maintenance End Point (MEP) table as disclosed in the embodiments herein;
[0014] FIG. 5 illustrates a flow of data between various components of the network detection engine  as disclosed in the embodiments herein;
[0015] FIG. 6a  6b and 6c illustrates flow diagrams which shows transmitting  receiving and scanning steps respectively  in the process of loopback generation and processing  as disclosed in the embodiments herein;
[0016] FIG. 7a  7b and 7c illustrates flow diagrams which shows transmitting  receiving and scanning steps respectively  in the process of continuity check generation and processing  as disclosed in the embodiments herein;
[0017] FIG. 8a  8b and 8c illustrates flow diagrams which shows transmitting  receiving and scanning steps respectively  in the process of loss measurement generation and processing  as disclosed in the embodiments herein; and
[0018] FIG. 9a  9b and 9c illustrates flow diagrams which show transmitting  receiving and scanning steps respectively  in the process of delay measurement generation and processing  as disclosed in the embodiments herein.

DETAILED DESCRIPTION OF EMBODIMENTS
[0019] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly  the examples should not be construed as limiting the scope of the embodiments herein.
[0020] The embodiments herein disclose a proactive monitoring system by implementing hardware based system. Referring now to the drawings  and more particularly to FIGS. 1 through 9  where similar reference characters denote corresponding features consistently throughout the figures  there are shown embodiments.
[0021] FIG. 1 illustrates a general block diagram of a communication network as disclosed in the embodiments herein. The system comprises a network 101  a router 102  an aggregation switch 103  access node 104 and a plurality of user devices 105. Any interaction between the network 101 and the user device 105 happens through router 102  aggregation switch 103 and access node 104. The network may be a broadband access network or any such communication network. Further  the network 101 may be interconnected to a plurality of other networks and provide means for communication between user devices 105 present in different networks. Further  the router 102 directs communication and traffic between network 101 and user devices 105. The aggregation switch 103 aggregates flow of data to and from computing devices/user devices 105 to the rest of the network. The aggregation switches 103 are further responsible for combining data which are sent in the form of packets  before delivering to the destination. The access node 104 acts as a gateway for the user devices 105 to connect to the core communication network. The user devices 105 can connect to the access node 104 which in turn connects the user devices 105 to the aggregation switch 103 present in the network.
[0022] FIGs. 2a and 2b are block diagrams which illustrates proposed network architecture as disclosed in the embodiments herein. The system comprises network 101  router 102  aggregation switch 103  network detection engine 201  access node 104 and user devices 105. The network detection engine 201 may be within the aggregator switch 103 (as depicted in FIG. 2a) or the router 102 (as depicted in FIG. 2b). The network detection engine 201 performs proactive monitoring of the network traffic and simultaneously checks for any faults in the network. In one embodiment  faults may refer to any connection related issue or network issue that may affect performance of the network adversely. The network detection engine 201 sends data packets to Maintenance End Points (MEP) present in the network and checks if the packets are returned from each MEP within a preset time interval. In one embodiment  the system may use a pair of MEPs to check connection. Of the two MEPs used for checking connection  one MEP may be present in the router 102 or the aggregation switch 103 and the other MEP may be present in other end of connection which could be a modem  Optical Network termination (ONT) or a residential gateway. The preset time interval may be a time set by a network administrator or any such responsible person who handles the network 101. If any packets sent to an MEP is missing or else the packets are not returned within the pre-set time interval  the network detection engine 201 alerts the software module which inturn may alert the network administrator. In one embodiment  the software module may be alerted only when the number of errors exceeds a set threshold value. The number of errors may be counted using a counter associated with the system. In another embodiment  the software module may be present in the aggregation switch 103 or else in any other related component of the system.
[0023] In another embodiment herein  the network detection engine 201 may be a distinct module  present external to the aggregator switch 103 or the router 102.
[0024] FIG. 3 is a block diagram which illustrates various components of the proposed network detection engine as disclosed in the embodiments herein. The system comprises a transmitter module 301  LBM scanning block 302  a CCM scanning block 303  a Loss measurement scanning block 304  a Delay measurement scanning block 305  a memory module 306 and a receiver module 307. The transmitter module 301 is used to transmit data over the network 101 to corresponding servers. The transmitter module 301 may also be used to transmit various testing signals associated with proposed LBM  CCM  LMM and DMM tests to the MEPs present in the network Further  the LBM scanning block 302 performs loop back tests during which the software module programs all available MEPs in the network to a MEP table. The LBM scanning block 302 sends loopback (LBM) data packets to all MEPs and updates transmit (Tx) time stamp. Further  the LBM scanning block 302 waits for the loopback reply from the MEPs. After receiving loopback replies from the MEPs  the LBM scanning block 302 updates Receipt (Rx) time stamp in the MEP table. Further if any LBM reply is missing from any MEP  the LBM scanning block 302 notifies the software module and triggers an alarm.
[0025] The CCM scanning block 303 performs continuity tests during which hardware continuously loops through the MEP table and generates continuity check (CCM) packets from all the local MEPs. Further  for each CCM packet received from MEP  the system updates Rx time stamp in the MEP table. If any CCM is missing in the reply  the CCM block notifies the software module which inturn triggers an alarm.
[0026] The loss measurement scanning block 304 performs loss measurement tests during which the hardware continuously loops through the MEP table and generates certain number of loss measurement packets (LMM) to all MEPs. Further  the system receives loss measurement replies (LMR) and checks the number of packets present in the LMR. If any packet is missing as compared to the number of packets in LMM  the loss measurement scanning block notifies the loss of packets to the software module which inturn triggers an alarm.
[0027] The delay measurement scanning block 305 performs delay measurement. For the purpose of delay measurement  the hardware continuously loops through the MEP table and generates delay measurement packets (DMM) to all the MEPs present in the table. The DMM packets are then sent to MEPs in the network. Further  the measurement scanning block 305 waits until it receive a delay measurement reply (DMR). The delay measurement scanning block 305 measures the time taken for the reply DMR and compares the measured time with a preset time period. In one embodiment  the preset time period may be set by a network administrator or any such authorized person. If the measured time is greater than or equal to the preset time period  the delay measurement scanning block 305 notifies the increase in time to a software module which inturn triggers an alarm.
[0028] Further  the memory module 306 may be used for storing MEP table or any such data that may be used during the processing stage of the proposed system. The receiver module 307 is used for receiving data from servers and other devices transmitted across the network 102.
[0029] FIG. 4 is a block diagram which shows a Maintenance End Point (MEP) table as disclosed in the embodiments herein. The MEP table comprises data related to MEPs associated with each port in the network. The data may comprise Id corresponding to each MEP (MEP Id)  Media Access Control (MAC) address corresponding to each MEP  Virtual LAN (VLAN) address corresponding to each MEP  length from table  transmit time stamp (Tx)  receive time stamp (Rx) and/or any such data specific to each MEP connected to each port in the network. In one embodiment  the data present in the MEP table may be used by the network detection engine 201 to detect any faults in the network and trigger an alarm to notify the network administrator or any such authorized person. In another embodiment  the MEP table may be stored in the memory module 306 associated with the network detection engine 201.
[0030] FIG. 5 illustrates a flow of data between various components of the network detection engine  as disclosed in the embodiments herein. Here the transmitter 301 and receiver 307 may be used to transmit and receive various control signals associated with the proposed tests  between MEP pairs. The MEP table 501 may comprise information regarding all the maintenance end points (MEP) in the network. In an embodiment  all the MEPs in the network may be programmed to the MEP table by the system. The MEP table 501 may be present in the memory module 306 of the network detection engine 201.
[0031] Further  the scanning block may comprise any or all of LBM scanning block 302  CCM scanning block 303  Loss measurement scanning block 304 and Delay measurement scanning block 305. Each scanning blocks perform corresponding tests on the MEPs listed in the MEP table 501. If the scanning blocks identify any error in the corresponding tests  they update an associated counter value and periodically checks if the counter value has exceeded a pre-set threshold limit. If the counter value exceeds the threshold limit  the scanning block notify the software component of the system and the software component generates an alarm using the alarm generator. In one embodiment  the software component may maintain count of the errors occurred and may trigger the alarm only if the error count exceeds a set threshold value.
[0032] FIG. 6a  6b and 6c illustrates flow diagrams which show transmitting  receiving and scanning steps respectively  in the process of loopback generation and processing  as disclosed in the embodiments herein. In the beginning of transmitting step (as depicted in Fig.6a) of loopback tests  the software module configures all MEPs associated with the network to a MEP table. The MEP table may comprise MEP Id  MAC address  VLAN  length and / or any such data specific to each MEP. The LBM scanning block 302 which perform loopback generation and processing  obtains (601) MEP Id and other parameters corresponding to each MEP in the network and generates (602) Protocol Data Unit (PDU) for each MEP. Further  the generated PDUs are sent (503) to corresponding MEPs in the order they are present in the MEP table. After sending PDU to a MEP  the corresponding Tx time stamp is updated (604) in the MEP table.
[0033] Further  in the receiving step (as depicted in Fig. 6b) the system waits untill it receive a loop back reply (LBR) from the MEP. Once the loop back reply is received (605)  the system filters (606) the received LBR packets. Further  the system updates (607) an Rx time stamp corresponding to the MEP in the MEP table. In an embodiment  the receive block is activated only when a packet is received.
[0034] Further  in the scanning step (as depicted in Fig. 6c) the loop back scanning block 302 analyzes (608) the data in the MEP table. In one embodiment  the loop back scanning block 302 may analyze the Tx time stamp and the Rx time stamp present in the MEP table. Further  the system checks (609) if the difference between the transmit time and the receive time is greater than or equal to a maximum loop back outage time (MAX_LBM_OUTAGE_TIME). In one embodiment  the MAX_LBM_OUTAGE_TIME may be a value preset by the network administrator or any such person who handles the network. If the difference between Tx time stamp and Rx time stamp is greater than or equal to MAX_LBM_OUTAGE_TIME value  the loop back scanning block 302 updates (610) a counter. Further the system checks (611) if the counter value has exceeded a set threshold value. In one embodiment  the threshold value may be set by an administrator or any other authorized person. If the counter value has exceeded the threshold  then the LBM block may notify an associated software block  which in turn triggers (612) an alarm to notify the user or administrator. If the difference between Tx time stamp and Rx time stamp is found to be less than the MAX_LBM_OUTAGE_TIME value or else if the counter value has not exceeded the set threshold value  then the system checks (613) if it is end of MEP table. If it is the end of MEP table  the system sleeps (615) for time period ‘T’ and after the expiry of the time period ‘T’  the loop back scanning block 302 move to the start (616) of MEP table and starts scanning again. If it is not the end of table  the system moves (614) to next MEP in the MEP table and perform loop back tests for that MEP. The various actions in method 600 may be performed in the order presented  in a different order or simultaneously. Further  in some embodiments  some actions listed in FIG. 6 may be omitted.
[0035] FIG. 7a  7b and 7c illustrates flow diagrams which show transmitting  receiving and scanning steps respectively  in the process of continuity check generation and processing  as disclosed in the embodiments herein. The continuity tests are performed by a CCM scanning block 303 present in the network detection engine 201. In the beginning of transmitting step (as depicted in Fig. 7a)  the software module programs all available MEPs to the MEP table. The MEP table may comprise MEP Id  MAC address  VLAN  length and any such data that corresponds to each MEP associated with each port. The CCM scanning block 303 obtains (701) MEP Id corresponding to each MEP from the MEP table. Further  the CCM scanning block 303 sends (702) CCM packets to MEPs in the order they are present in the MEP table. Once the CCM packet is sent to a MEP  the corresponding Tx time stamp is updated (703) in the MEP table.
[0036] Further  in the receiving step (as depicted in Fig. 7b)  the system waits untill it receive the CCM packets from MEP. Once the system receives (704) the MEP packets  corresponding Rx time stamp is updated (705). In an embodiment  the receive block is activated only when a packet is received.
[0037] Further  in the scanning step (as depicted in Fig. 7c)  the CCM scanning block 303 analyzes (706) the data present in the MEP table. Further  the system measures difference between current time and Rx time stamp and checks (707) if the measured time is greater than or equal to a MAX_CCM_OUTAGE_TIME. In one embodiment  the MAX_CCM_OUTAGE_TIME may be preset by a network administrator or any such person who handles the network. If the measured time is greater than or equal to MAX_CCM_OUTAGE_TIME  the CCM scanning block 303 updates (708) a counter associated with the system. Further  the system checks (709) if the counter value has exceeded a set threshold value or not. In an embodiment  the threshold value may be set by an administrator or by any other authorized person. If the counter value has exceeded the threshold value  then the CCM scanning block 303 may notify an associated software module which in turn triggers (710) an alarm to notify the user or administrator. After triggering the alarm or else if the measured time is less than the MAX_CCM_OUTAGE_TIME value or else if the counter value has not exceeded the threshold value  the CCM scanning block 303 move onto (711) next MEP in the MEP table and performs continuity checks. The various actions in method 700 may be performed in the order presented  in a different order or simultaneously. Further  in some embodiments  some actions listed in FIG. 7 may be omitted.
[0038] FIG. 8a  8b and 8c illustrates flow diagrams which show transmitting  receiving and scanning steps respectively  in the process of loss measurement generation and processing  as disclosed in the embodiments herein. To start with the transmitting step (as depicted in Fig. 8a)  the software module programs all available MEPs to a MEP table. The MEP table may comprise MEP Id  MAC address  VLAN  length and any such data that corresponds to each MEP associated with each port. The loss measurement tests are conducted by a loss measurement scanning block 304 in the network detection engine 201. The loss measurement scanning block 304 obtains (801) Id corresponding to each MEP (MEP Id) from the MEP table and generates (802) certain number of loss measurement packets (LMM) to all the MEPs. Further the system transmits (803) the LMM packets to MEP and updates (804) the Tx time stamp.
[0039] Further  in the receiving step (as depicted in Fig. 8b) the system receives (805) Loss Measurement Reply (LMR) packets from the MEP  it filters (806) the received LMR packets and updates (807) the Rx time stamp. In an embodiment  the receive block is activated only when a packet is received.
[0040] Further  in the scanning step (as depicted in Fig. 8c)  the loss measurement scanning block 304 analyzes (808) the data present in the MEP table and measures the difference between number of packets in the LMM message and number of packets in the LMR message. Further  the loss measurement scanning block 304 checks (809) if the difference in number of packets between LMM and LMR is greater than or equal to a maximum allowed loss (MAX_ALLOWED_LOSS). In one embodiment  the MAX_ALLOWED_LOSS may be a value preset by a network administrator or any such person who handles the network. If the difference in number of packets is greater than or equal to the maximum allowed loss  the loss measurement scanning block 304 updates (810) a counter value associated with the system. Then the system checks (811) if the counter value has exceeded a set threshold value or not. In one embodiment  the threshold value may be a value preset by a network administrator or any such person who handles the network. If the counter value has exceeded the set threshold value  then the loss measurement scanning block 304 notifies an associated software module which in turn triggers (812) an alarm to notify the user or an administrator. After triggering the alarm  the loss measurement scanning block 304 moves (813) onto the next MEP in the table and performs loss measurement tests. Further  if the difference in number of packets between LMM and LMR are less than the maximum allowed loss (MAX_ALLOWED_LOSS) or else if the counter value has not exceeded the maximum threshold value  then the loss measurement scanning block 304 moves (813) onto next MEP in the table and performs loss measurement tests. The various actions in method 800 may be performed in the order presented  in a different order or simultaneously. Further  in some embodiments  some actions listed in FIG. 8 may be omitted.
[0041] FIG. 9a  9b and 9c illustrates flow diagrams which show transmitting  receiving and scanning steps respectively  in the process of delay measurement generation and processing  as disclosed in the embodiments herein. In the transmitting step (as depicted in Fig. 9a)  the delay measurement generation and processing is carried out by a delay measurement scanning block 305. To begin with  a software module programs all available MEPs to a MEP table. The delay measurement scanning block 305 obtains (901) EMP Id from an EMP table. Further  the delay measurement scanning block 305 generates (902) delay measurement packets and transmits (903) the delay measurement packets to MEP in the order MEPs are present in the MEP table. After transmitting the delay measurement packets to MEP  the Tx time stamp in the MEP table corresponding to the MEP is updated (904).
[0042] Further  in the receiving step  the system waits untill the MEP sends a delay measurement reply (DMR). Once  the DMR packets are received (905)  the system updates (906) Rx time stamp in the MEP table. In an embodiment  the receive block is activated only when a packet is received.
[0043] Further  in the scanning step (as depicted in Fig. 9c)  the delay measurement scanning block 305 measures (907) an average considering the Tx time stamp value and the Rx time stamp value. Further  the delay measurement scanning block 305 checks (908) if the measured average delay is greater than or equal to a set threshold value. In one embodiment  the threshold value may be set by a network administrator or any such person who handles the network. If the measured average delay is greater than or equal to the threshold value  the delay measurement scanning block 305 updates (909) an associated counter value. Further  the system checks (910) if the counter value has exceeded a set threshold value. If the threshold value has been exceeded  then the delay measurement scanning block 305 notifies a software module which in turn triggers (911) an alarm to notify the error to the user or an administrator. Once the alarm is triggered or else if the average delay is less that set threshold or else if the counter value is less than the set threshold value  then the delay measurement scanning block 305 moves (912) onto next MEP in the MEP table and performs delay measurement tests. The various actions in method 900 may be performed in the order presented  in a different order or simultaneously. Further  in some embodiments  some actions listed in FIG. 9 may be omitted.
[0044] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements. The network elements shown in Fig. 3 include blocks which can be at least one of a hardware device  or a combination of hardware device and software module.
[0045] The embodiment disclosed herein specifies a system for proactive fault detection and alarming in a communication network. The mechanism allows proactively detecting faults in a network and triggering alarm to notify a network administrator  providing a system thereof. Therefore  it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein  such computer readable storage means contain program code means for implementation of one or more steps of the method  when the program runs on a server or mobile device or any suitable programmable device. The method is implemented in a preferred embodiment through or together with a software program written in e.g. Very high speed integrated circuit Hardware Description Language (VHDL) another programming language  or implemented by one or more VHDL or several software modules being executed on at least one hardware device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer  or the like  or any combination thereof  e.g. one processor and two FPGAs. The device may also include means which could be e.g. hardware means like e.g. an ASIC  or a combination of hardware and software means  e.g. an ASIC and an FPGA  or at least one microprocessor and at least one memory with software modules located therein. Thus  the means are at least one hardware means and/or at least one software means. The method embodiments described herein could be implemented in pure hardware or partly in hardware and partly in software. The device may also include only software means. Alternatively  the invention may be implemented on different hardware devices  e.g. using a plurality of CPUs.
[0046] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can  by applying current knowledge  readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept  and  therefore  such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore  while the embodiments herein have been described in terms of preferred embodiments  those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the claims as described herein.

CLAIMS
We claim 
1. A method for monitoring a wireline access network in a continuous manner without software intervention  said method comprising of
Running at least one test between pairs of Maintenance End Points (MEPs) from a plurality of MEPs present in said network in a concurrent manner by a network detection engine; and
Generating an alarm by said network detection engine  on detecting a fault between a pair of MEPs.
2. The method  as claimed in claim 1  wherein said at least one test is selected from one of
A loopback test;
A continuity test;
A loss test; and
A delay test.
3. The method  as claimed in claim 2  wherein said loopback test comprises of
Sending loopback packets to all pairs of MEPs;
Updating transmission time stamp and receiving time stamp  wherein said transmission time stamp and said receiving time stamp are the time of transmission of said loopback packets and receiving of responses to said loopback packets; and
Generating an alarm on detecting absence of receipt of responses to said loopback packets.
4. The method  as claimed in claim 2  wherein said continuity test comprises of
Sending continuity check packets to all pairs of MEPs;
Updating transmission time stamp and receiving time stamp  wherein said transmission time stamp and said receiving time stamp are the time of transmission of said continuity check packets and receiving of responses to said continuity check packets; and
Generating an alarm on detecting absence of receipt of responses to said continuity check packets for a specified time interval.
5. The method  as claimed in claim 2  wherein said loss measurement test comprises of
Sending loss measurement packets to all pairs of MEPs;
Updating a count of packets received in response to said loss measurement packets from said pair of MEPs;
Comparing the number of transmitted loss measurement packets and number of received responses to said loss measurement packets; and
Generating an alarm on detecting that the difference between the number of transmitted loss measurement packets and number of received responses to said loss measurement packets crosses a specified number.
6. The method  as claimed in claim 2  wherein said delay measurement test comprises of
Sending delay measurement packets to all pairs of MEPs;
Updating transmission time stamp and receiving time stamp  wherein said transmission time stamp and said receiving time stamp are the time of transmission of said continuity check packets and receiving of responses to said continuity check packets;
Computing average delay for each MEP from said transmission time stamp and said received time stamp; and
Generating an alarm on said average delay exceeding a pre-defined threshold.
7. A wireline access network  wherein said wireline access network is monitored in a continuous manner without software intervention  said wireline access network comprising at least one means configured for
Running at least one test between pairs of Maintenance End Points (MEPs) from a plurality of MEPs present in said network in a concurrent manner; and
Generating an alarm  on detecting a fault between a pair of MEPs.
8. The wireline access network  as claimed in claim 7  wherein said wireline access network is configured for selecting said at least one test from one of
A loopback test;
A continuity test;
A loss test; and
A delay test.
9. The wireline access network  as claimed in claim 8  wherein said wireline access network is configured for running said loopback test comprising of
Sending loopback packets to all pairs of MEPs;
Updating transmission time stamp and receiving time stamp  wherein said transmission time stamp and said receiving time stamp are time of transmission of said loopback packets and receiving of responses to said loopback packets; and
Generating an alarm on detecting absence of receipt of responses to said loopback packets.
10. The wireline access network  as claimed in claim 8  wherein said wireline access network is configured for running continuity test comprising of
Sending continuity check packets to all pairs of MEPs;
Updating transmission time stamp and receiving time stamp  wherein said transmission time stamp and said receiving time stamp are the time of transmission of said continuity check packets and receiving of responses to said continuity check packets; and
Generating an alarm on detecting absence of receipt of responses to said continuity check packets for a specified time interval.
11. The wireline access network  as claimed in claim 8  wherein said wireline access network is configured for running said loss measurement test comprising of
Sending loss measurement packets to all pairs of MEPs;
Updating a count of packets received in response to said loss measurement packets from said pair of MEPs;
Comparing the number of transmitted loss measurement packets and number of received responses to said loss measurement packets; and
Generating an alarm on detecting that the difference between the number of transmitted loss measurement packets and number of received responses to said loss measurement packets crosses a specified number.
12. The wireline access network  as claimed in claim 8  wherein said wireline access network is configured for running said delay measurement test comprising of
Sending delay measurement packets to all pairs of MEPs;
Updating transmission time stamp and receiving time stamp  wherein said transmission time stamp and said receiving time stamp are the time of transmission of said continuity check packets and receiving of responses to said continuity check packets;
Computing average delay for each MEP from said transmission time stamp and said received time stamp; and
Generating an alarm on said average delay exceeding a pre-defined threshold.

Dated: 21th day of March 2012 Signature:
Dr Kalyan Chakravarthy
(Patent Agent)

ABSTRACT

The embodiments disclosed herein relate to a method and system for proactive fault detection and alarm triggering in a large scale broadband access network. The system is capable of performing various types of tests such as loop back monitoring  continuity checks  loss measurement tests  delay measurement tests an so on. The system has a network fault detection engine which comprises dedicated blocks for performing each test. The system maintains a MEP table which stores parameters specific to each MEP (Maintenance End Points) associated with each port. The system obtains MEP Id for each MEP from the table and sends test packets to the MEP. Based on the transmission time and reception time  the system updates Tx and Rx time stamps for each MEP. The Tx and Rx time stamps and number of packets transmitted and received are considered to detect any fault associated with any connection.

FIG. 3