Process for determining in service status

Electrical computers and digital processing systems: multicomput – Computer network managing

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C370S254000

Reexamination Certificate

active

06182132

ABSTRACT:

This invention relates to networked devices which act in concert with one another and give the appearance of a single device, an Orchestrated Entity, when interacting with devices which are not part of the Orchestrated Entity. More particularly, this invention relates to a process for the Orchestrated Entity to determine whether each device comprising part of the Orchestrated Entity can declare itself “In Service”.
BACKGROUND
With the growth of distributed operations in telecommunications and computing operations, there are now often collections of equipment and software, i.e., devices, which operate in concert with one another in providing some service to the larger telecommunications computing, or electrical or electro-mechanical system in which they reside.
This can be as simple as a CPU which accesses a database stored on a separate server in responding to a plurality of workstations or can consist of a more elaborate collection of equipment.
For example, in a computer environment, a group of computers may each act as a tasking station to provide information to a larger group of workstations. Each tasking station computer does not contain necessary databases populated with data to perform all the requested tasks to respond to the served workstations. Instead, when information from a database is required, the tasking station computer accesses a server which has the populated databases resident. The separation of server from tasking station allows efficient use of system resources. For example, the server can have greater memory and speed than the querying tasking stations. Moreover, more than a single server can be used to increase response time and to segregate specific types of data. Further, to assure the efficient utilization of all servers, several controllers can be used to monitor data requests from the tasking stations and direct and distribute the tasking stations' requests between all servers. In this example, communication between the servers and the tasking stations must be through the controllers. This interactive subset of system components, from the perspective of the remainder of the system, could just as well be a single piece of equipment. It is unimportant which workstation connects to which tasking station since each tasking station has the potential to provide the same results in response to a request from the workstation. This seamless collaboration of devices providing a service to the other resources in the system is referred to hereafter as an orchestrated entity (OE).
As long as the OE is fully functional, that is, each and every device making up the OE is functioning and the communication lines between the devices are operational, then the OE can properly serve the other system resources. However, should any device or communication line go down, there is the potential that the OE may not be able to adequately serve the other system resources. As examples, this may be because, in the case of a server, that pertinent database information cannot be accessed; in the case of a controller, that not all servers are accessible; and in the case of tasking stations, that requests from other system resources accessing the OE through that particular tasking station will not be recognized by the OE. On the other hand, OE's can be constructed to have a certain resilience against loss of one or more devices within the OE, being capable of operating without all devices operating.
The problem, then, is to determine whether the OE is sufficiently operational at any point in time to adequately provide the desired service to the other network resources. In conventional systems, this has been the task of a master device or master node which monitors the condition of each other device and communication channel. If a device or communication channel does not respond to the master node's direct polling, that device is declared “Out of Service”. Based on the master node's polling results, the master device then determines whether the OE, as a whole, is sufficiently operational to adequately provide the desired service to the other network resources and, if not, declares the OE “Out of Service” to the other network resources which must then either seek the service from alternative system resources or await the OE returning to “In Service” status.
The conventional approach to determining resource status for an OE suffers from several problems. First, the master node must be selected and connected to each device and line in the OE. Second, if the master node fails, the OE must be declared out of service because the status of other devices and lines in the OE cannot be otherwise determined.
There is therefor a need for an approach for determining whether devices in the OE are In Service and whether the OE is In Service without the use of a master polling device.
Solution
Each and Every Device Comprising Part of the OE determines OE Status for Itself.
This problem is solved and a major advance over the prior art is achieved by the instant invention which provides a distributed method for each device in an OE to self-diagnose whether the OE should be considered by that device In Service based that device, comprising part of OE, independently determining that sufficient other devices comprising the OE are operational that the device making the determination can declare itself In Service.
Conventional processor-based electronic equipment and software, i.e., devices, are capable of polling, that is, sending a signal through a communication line to another device, receiving a signal in response, and recognizing that responding signal. In one type of polling called “Echo” polling, the initiating device sends a signal which is simply returned by the polled devices. In a second type of polling, the initiating device sends a more complex signal, one which includes as part of the signal an identifier which identifies the initiating device, and the responding device likewise responds with a more complex signal, one which includes as part of the signal an identifier which identifies the responding device as part of the returned signal.
Both types of polling are used in providing device status to monitoring equipment.
The instant invention recognizes and implements a series of rules discovered by the inventors which, through device polling, permit the devices comprising the OE to self-diagnose OE status.
To simplify this discussion, a device which relays signals from an initiating device to a responding device is hereafter called a “hub”. An initiating device and a responding device are both called “nodes”. The pathway by which signals are sent between the nodes and hubs are called “lines”. Devices are said to “talk” to one another when an initiating signal results in a responding signal, regardless of the type of signal.
A Rule-Based Determination of Device Status
A. Simplistic Determination—“In Service” Permits Only Failure of One Hub
A node declares itself “In Service” if it passes either of the following tests:
Rule 1) if a node is able to talk to all hubs in the OE, then the node is “In Service”; or
Rule 2) if the node fails Rule 1, but the node can talk to all other nodes, then the node is “In Service”.
Otherwise, the node is “Out-of-Service”.
Referring to
FIG. 1
, an OE is illustrated which has two hubs, Hi and Hii, each connecting four Tasking Stations, TS
1
-TS
4
, to two Responding Devices, RDa and RDb. Consider RDa as the node of interest, consider further that hub Hi, which is normally capable of sending a return signal to RDa is not currently able to do so, and consider further still that all other hubs and nodes are capable of sending a return signal.
As a consequence of not being able to talk to Hi, RDa fails to be “In Service” under Rule 1 and must apply Rule 2 to determine its final status. Under Rule 2, in the particular configuration shown in
FIG. 1
, RDa connects through operational hub Hii to all other nodes, RDb and TS
1
-
4
; consequently, RDa will declare itself “In Service”.
Similarly considering every other node in
FIG. 1
against Rule 1 and

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Process for determining in service status does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Process for determining in service status, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Process for determining in service status will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2513164

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.