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