RAD IPMUX-14 and BC9 Sync problems

[splinkio]

Hi. I am new to the forum, so first of all hello to everyone. My experience with the MD110 is about 1 year, so please bear with me. MD110 is on BC9 latest patch.

We have 2 lims which are connected to our GSM by RAD IPMUX-14 devices across our gbit network on a dedicated VLAN. Calls work fine for the most part, but every now and again we get the LIMS drop off for about 15 minutes with the following errors:


287 CONGESTION SUPERVISION VALUE REACHED FOR PCM-LINE
DATE TIME ALP NOIF UNIT EQU INF1 INF2 INF3
26MAR06 20:00:00 26 2 GSP 007-*-**-** 312 143 10
RDATE RTIME
26MAR06 20:15:00
287 CONGESTION SUPERVISION VALUE REACHED FOR PCM-LINE
DATE TIME ALP NOIF UNIT EQU INF1 INF2 INF3
27MAR06 09:45:00 32 1 GSP 007-*-**-** 48 143 10
RDATE RTIME
27MAR06 10:00:00
287 CONGESTION SUPERVISION VALUE REACHED FOR PCM-LINE
DATE TIME ALP NOIF UNIT EQU INF1 INF2 INF3
27MAR06 09:45:00 33 1 GSP 006-*-**-** 84 143 10
RDATE RTIME
27MAR06 10:00:00


and then, more times than not, we get the following LIM out of order messages:


34 LIM OUT OF ORDER
DATE TIME ALP NOIF EQU INF1 INF2
01APR06 11:02:02 11 5 006-*-**-** 0 0
RDATE RTIME
01APR06 11:02:02
34 LIM OUT OF ORDER
DATE TIME ALP NOIF EQU INF2
01APR06 11:14:44 31 5 007-*-**-** 0
RDATE RTIME
01APR06 11:14:44
287 CONGESTION SUPERVISION VALUE REACHED FOR PCM-LINE
DATE TIME ALP NOIF UNIT EQU INF1 INF2 INF3
01APR06 11:15:00 45 2 GSP 006-*-**-** 235 143 10
RDATE RTIME
01APR06 11:30:00
287 CONGESTION SUPERVISION VALUE REACHED FOR PCM-LINE
DATE TIME ALP NOIF UNIT EQU INF1 INF2 INF3
01APR06 11:15:00 46 2 GSP 007-*-**-** 368 143 10
RDATE RTIME
01APR06 11:30:00


The RAD boxes jitter buffer is set to 5 and the GSM RAD is set to loopback for clocking, and the End point is set to adaptive (LIM 6 and 7)


Does anyone else have any experience with the above issue, or tell me if BC9 works ok with TDMoIP devices ?

 

[slash50]

In theory TDMoIP should work with any release because it's a "Transparent" E1 link. I read somewhere that RAD's do not support protection of timeslot 16 (The timeslot Md110 uses for signalling) so maybe the problem lies there?

I don't know much about RAD's, I'm just trying to get the Ericsson HL950's working at the moment.

 

[splinkio]

This is interesting information. We get a lot of sync problems when the RADS are plugged in, but when we go back to using line drivers on our ATM network they appear to drop off.

Do you know where you read about time slot 16 at all ? If this is the case, then we could probably do something on the line bundles on the RAD to accomodate this.

How are the Ericsson HL950's doing. Are you getting issues with them ?

 

[Mpe]

Hi.

We have used RAD:s ip mux with 4 E1 interfaces with good result.
On the GS side we hade external clocking and adaptive on remote side.

How many GS links do you have to LIM 6 & 7?
If there are more than one, are they connected to the same RAD mux?

Curently we run remote LIM over HL 950, works fine as long as we only need one GS link. If more than one link, we need to have some kind of external clock.
All these connection are over a least 100 mbits con.

 

[dstrang1]

You don't say anything about how your RAD's are set up......

For the physical port configuration, the GS side needs to be set for "loopback" and the LIM side needs to be set for "adaptive" for the "transmit clock source". You can choose either "unframed" or CAS disable" for the "link type". I believe the docs I have recommend "CAS disable".

The very critical portions of the configuration are the method of QoS on your network and the jitter buffer settings for your bundles. AS long as you can keep your jitter buffer setting below 900 or so, you won't have echo.

You'll need to look at your performance stats for "bundle connection status" and "bundle connection statistics". If you max jitter buffer deviation exceeds your setting for the bundle, you'll get jitter buffer overflows, which cuases the mux to purge the jitter buffer, which in turn causes a momentary interruption of the signalling channel on the link.......the error code 34's with the time and rtime values being the same are indicative of signal channel faults (GJLOP for the LIM in question will show signal channel faults with times corresponding to the code 34's).

If QoS is set correctly on your network and traffic between the muxes has priority on the network path, then you may only have to play with the jitter buffer settings (assuming the rest of the physical port and bundle configuration is correct).

If it's a QoS issue, I hope you get along well with your network folks........a lot of them don't understand the TDM
environment and can be too damned arrogant to admit it (in my own personal experiences anyway).

As for there being no protection for channel 16........the muxes don't make any kind of distinction....you assign a timeslot to a bundle.....what ever is in that timeslot, the RAD packetizes it and send it to the destination IP for that bundle.


Good luck,

Dave Strang

 

[TripleT]

One of the things that Rad Mux's introduce is and increase in the latency of the signalling between the Lims.

If I rememeber right Rad Mux's are not supported on versions below BC10.

There were some corrections in the LPU5 Firmware to overcome this issue.

Try upgrading the LPU5 to the latest Firmware. IT should be ok with BC9.

Also double check and ensure that your system dumps are working properly.

 

[splinkio]

Well this makes some sense, as after checking on the Mux's yesterday, I am seeing buffer under-runs.

We are getting dumping issues in the respect of:

75 ERROR DURING DUMPING OF CIL DATA
DATE TIME ALP NOIF UNIT EQU BRDID INF1 INF2 INF3
28MAR06 13:11:32 36 1 SIP 002-0-63-00 29 2 3 3
RDATE RTIME
28MAR06 13:11:43


along with ..

85 BUFFER TRANSFER HAS FAILED
DATE TIME ALP NOIF EQU BRDID INF1 INF2 INF3 INF4
27MAR06 09:31:59 28 3 002-0-63-00 29 351 0 6 2
85 BUFFER TRANSFER HAS FAILED
DATE TIME ALP NOIF EQU INF1 INF2 INF3 INF4
27MAR06 09:32:04 29 1 006-0-**-** 351 6 6 1
85 BUFFER TRANSFER HAS FAILED
DATE TIME ALP NOIF EQU INF1 INF2 INF3 INF4
27MAR06 09:32:04 30 1 007-0-**-** 351 6 7 1


I am not seeing a periodical system dump failure on there however.

If this is all related to a firmware issue, then great, we will just have the firmware on there. Is it in a patch/service pack at all? as I think we are on the latest release for bc9.

 

[TripleT]

I believe the firmware was released as part of BC10 or BC11.

Other things to check are: -

1) Ensure that in the RadMux at the GS End that he clocking is sett ot Loopback and that in the RadMux at the Lim end Clocking is set to Adaptive.

2) You need to ensure that the Packets from the RadMux are prioritised in your Data Network. As you have a dedicted Vlan th best way maybe to use Vlan Prioritisation.

3) Check your Jitter Buffer settings you may need to increase this. Of course increasing the Jitter Buffer will also increase the Latency so take it up in Steps and leave overnight to check.

If you are seeing Buffer Underruns it would seem that it could be a combination of 1, 2 and 3 above.

 

[splinkio]

GS end is set to loopback and the LIM is set to adaptive. This has always been set this way as we were getting issues with our oubound q931 circutis dropping off with different configs

We have been looking at the VLAN priority, and that network does not have QoS at the moment, and I dont think the switches have vlan prioritisation on at the moment, as they are just standard layer 2 devices which just about support 802.11q

Ill have a go with the jitter buffer settings and then see if it resolves the issue. I will post on update on here in a few days to let eveyerone know how it is going

 

[dstrang1]

splinkio (TechnicalUser)writes:
>We have been looking at the VLAN priority, and that >network does not have QoS at the moment, and I dont think >the switches have vlan prioritisation on at the moment, as >they are just standard layer 2 devices which just about >support 802.11q

If you don't have QoS or some other way to give those packets priority on that network, then nothing else you try will resolve your problem.

Been there, done that!

Good luck,

Dave Strang