You are on page 1of 13

POOR SDCCH ESTABLISHMENT From: Alex Abrokwah Sent: 22 April 2009 15:04 To: Viktor Nagy V Cc: Faustina

Obiri; info@smsmail.al.sw.ericsson.se; RNE Subject: RE: (1089539) - Poor SDCCH Establishment

Hi Victor, In the mail I sent to Joakim, I was explaining that his mail did not contain any information on the CESTIMMASS problem. We need information about why we are having SDCCH Establishment failures because of CESTIMMASS. Please let us know if there were any findings on that from the log files we sent. BR. Alexander Abrokwah
From: Viktor Nagy V [mailto:viktor.v.nagy@ericsson.com] Sent: 22 April 2009 13:41 To: Alex Abrokwah Cc: Faustina Obiri; info@smsmail.al.sw.ericsson.se Subject: RE: (1089539) - Poor SDCCH Establishment Hi Alex, Do you have any more questions or we can close the CSR? Thank you, best regards, Viktor From: Viktor Nagy V Sent: 2009. prilis 20. 16:38 To: 'Alex Abrokwah' Cc: Faustina Obiri; 'info@smsmail.al.sw.ericsson.se' Subject: (1089539) - Poor SDCCH Establishment Hi Alex, Do you have any more questions regarding this case? Thank you, best regards, Viktor From: Joakim Bolme Sent: 2009. prilis 16. 17:21 To: Alex Abrokwah; Wilfred Chikati; Viktor Nagy V Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; PLMBTS; Mercy G.A. BoadiSiaw; Larry

Arthur; Per Forsgren; Mats berg Subject: RE: CSR 1089539 - Poor SDCCH Establishment Hi Alexander, Here's the report from the site visit that was performed. Best regards //Joakim From: Alex Abrokwah [mailto:Alex.Abrokwah@tigo.com.gh] Sent: den 15 april 2009 16:28 To: Joakim Bolme; Wilfred Chikati; Viktor Nagy V Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; PLMBTS; Mercy G.A. BoadiSiaw; Larry Arthur; Per Forsgren; Mats berg Subject: RE: CSR 1089539 - Poor SDCCH Establishment

Hi Joakim, Yes there was a site visit by Per and Olof. They gave recommendations which included the MAXTA optimization which has already been effected. This CSR was raised again because the SDCCH Establishment is still below the target for the KPI and the majority of failures is still due to CESTIMMASS which was one of the reasons for raising the CSR in the first place. Please let me have the report regarding this issue. Thanks BR. Alexander Abrokwah
From: Joakim Bolme [mailto:joakim.bolme@ericsson.com] Sent: 15 April 2009 11:21 To: Alex Abrokwah; Wilfred Chikati; Viktor Nagy V Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; PLMBTS; Mercy G.A. BoadiSiaw; Larry Arthur; Per Forsgren; Mats berg Subject: RE: CSR 1089539 - Poor SDCCH Establishment Hello Alexander, Ok, good that you are aware why this Random Access failure is caused. Regarding the SDCCH Establishment failure this was handled during the site visit by Per and Olof. From my understanding this was accepted, there is also a report regarding this issue. Best regards Joakim From: Alex Abrokwah [mailto:Alex.Abrokwah@tigo.com.gh] Sent: den 14 april 2009 13:04 To: Joakim Bolme; Wilfred Chikati; Viktor Nagy V Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; PLMBTS; Mercy G.A. BoadiSiaw; Larry

Arthur; Per Forsgren; Mats berg Subject: RE: CSR 1089539 - Poor SDCCH Establishment

Hello Joakim, The Tesano1800 site is in an urban area and the maximum site-to-site distance between Tesano1800 and its neighbour is about 2.3km and that explains the reason for the MAXTA settings. From your mail below we did not get any explanation for the high SDCCH Establishment failure for both Tesano1800 and Manhea 900. Please let us know if you have any information from the logs as to the reasons for the high SDCCH Establishment failure. Thanks. BR. Alexander Abrokwah
From: Joakim Bolme [mailto:joakim.bolme@ericsson.com] Sent: 01 April 2009 08:04 To: Alex Abrokwah; Wilfred Chikati; Viktor Nagy V Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; PLMBTS; Mercy G.A. BoadiSiaw; Larry Arthur; Per Forsgren; Mats berg Subject: RE: CSR 1089539 - Poor SDCCH Establishment

Hi Alexander, We have now analyzed the attached files and we have come to the following conclusion. The reason for the increase in high Random Access Attempt Failure rate, RAACCFA, is that the value of MAXTA has been adjusted to limit the amount of SDCCH establishment failures. This is a expected result from the MAXTA adjustment as the type of connections that before caused bad SDCCH establishment rate is now denied access to the cell which will result in increased random access attempt failures. From the RLLDP printout it is verified that the cells TESANO5 and TESANO6 has MAXTA=10 and the cell TESANO7 has MAXTA=15. In the abis log the total number of failed access attempts with TA>10 in TESANO5 and TESANO6 and with TA>15 in TESANO7 is approx. 375. The abis log file from the site TESANO1800 is recorded from 2009-03-17 16:41 until 2009-0318 08:31, approx 12 hours. According to STS the number of RAACCFA during the same period is 383. This means that almost all of the failed attempts are not supposed to be successful due to the MAXTA limitation. It is however important to take the cell planning into consideration when defining the MAXTA parameter. If the neighboring cells also are defined with a low MAXTA there is a risk that a

geographic area between the cells is covered (with poor quality) but none of the cells allow the subscriber to access the network. In this case a higher MAXTA will allow all subscribers to access the network but will also increase the risk of higher SDCCH establishment failure rate. If the cell is on the border to an area that is not covered by any other cell in the network there will always be either random access attempt failure (with low MAXTA) or SDCCH assignment failure (with high MAXTA). From the abis log it can be seen that there are a lot of random access attempts with access delay 13 and 14 in the cell TESANO5. This might be a area that is not covered by any neighboring cells and for this cell increasing MAXTA to 15 might improve the network performance. If you have any questions or objections feel free to contact me, otherwise I'm planning to answer this CSR in the end of this week. P.S. We observered some strange bahaviours in the Abis logs, it looked like there were some messages missing in the log. Can you please inform me what tool you are using to collect the data (this is just for you information, it has nothing to do with the analazys. Best regards Joakim
________________________________ From: Alex Abrokwah [mailto:Alex.Abrokwah@tigo.com.gh] Sent: den 20 mars 2009 16:20 To: Joakim Bolme; Per Forsgren; Wilfred Chikati Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; PLMBTS; Mercy G.A. BoadiSiaw; Larry Arthur Subject: RE: CSR 1089539 - Poor SDCCH Establishment

Done. I have uploaded the files.

I have sent the links to your email addresses, but just in case you did not receive it, find them below:

http://rapidshare.com/files/211470595/Tesano1800.rar.html http://rapidshare.com/files/211470935/Manhea900_data.rar.html

The cells with the worst SDCCH Establishment are Tesano7 and Manhea1.

BR. Alexander Abrokwah

BR. Alexander Abrokwah

From: Joakim Bolme [mailto:joakim.bolme@ericsson.com] Sent: 12 March 2009 09:19 To: Alex Abrokwah; Per Forsgren; Wilfred Chikati Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; PLMBTS Subject: RE: CSR 1089539 - Poor SDCCH Establishment

Hi Alexander,

I have attached the required data, please make sure that you collect the data when the fault is active.

If it's ok with you I will send the CSR back until we get the requested data?

- STS data - Abis log with CF and TRX signaling from all TRX'es - RBS log and Idb - Also attach following BSC printouts RXCDP:MO=RXOTG-<tg>; RXMSP:MO=RXOTG-<tg>,subord; RXAPP:MO=RXOTG-<tg>; RXMOP:MO=RXOTG-<tg>; RXMOP:MO=RXOTRX-<tg>-<trx>; RXMOP:MO=RXOTX-<tg>-<trx>-<tx>; RLCRP:CELL=<cell>; RLCFP:CELL=<cell>; RLDEP:CELL=<cell>;

Best regards Joakim

________________________________ From: Alex Abrokwah [mailto:Alex.Abrokwah@tigo.com.gh] Sent: den 11 mars 2009 13:05 To: Joakim Bolme; Per Forsgren; Wilfred Chikati

Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; PLMBTS Subject: RE: CSR 1089539 - Poor SDCCH Establishment Hello Joakim,

From the mail sent by Per, it is evident our problem is different from what have encountered before. I am therefore working on the logs he requested. And I will make the available to you as soon as I have it.

Please let me know explicitly all the data that is required so I would work on getting them for you.

Thanks

BR. Alexander Abrokwah

From: Joakim Bolme [mailto:joakim.bolme@ericsson.com] Sent: 11 March 2009 10:51 To: Per Forsgren; Alex Abrokwah; Wilfred Chikati Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; PLMBTS Subject: RE: CSR 1089539 - Poor SDCCH Establishment

Hi Alex,

What is your opinion on how we should continue this case, are you planning to collect this data that Per described? As Per mentioned we are not able to perform any further analyzes until we have this data. From our side we have seen different cases and these needs to be analyzed individually with previous mentioned data collected.

We believe that the problems that have been seen in previous logs have been described, and if this it not enough let me know so we know on how we should continue the investigation?

If you have any questions feel free to contact me.

Best regards Joakim

________________________________ From: Per Forsgren Sent: den 6 mars 2009 09:24 To: Alex Abrokwah; Joakim Bolme; Wilfred Chikati Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; PLMBTS Subject: RE: CSR 1089539 - Poor SDCCH Establishment Hello Alexander,

There are no other issue we know of that behaves the way you have explained, and I am afraid that the only way for us to firmly establish the cause of these spikes is to have an Abis-log (as well as the other information requested by Joakim 24 February 2009 12:46) from the time where the spike occurs.

Basically this means that you would need to find a site where these spikes occur frequently and start periodic Abisrecordings, so that one log file is recorded each hour. Then you need to monitor hourly stats from STS to know when the spike has occured. Besides a rather complicated setup this also requires you to have a protocol analyzer with sufficient memory capacity.

BR / Per

________________________________ From: Alex Abrokwah [mailto:Alex.Abrokwah@tigo.com.gh] Sent: den 5 mars 2009 16:35 To: Per Forsgren; Joakim Bolme; Wilfred Chikati Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; PLMBTS Subject: RE: CSR 1089539 - Poor SDCCH Establishment Hello,

Yes, we only implemented the MAXTA changes.

And now the tiGO Ghana Network has its own synchronization clock which has been integrated and tested. So the issue with synchronization is no longer present.

Per, We see this problem across the entire network and not just a few cells. Plus if there is a spike in one cell you dont necessarily see spikes in its neighbouring cells.

BR. Alexander Abrokwah

From: Per Forsgren [mailto:per.forsgren@ericsson.com] Sent: 05 March 2009 15:27 To: Alex Abrokwah; Joakim Bolme; Wilfred Chikati Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; PLMBTS Subject: RE: CSR 1089539 - Poor SDCCH Establishment

Hi everyone!

I have one quick comments here:

When there are certain MSs that repeatedly try to access the system this will typically affect intermittent effects across a number of cells in a network. When the MSs enters this faulty mode it will not be able top perform Location Update to any cell, and will thus room around on various cells, even when staying in one position. This is also exactly what we saw in Portugal.

Your observation thus strengthens the suspicion that these spikes of high SDCCH failure rates are due to MS issues.

As a side note: I don't think we recommended to move SDCCH into non-hopping channels, as this did not turn out well when we tried it in RUSSIA3. Our second recommendation was to "Ensure that Synchronization is fulfilling the GSM soecifications, and that only one synch source is used across the network, or use GPS synch on site".

BR / Per

________________________________ From: Alex Abrokwah [mailto:Alex.Abrokwah@tigo.com.gh] Sent: den 5 mars 2009 15:54

To: Joakim Bolme; Wilfred Chikati Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; PLMBTS; Per Forsgren Subject: RE: CSR 1089539 - Poor SDCCH Establishment Hello Joakim,

Yes I have gone through the mail from Per Forsgren. And from the analysis made on SPINTX1 it can be agreed that the spikes in SDCCH Establishment could be due to some particular MSs. But this conclusion does not hold because we have this problem of SDCCH failure due to CESTIMMASS present in cells throughout the network. Its worst for some cells than others. Also some cells intermittently have very high failures due to CESTIMMASS. How do we explain this also, because the frequency of occurrence of this high failure is quite high. Also from the STS I sent you the second time (SPINTX and ASZENU) SPINTX3 and ASZENU3 had the worst SDCCH Establishment but there were no comments on analysis based on those cells.

When Per Forsgren visited Ghana to look at this problem there were two recommendations given: Optimization of our MAXTA settings across the network Moving SDCCH into the non-hopping channels.

These recommendations were effected but there was only a marginal improvement in the SDCCH Establishment.

I would therefore be glad if the SPINTX3 and ASZENU3 stats can be looked into and recommendations given. For ASZENU3 you said the SDCCH establishment was 88% but no recommendations were given.

Thanks

BR. Alexander Abrokwah

From: Joakim Bolme [mailto:joakim.bolme@ericsson.com] Sent: 05 March 2009 12:29 To: Alex Abrokwah; Wilfred Chikati Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; PLMBTS; Per Forsgren Subject: RE: CSR 1089539 - Poor SDCCH Establishment

Hi Alex,

As I haven't received any feedback from you I'm planning to close the CSR tomorrow with suggested actions. If you have any objections get back to me a.s.a.p.

Best regards Joakim ________________________________ From: Joakim Bolme Sent: den 3 mars 2009 13:48 To: 'Alex Abrokwah'; Wilfred Chikati Cc: Ronke Adelanwa; Areta Nwosu; 'Magnus O. Cofie'; PLMBTS; Per Forsgren Subject: RE: CSR 1089539 - Poor SDCCH Establishment Hi Alex,

Hope that Per Forsgren e-mail gave a good explanation to this mobile issue and also some suggestions to you other problems.

What is your suggestion on how we should continue the investigation in this case? From our point of view we believe that an explanation have been presented, and that this is the cause of your problems.

If this is ok by you we will close the CSR. If you have any questions or objections feel free to contact me.

Best regards //Joakim

________________________________ From: Per Forsgren Sent: den 26 februari 2009 15:14 To: Alex Abrokwah; Joakim Bolme; Wilfred Chikati Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie Subject: RE: CSR 1089539 - Poor SDCCH Establishment Hi Alex,

I was on site in Portugal when we discovered the issue with a handset that repeatedly unsuccesfully accessed the network, and there damaged that Establishment Rate for a number of cells at the time.

The reason we suspect that you may have this issue in SPINTX2 is that there is a sudden, very significant influx of failed SDCCH attempts. In order to prove this we would need to have an Abis-log taken from the time when the issue occurs, which of course is very difficult as you never know when this will happen. For more information on this issue, please see attached presentation (SDCCH Issue MS Fault)

The bad news with this issue is that there is no known workaround. The good news is that it has limited system impact as long as it does not result in SDCCH blocking.

I suggest the following:

- As it is very time consuming to establish to 100% that indeed you have the problem "repeated failed accesses from faulty handsets", and there is no know solution I propose that we leave as a well founded suspicion and focus on the problems we can actually rectify.

- That leaves us with two issues:

At SPINTX1 you seem to have a lot of RACHs with either illegal cause value or too high Access Delay. This could be due to Co BSIC/BCCH intereference. I suggest that the BSIC value is changed to see if the situation improves.

In the cells that we priorly received Abis-logs from my firm conclusion is that the poor SDCCH performance is due to poor signal quality/high interefernce levels. At these sites the only way to improve the SDCCH performance is to reduce the interference levels.

Best Regards / Per Forsgren

________________________________ From: Alex Abrokwah [mailto:Alex.Abrokwah@tigo.com.gh] Sent: den 26 februari 2009 11:28 To: Joakim Bolme; Wilfred Chikati

Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; Per Forsgren Subject: RE: CSR 1089539 - Poor SDCCH Establishment Hi Joakim,

Please find attached the printout for the commands requested.

The two cells with poor SDCCH Establishment were Spintx3 and ASZENU3 (as you noted).

I would be glad if you could elaborate on the mobile issue found in Portugal.

Please let me know if you need any further information.

BR. Alexander Abrokwah

From: Joakim Bolme [mailto:joakim.bolme@ericsson.com] Sent: 24 February 2009 12:46 To: Alex Abrokwah; Wilfred Chikati Cc: Ronke Adelanwa; Areta Nwosu; Magnus O. Cofie; Per Forsgren Subject: CSR 1089539 - Poor SDCCH Establishment

Hi Alex, This is what we have found from the attached files. - In the STS date we can see that ASZENU3 has low access rate approx. 88%. - SPINTX1 seems to have a very high Random Access Fail Rate. This could be due to RACH from MSs locked to another cell, ie. co BCCH/BSIC interference. - SPINTX2 is having problem both with acces rate and high Random Access Fail Rate during a dew hours on Feb 56th and Feb9th. Picture (Enhanced Metafile) This could be related to that mobile issue that was seen in Portugal. In the attached RBS logs we can not see anything abnormal. We will need some additional information to be able to trouble shoot on this further, see below. If you have any questions feel free to contact me. - STS data

- Abis log with CF and TRX signaling from all TRX'es - RBS log and Idb - Also attach following BSC printouts RXCDP:MO=RXOTG-<tg>; RXMSP:MO=RXOTG-<tg>,subord; RXAPP:MO=RXOTG-<tg>; RXMOP:MO=RXOTG-<tg>; RXMOP:MO=RXOTRX-<tg>-<trx>; RXMOP:MO=RXOTX-<tg>-<trx>-<tx>; RLCRP:CELL=<cell>; RLCFP:CELL=<cell>; RLDEP:CELL=<cell>; Best regards Joakim PLMBTS Hlsningar / With Best regards Joakim Bolme Senior Support Engineer PLMBTS Market Support Ericsson AB PDU BTS, GSM System Telephone: +46 10 71 75529 (Fixed and Mobile) Fax: +46 8 404 59 24 http://internal.ericsson.com/page/hub_radionetwork/unit/pdu_bts/operations/operations.html <http://internal.ericsson.com/page/hub_radionetwork/unit/pdu_bts/operations/operations.html>