Periodically congestion in LIM1-need help

[wladimir]

Hi!
MD110 ver 9
Sometimes (app. every 1.5-2 month) all outgoing calls from sets connected to LIM1 (at all - 3 LIMs + 1 GS) are impossible. Incoming calls and calls from other LIMs - OK.
In ALLOP - no errors.FTMFI,GSFTI-OK. On EL6 and EL8 sets - congestion tone (shorter,than busy) on KS screens - CONGESTION. After restart LIM1 (BLLTI, RFLII, BLLTE) - all OK (some time to next "congestion&quot. What is wrong?

 

[Jaydee2002]

Hi,

Wladimir How many PCM links do you have to the GS? Have checked that there is sufficient capacity there?

JD

 

[wladimir]

Hi, Jajdee!
It's 1 link to GS, but I think, that's no matter, because this error appear after week-end (traffic is _wery_ low) and newer "at once" - usually number of "congested" sets increasing from some to all at some hours. And congestion tone appears _before_ dialing any number - immediatly after lifting handset.

 

[lalrl1]

Hi,

what kind of external lines is connected to lim1? sl60? Internal calls within lim1 is possible? Internal calls to lim2 is possible? Next time try to start not the whole lim (rfrli would be easier than rflii)but only a single programm to fix the problem, for example klp1t1 or slp60

MB

 

[wladimir]

Hi, DEMIBE2!
In LIM1 - only TLU75(TLP95). At first, all calls are possible (some sets some times gets "congestion" after lifting handset, after 2-5 attemptions they can make call, incomming calls -OK). Number of "congestions" increasing very fast, and 3-4 hrs later all sets in LIM1 gets "congestion" immediatly after lifting handset (before any dial). At first, I tryed restart all PU-s in LIM1 sequentally. But work only full LIM restart.

 

[Petya]

Hi, Wladimir.
I had absolutely the same problem. This problem is in very high traffic. If load of LIM more than 1.2 calls/second new calls are rejected. You should ask your local Ericsson company for patch 73006. This patch increases the max load level in LIM from 1.2 to 1.8 calls/second.

 

[Orim]

Hi Vladimir,
I had the same problem. I fixed it by replacing (not with new one) LSU and DSU board. Only pull and push these boards 2-3 times. Replace the connectors too.

 

[Avstral]

To Petya:
Sorry, this is not high traffic problem.
There is no alarm 320 and incoming traffic possible.

This look likes a problem with TMU in LIM 1.

To Vova:
1. Could you, please, check your software version with CADAP; command.

2. Check with CNLIP:LIM=1,DEV=ALL; number of TMU's installed in LIM 1. (They have BRDID=102).

3. How many extencions do you have in LIM 1?
It is recommended by E/// to have 1 TMU per 80 extensions.

4. Check revision state for: TMU (it MUST R3A), LPU5, LSU and DSU's.



How to fight with this problem:

1. If this problem appear again, make
FTTDI:LIM=1;
LSFTI:LIM=1,FULL=YES;,
check also HIMDP:LIM=1;

Try to restart with RFBOI:BPOS=...; TMU boards and
program unit:RFPUI:LIM=1,UNIT=TSP;


2. If you have spare TMU - swap them in the evening.

3. DON'T WARRY, BE HAPPY.


It is IMXO.

It is extremely useful to make SFCEI; and RFEXI; at least once a month.

Clean up the brain, relief from the pain.

 

[TBLuk]

I agree this has, but also disagree with Avstral:

We need to know what CNA level you are at by doing a CADAP;

TMU does not *need* to be R3A, as it may be a TMU1 in the system rather than a TMU2

There is a problem with several variants of the TMU1 and TMU2, mainly TMU1 ROF1375335/1 at any revision, or the TMU2 ROF1375335/2 at R3 or higher, but we'll come to that later.

I would not agree with the fact that a RFEXI is required every month, this is totally unnecessary, and I cannot see the thinking behind it. A system should never need RFEXI'd in normal operation.
One of the networks we operate is safety critical, and none of these 180 MD110's have been restarted in over two years!

 

[Avstral]

To TBLuk:

I've reed you post several times, but didn't catch, what do you agree with and what not.

Anyhow, I'll try to answer you step by step.

We need to know what CNA level you are at by doing a CADAP;

Great, this was the first point in my message to Wladimir.
Just check it upper.

"TMU does not *need* to be R3A, as it may be a TMU1 in the system rather than a TMU2;
There is a problem with several variants of the TMU1 and TMU2, mainly TMU1 ROF1375335/1 at any revision, or the TMU2 ROF1375335/2 at R3 or higher, but we'll come to that later.

I really didn’t mention about TMU /1 before, so let’s open Upgrade System Support (USS) program and check board status for TMU.

TMU board with ROF1375335/1 had releases from R1A to R6A.

Boards with R1A to R4A are to be modified to TMU2 ROF1375335/2 with R3.
Boards with R5A are to be upgraded to TMU ROF1375335/2 with R3A changing two proms.
Boards with R6A are OK for BC9 – BC11.

TMU board with ROF1375335/2 had releases from R1A to R3A.
Boards with R1A and R2A are to be upgraded to with R3A changing one prom.
Boards with R3A are OK for BC9 – BC11.

So, I still insist that TMU board MUST be R3A for almost all hardware. If you have TMU /1, you can relax only with R6A version.
But! TMU /1 has never been delivered to Russia with BC9 (this is Russia because of TLP95 using). And if this exchange was upgraded from BC7, TMU was upgraded either.


TMU ROF1375335/2 higher than R3 not exist at all. Sorry.

I would not agree with the fact that a RFEXI is required every month, this is totally unnecessary, and I cannot see the thinking behind it.…One of the networks we operate is safety critical, and none of these 180 MD110's have been restarted in over two years!

My congratulations! You have very stabile and reliable MD net.

Just a question. In witch country?

When you work in Russia, you can forget about all your previous experience.

If you wish, I would organize a trip for you to Siberia. In 1995-2001 we installed there more than 300 LIMs in very different configurations (biggest transit node has 41 LIMs with GS).
In this area, regular SFCEI+RFEXI set of commands is part of maintenance routine and executing regularly.
Being there you can explain to maintenance personnel that you “cannot see the thinking behind it”.

Nothing personal.

Best regards

 

[TBLuk]

RE: The TMU issue.

I am going on what we have in the UK, and the part you quoted me on about the TMU revision was taken directly from an Ericsson patch report, on a TMU congestion problem we have had on our expansive MD110 network of around 200 sites with some sites having one LIM upto 20+ LIMs.
The patch in question solved the problem, I will need to look into if it is a UK specific patch.

As you say 'TMU board MUST be R3A for almost all hardware', but there is still a version of TMU1 for which this is not the case, so your argument holds little water.

Regarding the CADAP, yes you did ask for it, but he did not provide it, so I asked again, he still did not reply.

Regarding SFCEI and RFEXI, my apologies, you have a very unstable network if you need to do these commands as part of routine maintenance, if these were routine maintenance commands they would be listed in the documented procedures.

I do not wish to enter into an argument, but wish to have a nice devate )