CS1000 PRI B-Channel locks up

[rollem]

Hi all,

Back in Meridian load x11 25.40B there were 2 PEPS (MPLR18485 and MPLR18486) that corrected an issue where b-channels would lock-up when a Nortel (now Genband) DMS-100 would switch controllers and send a SABME on the d-channel. This SABME caused any b-channels in the ringing state in the Option 11-81C to lock up until a busy and restore was done from either side.

I now have a CS-1000 on software load 7.5 acting exactly the same way! A midnight routine in the DMS-100, a switch of controller activity, the resulting SABME, and the b-channel that was unaswered (ringing) in the CS-1000 locked up. On all subsequent Q.931 SETUP messages destined for (in this last case) b-channel 2 the CS1000 sent back a Q.931 Release Complete with cause code #6 'channel is unacceptable'. (2 occurences so far with this exact scenario)

A busy and return to service of b-channel 2 sent a Q.931 RESTART message out to which the CS-1000 to sent back a Q.931 RESTART ACK back, and it started accepting calls on b-channel 2.

Has anyone had this trouble? It was initally fixed back in 2004 but it sure seems like the exact same set of circumstances in CS-1000 7.5 load as back when in X11 25.40B.


Thanks

[rollem]

Also, the history from the CS-1000 shows DCH 0 and 1 both issued a establish remote at the time the DMS did the controller SWACT and sent the SABMEs

[rollem]

Simplified sequence of events:
1.DMS DTCI switches activity from one unit controller to the other
2. DMS sends a layer 2 SABME to re-establish multi-frame operation on both the primary and backup d-channels
3. CS-1000 acknowledges the SABMEs with a UA frame on both d-channels
4. The CS-1000 sends a layer 3 B-Channel RESTART message, coded to globally restart all b-channels associated with the d-channel
5. The DMS sends out a layer 3 SERVICE message saying to make the primary d-channel the active one

Problem is that the CS-1000 is program coded to send a global restart on all b-channels if there are no calls in an answered state. With only calls in a ringing state or no calls up at all the CS-1000 sends a layer 3 global restart.

On a NFAS PRI (primary and backup d-channels) a restart should not be sent until after the d-channel service message is received specifying which d-channel is the active one:

Telcordia TR-NWT-001268 ISDN PRI Generic Requirements for Class II Equipment (Class 2 is PRI, Class 1 is BRI) states that RESTART procedures will be Subsequent to the d-channel being restored to an in-service state.

Because the RESTART message is received by the DMS switch before the SERVICE message is sent the DMS premature restart message is being ignored. The CS-1000 puts all b-channels into the far-end busy state until Q.931 timer T316 expires (CS-1000 appears to use the default ITU Q.931 T316 retstart acknowledgement value of 2 minutes) whose expiry causes the CS-1000 to retransmit the RESTART which is then acknowledged by the DMS and the mini 2 minute outage is over.

If the CS-1000 waited half a second to send the first RESTART message the d-channel message would have already been received and that first restart would have been processed.

This is not going to be fixed in release 7.5.

To resolve this issue our plan is to change the NFAS PRI into individual FAS PRI spans since FAS PRI does not use/need the d-channel in-service message (there is just a single d-channel associated with each span). With FAS PRI the CS-1000 doesn't need to wait half a second to send its RESTART message.

[rollem]

Note: also in the CS-1000 LD 96 had SERV DIS. We proved that this is b-channel service messaging.

In D100 protocol it impossible to disable the b-channel service messaging in the DMS-100 (it is program hardcoded in the DMS switch for NTANPRI and the DMS-100/D100 protocol specification NIS-A211 contains no provision to disable it) we will change LD 96 to SERV ENL so that the b-channels can stay insync with each other. Otherwise if a channel goes out-of-service on one side the other side doesn't know about and we get blocked calls.