[VoiceOps] Geographic redundancy

[Mark R Lindsey]

On Aug 13, 2009, at 12:46 PM, Kenny Sallee wrote:

> * redundancy for CLEC


You earlier mentioned BroadSoft BroadWorks geographic redundancy.  
We've done it for several carriers, and it works. Supporting all the  
fault-tolerance scenarios can be extremely complex, but it's  
definitely achievable. It introduces a set of requirements on the  
network, and especially on your connectivity to subscribers.

But on to CLECs: The technical problem involves termination and  
origination, of course. Termination (sending calls to the PSTN from  
your subscribers) through different gateways, for a CLEC, is easy. You  
just dump your calls outbound wherever you'd like to; unless you have  
a screen list, it shouldn't be a problem.

Origination -- receiving calls from the PSTN to subscribers -- is the  
challenge. But it can be done. A minimal design achievable with  
popular equipment, such as MetaSwitch. It includes splitting your SS7  
Linkset, sending one member of the linkset to site A, and the other to  
site B. This type of system doesn't require any special tricks with  
ISUP routes or point-code proxy.

In addition, you need to build your ISUP trunk groups to two  
locations. Suppose your local inbound trunk groups go to the Atlanta  
tandem. You'd have some trunks go from the tandem to site A, and some  
go to site B. Suppose you have four ISUP-controlled T1s in this trunk  
group.

T1-1 with TCICs 1-24
T1-2 with TCICs 25-48
T1-3 with TCICs 25-72
T1-4 with TCICs 73-96

T1-1 and T1-2 could connect to site A, while
T1-3 and T1-4 connect to site B.

At Site A, you'd need a media gateway and signaling interface to  
connect the two ISUP trunk groups, there. At Site B, you'd need a  
matched set.

You'd have a Call-Control server at both Site A and Site B; these  
boxes would handle the SS7/ISUP signaling received at both of the  
sites. In a Sunny-Day Situation (all is normal), the Call Control  
server at Site A could be the master, and control signaling through  
both of the SS7 A-links.  The two call-control servers would should an  
SS7 point code, but only one of those two would be activate at any one  
time. Some of your calls would be transported to Site A, while others  
are transported to Site B.

In the case of a site fault, the remaining site would detect the fault  
and assume full control. It's critically important in these designs  
that the two call control servers have connectivity that's the most  
reliable part; i.e., if anything at all is working, then the two call  
control servers should be able to communicate: If I'm a call control  
server, it is impossible for me to determine whether the other call- 
control server is dead, or if it's just not able to communicate with  
me. If it's alive, but the two call control servers cannot  
communicate, then both can become active and try to assume control of  
the linkset. Bad stuff ensues.

But none of that particularly relates to BroadWorks. While the SS7- 
connected call-control servers need to be call-state synchronized,  
BroadWorks doesn't have to be. It's actually quite forgiving in  
failover scenarios where Site A's Application Server cannot  
communicate with Site B's Application Server.

Mark R Lindsey lindsey at e-c-group.com http://e-c-group.com/~lindsey  
+12293160013