Software intelligence in today's all-optical networks

Software intelligence is already well established within modern optical transmission networks. Its role is to remove the need for manual intervention at the lowest levels of network operation, thus reducing operational costs and decreasing the reaction time for critical events such as link failures.

For example:

• Software may already exist within your network to automatically perform inventory management on components or subsystems within a communications shelf.

• Software may already exist within your network to automatically manage power levels of all-optical line components between 3R regenerators (also known as optical span management).

• If you have SONET or SDH networks then there may be software running on the network elements that will allows services to be protected against link failure, or the failure of a switching unit.

Historically, however, this software tends to have been developed without any overall coordination of the various software functions. It tends to be based on proprietary protocols, and is usually limited in scope.

To make matters worse, the analog nature of all-optical networks is a real barrier to the efficient functionality of software intelligence. For example, if you cannot see digital information for most of the service path, then how can you monitor vital, but inherently digital parameters such as bit error rate? And if devices can't see bit error rates, how are they supposed to automatically initiate protection switching?

Extending the scope of ESI in all-optical network has not been a priority for most manufacturers because the complexity introduced in an all-analog system makes the task of software automation all but impossible. For example , just a few of the parameters that restoration software in an all-optical system would need to consider includes: optical losses on each wavelength; the number of channels in use and the impact that this will have on in-line amplifer performance; dispersion characteristics of the fiber in a given span; and the optical capabilities of a given transponder. Creating a stable routing protocols that has to take these, and many other metrics into consideration is simply impractical.

Back to Top >>