WO2009156733A1

WO2009156733A1 - Method and apparatus for generating error keys for fault diagnosis in communication networks

Info

Publication number: WO2009156733A1
Application number: PCT/GB2009/001595
Authority: WO
Inventors: Kee Leong Tan; Pang Leang Hiew; See Leng Ng
Original assignee: British Telecommunications Public Limited Company
Priority date: 2008-06-25
Filing date: 2009-06-24
Publication date: 2009-12-30

Abstract

The present invention provides a method and apparatus for generating error keys that may be used in the diagnosis of faults in communication networks. A network element registers with a profile database and a profile is associated with the network element. The network element will transmit periodic messages; if an alert or error is detected in the transmitted message then an error key can be constructed on the basis of the network element profile and the content of the received message.

Description

METHOD AND APPARATUS FOR GENERATING ERROR KEYS FOR FAULT DIAGNOSIS IN COMMUNICATION NETWORKS

The present invention relates to a method and apparatus for generating error keys that may be used for fault diagnosis in communications networks.

It is common for communications networks to be constructed using equipment (such as routers, switches, transmission equipment, etc. [for the sake of clarity these will subsequently be referred to network elements]) that has been manufactured by different suppliers. Such communication networks are often characterized by a wide variety of network devices and applications. These devices and applications may operate on heterogeneous platforms using heterogeneous protocols and possibly connected to heterogeneous networks. If problems or faults occur then it may not obvious to a network administrator in which network element the fault has occurred. Such a problem is likely to be more pronounced within a home network as it probable that a user will have average computer knowledge and limited troubleshooting skills.

Even if users have access to remote assistance, for example a telephone helpdesk or an online help function, it is common for problems not to be solved due to communication problems between users and technical support or for simple problems to take a long time to be solved as helpdesk personnel need to go through a number of steps to identify and analyse user's problems.

According to a first aspect of the present invention there is provided a method of operating a communications network, the method comprising the steps of: (a) registering a network element with a profile database such that a profile can be associated with the network element; (b) receiving periodic reports from the network element; (c) identifying received reports which are of interest; (d) parsing each report of interest to identify one or more properties of the report; and (e) generating an error key in accordance with the profile associated with the network element in step (a) and the one or more properties of the report identified in step (d). Step (e) may further comprise that the error key is generated in accordance with the contents of the report of interest. A network element may be registered with the profile database when the network element is connected to the communications network. A profile may be associated with the network element by initiating a discovery process with the network element; alternatively, a profile may be associated with the network element by initiating a communication session with an external agent, such as a DHCP server, or a profile may be associated with the network element by selecting a profile held within the profile database.

In step (c) of the method a received report which comprises an alert may be identified as a report of interest. Alternatively, or in addition, a received report which comprises a severity level which exceeds a predetermined threshold may be identified as a report of interest.

The error key generated in step (e) may comprise a plurality of segments and the first segment may comprise information concerning the other segments. Furthermore, the error key generated in step (e) may comprise data regarding the properties of the network element and/or data regarding an error state of the network element. The data regarding the properties of the network element may be extracted from the profile associated with the network element. The data regarding the error state of the network element may be extracted from the report of interest received from the network element.

According to a second aspect of the present invention there is provided an apparatus configured to perform any of the methods described above.

According to a third aspect of the present invention there is provided a computer program product comprising computer executable code for performing any of the methods described above.

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings in which:

Figure 1 shows a schematic depiction of a communications network which comprises a plurality of network elements; and Figure 2 shows a schematic depiction of an apparatus according to the present invention.

Figure 1 shows a schematic depiction of a communications network 100 which comprises a plurality of network elements 10, which are in communication with first and second monitoring servers 20a, 20b. The network elements are conventional network components, such as, for example, a router, switch, transmission equipment etc. The first and second monitoring servers are in communication with respective first and second admin clients 30a, 30b. A communications network 25 enables the communication between the various components that form the network. Preferably the communications network 25 is an IP (Internet Protocol) based network.

Figure 2 shows a schematic depiction of an apparatus 200 according to the present invention. The apparatus 200 comprises XML messaging server 205, XML messaging API 210, remote control device manager 215, status probe 220, DHCP server 225, device profile database 230, monitoring server 235, log aggregator 240, log parser 245, log ID manager 250, first lookup table 255, interface 260, knowledgebase 265 and second look up table 270.

The operation of the apparatus 200 will now be described in detail. A new network element, for example a wireless router, may be installed into a communications network; for example, network element 10 shown in Figure 1. Upon installation, the network element will register one or more properties, along with any associated data values or parameters with the device profile database 230. The apparatus 200 is in communication with communications 100, either directly or via a gateway or other apparatus. The apparatus may be in communication with one or more further communications networks (not shown).

The network element properties may comprise one or more of, for example, manufacturer name, device model, device type, etc. These properties may be obtained from the network element itself, for example during a discovery process (for example, Universal Plug and Play {UPnP} discovery, or Simple Network Management Protocol {SNMP} discovery) or via communication with an external agent, for example, opening a session with DHCP server 225. An example of a set of properties and associated data values are shown below in Table 1 :

Table 1 : Exemplary network element property set.

As an alternative to explicitly sending the property data to the device profile database, a network element may select a pre-defined device profile that is held within the device profile database. As a further alternative, a pre-defined device profile may be selected from the device profile database, one or more properties or property values overwritten, and the modified device profile written to the device profile database.

Once a network element has been registered with the device profile database 230, the element will transmit periodic reports to a monitoring server 235, which processes the received reports. The reports can be log message, or SNMP message that has been converted to log format. The monitoring server may be, for example, a syslog server. The monitoring server is in communication with a log aggregator 240; the log aggregator is able to identify those reports which are an alert or which have a level of severity that exceeds a predetermined threshold value. Those reports that are alerts or that have a critical severity level can then be forwarded to a log parser 245. An example of such a log message is given below in Table 2:

Log message sshd(pam_unix): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost.localdomain user=root

Table 2: Exemplary log message

The log parser 245 identifies the error category from the content of the log message and sends both the error category and the log message to the log ID manager 250. The log ID manager will then use this information in order to construct an error identification key (EIK).

The log ID manager accesses the first lookup table 255 in order to determine the different segments that will form the EIK; these EIK segments may be written into a temporary array. The log ID manager then accesses the device profile database to retrieve the data associated with the network element which generated the report. The network element may be identified by an IP address, MAC address or another unique identifier. The data received from the device profile database is then stored within the temporary array. An EIK can then be formed by appending the array elements together and separating them using a common delimiter symbol, for example ::. Table 3 shows a example of an EIK and the contents of the different segments:

Table 3: Exemplary EIK

Once an EIK has been generated, the knowledgebase 265 can be queried to determine whether such an EIK already exists. If no match is found in the knowledgebase, that is the EIK is a new EIK, then the Log ID manager can register the EIK to the knowledgebase by uploading the EIK and associated pre-hash array data.

Any files created during the generation of an EIK may be compressed and encrypted before being uploaded to the knowledgebase and/or the remote-helpdesk. It may be possible for a user to exclude sensitive or personal information, for security reasons or otherwise. The EIK comprises multiple segments which are separated by common delimiters. The number of segments in an EIK may vary from a problem to another. An EIK comprises three types of information, namely segment information, device descriptor, error information. The EIK format is shown in Table 4 below:

Segment Information :: Descriptor 1... Descriptor N :: Error Information 1... Error Information M

Table 4: Exemplary EIK Format

The segment information is mandatory within an EIK; it describes the fields of the segments in the EIK by indicating T or '0' at its bit locations. The device descriptor information is optional and can be used to describe the problem in more detail and also to provide sufficient information to troubleshoot the problem identified, for example, device manufacturer information, device model information, device firmware, operating system information, network connection, etc. The error information is also mandatory; it is extracted from the error logs generated by the devices (see above) and comprises, for example, error category, process name, error message, etc. The number and type of segments that comprises an EID may vary, dependent on the error information that is present in the error logs. Different types of error may require different types of quantities of information in order for a fault to be identified and/or fixed.

The segment information segment provides an indication of the information held in other EIK segments. The first EIK segment can be mapped to the second lookup table 270, which holds data which defines all the possible segment information that is comprised within the other segments. If segment information exists then this may be indicated by setting a bit value, for example a "T may indicate that a segment contains information, otherwise the segment may be marked with a '0'. The second lookup table may be expandable to enable more information to be included in the EIK, based upon different requirements of the error categories and/or types. It also serves as an index of a table which contains all possible attributes to construct an EIK. The format of the EIK segments can be fixed to suit a specific service or system.

Table 5: Examples of first segments from EIKs

Table 5 above shows examples of the first segment from two EIKs, and it will be shown below how the first segment can be used to define the content of an EIK. For the EIK associated with error A₁ the first segment comprises '11111 ' and thus the EIK will have the format of '11111 :: Device Manufacturer :: Device Model :: Device Type :: Error message :: Error type'. Thus, an example of a generated EIK for Error A would be '11111 :: Linksys lnc :: WRT54G-v1.02.2:: WirelessAP :: authentication failure:: secure-sshd'.

Similarly, for the EIK associated with error B, the first segment comprises '11001 ' and thus the EIK will have the format of '11001 :: Device Manufacturer :: Device Model :: Error type'. Thus, an example of a generated EIK for Error B would be '11001 :: Dlink lnc:: DP-301 P+ :: :: :: function address 0x1fd3c70 caused a protection fault'.

It can be seen that an EIK will be unique and specific to a particular error type, irrespective of time and location of occurrences. The EIK comprises sufficient data to assist user to describe the error, setup and device information. These data can be based on variables such as device profile, log messages, network topology, user settings, network protocol, etc. The EIK data should contain sufficient information to describe the problem such that a fault can be diagnosed and rectified by a user, helpdesk, online community, etc.

If, for example for the sake of data presentation, there is a need to convert the EIK into a fixed length string, then this can be realised by converting each of the elements of the EIK into a fixed-length hash key. The use of a hash function should minimize the probability of having duplicate keys, as a small change in the value of an array element will lead to a large variance in the key value. Preferably the fixed-length hash key comprises both numerical numbers (0-9) and one or more symbols (such as, for example ^* or #). This is for the purpose of uncomplicated distribution and enables an EIK to be easily entered via phone key pad, as during an event where communication network total failure, user may fallback to telecommunication to perform fault diagnosis.

It will be understood that the present invention will be implemented as a program or software component that can be executed by a general purpose computing device, such as a personal computer or similar computing device(s). Software implementing a method according to the present invention may be supplied on physical media (such as a USB drive, CD-ROM, DVD, etc) or supplied or made available for transfer or, download via a communications network.

Claims

1. A method of operating a communications network, the method comprising the steps of:

(a) registering a network element with a profile database such that a profile can be associated with the network element;

(b) receiving periodic reports from the network element;

(c) identifying received reports which are of interest;

(d) parsing each report of interest to identify one or more properties of the report; and

(e) generating an error key in accordance with the profile associated with the network element in step (a) and the one or more properties of the report identified in step (d).

2. A method according to Claim 1 , wherein step (e) further comprises that the error key is generated in accordance with the contents of the report of interest.

3. A method according to either Claim 1 or Claim 2, wherein a network element is registered with the profile database when the network element is connected to the communications network.

4. A method according to any of Claims 1 to 3, wherein a profile is associated with the network element by initiating a discovery process with the network element.

5. A method according to any of Claims 1 to 3, wherein a profile is associated with the network element by initiating a communication session with an external agent.

6. A method according to Claim 5, wherein a communication session is initiated with a DHCP server.

7. A method according to any of Claims 1 to 3, wherein a profile is associated with the network element by selecting a profile held within the profile database..

8. A method according to any of Claims 1 to 7, wherein in step (c) a received report which comprises an alert is identified as a report of interest.

9. A method according to any of Claims 1 to 7, wherein in step (c) a received report which comprises a severity level which exceeds a predetermined threshold is identified as a report of interest.

10. A method according to any of Claims 1 to 9, wherein the error key comprises a plurality of segments and the first segment comprises information concerning the other segments.

11. A method according to Claim 10, wherein the error key comprises data regarding the properties of the network element.

12. A method according to Claim 11 , wherein the data regarding the properties of the network element is extracted from the profile associated with the network element.

13. A method according to any of Claims 10 to 12, wherein the error key further comprises data regarding an error state of the network element.

14. A method according to Claim 13, wherein the data regarding the error state of the network element is extracted from the report of interest received from the network element.

15. An apparatus configured to perform the method of any of Claims 1 to 14.

16. A computer program product comprising computer executable code for performing a method according to any of Claims 1 to 14.