Patent Application
20080019286
The foregoing will be apparent from the following more particular description of example embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments of the present invention.
A description of example embodiments of the invention follows.
In one embodiment of the optical communications system 100, fifty-two PON cards 120 may connect to an OLT 110 via a network link 112 or, in another embodiment, the PON cards 120 may be physically co-located in a chassis (not shown) with an OLT 110. Any number of ONTs 130 (e.g., thirty-two or sixty-four ONTs), in turn, may connect to each PON card 120. Finally, each ONT 130 may support four network devices 135, such as a computer, video device, alarm system, or telephone, via four interfaces (not shown). Thus, an OLT 110 may connect to 52 (PONs)×32 (ONTs)=1664 ONTs 130 or 1664 (ONTs)×4 (interfaces or network devices)=6656 network devices 135, and each managed entity (i.e., the OLTs 110, PON cards 120, ONTs 130, and network devices 135) can provide state indicators representing its status.
In another embodiment, the network devices 135 may represent interfaces (not shown) that are integrated into a given ONT 130. For example, Session Initiation Protocol (SIP) and Multimedia over Coax Alliance (MoCA) technology may be integrated into the given ONT 130. Thus, an ONT 130 may provide the operational state of an interface (i.e., on or off) as a state indicator.
The state indicators may represent an alarm state, an alarm reset state, or a non-alarm event. The non-alarm event may include a threshold crossing alert indicating that a given threshold has been exceeded.
In the embodiment of
In other embodiments, network elements at higher levels may further consolidate consolidated state indicators from subtending network elements. For example, a PON card 120 may receive multiple consolidated state indicators 151 from subtending ONTs 130 and provide further consolidated state indicator(s) 155a to an OLT 110. The OLT 110, in turn, may receive the further consolidated state indicator(s) 155a and forward them to the WAN 142 for delivery to, for example, a Management System (MS) or other network node for inspection by or informing of a service provider or third party network management organization.
The OLTs 110, PON cards 120, or ONTs 130 may maintain the alarm states of a subset of all network devices 135. In this way, a user may retrieve “on demand” detailed alarm information, such as the current alarm state, from the OLTs, PON cards, or ONTs through an MS.
Briefly, high level differences in example embodiments among the networks 100, 101, and 102 of
It should be understood that further state indicator consolidation may occur at hierarchical level(s) beyond the level where the initial state indicator consolidation occurs. In addition, each network node may be equipped to generate state indicators. Thus, there may be an initial state indicator consolidation or a further consolidation of consolidated state indicators at each hierarchical level.
Registers 210a, 210b, . . . , 210n, associated with respective ONTs 1, 2, . . . , n, may indicate a status of various aspects of the ONTs 1, 2, . . . , n by setting bits in register cells 220a-0, 220a-1, . . . , 220a-n; 220b-0, 220b-1, . . . , 220b-n; and so forth, where the bits, or combinations of bits, represent state indicators. The state of various aspects of the ONTs may be representative of a state of communications readiness, port traffic level, alarm state, and so forth. Again, individual register cells 220a-0, 220a-1, etc. may represent a state of the network device with which they are associated, or multiple register cells may be treated as a hexadecimal value, for example, to represent a state.
Examples of the SIP alarms may include an alarm associated with each interface or port of an ONT that indicates an ONT hardware or software failure or a user's failing to hang up a telephone device (e.g., “POTS—Excessive Analog Off-hook Time”). Examples of the SIP alarms may also include: (1) two Dynamic Host Configuration Protocol (DHCP) server-type alarms associated with each ONT (2 total alarms); (2) twelve SIP User Agent (UA) alarms associated with each of four UAs (48 total alarms); (3) thirteen Configuration Server alarms associated with each of a trusted anchor profile and a local-network profile of an ONT (26 total alarms); and (4) thirteen Configuration Server alarms associated with each of a device profile, an application profile, and a user profile for each of the four UAs (4 UAs×39 alarms=156 total alarms). Thus, each ONT may generate up to two hundred thirty-six (236) SIP alarms, and an OLT connected to one thousand six hundred sixty-four (1664) ONTs may receive up to 236×1664=392,704 SIP alarms.
Under normal circumstances, a network operator or automated management system at a central office, monitoring ONTs through a computer terminal (not shown) connected to an OLT, receives a manageable number of alarms. However, a single network event, such as a router failure, can cause an “alarm storm” of hundreds, thousands, or millions of alarms. A network operator receiving such a large volume of alarms may find it difficult and time-consuming to diagnose network issues and respond accordingly. In addition, a large number of alarms may overwhelm MS resources.
In existing systems, each subtending network element (e.g., ONT) reports all alarms to the carrier MS. Then, the MS correlates alarms from the network and completes a root cause analysis.
According to embodiments of the present invention, an ONT 130, PON card 120, or OLT 110 may consolidate (or “roll-up”) multiple state indicators, such as alarms, by forwarding one alarm, a subset of alarms, or a representative alarm indicator for each alarm type declared on subtending network elements, e.g., network devices 135, ONTs 130, or PON cards 120, respectively.
It should be understood that alarms are being used in this description as an example only. In every instance of “alarm” or at least certain instances of “alarm,” the term “alarm” may be replaced with “event” or a combination of “alarms and events,” including cases where the term “alarm” is used as a modifier, such as alarm registers, alarm processing, alarm components, and so forth. Moreover, a state indicator may represent a set state (e.g., alarm active) or a reset state (e.g., alarm inactive).
The PON card 420 may include a reporting unit 422, a mapping unit 424, a monitoring unit 426, and memory 428. The monitoring unit 426 may provide the state indicator packet 460 to the mapping unit 424, which maps the state indicator 460 to a consolidated state indicator 450. The mapping unit 424, in turn, may provide the consolidated state indicator 450 to the reporting unit 422. The reporting unit 422 may then forward the consolidated state indicator 450 to the MS 405 via the OLT 410. The monitoring unit 426 may detect additional occurrences of the state indicator 460 from other ONTs (not shown) in communication with the PON card 420. In this case, the monitoring unit 426 may store the additional occurrences of the state indicator 460 in the memory 428.
An operator or an automated management system of the MS 405 may query the PON card 420 through the OLT 410 for a specified level of detail (465) of the consolidated state indicator 450. For example, the operator may make a query to the PON card 420 for the state indicator 460. The PON card may then provide the state indicator 460 to the OLT 410 and MS 405 through the reporting unit 422. The operator may query (465) the PON card 420 through the OLT 410 for further details about the state indicator 460. The PON card 420, in turn, may query (475) the ONT 430 for details about the state indicator 460. In response to the query, the ONT 430 may provide the state indicator details 470 to the PON card 420. The PON card 420, in turn, may provide the state indicator details 470 to the OLT 410 and MS 405 through the reporting unit 422.
The second network node or entity may be an OLT, a PON card, or an ONT. The first network nodes or entities may be one or more PON cards, ONTs, or network devices in communication with an ONT.
The PON card 820a (“PON1”) communicates with multiple ONTs 831a-c (“ONT-1.1,” “ONT-1.2,” and “ONT-1.3”) and the other PON card 820b (“PON1”) communicates with multiple ONTs 832a-c (“ONT-2.1,” “ONT-2.2,” and “ONT-2.3”). In one embodiment, the PON cards 820a-b forward consolidated state indicators or alarms, such as consolidated Dynamic Host Configuration Protocol (DHCP) server alarms 851, 852 (“DHCP.ONT.1” and “DHCP.ONT.2”), respectively, when they receive multiple state indicators or alarms of the same type. For example, the PON card 820a may receive multiple DHCP alarms 841a-c (“DHCP.ONT-1.1,” “DHCP.ONT-1.2,” and “DHCP.ONT-1.3”) from respective ONTs 831a-c and the other PON card 820b may receive multiple DHCP alarms 842a-c (“DHCP.ONT-2.1,” “DHCP.ONT-2.2,” and “DHCP.ONT-2.3”) from respective ONTs 832a-c. In another embodiment, the PON cards 820a-b may forward a number of consolidated state indicators or alarms that are fewer in number than received state indicators or alarms.
The OLT processor 815 (“CPU”), in turn, forwards a further consolidated alarm, such as a further consolidated DHCP alarm 860 (“DHCP.ONT”), to the IPMI 817 when the OLT processor 815 receives the consolidated alarms, such as DHCP alarms 851, 852 (“DHCP.ONT.1” and “DHCP.ONT.2”), from the PON cards 820a-b, respectively. The IPMI 817 may then forward a DHCP alarm 870 (“DHCP”), representing the further consolidated DHCP alarm 860 (“DHCP.ONT”), to the EMS 875.
In other embodiments, the PON cards 820a-b or OLT processor 815 may detect the state indicators or alarms in the ONTs 831a-c, 832a-c or PON cards 820a-b, respectively. The PON cards 820a-b and OLT processor 815 may track or store alarms using tables or scorecards 880a-b, 885. As shown, for example, in
The OLT processor 915, in turn, forwards a further consolidated DHCP alarm 960 (“DHCP.ONT”) to an IPMI 917 upon receiving a first consolidated DHCP alarm, such as consolidated DHCP alarm 951 (“DHCP.ONT.1”), from a subtending PON card, such as PON card 920a. The OLT processor 915 may responsively make an indication in its scorecard 985 that the consolidated DHCP alarm 951 has been received from PON card 920a (e.g., by adding an “X” to the column labeled “1”).
When PON card 920a receives a second DHCP alarm 941b (“DHCP.ONT-1.2”) from ONT 931b (“ONT-1.2”), it may make an indication in its scorecard 980a that the second DHCP alarm 941b (“DHCP.ONT-1.2”) has been received (e.g., by adding an “X” to the column labeled “1.2”). The PON card 920a, however, does not forward the second DHCP alarm 941b or any other DHCP alarms of the same type to the IPMI 917.
In a similar manner, the other PON card 920b (“PON2”) may forward a second consolidated DHCP alarm 952 (“DHCP.ONT.2”) to the OLT processor 915 (“CPU”) upon receiving a first DHCP alarm, such as DHCP alarm 942a (“DHCP.ONT-2.1”), from a subtending ONT, such as ONT 932a (“ONT-2.1”). As shown in
As described above, the state indicator may represent an alarm state. The state indicator may also represent an alarm reset state. For example, each ONT may generate an instance of an alarm reset state (e.g., an alarm clear). Each PON card, in turn, may generate an alarm reset state when all ONTs communicating with that PON card have generated an instance of an alarm reset state. In another embodiment, each PON card may generate an alarm reset state when the number of ONTs communicating with that PON card is less than a given threshold. For example, if a given number of non-critical alarms is fewer than a threshold (e.g., 3) in a system in which many non-critical alarms are possible (e.g., 10), then an embodiment of the PON card does not generate an alarm until at least the threshold number of alarms are detected. An OLT, in turn, may generate an alarm reset state when all PON cards with outstanding alarm states have generated an instance of an alarm reset state or when the number is less than a given threshold. Other methodologies may also be implemented to improve system or network level performance.
As shown in
Referring to
Referring to
Referring to
In
After all consolidated DHCP alarms have been set to the reset state as indicated by the OLT scorecard 1085 (e.g., a table in OLT memory), the OLT processor 1015 (“CPU”) changes the first further consolidated DHCP alarm 1060 to a reset state (“DHCP.ONT Clear”). The OLT processor 1015 may also forward a further consolidated DHCP alarm clear indicator to an IPMI 1017. The IPMI 1017, in turn, may change the second further consolidated DHCP alarm 1070, which represents the first further consolidated DHCP alarm 1060, to a reset state (“DHCP Clear”).
Examples of state indicators include alarms, non-alarm events, and threshold crossing alerts (a non-alarm event). An alarm may be an alerting indication to a condition that may have immediate or potential negative impact on the state of a monitored managed entity or network element. Alarms are typically standing conditions that may be cleared by some autonomous event. An event may be an informative indication to a condition on the state of the monitored managed entity. Unlike an alarm, however, an event may not be cleared. But, a “cleared event” can be generated.
A Threshold Crossing Alert (TCA) is a notification to a condition that has exceeded a threshold for a current collection interval or period. A TCA may be an event that may not be cleared in an automated manner, for example, as described above in reference to state indicators.
The SIP TCAs 1108 may include two TCAs associated with each of four Real-time Transport Protocol (RTP) streams (8 total TCAs). The SIP TCAs 1108 may further include: (1) eight SIP User Agent (UA) TCAs associated with each of four UAs (32 total TCAs); (2) one DHCP TCA associated with an ONT; (3) five Configuration Server TCAs associated with each of a trusted anchor profile and a local-network profile of the ONT (10 total TCAs); and (4) five Configuration Server TCAs associated with each of a device profile, an application profile, and a user profile for each of the four UAs (60 total TCAs). Thus, each ONT may generate up to 112 SIP TCAs and an OLT connected to 1664 ONTs may receive up to 112×1664=186,368 SIP TCAs.
Events, including events outside the control of the EMS, may cause all ONTs to generate large numbers of TCAs every fifteen minutes (e.g., up to 186,368 SIP TCAs). Large numbers of TCAs may quickly overwhelm EMS resources and be useless to the network operator.
Within a subsequent fifteen minute interval, yet another ONT 1232a may forward an RTP excessive jitter TCA 1242 to the second PON card 1220b, and the respective ONT 1231a may forward an RTP excessive jitter TCA 1241d to the first PON card 1220a. At the end of the fifteen minute interval, the second PON card 1220b may forward a consolidated RTP excessive jitter TCA 1252, and the first PON card 1220a may forward a consolidated RTP excessive jitter TCA 1251b to the EMS 1275. In an optical communications system, the collection interval or period may be anywhere from fifteen minutes to 24 hours, but can be more or less time in other embodiments.
Each PON card 1220a-b may transmit a consolidated TCA with a unique offset to differentiate consolidated TCAs. The PON cards 1220a-b may also include ONT details in their consolidated TCAs.
The above example alert consolidation method limits the number of TCAs forwarded to the EMS 1275. For example, as described above, without alert consolidation, a PON card may receive up to 112 TCAs from each of 32 ONTs and thus may forward up to 112×32=3584 total TCAs to the EMS 1275. In contrast, a PON card applying TCA consolidation as described herein may forward up to 16 TCAs (i.e., two TCAs associated with the RTP steams+eight TCAs associated with the UAs+one TCA associated with the ONT+five TCAs associated with the profiles) to the EMS 1275. Thus, the EMS 1275 may receive up to a total of 832 TCAs from 52 PON cards. In a TCA storm, however, up to 832 consolidated TCAs can still overwhelm the OLT alarm and event manager and the EMS.
In a further embodiment, the PON cards may bypass the OLT alarm and event manager and send one or more messages that represent a bit map of some or all outstanding TCAs on some or all PON cards directly to the EMS at the end of each fifteen minute interval.
While this invention has been particularly shown and described with references to example embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.
For example, the flow diagrams of
It should be understood that the terms “when” and “upon” as used above may be interpreted to mean “immediately after” or “after a nonzero time period.”
It should also be understood that alarms or events of same, similar, or different types may be consolidated into a consolidated alarm or event. For example, the alarms or events of different types may be consolidated if there is some commonality between or among the alarms or events.
It should also be understood that various elements described above may be combined into a single element. For example, the OLT processor 815 and IPMI 817 of
Although embodiments of the present invention are illustrated in contexts of optical communications networks, it should be understood that embodiments of the present invention apply to any type of network (e.g., wired networks, wireless networks, data networks, and so forth) in which status (e.g., alarm, event, etc.) indicators can be consolidated. Further, the networks may be any type of network configuration, such as hierarchical, distributed, ring, and so forth.
Flow diagrams, such as
