Network element
In computer networks, a network element is 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' refers to a facility or to
equipment used in the provision of a telecommunications service. This term also refers to features,
functions, and capabilities that are provided by means of such facility or equipment. This includes items
such as subscriber numbers, databases, signaling systems, and information that is sufficient for billing
and collection. Alternatively, it's also included if it's used in the transmission, routing, or other provision
of a telecommunications service.
Background
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.
Examples
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).
Maintenance
In general, an NE can generate two types of maintenance information:
1. Information related to the quality or health of the transmission signal, and
2. Information related todata 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 repairs. A typical seven-step maintenance process
consists of:
1. Trouble Detection – Detect trouble by continuous monitoring, periodic tests, per-call or
other pre-action tests, or other automatic processes.
2. 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.
3. Service Recovery – Minimize the degradation of service by automatic or manual
protection actions.
4. Trouble Verification – Determine whether the reported condition still exists.
5. Trouble Isolation – Isolate the trouble to its source, preferably to a single field-
repairable element, e.g., circuit pack.
6. Repair – Fix or replace the faulty element.
7. 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 or software anomalies. GR-474 provides proposed generic requirements that pertain to
the Fault and Performance Management functions in transport and switching NEs used for alarm
surveillance and control.[1]
GR-474 complements recent criteria in industry standards such as ITU-T Recommendation M.3100 (htt
p://[Link]/rec/T-REC-M.3100/en/), G.707 ([Link] and G.709 (htt
p://[Link]/rec/T-REC-G.709), and ANSI T1.
State models
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.[2] 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.[3]
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.
Telecommunications Management Network
A concept of the network element as a distributed entity is widely used in TMN model which in turn is
used as a standard for developing element management systems.
See also
Unbundled network element
References
1. GR-474, Network Maintenance: Alarm and Control for Network Elements ([Link]
[Link]/site-cgi/ido/[Link]?ID=SEARCH&DOCUMENT=GR-474&), Issue 2
2. GR-1093, Generic State Requirements for Network Elements (NEs), ([Link]
[Link]/site-cgi/ido/[Link]?ID=SEARCH&DOCUMENT=GR-1093&)
3. ITU-T Recommendation X.731 ([Link]
Retrieved from "[Link]
