|
TL1
- Gateway Network Element
Gateway NE routes TL1 messages between OSS (or EMS/NMS) and ENEs (End Network Element - NE to which the TL1 commands are targeted).
GNE deployment scenarios
Systems such as SONET, SDH networks are deployed in a ring topology (UPSR-Unidirectional path switched ring / BLSR-Bidirectional Line Switch Ring). IDLC (Integrated Digital Loop Carrier) networks implement a linear topology. GNE functionality implemented in these networks is detailed in the following sections
Need for SONET GNE
In SONET networks, a TL1 command addressed to an NE may be required to traverse through intermediate NE(s) before arriving at the target ENE (end network element). A GNE serves as the gateway to forward commands to the target
ENE.
Figure 1.0
In some SONET environments, the
Data Communication Channel (DCC) is used for administrative and management operations. A command, sent through
DCC travels through multiple GNEs before reaching the target ENE.
Figure 2.0
IDLC networks require a dedicated
TCP/IP connections between NEs and the manager. Holding a dedicated
TCP/IP connection for every NE is not scalable. A GNE is used to
route messages between OSS (or EMS/NMS) and NEs.
For
security reasons, some NEs have restrictions on the number of "simultaneous
user sessions". While managing such elements, the management applications
and the craft operators face a "resource constraint problem" accentuated
by the user session restrictions. Installing a GNE and routing the
messages from multiple operators via the GNE solves this problem.
refer figure 3.0
Figure 3.0
Session Management with GNE
It is common to have restrictions on the number of "simultaneous
user sessions". While managing such NEs, the craft operators face
a "resource constraint problem" accentuated by the user session
restrictions. Installing a GNE and routing the messages from multiple
operators via the GNE solves this problem. refer figure 3.0
How GNE works
A gateway network element has the
ability to route information between NEs and the OSSs (or EMS/NMS).
It holds a persistent connection with the manager to enable message
routing. The TID in the input command helps GNE identify the target
NE. GNE maintains the list of TIDs of NEs connected to it. Whenever
GNE receives a TL1 input message, it routes the message to the appropriate
NE using the TID. The GNE will also route the autonomous messages
from the NEs to the OSS.
If the device is IP based, then the GNE opens up a TCP/IP connection,
sends the command, and then closes the TCP/IP connection. In a SONET
network the dedicated Embedded Operations Channel (EOC) is used.
GNE uses separate EOC commands such as ENT-EOCRE, ED-EOCRE, DLT-EOCRE,
RTRV-EOCRE (refer GR199) to add, delete, edit, and retrieve EOC
entries in the GNE table.
Some networks use multiple communication channels, such as TCP/IP
and X2.5. The routing entries for such channels will be different.
Hence, for every protocol TL1 commands similar to those of EOC commands
has to be implemented. This enables the GNE to route messages in
these channels over the specified protocol.
How
to configure a NE as GNE
The difference between an NE
and GNE lies in the agent that is installed in it. The agent should
have the capability to interpret the command and identify the target
NE. It should then send the command to the target NE, by establishing
a session. If the command is intended for the GNE itself, then it
should be capable of executing the command. For an NE to act as
a gateway NE, its agent should support the following.
- Routing table (TID, subtended NE details - eg. IP address and
port number)
- It should also implement TL1 Messages for manipulating routing
table
|
