WO2004068786A1 - Determination of groupmembers prior of monitoring groups of network nodes - Google Patents

Determination of groupmembers prior of monitoring groups of network nodes Download PDF

Info

Publication number
WO2004068786A1
WO2004068786A1 PCT/IB2004/000187 IB2004000187W WO2004068786A1 WO 2004068786 A1 WO2004068786 A1 WO 2004068786A1 IB 2004000187 W IB2004000187 W IB 2004000187W WO 2004068786 A1 WO2004068786 A1 WO 2004068786A1
Authority
WO
WIPO (PCT)
Prior art keywords
controller
network
network nodes
group
nodes
Prior art date
Application number
PCT/IB2004/000187
Other languages
French (fr)
Inventor
Gyula Kun-Szabo
Gergely Homanyi
Original Assignee
Nokia Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Corporation filed Critical Nokia Corporation
Priority to EP04705858A priority Critical patent/EP1588521A1/en
Publication of WO2004068786A1 publication Critical patent/WO2004068786A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0681Configuration of triggering conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • H04L41/0823Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
    • H04L41/083Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability for increasing network speed
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0893Assignment of logical groups to network elements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/20Network management software packages
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements

Definitions

  • the present invention relates to a controller for controlling a plurality of network nodes such as routers in a network and to a method of controlling a plurality of network nodes in a network and in particular but not exclusively to a wireless network.
  • a diverse range of communication systems are in use today enabling communication between two or more entities, such as user equipment and/or other nodes associated with the system.
  • Wireless broadband' networks have been proposed which make high performance Internet access possible.
  • new wireless networks with wireless routers as network nodes on a mesh network basis emulate the topology and protocols of the Internet but are optimised for wireless highspeed data transmission.
  • a wireless routing network has been developed. The key components of such a wireless routing network are routed mesh network architecture, wireless routers, a wireless operating system and the deployment and management of the network.
  • Routed mesh networks mirror the structure of the wired Internet.
  • Each radio transceiver at a node in the wireless network becomes part of the infrastructure and can route data through the wireless mesh network to its destination just as in the wired Internet.
  • the advantage of such a routed mesh networks is that line-of-sight problems can be reduced in comparison to a client/base station architecture because each node only needs line-of-sight to one other node in the network and not all the way to the ultimate destination of the data traffic, e.g. the point-of-presence (POP) .
  • POP point-of-presence
  • With such an infrastructure the reach and coverage of the wireless network is extended with a minimal amount of wireless network infrastructure and interconnection costs.
  • the data traffic can be routed around obstructions rather than needing to deploy additional base stations for line-of-sight in densely populated diverse geographical locations.
  • wireless routers with omni-directional antennas are used as a network node. Each wireless router can communicate with other nodes, i.e. other wireless routers in any direction.
  • the omni-directional antennas offer a 360 -degree range and do not require precise pointing or steering. Therefore additional wireless routers can be added in an ad hoc and incremental fashion.
  • the wireless routers substantially comprise three components, namely a full TCP/IP (Transmission Control Protocol / Internet Protocol) protocol suite support, a wireless operating system that optimises the wireless network performance and robustness, and a high-performance digital RF modem.
  • TCP/IP Transmission Control Protocol / Internet Protocol
  • a specialized wireless networking software in combination with the high-performance RF modem optimises the network performance while ensuring full IP support and robust and stream-less IP routing.
  • Routed wireless mesh networks deploy specialized protocols, that operate efficiently in a multi-hop wireless network environment. From the media access control (MAC) layer through to the routing layer protocols are used that are specifically designed to deal with their unique attributes .
  • the protocol suite extends the traditional TCP/IP stack to provide efficient and robust IP-based networking in multi-hop wireless mesh networks. These protocols consist of four parts, namely channel access protocols, reliable link and neighbour management protocols, wireless multi-hop routing and multicast protocols, and standard Internet protocols.
  • protocols are used to efficiently schedule transmissions to avoid collisions and efficiently reuse the available spectrum.
  • Reliable link and neighbor management protocols ensure reliable transmissions on a hop-by-hop basis, and manage the automatic adaptation to changes in the network topology by monitoring the status of neighbor links.
  • the role of the reliable link and neighbor management protocols is to perform network synchronization and to manage the links to each neighbor node.
  • Wireless multi-hop routing and multicast protocols maintain performance-optimized routing tables and enable an efficient multicast capability.
  • the standard Internet protocols and tools are used for seamless integration with the wired Internet.
  • the protocols and tools are for example TCP/IP, UDP (User Datagram Protocol) , SNMP (Simple Network Management Protocol) , RIP, ICMP (Internet Control Message Protocol) , TFTP, ARP, IGMP, Proxy-ARP, DHCP relay (Dynamic Host Configuration Protocol) , DHCP server, and NAT (Network Address Translation) .
  • Wireless mesh networks based on a multipoint-to-multipoint architecture make an ad hoc integration of new nodes, i.e. wireless routers, easier since the actual demand and traffic flow in such a wireless network environment makes it much easier to adjust the coverage and bandwidth needs than design a network ahead of time.
  • Adaptive routed mesh network make obstructions to the line-of-sight by growing trees or temporary obstructions less problematic, since the data traffic is automatically re-routed through as a link becomes unavailable.
  • the nodes, i.e. wireless routers, in such a wireless routing network environment can adapt to changes in the link availability and the quality in real-time without requiring intervention by a network administrator.
  • the network should be monitored continuously so that the operator can have an overview of the general status of the network and its potentially problematic parts.
  • problems with loading of nodes can occur. Overloading can result in a poor service.
  • a faulty node is not identified or the nature of its fault is not properly identified, this could have an adverse impact on the network. This is a particular problem with large networks, such as telecommunication networks, regardless of the standard used in those communication networks.
  • the monitoring software had to be scriptable so that some external tool could generate the necessary updating script commands .
  • a controller for controlling a plurality of network nodes in a communications network, said controller being arranged to define a group of network nodes to be monitored based on a value of one or more attributes of said network nodes .
  • a communications system comprising a plurality of network nodes in a communications network, and a controller, said controller being arranged to define a group of network nodes to be monitored based on a value of one or more attributes of said network nodes .
  • a method for monitoring a plurality of network nodes in a communications network comprising the step of: defining a group of network nodes to be monitored based on one or more attributes of said network nodes
  • Embodiments of the present invention may be simple, cost- efficient, and robust and can handle large networks (e.g. thousands of routers or network elements) .
  • Figure 1 shows a routing network with which embodiments of the present invention can be used
  • Figure 2 shows the entities to which the routing network of Figure 1 is attached
  • FIG. 3 shows schematically a flow diagram of embodiments of the present invention.
  • Figure 4 shows schematically the management engine of Figure 2.
  • Fig. 1 shows a schematic representation of the wireless network with a plurality of network nodes 10.
  • Each network node 10 is connected to neighbouring network nodes 10 via a multipoint-to-multipoint line-of-sight connection 15 by which the network nodes 10 communicate with each other.
  • the wireless network comprise a Point-of-Presence POP 50 by which the wireless network is connected to the Internet or any other network.
  • additional nodes 20, 30 are to be added.
  • FIG. 2 shows the network 2 connected to a RMS (router management system) management engine 9 via a connection in accordance with a NetJazz Protocol.
  • the NetJazz protocol is a proprietary protocol developed by Nokia for use with their wireless mesh networks.
  • the RMS engine 9 is arranged to monitor the network so that the operator can have an overview of the general status of the network and its potentially problematic parts.
  • the RMS management engine is part of the management system for the wireless mesh network. It collects data from the wireless routers. It also translates alarms into SNMP traps that can be viewed with any umbrella management system that supports SNMP. With a single RMS management engine it is possible to continuously monitor large wireless router networks, generate alarms and collect performance data. Of course some embodiments of the invention may have more than one RMS management engine.
  • the RMS engine 9 may be optionally connected to a SNMP manager 40 such as HP (Hewlett Packard) OpenView products.
  • HP Hewlett Packard
  • the RMS engine is connected to a database 42 such as an ORACLE or MySQL database.
  • the RMS management engine 9 comprises an alarm monitor 22, a group manager 24 and a monitoring engine 26.
  • the alarm monitor 22 is connected to the database engine 11 and it may be connected to an SNMP Manager system 8.
  • the Group manager 24 is connected to the alarm monitor 22, the database engine 11 and the monitoring engine 26.
  • the group manager 24 is arranged to send monitoring parameters to the monitoring engine 26 and to receive network monitoring data from the monitoring engine 26.
  • the monitoring engine 26 is additionally arranged to be connected to the routing network 2.
  • the monitoring engine 26 is responsible for monitoring network elements 10, implementing the actual monitoring protocol.
  • the group manager 24 is responsible for maintaining the membership of monitoring groups 25 runtime depending on the received network element attributes.
  • the alarm monitor 22 generates SNMP traps, this functionality depends on the actual monitoring groups 25 because the groups can have different alarm situations defined.
  • the database engine 11 simply performs the database operations.
  • the RMS management engine 9 monitors the router network 2 by sending probes from the monitoring engine 26 to the network 2 and receiving reports from routers or network elements.
  • the collected data is stored in the database 11.
  • the RMS management engine examines the reports. It may apply e.g. fault detection criteria, leading to SNMP traps indicating detected faults as alarms.
  • the list of collected alarms (traps) can be viewed through an SNMP manager 8 (after they have been relayed to the SNMP manager by the RMS management engine 9) .
  • Monitoring parameters specify the performance and alarm monitoring frequency and data that is collected from the wireless router network.
  • Node parameters relate to nodes e.g. routers in that particular network, while link parameters relate to connections between different nodes.
  • routers have different 'roles' and their role can be configured on the fly by changing some operational parameters. These roles can be for example 'mesh gateway' and 'subscriber router'. Additional roles can be defined by the users via the filter expressions determining the group membership, like "low traffic routers", “experimental hardware version”, “potentially faulty routers", etc. Any meaningful combination of status attribute value ranges can denote a particular "role” . The roles determine the needed frequency of probing by the RMS management engine 9 for each router.
  • the routers In the responses to the probes from the RMS management engine 9, the routers report a subset of their operational attributes. The routers report to the RMS management engine 9. Depending on these values, a given router may need special attention and a different probing scheme may be required. A given router may be able to play two or more different roles either at the same time or at different time. The frequency of the probing, the alarm handling, and the required attributes may be changed. This will be described in more detail hereinafter.
  • the large number of routers in a network also requires an intelligent strategy for determining when a particular router should be probed to prevent network congestion and loss of status report data caused by big bursts of responses to probes. This can be achieved by the RMS management engine 9 applying different monitoring schemes to different parts of the network.
  • the RMS management engine is provided to deal with the fact that the statuses of the routers may change quickly.
  • the RMS management engine is arranged to deal with a large number of routers in a network without the operator handling each network node one by one. Instead, the RMS management node 9 is arranged to apply general rules defined by the operator. These rules can be applied to a set of nodes at a time. Filtering rules are evaluated dynamically to determine if a given entity belongs to a monitoring group.
  • the RMS management engine 9 is arranged to change its monitoring behavior depending on the values of router status attributes and a set of strategy definitions that consist of Boolean filter expressions on the domain of the status attributes evaluated during monitoring of every router.
  • the RMS management engine is arranged to control the following aspects of monitoring:
  • Threshold values for alarm generation based on the status of the routers For example:
  • the RMS management engine can be tuned by editing a configuration file.
  • This file contains, among other settings, the group definitions (name, filtering expressions and the overridden monitoring parameters mentioned above) used by the management engine.
  • the application When the application starts, it reads the definitions and sets up the monitoring groups. Then, before each polling cycle, it evaluates the group filters for each router, determines the group to which the router belong based on the filtering results and polls the elements of those groups that are eligible for polling at the given time.
  • rules are defined that are evaluated dynamically to determine if a given entity belongs to a supervision group. This contrasts which previously proposed solutions which statically assign group attributes to the entities .
  • Embodiments of the present invention allow the operator to define a new monitoring group e.g. based on the value of the status attribute containing the operating system (OS) version of the nodes. From that point on, whenever a node's OS is upgraded, the filter of the newly defined group automatically recognizes it and the device is handled according to the operating rules given in the group definition.
  • OS operating system
  • the network can be logically partitioned into e.g. 'important' and 'ordinary' nodes.
  • the 'important' nodes then can be polled much more frequently, with requests for more detailed status reports while the 'ordinary' ones are allowed to report only basic data with a lower frequency. This can significantly reduce the management- related traffic on the network.
  • Embodiments of the present invention can for example collect automatically more data from faulty nodes than nodes which are running without problems.
  • Embodiments of the invention may save network and management , engine resources .
  • the RMS management engine adjusts automatically to changes.
  • routers and their roles can be configured on the fly by changing their parameters. These roles are used for example to determine a needed frequency of probing. In responses to the probes, the routers report a subset of their operational attributes. Depending on these values, they might need special attention and a different probing scheme (e.g. frequency, alarm handling, required attributes) . To prevent network congestion due to probing large number of routers in the network, an intelligent strategy is used. This is achieved by applying different monitoring schemes to different parts of the network. The RMS management engine thus changes its monitoring behavior depending on the values of router status attributes and a set of strategy definitions.
  • Embodiments of the invention have the advantage that there is dynamic behaviour in the monitoring logic in the RMS management engine. It introduces some intelligence to the system, so that it becomes adaptive to a constantly changing network environment. For example: in one embodiment, the RMS management engine can poll those clusters of the network more frequently (e.g. every 5 minutes) where the routers were reset more than 10 times during the last week. The target group may change all the time.
  • embodiments of the present invention may result in no need for external data exchange interfaces to any kind of helper applications.
  • Embodiments of the invention may result in no need for: scripting facilities; distributed hardware and software elements; and/or regular user intervention related to massive status changes .
  • Each router is arranged to handle group filter expressions.
  • the user edits the configuration of the RMS management engine. This is done by editing an XML file with a text editor.
  • XML - extensible Markup Language - is a widely used standard to exchange structured data in textual format Alternatively, any XML editor can be used as the DTD (Document Type Definition - a descriptor file that defines valid XML tags in a certain XML file) of the configuration file is shipped with the product.
  • the configuration settings for polling, status logging and alarm handling are defined in their corresponding XML tags and their attributes .
  • the group definitions are given in ⁇ group> elements. Their name, filtering expressions and the redefinitions of polling, status logging and alarm handling parameters have to be specified. The mentioned parameters have to be defined on the general 'top level', and they can have different values in each management group .
  • XML documents are used to define structured data and is well known to the man skilled in the art.
  • An XML document contains elements which hold actual data. Each element has some attributes with their values, and can have also sub-elements (elements) .
  • the element names are written between ' ⁇ • and ' >' characters. When an element has attributes the closing ' >' has to be typed after the attribute list. The elements must be closed with a special ending: " ⁇ /elementname>" where "elementname” is the name of the element .
  • ⁇ mysubelement> should be closed by a ⁇ /mysubelement> . Instead because it has no sub elements, the end of the element can be signed by the "/" before the closing '>' .
  • the filtering expressions can use the following XML tags:
  • the membership of a router can be described as a sentence in Boolean logic. Say every router is a member whose attribute 0x8f04 (this is a hexadecimal number) equals zero AND attribute 0x0601 is less than or equal to 10 AND attribute 0x1101 is equal to 1. (Note: Term 'attribute' here refers to a NetJazz protocol (NJP) attribute as the used hexadecimal constants are from NJP. Embodiments of the invention would work with any implementation where the attributes in question can be addressed with symbolic identifiers) .
  • This sentence contains 3 sub-conditions connected with "AND”, so on the upper level the ⁇ all> element is used. This means that the examined router is a member only if _all_ the three sub-conditions are satisfied.
  • the three sub-condition can be wrapped in only one condition using the ⁇ all> element (with the meaning of Boolean *and*) : ⁇ all> negative definition can be used (e.g. the members are routers whose attribute 0x1101 is NOT equal to 1) . So the members can report either 0 or 8 or 13 or anything but 1 as value of attribute 0x11,01. This can be coded like: ⁇ not>
  • step SI the application is started.
  • step S2 the configuration file and sets up the monitoring groups according to their XML definitions.
  • the criteria of group membership are defined by the user by describing the filter expressions of the groups using the XML tags discussed above in the configuration file of the management engine.
  • the attributes are the wireless mesh routers' attributes. Other implementations can use their relevant status descriptors. The emphasis is not on the mode of describing the expressions but on the fact that these expressions are repeatedly evaluated during run-time of the management engine and the routers are enrolled in /removed from their respective groups based on the result of these filtering expressions.
  • the corresponding monitoring, attribute logging and alarm handling parameters are stored with the groups.
  • the monitoring parameters define the frequency for polling a given router or the like. Examples of this are
  • the groups may redefine not only the monitoring parameters but the logging details and the alarm handling as well.
  • the attribute parameters define those parameters which should be reported back to the RMS management engine and can include NetJazz attributes that can be reported by the routers or in alternative embodiments of the invention any relevant attribute that can be reported.
  • the alarm handling parameters define how the router should be dealt with in the event that the router has an alarm condition.
  • the groups can redefine the alarm conditions. For example in general a certain node is allowed to carry a given amount of traffic for say 10 minutes before being reported. This can be redefined so that this is redefined for mesh gateways to 20 minutes as gateways carry more traffic than ordinary routers.
  • management engine examines all groups' polling- related parameters and computes their greatest common divisor. For example if one group has a polling time of 10 minutes, another group has a polling time of 60 minutes and the third group have a polling time of 100 minutes, the greatest common time is 10 minutes. This common value will be used as the polling clock's time tick. Whenever a tick happens the groups whose polling time has arrived collect their nodes by evaluating the group filters against the routers' attributes and poll the routers. Thus, every time a tick arrives, the first group is polled with the second group being polled every 6 ticks and the third group being polled every 10 ticks. After having probed the routers, the engine sleeps until the next tick arrives.
  • the polling frequency is a function of the network size. The larger the network, the smaller the frequency should be to avoid overloading the management engine. These times can be different in each group.
  • step S4 As answers come from the polled routers, they are parsed in step S4 and the corresponding router's attributes are updated in step S5.
  • the alarm-monitoring phase examines the routers' state and acts as necessary in step S6.
  • the different groups can have different alarm threshold settings, which allow a fine-tuned setup for alarm supervision.
  • An alternative form of implementation could use separate threads for each monitoring group with their own polling timer instead of having one running with the greatest common denominator of the specified polling intervals. This would allow handling more routers at a cost of increased complexity of the software due to the necessary locking to control inter-thread data flow.
  • the preferred embodiments of the invention have been described in the context of a Nokia wireless mesh system using NetJazz protocol . It should be appreciated that firstly, embodiments of the invention can be used with any other protocol. Secondly, the invention can be implemented in any network regardless of its type where there is a plurality of routers or network elements.
  • the network can be any type of communications network and the network can be wired, wireless or a combination thereof.
  • Embodiments of the invention can be generalized to any situations where a large number of entities have to be supervised and their handling has to be different based on the results of polling as long as their status attributes can be addressed by symbolic identities .
  • Embodiments of the present invention have been described in the context of a wireless communications network. However it should be appreciated that embodiments of the present invention can be used in any other network or system having a number of routers or elements requiring managements. For example embodiments of the present invention can be used in a wired system.
  • each network may have its own RMS management engine.
  • a network may have more than one RMS management engine.
  • the RMS management engines may operate independently or may be in communication.
  • a single RMS management engine may serve more than one network.
  • the RMS management engine is provided by a single entity. In alternative embodiments of the present invention, the functionality of the RMS management engine may be provided in a distributed manner.

Abstract

A controller for controlling a plurality of network nodes in a communications network is disclosed. The controller is arranged to define a group of network nodes to be monitored based on a value of one or more attributes of said network nodes. The network nodes may be routers.

Description

DETERMINATION OF GROUPMEMBERS PRIOR OF MONITORING GROUPS OF NETWORK NODES FIELD OF THE INVENTION
The present invention relates to a controller for controlling a plurality of network nodes such as routers in a network and to a method of controlling a plurality of network nodes in a network and in particular but not exclusively to a wireless network.
BACKGROUND OF THE INVENTION
A diverse range of communication systems are in use today enabling communication between two or more entities, such as user equipment and/or other nodes associated with the system.
In the last few years the Internet has seen a rapid growth so that the Internet has become one of the single most important tools for communication. Along with the growth of the Internet the need for quick and ready access to the Internet from any location has increased. Wireless broadband' networks have been proposed which make high performance Internet access possible. In particular, new wireless networks with wireless routers as network nodes on a mesh network basis emulate the topology and protocols of the Internet but are optimised for wireless highspeed data transmission. To provide a wireless broadband solution a wireless routing network has been developed. The key components of such a wireless routing network are routed mesh network architecture, wireless routers, a wireless operating system and the deployment and management of the network.
Routed mesh networks mirror the structure of the wired Internet. Each radio transceiver at a node in the wireless network becomes part of the infrastructure and can route data through the wireless mesh network to its destination just as in the wired Internet. The advantage of such a routed mesh networks is that line-of-sight problems can be reduced in comparison to a client/base station architecture because each node only needs line-of-sight to one other node in the network and not all the way to the ultimate destination of the data traffic, e.g. the point-of-presence (POP) . With such an infrastructure the reach and coverage of the wireless network is extended with a minimal amount of wireless network infrastructure and interconnection costs. The data traffic can be routed around obstructions rather than needing to deploy additional base stations for line-of-sight in densely populated diverse geographical locations. The more wireless routers are added to the network, the more robust and far-reaching the network becomes. In the above mentioned wireless routing network, wireless routers with omni-directional antennas are used as a network node. Each wireless router can communicate with other nodes, i.e. other wireless routers in any direction. The omni-directional antennas offer a 360 -degree range and do not require precise pointing or steering. Therefore additional wireless routers can be added in an ad hoc and incremental fashion.
The wireless routers substantially comprise three components, namely a full TCP/IP (Transmission Control Protocol / Internet Protocol) protocol suite support, a wireless operating system that optimises the wireless network performance and robustness, and a high-performance digital RF modem. A specialized wireless networking software in combination with the high-performance RF modem optimises the network performance while ensuring full IP support and robust and stream-less IP routing.
Routed wireless mesh networks deploy specialized protocols, that operate efficiently in a multi-hop wireless network environment. From the media access control (MAC) layer through to the routing layer protocols are used that are specifically designed to deal with their unique attributes . The protocol suite extends the traditional TCP/IP stack to provide efficient and robust IP-based networking in multi-hop wireless mesh networks. These protocols consist of four parts, namely channel access protocols, reliable link and neighbour management protocols, wireless multi-hop routing and multicast protocols, and standard Internet protocols.
In the channel access, protocols are used to efficiently schedule transmissions to avoid collisions and efficiently reuse the available spectrum. Reliable link and neighbor management protocols ensure reliable transmissions on a hop-by-hop basis, and manage the automatic adaptation to changes in the network topology by monitoring the status of neighbor links. The role of the reliable link and neighbor management protocols is to perform network synchronization and to manage the links to each neighbor node. Wireless multi-hop routing and multicast protocols maintain performance-optimized routing tables and enable an efficient multicast capability. The standard Internet protocols and tools are used for seamless integration with the wired Internet. The protocols and tools are for example TCP/IP, UDP (User Datagram Protocol) , SNMP (Simple Network Management Protocol) , RIP, ICMP (Internet Control Message Protocol) , TFTP, ARP, IGMP, Proxy-ARP, DHCP relay (Dynamic Host Configuration Protocol) , DHCP server, and NAT (Network Address Translation) .
Wireless mesh networks based on a multipoint-to-multipoint architecture make an ad hoc integration of new nodes, i.e. wireless routers, easier since the actual demand and traffic flow in such a wireless network environment makes it much easier to adjust the coverage and bandwidth needs than design a network ahead of time. Adaptive routed mesh network make obstructions to the line-of-sight by growing trees or temporary obstructions less problematic, since the data traffic is automatically re-routed through as a link becomes unavailable. The nodes, i.e. wireless routers, in such a wireless routing network environment can adapt to changes in the link availability and the quality in real-time without requiring intervention by a network administrator. Regardless of whether the communication network is a wired or wireless network, the network should be monitored continuously so that the operator can have an overview of the general status of the network and its potentially problematic parts. In particular, if a network is not properly monitored, problems with loading of nodes can occur. Overloading can result in a poor service. Additionally, if a faulty node is not identified or the nature of its fault is not properly identified, this could have an adverse impact on the network. This is a particular problem with large networks, such as telecommunication networks, regardless of the standard used in those communication networks.
Defining and changing monitoring schemes of certain network nodes requires human intervention, which is time consuming and, as with all human operations, inherently error-prone. When there are a great number of nodes (for example routers) that need attention, it is easy to miss some of them or introduce errors because of mistyped user input.
In a known approach, fixed monitoring group assignment is used. If, for example, there are a great number of routers that need to be reconfigured in a batch to use a newer version of their operating system software, they have to be manually registered in a corresponding monitoring group that is aware of the different needs of the new software version. Further problems with this manual re-registration may occur if a different kind of polling is required.
If the operator wanted to avoid this manual assignation phase, the monitoring software had to be scriptable so that some external tool could generate the necessary updating script commands .
In another known approach, different monitoring groups have to be defined on different management computers (called for example Collection Stations in HP OpenView) . On one given management station the polling timings, for example, are global. This is inflexible.
SUMMMARY OF THE INVENTION
It is an aim of embodiments of the present invention to address the problems discussed about.
According to one aspect of the invention, there is provided a controller for controlling a plurality of network nodes in a communications network, said controller being arranged to define a group of network nodes to be monitored based on a value of one or more attributes of said network nodes .
According to a second aspect of the invention, there is provided a communications system comprising a plurality of network nodes in a communications network, and a controller, said controller being arranged to define a group of network nodes to be monitored based on a value of one or more attributes of said network nodes .
According to a third aspect of the invention, there is provided a method for monitoring a plurality of network nodes in a communications network, said method comprising the step of: defining a group of network nodes to be monitored based on one or more attributes of said network nodes
Embodiments of the present invention may be simple, cost- efficient, and robust and can handle large networks (e.g. thousands of routers or network elements) .
BRIEF DESCRIPTION OF EMBODIMENTS OF THE PRESENT INVENTION
For a better understanding of the present invention and as to how the same may be carried into effect, reference will now be made by way of example only to the accompanying drawings in which: Figure 1 shows a routing network with which embodiments of the present invention can be used;
Figure 2, shows the entities to which the routing network of Figure 1 is attached;
Figure 3 shows schematically a flow diagram of embodiments of the present invention; and
Figure 4 shows schematically the management engine of Figure 2.
DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION
Embodiments of the present invention are particularly applicable to wireless communication networks or systems. Fig. 1 shows a schematic representation of the wireless network with a plurality of network nodes 10. Each network node 10 is connected to neighbouring network nodes 10 via a multipoint-to-multipoint line-of-sight connection 15 by which the network nodes 10 communicate with each other. The wireless network comprise a Point-of-Presence POP 50 by which the wireless network is connected to the Internet or any other network. Into this wireless network with its existing network nodes 10 additional nodes 20, 30 are to be added.
Reference is made to Figure 2 which shows the network 2 connected to a RMS (router management system) management engine 9 via a connection in accordance with a NetJazz Protocol. The NetJazz protocol is a proprietary protocol developed by Nokia for use with their wireless mesh networks. The RMS engine 9 is arranged to monitor the network so that the operator can have an overview of the general status of the network and its potentially problematic parts. The RMS management engine is part of the management system for the wireless mesh network. It collects data from the wireless routers. It also translates alarms into SNMP traps that can be viewed with any umbrella management system that supports SNMP. With a single RMS management engine it is possible to continuously monitor large wireless router networks, generate alarms and collect performance data. Of course some embodiments of the invention may have more than one RMS management engine.
The RMS engine 9 may be optionally connected to a SNMP manager 40 such as HP (Hewlett Packard) OpenView products.
In the preferred embodiment the RMS engine is connected to a database 42 such as an ORACLE or MySQL database.
Reference is now made to Figure 4 which shows the main modules of the RMS management engine 9. The RMS management engine 9 comprises an alarm monitor 22, a group manager 24 and a monitoring engine 26. The alarm monitor 22 is connected to the database engine 11 and it may be connected to an SNMP Manager system 8. The Group manager 24 is connected to the alarm monitor 22, the database engine 11 and the monitoring engine 26. In particular, the group manager 24 is arranged to send monitoring parameters to the monitoring engine 26 and to receive network monitoring data from the monitoring engine 26. The monitoring engine 26 is additionally arranged to be connected to the routing network 2. The monitoring engine 26 is responsible for monitoring network elements 10, implementing the actual monitoring protocol. The group manager 24 is responsible for maintaining the membership of monitoring groups 25 runtime depending on the received network element attributes. The alarm monitor 22 generates SNMP traps, this functionality depends on the actual monitoring groups 25 because the groups can have different alarm situations defined. The database engine 11 simply performs the database operations.
The RMS management engine 9 monitors the router network 2 by sending probes from the monitoring engine 26 to the network 2 and receiving reports from routers or network elements. The collected data is stored in the database 11. The RMS management engine examines the reports. It may apply e.g. fault detection criteria, leading to SNMP traps indicating detected faults as alarms. The list of collected alarms (traps) can be viewed through an SNMP manager 8 (after they have been relayed to the SNMP manager by the RMS management engine 9) .
Monitoring parameters specify the performance and alarm monitoring frequency and data that is collected from the wireless router network. Node parameters relate to nodes e.g. routers in that particular network, while link parameters relate to connections between different nodes.
In the preferred embodiment routers have different 'roles' and their role can be configured on the fly by changing some operational parameters. These roles can be for example 'mesh gateway' and 'subscriber router'. Additional roles can be defined by the users via the filter expressions determining the group membership, like "low traffic routers", "experimental hardware version", "potentially faulty routers", etc. Any meaningful combination of status attribute value ranges can denote a particular "role" . The roles determine the needed frequency of probing by the RMS management engine 9 for each router.
In the responses to the probes from the RMS management engine 9, the routers report a subset of their operational attributes. The routers report to the RMS management engine 9. Depending on these values, a given router may need special attention and a different probing scheme may be required. A given router may be able to play two or more different roles either at the same time or at different time. The frequency of the probing, the alarm handling, and the required attributes may be changed. This will be described in more detail hereinafter. The large number of routers in a network also requires an intelligent strategy for determining when a particular router should be probed to prevent network congestion and loss of status report data caused by big bursts of responses to probes. This can be achieved by the RMS management engine 9 applying different monitoring schemes to different parts of the network.
The RMS management engine is provided to deal with the fact that the statuses of the routers may change quickly. The RMS management engine is arranged to deal with a large number of routers in a network without the operator handling each network node one by one. Instead, the RMS management node 9 is arranged to apply general rules defined by the operator. These rules can be applied to a set of nodes at a time. Filtering rules are evaluated dynamically to determine if a given entity belongs to a monitoring group.
The RMS management engine 9 is arranged to change its monitoring behavior depending on the values of router status attributes and a set of strategy definitions that consist of Boolean filter expressions on the domain of the status attributes evaluated during monitoring of every router. In preferred embodiments of the present invention, the RMS management engine is arranged to control the following aspects of monitoring:
1. Supervised and logged status attributes of the wireless routers, [0] for example, traffic flowing through the router, uptime, software/hardware version.
2. Timing parameters of the polling of the routers
3. Threshold values for alarm generation based on the status of the routers - For example:
1. There are at least X routers in the network that have not responded in the last Y minutes. 2. A Mesh Gateway has not responded within the last X minutes . 3. A router has more than X neighbours .
The RMS management engine can be tuned by editing a configuration file.
This file contains, among other settings, the group definitions (name, filtering expressions and the overridden monitoring parameters mentioned above) used by the management engine.
When the application starts, it reads the definitions and sets up the monitoring groups. Then, before each polling cycle, it evaluates the group filters for each router, determines the group to which the router belong based on the filtering results and polls the elements of those groups that are eligible for polling at the given time.
In embodiments of the invention, rules are defined that are evaluated dynamically to determine if a given entity belongs to a supervision group. This contrasts which previously proposed solutions which statically assign group attributes to the entities .
Embodiments of the present invention allow the operator to define a new monitoring group e.g. based on the value of the status attribute containing the operating system (OS) version of the nodes. From that point on, whenever a node's OS is upgraded, the filter of the newly defined group automatically recognizes it and the device is handled according to the operating rules given in the group definition.
In one embodiment of the present invention, the network can be logically partitioned into e.g. 'important' and 'ordinary' nodes. The 'important' nodes then can be polled much more frequently, with requests for more detailed status reports while the 'ordinary' ones are allowed to report only basic data with a lower frequency. This can significantly reduce the management- related traffic on the network. Embodiments of the present invention can for example collect automatically more data from faulty nodes than nodes which are running without problems. Embodiments of the invention may save network and management , engine resources . The RMS management engine adjusts automatically to changes.
With the RMS management engine routers and their roles can be configured on the fly by changing their parameters. These roles are used for example to determine a needed frequency of probing. In responses to the probes, the routers report a subset of their operational attributes. Depending on these values, they might need special attention and a different probing scheme (e.g. frequency, alarm handling, required attributes) . To prevent network congestion due to probing large number of routers in the network, an intelligent strategy is used. This is achieved by applying different monitoring schemes to different parts of the network. The RMS management engine thus changes its monitoring behavior depending on the values of router status attributes and a set of strategy definitions.
Embodiments of the invention have the advantage that there is dynamic behaviour in the monitoring logic in the RMS management engine. It introduces some intelligence to the system, so that it becomes adaptive to a constantly changing network environment. For example: in one embodiment, the RMS management engine can poll those clusters of the network more frequently (e.g. every 5 minutes) where the routers were reset more than 10 times during the last week. The target group may change all the time.
There is no need for data exchange between the management software and any external tools to achieve this result.
In summary, embodiments of the present invention may result in no need for external data exchange interfaces to any kind of helper applications. Embodiments of the invention may result in no need for: scripting facilities; distributed hardware and software elements; and/or regular user intervention related to massive status changes .
Each router is arranged to handle group filter expressions.
The operational description is as follows:
The user edits the configuration of the RMS management engine. This is done by editing an XML file with a text editor. XML - extensible Markup Language - is a widely used standard to exchange structured data in textual format Alternatively, any XML editor can be used as the DTD (Document Type Definition - a descriptor file that defines valid XML tags in a certain XML file) of the configuration file is shipped with the product.
The configuration settings for polling, status logging and alarm handling are defined in their corresponding XML tags and their attributes .
The group definitions are given in <group> elements. Their name, filtering expressions and the redefinitions of polling, status logging and alarm handling parameters have to be specified. The mentioned parameters have to be defined on the general 'top level', and they can have different values in each management group .
If a certain parameter is not redefined in a group, the value is inherited from the default configuration.
XML documents are used to define structured data and is well known to the man skilled in the art. An XML document contains elements which hold actual data. Each element has some attributes with their values, and can have also sub-elements (elements) . The element names are written between '<• and ' >' characters. When an element has attributes the closing ' >' has to be typed after the attribute list. The elements must be closed with a special ending: "</elementname>" where "elementname" is the name of the element .
Example :
<myelement myattribl="myvaluel" myattrib2="myvalue2 ">
<mysubelement mysubelemAttrib="5"/> </myelement>
In this example <mysubelement> should be closed by a </mysubelement> . Instead because it has no sub elements, the end of the element can be signed by the "/" before the closing '>' .
The filtering expressions can use the following XML tags:
Figure imgf000014_0001
does not exceed 10] AND [they are 1 hop away from their mesh gateway] . This will now be explained - Group definition in XML file:
The membership of a router can be described as a sentence in Boolean logic. Say every router is a member whose attribute 0x8f04 (this is a hexadecimal number) equals zero AND attribute 0x0601 is less than or equal to 10 AND attribute 0x1101 is equal to 1. (Note: Term 'attribute' here refers to a NetJazz protocol (NJP) attribute as the used hexadecimal constants are from NJP. Embodiments of the invention would work with any implementation where the attributes in question can be addressed with symbolic identifiers) .
This sentence contains 3 sub-conditions connected with "AND", so on the upper level the <all> element is used. This means that the examined router is a member only if _all_ the three sub-conditions are satisfied. The first sub-condition is that the router's attribute number 0x8f04 equals to 0. This is coded with the <equal> element: <equal value="0">
<netjazz_attribute type="node" id=" 0x8f04 "/> </equal>
The second condition is that the router's attribute number 0x0601 is less than or equal to 10. See the coded version: <less_than_or_equal value= " 10 " >
<netjazz_attribute type="node" id=" 0x0601"/> </less_than_or_equal> etc .
The three sub-condition can be wrapped in only one condition using the <all> element (with the meaning of Boolean *and*) : <all>
Figure imgf000016_0001
negative definition can be used (e.g. the members are routers whose attribute 0x1101 is NOT equal to 1) . So the members can report either 0 or 8 or 13 or anything but 1 as value of attribute 0x11,01. This can be coded like: <not>
<equal value="l">
<netjazz_attribute type="node" id="0xll01"/>
</equal> </not>
<true> Boolean constant. Its value is always true. In the average case <true> and <false> tags may not be used, they are here for
1. To make the logical expression system complete.
2. To give a certain shortcut while testing different filtering expressions. For example, a complicated <all> element that is not needed in a given test run can be short-circuited by inserting a <false> tag as one of its sub-expressions . It will cause the expression all (false, expl, exp2,..., expN) to always fail, effectively 'commenting out' that part of the filter without the need to physically remove the expression.
<false> Boolean constant. Its value is always false.
Comparison operators :
Figure imgf000017_0001
Figure imgf000018_0001
Reference is made to Figure 3, which illustrates a method embodying the invention. In the first step SI, the application is started. After starting the RMS management engine, it parses in step S2 its configuration file and sets up the monitoring groups according to their XML definitions. The criteria of group membership are defined by the user by describing the filter expressions of the groups using the XML tags discussed above in the configuration file of the management engine. In one implementation, the attributes are the wireless mesh routers' attributes. Other implementations can use their relevant status descriptors. The emphasis is not on the mode of describing the expressions but on the fact that these expressions are repeatedly evaluated during run-time of the management engine and the routers are enrolled in /removed from their respective groups based on the result of these filtering expressions.
The corresponding monitoring, attribute logging and alarm handling parameters are stored with the groups.
The monitoring parameters define the frequency for polling a given router or the like. Examples of this are
- frequency of polling
- frequency of calculating the set of routers that would be polled in next polling cycle
- link timeout threshold
The groups, may redefine not only the monitoring parameters but the logging details and the alarm handling as well.
The attribute parameters define those parameters which should be reported back to the RMS management engine and can include NetJazz attributes that can be reported by the routers or in alternative embodiments of the invention any relevant attribute that can be reported. The alarm handling parameters define how the router should be dealt with in the event that the router has an alarm condition. The groups can redefine the alarm conditions. For example in general a certain node is allowed to carry a given amount of traffic for say 10 minutes before being reported. This can be redefined so that this is redefined for mesh gateways to 20 minutes as gateways carry more traffic than ordinary routers.
In step S3, management engine examines all groups' polling- related parameters and computes their greatest common divisor. For example if one group has a polling time of 10 minutes, another group has a polling time of 60 minutes and the third group have a polling time of 100 minutes, the greatest common time is 10 minutes. This common value will be used as the polling clock's time tick. Whenever a tick happens the groups whose polling time has arrived collect their nodes by evaluating the group filters against the routers' attributes and poll the routers. Thus, every time a tick arrives, the first group is polled with the second group being polled every 6 ticks and the third group being polled every 10 ticks. After having probed the routers, the engine sleeps until the next tick arrives.
It should be appreciated that the above polling times are by way of example only and in practice can be longer or shorter than those. The polling frequency is a function of the network size. The larger the network, the smaller the frequency should be to avoid overloading the management engine. These times can be different in each group.
At this point, that is when the next tick arrives, the polling cycle starts again.
As answers come from the polled routers, they are parsed in step S4 and the corresponding router's attributes are updated in step S5.
After this step, the alarm-monitoring phase examines the routers' state and acts as necessary in step S6. The different groups can have different alarm threshold settings, which allow a fine-tuned setup for alarm supervision. An alternative form of implementation could use separate threads for each monitoring group with their own polling timer instead of having one running with the greatest common denominator of the specified polling intervals. This would allow handling more routers at a cost of increased complexity of the software due to the necessary locking to control inter-thread data flow.
The preferred embodiments of the invention have been described in the context of a Nokia wireless mesh system using NetJazz protocol . It should be appreciated that firstly, embodiments of the invention can be used with any other protocol. Secondly, the invention can be implemented in any network regardless of its type where there is a plurality of routers or network elements. The network can be any type of communications network and the network can be wired, wireless or a combination thereof.
In alternative embodiments of the invention, other elements maybe alternatively or additionally monitored instead of or as well as routers .
Embodiments of the invention can be generalized to any situations where a large number of entities have to be supervised and their handling has to be different based on the results of polling as long as their status attributes can be addressed by symbolic identities .
Embodiments of the present invention have been described in the context of a wireless communications network. However it should be appreciated that embodiments of the present invention can be used in any other network or system having a number of routers or elements requiring managements. For example embodiments of the present invention can be used in a wired system.
In preferred embodiments of the present invention, each network may have its own RMS management engine. However in some embodiments of the invention, a network may have more than one RMS management engine. The RMS management engines may operate independently or may be in communication. In some embodiments of the present invention, a single RMS management engine may serve more than one network.
In preferred embodiments of the invention, the RMS management engine is provided by a single entity. In alternative embodiments of the present invention, the functionality of the RMS management engine may be provided in a distributed manner.

Claims

1. A controller for controlling a plurality of network nodes in a communications network, said controller being arranged to define a group of network nodes to be monitored based on a value of one or more attributes of said network nodes .
2. A controller as claimed in claim 1, wherein a plurality of groups of network nodes to be monitored are provided, at least two of said groups having at least one different value of one or more attributes .
3. A controller as claimed in claim 1 or 2 , wherein said network node is a router and said communications network is a routing network.
4. A controller as claimed in claim 3, wherein said router is a wireless router and said communications network is a wireless routing network.
5. A controller as claimed in any preceding claim, wherein the value of at least one or more attributes is used to define a group based on: software version used by said network node; function of said network node; amount of traffic through said network node; potentially faulty network node; and experimental network nodes .
6. A controller as claimed in any preceding claim, wherein said controller is arranged to apply different monitoring schemes to different parts of said network.
7. A controller as claimed in any preceding claim, wherein said controller is arranged to apply different monitoring schemes to different groups of network nodes.
8. A controller as claimed in any preceding claim, wherein at least two groups of network nodes are provided with one group of network nodes providing a first function and one group of network nodes providing a second different function.
9. A controller as claimed in claim 8, wherein said first function comprises a gateway function.
10. A controller as claimed in claim 8 or 9, wherein said second function comprises a subscriber router function.
11. A controller as claimed in any preceding claim, wherein said controller is arranged to collect performance data from said network.
12. A controller as claimed in any preceding claim, wherein said controller is arranged to define at least one of:
Performance parameters of said network nodes to be monitored;
Alarm monitoring frequency; and
Data to be collected from said network nodes.
13. A controller as claimed in any preceding claim, wherein said controller is arranged to generate alarms.
14. A controller as claimed in claim 12 or 13, wherein said controller is arranged to translate alarms into traps.
15. A controller as claimed in claim 14, wherein said traps comprise SNMP traps.
16. A controller as claimed in claim 14 or 15, wherein said controller is connected to a management system which views said traps .
17. A controller as claimed in any preceding claim, wherein said controller is arranged to send probes to said network nodes.
18. A controller as claimed in any preceding claim, wherein said controller is arranged to receive data from said network nodes in response to said probes .
19. A controller as claimed in any preceding claim, wherein said controller is connected to a database which stores network node data.
20. A controller as claimed in any preceding claim, wherein the controller is arranged to control timing parameters relating to the polling of the network nodes.
21. A controller as claimed in any preceding claim, wherein said controller is arranged to control threshold values for alarm generation based on the status of the network nodes.
22. A controller as claimed in any preceding claim, wherein said controller is arranged to carry out a plurality of polling cycles with respect to said network nodes .
23. A controller as claimed in claim 22, wherein before each polling cycle, the controller is arranged to determine which network node belongs to which group and to poll the network nodes of at least one group eligible for polling in a respective polling cycle.
24. A controller as claimed in claim 23, where each network node has associated therewith at least one attribute, said controller determining to which at least one group said network node belongs based on the value of said at least one attribute.
25. A controller for controlling a plurality of routers in a communications network, said controller being arranged to monitor a plurality of routers, wherein the monitoring behaviour of said controller is determined by a value of one or more attributes of said routers .
26. A communications system comprising a plurality of network nodes in a communications network, and a controller, said controller being arranged to define a group of network nodes to be monitored based on a value of one or more attributes of said network nodes .
27. A system as claimed in claim 26, comprising a database for storing monitored parameters of said nodes.
28. A method for monitoring a plurality of network nodes in a communications network, said method comprising the step of: defining a group of network nodes to be monitored based on one or more attributes of said network nodes.
29. A method as claimed in claim 28, comprising the step of: carrying out a plurality of polling cycles with respect to said network nodes .
30. A method as claimed in claim 29, comprising the step: determining which group or groups of network nodes are to be polled in a given polling cycle.
31. A method as claimed in claim 29 or 30, comprising the step of: determining before each polling cycle which network nodes belong to a group to be polled in the respective polling cycle.
32. A method as claimed in claim 29, 30 or 31, comprising the step of : changing the value of at least one attribute of at least one network node to thereby change one of more groups to which said network node belongs .
33. A method as claimed in claim 29 or any claim appended thereto, wherein a network node is able to belong to a plurality of groups .
PCT/IB2004/000187 2003-01-31 2004-01-28 Determination of groupmembers prior of monitoring groups of network nodes WO2004068786A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP04705858A EP1588521A1 (en) 2003-01-31 2004-01-28 Determination of groupmembers prior of monitoring groups of network nodes

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US44384403P 2003-01-31 2003-01-31
US60/443,844 2003-01-31

Publications (1)

Publication Number Publication Date
WO2004068786A1 true WO2004068786A1 (en) 2004-08-12

Family

ID=32825382

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2004/000187 WO2004068786A1 (en) 2003-01-31 2004-01-28 Determination of groupmembers prior of monitoring groups of network nodes

Country Status (5)

Country Link
US (1) US20040151129A1 (en)
EP (1) EP1588521A1 (en)
KR (1) KR20050104364A (en)
CN (1) CN1833404A (en)
WO (1) WO2004068786A1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1641184A1 (en) * 2004-09-24 2006-03-29 Microsoft Corporation Method for accessing a WLAN by establishing an ad-hoc network with a wireless connected device
WO2007096287A1 (en) * 2006-02-27 2007-08-30 International Business Machines Corporation Apparatus, system, and method for dynamically determining a set of storage area network components for performance monitoring
US7317914B2 (en) 2004-09-24 2008-01-08 Microsoft Corporation Collaboratively locating disconnected clients and rogue access points in a wireless network
WO2008058263A3 (en) * 2006-11-08 2008-08-21 Univ California Complex network mapping
US7603460B2 (en) 2004-09-24 2009-10-13 Microsoft Corporation Detecting and diagnosing performance problems in a wireless network through neighbor collaboration
WO2011004133A2 (en) 2009-07-10 2011-01-13 L'oreal Composite material comprising uv filters and plasmonic particles, and use as sun screen

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7844729B1 (en) 1999-05-03 2010-11-30 Digital Envoy, Inc. Geo-intelligent traffic manager
US20060224752A1 (en) * 1999-05-03 2006-10-05 Parekh Sanjay M Determining geographic locations of private network Internet users
US7685311B2 (en) * 1999-05-03 2010-03-23 Digital Envoy, Inc. Geo-intelligent traffic reporter
US6757740B1 (en) * 1999-05-03 2004-06-29 Digital Envoy, Inc. Systems and methods for determining collecting and using geographic locations of internet users
HUE025509T2 (en) * 2002-04-19 2016-02-29 Linak As A drive unit, preferably an actuator, a control and a construction
US7583648B2 (en) * 2003-05-08 2009-09-01 Meshdynamics, Inc. Managing latency and jitter on wireless LANs
US20060146820A1 (en) * 2002-11-26 2006-07-06 Robert Friedman Geo-intelligent traffic manager
US8031630B2 (en) * 2003-03-03 2011-10-04 Alcatel Lucent Method and apparatus for updating provider domain due to customer TCNs
US7613105B2 (en) * 2004-01-30 2009-11-03 Microsoft Corporation Methods and systems for removing data inconsistencies for a network simulation
US7583587B2 (en) * 2004-01-30 2009-09-01 Microsoft Corporation Fault detection and diagnosis
US7606165B2 (en) 2004-01-30 2009-10-20 Microsoft Corporation What-if analysis for network diagnostics
US20080049012A1 (en) * 2004-06-13 2008-02-28 Ittai Bar-Joseph 3D Line-of-Sight (Los) Visualization in User Interactive 3D Virtual Reality Environments
US7480837B2 (en) * 2005-06-01 2009-01-20 Freescale Semiconductor, Inc. Method of monitoring timeout conditions and device therefor
CA2559142A1 (en) 2005-09-12 2007-03-12 Acuity Brands, Inc. Light management system having networked intelligent luminaire managers with enhanced diagnostics capabilities
US7817063B2 (en) 2005-10-05 2010-10-19 Abl Ip Holding Llc Method and system for remotely monitoring and controlling field devices with a street lamp elevated mesh network
US20080198754A1 (en) * 2007-02-20 2008-08-21 At&T Knowledge Ventures, Lp Method and system for testing a communication network
US8203968B2 (en) * 2007-12-19 2012-06-19 Solarwinds Worldwide, Llc Internet protocol service level agreement router auto-configuration
US8594976B2 (en) 2008-02-27 2013-11-26 Abl Ip Holding Llc System and method for streetlight monitoring diagnostics
US8443107B2 (en) 2009-11-11 2013-05-14 Digital Envoy, Inc. Method, computer program product and electronic device for hyper-local geo-targeting
US8832700B2 (en) 2010-09-29 2014-09-09 Microsoft Corporation Subscriber-based ticking model for platforms
US9647913B2 (en) * 2010-11-16 2017-05-09 Avago Technologies General Ip (Singapore) Pte. Ltd. Measuring and managing power usage and cooling in a network
US9693428B2 (en) 2014-10-15 2017-06-27 Abl Ip Holding Llc Lighting control with automated activation process
US9781814B2 (en) 2014-10-15 2017-10-03 Abl Ip Holding Llc Lighting control with integral dimming

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0849909A2 (en) * 1996-12-18 1998-06-24 Nortel Networks Corporation Communications network monitoring
US5796951A (en) * 1995-12-22 1998-08-18 Intel Corporation System for displaying information relating to a computer network including association devices with tasks performable on those devices
US6269398B1 (en) * 1993-08-20 2001-07-31 Nortel Networks Limited Method and system for monitoring remote routers in networks for available protocols and providing a graphical representation of information received from the routers
US6295527B1 (en) * 1998-02-13 2001-09-25 Cisco Technology, Inc. Real-time user-defined creation of network device information collections
US20020112051A1 (en) * 2000-12-15 2002-08-15 International Business Machines Corporation Method and system for network management with redundant monitoring and categorization of endpoints
EP1244248A1 (en) * 2001-03-21 2002-09-25 Lucent Technologies Inc. Method and apparatus for efficient reactive monitoring
US20020143929A1 (en) * 2000-12-07 2002-10-03 Maltz David A. Method and system for collection and storage of traffic data from heterogeneous network elements in a computer network

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5659787A (en) * 1995-05-26 1997-08-19 Sensormatic Electronics Corporation Data communication network with highly efficient polling procedure
US5787248A (en) * 1996-01-02 1998-07-28 Racal-Datacom, Inc. System for selecting network management protocol by setting protocol handler index based on newly selected protocol and selecting protocol handler address using protocol handler index
US6747957B1 (en) * 2000-04-28 2004-06-08 Cisco Technology, Inc. Network availability monitor
US6757269B2 (en) * 2001-02-27 2004-06-29 Motorola, Inc. Mobile wireless router
US6879574B2 (en) * 2002-06-24 2005-04-12 Nokia Corporation Mobile mesh Ad-Hoc networking

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6269398B1 (en) * 1993-08-20 2001-07-31 Nortel Networks Limited Method and system for monitoring remote routers in networks for available protocols and providing a graphical representation of information received from the routers
US5796951A (en) * 1995-12-22 1998-08-18 Intel Corporation System for displaying information relating to a computer network including association devices with tasks performable on those devices
EP0849909A2 (en) * 1996-12-18 1998-06-24 Nortel Networks Corporation Communications network monitoring
US6295527B1 (en) * 1998-02-13 2001-09-25 Cisco Technology, Inc. Real-time user-defined creation of network device information collections
US20020143929A1 (en) * 2000-12-07 2002-10-03 Maltz David A. Method and system for collection and storage of traffic data from heterogeneous network elements in a computer network
US20020112051A1 (en) * 2000-12-15 2002-08-15 International Business Machines Corporation Method and system for network management with redundant monitoring and categorization of endpoints
EP1244248A1 (en) * 2001-03-21 2002-09-25 Lucent Technologies Inc. Method and apparatus for efficient reactive monitoring

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"IBM NETWIEW/6000 IM VERGLEICH ZU HP OPEN VIEW. SOLID PLATTFORMEN", NACHRICHTEN ELEKTRONIK UND TELEMATIK, VERLAG DR. HUETHIG. HEIDELBERG, DE, vol. 48, no. 10, 1 October 1994 (1994-10-01), pages 44 - 46, XP000468302, ISSN: 0177-5499 *
GARG A R ET AL: "DEVELOPING A DISTRIBUTED NETWORK MANAGEMENT APPLICATION USING HP OPEN VIEW WINDOWS", HEWLETT-PACKARD JOURNAL, HEWLETT-PACKARD CO. PALO ALTO, US, vol. 41, no. 2, 1 April 1990 (1990-04-01), pages 85 - 91, XP000116179 *
HURST M S: "HP OPEN VIEW DATA LINE MONITOR", HEWLETT-PACKARD JOURNAL, HEWLETT-PACKARD CO. PALO ALTO, US, vol. 41, no. 2, 1 April 1990 (1990-04-01), pages 71 - 75, XP000116177 *
SMITH C J ET AL: "HP OPENVIEW WINDOWS: A USER INTERFACE FOR NETWORK MANAGEMENT SOLUTIONS", HEWLETT-PACKARD JOURNAL, HEWLETT-PACKARD CO. PALO ALTO, US, vol. 41, no. 2, April 1990 (1990-04-01), pages 60 - 65, XP009006768 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1641184A1 (en) * 2004-09-24 2006-03-29 Microsoft Corporation Method for accessing a WLAN by establishing an ad-hoc network with a wireless connected device
US7317914B2 (en) 2004-09-24 2008-01-08 Microsoft Corporation Collaboratively locating disconnected clients and rogue access points in a wireless network
US7603460B2 (en) 2004-09-24 2009-10-13 Microsoft Corporation Detecting and diagnosing performance problems in a wireless network through neighbor collaboration
US7760654B2 (en) 2004-09-24 2010-07-20 Microsoft Corporation Using a connected wireless computer as a conduit for a disconnected wireless computer
US8086227B2 (en) 2004-09-24 2011-12-27 Microsoft Corporation Collaboratively locating disconnected clients and rogue access points in a wireless network
WO2007096287A1 (en) * 2006-02-27 2007-08-30 International Business Machines Corporation Apparatus, system, and method for dynamically determining a set of storage area network components for performance monitoring
US7680926B2 (en) 2006-02-27 2010-03-16 International Business Machines Corporation Apparatus, system, and method for dynamically determining a set of storage area network components for performance monitoring
WO2008058263A3 (en) * 2006-11-08 2008-08-21 Univ California Complex network mapping
WO2011004133A2 (en) 2009-07-10 2011-01-13 L'oreal Composite material comprising uv filters and plasmonic particles, and use as sun screen

Also Published As

Publication number Publication date
KR20050104364A (en) 2005-11-02
US20040151129A1 (en) 2004-08-05
EP1588521A1 (en) 2005-10-26
CN1833404A (en) 2006-09-13

Similar Documents

Publication Publication Date Title
US20040151129A1 (en) Controller for controlling routers
US6611863B1 (en) Automatic device assignment through programmable device discovery for policy based network management
US7263552B2 (en) Method and apparatus for discovering network topology
US7548540B2 (en) Dynamic discovery of ISO layer-2 topology
US6275853B1 (en) System and method for extending communications features using generic management information base objects
Prehofer et al. Self-organization in communication networks: principles and design paradigms
EP1393503B1 (en) Method and system for determining network characteristics using routing protocols
US20020161883A1 (en) System and method for collecting, aggregating, and coalescing network discovery data
US6795403B1 (en) Automatic discovery of switch devices in a network
CA2457718C (en) Using link state information to discover ip network topology
KR100793530B1 (en) Using link state information to discover ip network topology
US7116643B2 (en) Method and system for data in a collection and route discovery communication network
CN102480759B (en) Network-management realizing method and system on basis of fit wireless access point architecture
US20050047350A1 (en) Apparatus and methods for discovery of network elements in a network
US10819659B2 (en) Direct replying actions in SDN switches
US20030167319A1 (en) Performance of lifetest using CMTS as a proxy
EP1695482B1 (en) Centralized configuration of link-scope-type managed objects in internet protocol (ip)-based networks
US6931441B1 (en) Method and apparatus for managing a network using link state information
CN113193975B (en) Controller device, method and computer readable storage medium
US20050120099A1 (en) Configuration management device for a self-configurable network equipment of a communication network provided with equipment configuration parameter consistency analysis module
Cisco Overview
Cisco Overview
Cisco Overview
Cisco Overview
CN114531392A (en) Multicast service design method, server and storage medium

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2004705858

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 1020057014110

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 20048040060

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2004705858

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1020057014110

Country of ref document: KR