Liberating your OSS architecture

As the quest for ongoing cost cutting continues, carriers are looking for new ways to improve the efficiency of their network. However, balancing the need to migrate to new-generation operations support systems with the desire to extend the life of existing network elements can be a challenge. The massive cost-cutting measures that have been the norm in recent years can help maintain profitable margins in the short term, but these tactics cannot be sustained in the long run. Distributing operations support intelligence throughout the network can provide innovative solutions to many of these current challenges and a well-defined path to address future needs.

Improving the operating environment

Carriers can improve the efficiency of their OSS by either implementing a new OSS or by bringing more efficiency to the existing OSS. Unfortunately, there are numerous and significant obstacles to overcome on the road to deploying any new OSS such as costs, logistics, data porting, organizational barriers and evolving technology. With ongoing attention placed on spending, it is not surprising that many carriers are delaying the wholesale replacement of existing OSS systems. With this being the case, it is imperative that the network architecture enable ways to cost-effectively extend the life of the existing OSS.

Distributing the OSS to the edge of the network

There are distinct challenges facing carriers at each stage of an OSS lifespan--from initial deployment, to migration and eventual decommission. Given these challenges, what can be done to address the issues and mitigate costs? One method is to implement an architecture that uses intelligent edge devices to support OSS functions. These site devices use scripting engines to distribute OSS functions closer to the edge of the network.

The basic architecture is illustrated in Figure 1. The intelligent edge device is positioned between the OSS/network management system (NMS) and the network elements. They have a scripting engine that allows them to be easily customized to efficiently perform the low-level tasks that otherwise bog down a centralized OSS server. The ratio of intelligent edge devices to network elements will vary based on the application.

Figure 1: NMS distributed to intelligent device

The concept of distributed computing architectures has been around almost as long as the computer itself. Just about the time everyone had grown to accept the concept of the mainframe in the 1970s, low-cost minicomputers and personal computers emerged to completely change the paradigm of centralized mainframe processing. The concept of distributing selected OSS functions to intelligent edge devices is analogous to this--there are some OSS functions that make sense to offload on a scriptable site device.

Extending the life of an existing OSS

Distributed intelligent edge devices can help extend the life of an existing OSS in numerous ways:

• An OSS that has problems scaling to the ever-growing number of network devices can offload either alarm or polling functions to the intelligent edge device. Further, the intelligent edge device can act as the communications gateway for a large number of subtended devices, greatly enhancing the scalability of existing OSSs.

• One of the fundamental issues resulting from network convergence is the variety of physical and logical protocols between circuit and packet switched networks. Oftentimes, there are no application programming interfaces (APIs) for circuit-switched network devices. Intelligent edge devices can bridge the gap by providing a scripted interface between any OSS/NMS and any device in the network.

Another consideration is that many network elements--legacy devices in particular--use protocols that are inherently insecure. Despite the huge risk of security compromise, many networks are still left with large security holes because of the connectivity required by the OSSs. An intelligent edge device can be scripted to act as a security proxy to shield particularly vulnerable devices. An intelligent edge device could even be scripted to provide an SSH secure shell connection between itself and the OSS, encrypting all data communications.

Transitioning to the new OSS

There are numerous issues that exist in the transitory period of a new OSS. All the issues that existed with the former OSS are still present during the transitional period because the former OSS is still deployed and active in the network. In addition to easing the problems with the legacy OSS, intelligent edge devices have the ability to actually ease the transition period by providing connection mirroring between OSS/NMS systems (see Figure 2).

Figure 2: Connection mirroring

Both northbound and southbound communication streams between the network device and the existing OSS can be split off using connection mirroring. This allows a next-generation OSS in any stage of deployment to exist in complete harmony with the legacy OSS. The capabilities of the existing OSS are not impacted. In this way, intelligent edge devices actually enable a carrier to implement a next generation OSS in small, controlled steps. This may also help alleviate organizational tension by providing a mechanism for both the existing and next-generation systems to coexist.

Fully deployed next-generation OSS

The challenge of keeping a next-generation OSS in synch with the many new and legacy protocols is an ongoing task. Fortunately, decommissioning the existing OSS does not diminish the applicability of the intelligent edge devices that were deployed to extend the life of that OSS. The scripting capability on the intelligent edge devices means that the original investment can be recouped for the next generation OSS simply by updating the scripts. The flexibility provided by intelligent edge devices enables them to be used in a nearly endless number of applications.

Integration into an existing NMS

Earlier, this article referenced a scenario where intelligent edge devices are used as a communications gateway to extend the scalability of their existing OSS applications in order to monitor a large number of outside plant devices from multiple vendors. There were several challenges to overcome:

1. Many of the outside plant devices did not have a TL1 interface.

2. Some of the devices did not have gateways, so the existing OSS would need to maintain a communications gateway-like session with each one. The tens of thousands of devices presented a large database and resource usage issue in the system, which was designed to monitor a smaller number of more complex devices. 

Intelligent edge devices can be used to solve both problems very efficiently. Scripts running on the intelligent edge devices are easily able to convert the ASCII alarm streams from the devices into TL1, as well implementing a concept called TID multiplexing to consolidate database and channel resources on the system (see Figure 3).

Figure 3: Legacy device integration into an existing NMS

TID multiplexing allows the system to send the intelligent edge device a single network call and then pipe multiple login sessions through that single network thread. The intelligent edge device watches for new incoming TIDs and spawns a child call for each new element, in essence becoming the communications gateway for all the subtending devices. And because the intelligent edge devices are physically distributed into the network, a large portion of the monthly long-distance expense for POTS lines is instantly eliminated. This solution was estimated to have an ROI in excess of 400%.

Protocol conversion for a probe-based OSS

Another large carrier had a fully deployed NMS that used probes to communicate to the network devices it manages. Although probes existed for many types of network equipment, the carrier had a number of existing devices they wished to manage for which no probe was available. While the conversion could have been performed on a central server, there were a few critical reasons why the carrier desired the probe capability on a site device:

• The probes require continually open sessions with the network elements. If the probes were located on a central server, the large number of open connections would span their core network, requiring a significant allocation of bandwidth.

• The existence of open sessions across large portions of the network represented reliability and security issues.

The carrier was left with two choices: have their own development staff create the probes, which would reside on a number of regional servers, or utilize intelligent edge devices at each site with the probes implemented as flexible scripts. Implementing the probes on intelligent edge devices was estimated to provide a 2-to-1 ROI advantage while providing enhanced scalability, reliability and security and minimizing bandwidth. 

Conclusion

OSS planners and network operations personnel face significant challenges as existing OSS systems are decommissioned to make way for more efficient next-generation OSSs. The need exists for an architecture that uses intelligent edge devices to facilitate both existing and next-generation OSS systems. The unique ability to write extendible scripts on intelligent edge devices will enable OSS planners and network operators to mitigate a variety of legacy problems, while successfully facilitating the migration to a next generation OSS system.

Gerard B. Moersdorf Jr. is Chairman, President and Chief Executive Officer of Applied Innovation Inc.

Visit Applied Innovation online.