A network element is usually defined as a manageable logical entity uniting one or more physical devices. This allows distributed devices to be managed in a unified way using one management system. According to the Telecommunications Act of 1996, the term 'network element' means a facility or equipment used in the provision of a telecommunications service. Such term also includes features, functions, and capabilities that are provided by means of such facility or equipment, including subscriber numbers, databases, signaling systems, and information sufficient for billing and collection or used in the transmission, routing, or other provision of a telecommunications service.
With development of distributed networks, network management had become an annoyance for administration staff. It was hard to manage each device separately even if they were of the same vendor. Configuration overhead as well as misconfiguration possibility were quite high. A provisioning process for a basic service required complex configurations of numerous devices. It was also hard to store all network devices and connections in a plain list. Network structuring approach was a natural solution.
With structuring and grouping, it is very well seen that in any distributed network there are devices performing one complex function. At that, those devices can be placed in different location. A telephone exchange is the most typical example of such a distributed group of devices. It typically contains subscriber line units, line trunk units, switching matrix, CPU and remote hubs. A basic telephone service leans on all those units, so it is convenient for an engineer to manage a telephone exchange as one complex entity encompassing all those units inside.
Another good example of a network element is a computer cluster. A cluster can occupy a lot of space and may not fit one datacenter. For enterprise solutions, it is common to locate cluster nodes in different locations, even in different regions (settlements).
In general, an NE can generate two types of maintenance information:
- Information related to the quality or health of the transmission signal, and
- Information related to its own internal hardware/software integrity.
The functional components of surveillance are performance monitoring and alarm/status monitoring, also known as alarm surveillance. In the national and international standards area for telecommunications operations, performance monitoring and alarm surveillance are classified as subcategories of the more general system management functional categories of performance management and fault management, respectively. Maintenance consists of both preventive and corrective procedures that are designed to (a) prevent troubles and identify potential troubles before they affect service, and (b) detect a network failure that impacts performance and make the appropriate repair(s). A typical seven-step maintenance process consists of:
- Trouble Detection – Detect trouble by continuous monitoring, periodic tests, per-call or other pre-action tests, or other automatic processes.
- Trouble Notification – Send notification of a specific event or condition to a local display or Operations System (OS). Trouble notifications include output messages and visual and audible alarms.
- Service Recovery – Minimize the degradation of service by automatic or manual protection actions.
- Trouble Verification – Determine whether the reported condition still exists.
- Trouble Isolation – Isolate the trouble to its source, preferably to a single field-repairable element, e.g., circuit pack.
- Repair – Fix or replace the faulty element.
- Repair Verification and Return to Service – Verify that the trouble has been fixed and return the element to service.
Telcordia GR-474 establishes trouble-detecting and reporting criteria for signal transmission failures and internal hardware and/or software anomalies. GR-474 provides proposed generic requirements that pertain to the Fault and Performance Management functions in transport and switching Network Elements (NEs) used for alarm surveillance and control.
A network element state model facilitates cross domain network management and promotes a multi-vendor environment. The standard definitions and mappings allow Operations Systems to gather state information from NEs and integrate it into a consistent representation of the status of the entire managed network and each of the services that it supports.
Telcordia GR-1093 discusses the two primary state models in industry. One is the Telcordia State Model, which consolidates the state models previously described in several Telcordia documents. By consolidating the models, changes and expansions to the models can be presented and can evolve in a coordinated fashion. Also, inconsistencies and redundancy may be averted. The other model is the International Organization for Standardization (ISO) State Model, which is defined in ITU-T Recommendation X.731.
The state of an entity represents the current condition of availability of the underlying resource or service in the NE from the point of view of management. In the context of the Telcordia State Model, the term "entity" represents an entry in a TL1 administrative view (i.e., represents the resource or service generally identified by the Access Identifier [AID] parameter). In the context of the ISO State Model, the term "entity" means "managed object".
Different types of entities (such as hardware, transport facilities, and subscriber service) have a variety of state characteristics that express the availability of their underlying resources that are specific to each entity type. However, a state model is expected to be common to a large number of types of entities. It expresses key aspects of their availability at any given time. The purpose of the state model is to indicate the availability of an entity in providing its functions and, if an entity is not available, to indicate the cause of the unavailability and what kind of activity may be taken by the manager (e.g., the OS or the craft) to make the entity available.
In a specific application, only a subset of the state model may be needed. The rationale of such restrictions is not described in GR-1093. The technology or application-specific requirements document should be consulted for this information.
The standard definitions and mappings allow Operations Systems to gather state information from NEs and integrate it into a consistent representation of the status of the entire managed network and each of the services that it supports.
To help ensure interoperability, particularly for an OS that interfaces with multiple NEs using one of the two state models, a mapping between the models may be needed. GR-1093 provides a mapping for the two models and also defines the extension to the OSI state/status attributes that is necessary to meet the telecommunications needs of the service providers.