Monday, 24 May 2010

Designing resilience into next-generation public safety communications

The team here at Aculab are gearing up for NENA 2010, which takes place in Indianapolis, USA in early June. NENA 2010 is an event run by the National Emergency Number Association (NENA) for public safety professionals, telecoms specialists and government officials, which focuses on the near and long term issues facing public safety in the USA.

NENA is calling for the migration of 911 networks to next generation E911. The idea is to move 911 systems to standards-based IP platforms and, in the process, enable citizens and those involved in emergency response to interact not only in voice, but also via text, IM and possibly even video communications.

The ultimate goal is that citizens, no matter who they are, where they are or which communications device they use, can make an emergency call and the emergency services will have the accurate location and subscriber information to find them.

With such critical communications, there is no room for error. Resiliency, reliability and interoperability are all essential, as is full integration between IP and PSTN networks. Specific recommendations for survivability and resilience (recommendations 16.10 and 16.12 respectively) have been made in the US government's national broadband plan and the FCC are already some way into making sure the new infrastructure handles these key issues.

Developers of communications solutions such as Aculab must provide the reliable and redundant connections to landline and cellular networks that carriers and emergency services providers demand. The mantra should be 'duplicate everything', so there is always a standby component when the main fails.

Protect your hardware and software elements
The media processing component of a communications server is the device (hardware or software) that handles the calls. It is clear that such a key component should be a) reliable in its own right, and b) have the ability to be duplicated in a master/slave arrangement. Extending this concept even further, it is also a good idea if the master and slave can be sited geographically remote from each other, which is not always easy if the media processing board uses an H.100 bus rather than IP for connectivity. The concept of the distributed architecture for VoIP telephony solutions is further discussed in our whitepaper.

Protect all links between the elements
Having master and slave communication servers on different sites is a great start, but what if they are linked by a single connection, and a roadworker goes through the cable with a jack hammer? What you need now is some form of link protection scheme such as a loop/ring topology. For this you need duplicated cable and duplicated ports on your media boards to support the two routes. Again, if these routes are IP-based then there are a myriad of choices for the protected connection.

Then protect anything else you missed in the first pass
Thumbnail image for resilience_checklist.png

How about the call control software? Whilst protection of the SS7 stack for legacy PSTN networks is commonplace, the same approach has, until now ,not been available with IP communication networks using SIP for call control. Our engineering team, with many years experience of the design of solutions for TDM and IP networks, realised this was the case and came up with a solution using duplicated SIP stacks and some clever software to control the stack mirroring. Our Dual Redundant SIP Service (DRSS) is now available as an optional feature of our field proven SIP stack, and has already confirmed itself as a hit with customers developing critical communications systems.

For someone who has been in the industry over 20 years, I sometimes feel that the transition from TDM to IP is happening so slowly that it won't be over in my lifetime! Building resilience and reliability features into IP-based systems is one way that we, in the vendor space, can speed this transition by convincing customers that the new system is going to perform better than the old one.

No comments:

Post a Comment