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

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.

Achieving 'five-9s' reliability in IP-based communications networks

Is the lack of widespread support for full 'five-9's' reliability in IP-based networks  holding back the adoption of IP communications?

It is certainly something we thought might be the case, and so we set our engineers the task of providing redundancy mechanisms for IP communications , based on Aculab's SIP stack, that would enable end customers to build in the reliability they were craving.

Our goal was to enable our customers to build enterprise and service provider communications platforms that could match the reliability and resilience of a legacy TDM-based system, but also give the full unified communications experience made possible by IP.

For over 30 years, designers of TDM networks have taken every step possible to minimise network downtime in search of the mythical 99.999% availability figure (just over 5 minutes downtime per year). The basic rule has been to eliminate any single point of failure. This philosophy has extended beyond simply duplicating the network hardware - separate buildings with separate power feeds and physical connecting cables are also a key part of a resilient network design.

For the IP-core network consisting of routers that are inherently designed to utilise multiple routing paths, this is not an issue; but for hardware attached at the network edge such as media processing servers, it is not so straightforward. An IP-based media server supporting VoIP and video services and using SIP for its signalling is one such platform that sits at the edge of the service delivery network. It is relatively straightforward to duplicate the hardware parts of this server, but not so easy to duplicate the software applications running on the server.

Aculab took on the challenge and created its dual redundant SIP service feature - mirrored SIP stacks are enabled, with failover mechanisms to keep calls active on the standby when the main server fails. The use of a floating IP address with switching to handle the traffic routing to the correct active server provides the mechanism to make sure the traffic is directed to the appropriate server. 

If you would like to know more of the detail then you can access our dual redundant SIP whitepaper here.

Telecoms standards: are they slipping?

I often hear people say things like, "standards are slipping" - maybe they are talking about our politicians! But that's not where I'm going today; I just had a few random thoughts on standards, per this definition: 

• standard (n): a specification for hardware or software that is both widely used and accepted (de facto) or is sanctioned by a standards organisation (de jure)

We're all familiar with the British Standards' kite mark and the American National Standards Institute (ANSI). Internationally, there is the Internet Engineering Task Force (IETF - maybe you could quibble on that one as its RFCs are more akin to recommendations; but let's not deviate from our standard interpretation), the International Telecommunications Union (ITU-T) or the 3rd Generation Partnership Project (3GPP) or...

Never mind that the list of standards bodies goes on and on, my first thought was, "Isn't it maddening that their collected output is seemingly endless?" The standard response is "yes", by the way.

Don't get me wrong, it's certainly a good idea that the graphics card you buy to upgrade your computer is built to the PCI electro-mechanical standard. You want it to slot in snugly, regardless of whether you bought it on eBay or from your local RadioShack. There might be a bewildering array of options for full-length, half-size, half-height, low-profile, etc. but the point is, it fits, because it's been standardised, which is good.

So much for hardware; then there was software.

The need for a standard specification is suggested by recalling the not too distant past, when everyone queued up to criticise Cisco for its so called 'Skinny' interpretation of SIP. Standards are good; right.

VoiceXML (VXML) is a standard that gets a mixed reception, depending to whom you're talking. Some engineers say things like, "It's not that easy or intuitive for a novice to grasp. It'd be just as quick to use a general purpose, high-level language."

Advocates of VXML as a standard for specifying interactive voice dialogues between (wo)man and interactive voice response (IVR) machines would surely take a different view. And, to be provocative, I suggest that Call Control eXtensible Markup Language (CCXML) was an afterthought - or as Homer said, "Oh, so they have Internet on computers now!"

The problem with such standards is that they are so niche. Nobody writes a business application entirely in VXML (or indeed, in MSML, MSCML, MGCP, MEGACO, ...). Quite likely, such applications are written in a general purpose, high-level language. These are de facto standards, such as Python, Ruby or C#.

That brings me to media servers and the argument for using niche standards to control them. I suggest application portability is a myth. A well structured, high-level API for voice (and video) may be proprietary, however, it is an arguably better option than using a niche standard, particularly if the API library uses the same language in which you write your business application.

Incidentally, the Battle of the Standard was fought on Cowton Moor, near Northallerton, on the 22nd of August, 1138. Historians on either side have since claimed at least a moral victory for their sponsors. So, it seems that standards never change.