You are on page 1of 14

Troubleshooting for Congestion

Congestion is the conflict resulted from the shortage of resource due to various reasons. The resource involved in congestion at BSS side can be divided into to two classifications: wire resource and radio resource. For example, A !nterface circuit congestion and Abis !nterface circuit congestion belong to wire resource congestion. The wire resource congestion mainl" refers to A !nterface congestion and the A !nterface congestion might be accompanied with radio signaling channel congestion. The radio resource congestion mainl" includes the congestions of various t"pes of channel, such as S#CC$, TC$ and A%C$. This document introduces the fundamental &nowledge, phenomenon and anal"sis of the congestion, and the troubleshooting.

Overview A-Interface Congestion
A !nterface is the interface between BSC and 'SC. So the A !nterface congestion is the most critical among all congestions and it affects all BTSs of the BSCs involved with this A !nterface. The A !nterface congestion is presented b" the following: () Subscribers cannot ma&e call in most cases. *) The radio signaling channels of all BTSs are congested simultaneousl". The channel state observed from BTS maintenance s"stem shows that all S#CC$s are bus" and the situation seems to be unable to release in a short time. At the same time, the traffic channels are rather idle. +) BSC C,- occupanc" ratio maintains high and it can reach up to ./0 or more than ./0 in a ver" short time. 1) All or most A !nterface SS2 signaling lin&s are in interrupted state. Caution: !n the case A !nterface SS2 signaling lin& flashes on3off or it is interrupted in a long period, or in the case of S#CC$ d"namic ad4ustment and channel overload or high C,occupanc" ratio, be calm to solve the problem according to the guide provided in this document. !f the methods are correct, the s"stem can be recovered smoothl".

Overview Radio Channel Congestion
The radio channel congestion refers to the congestion of pure radio channel resource, i.e., individual BTS rather than large area. Classified according to the channel t"pe, radio channel congestion includes congestion of common channel 5such as ,C$ and A%C$), and congestion of dedicated channel 5such as S#CC$ and TC$). %enerall", if the 6A is

the bus" hour congestion rate does not exceed 70. All statistic items of these two functions should be registered and the statistic c"cle is (7 minutes at most. tas& and . 7) T89 fault :) !nterference resulting in channel assignment failure Locating A-Interface Congestion Check whether the traffic statistics tasks related to A-Interface signaling performance are being measured There are three related traffic statistic tas&s: . common channel congestion rarel" occurs.'T. .. !t is recommended that the . tas&. ..BSC 'easurement Function. tas& is used to measure the items related to paging. location for festival gathering and the time for short messages being intensivel" sent etc. . tas& ob4ect is the SS2 lin&s of all modules. !f S#CC$ or TC$ bloc&ing rate of a cell is obviousl" high. After the problem occurs. it can be concluded that the congestion occurs.SCC.BSC 'easurement Function. And this tas& can contain onl" the statistic items related to paging so as to facilitate the anal"sis when the problem occurs.SCC.. 'easurement Function. So this document mainl" describes the troubleshooting for dedicated channel congestion. This tas& can onl" contain the statistic items related to paging. 1) !ncrease of burst traffic. This is a supplement to observing A !nterface signaling flow. ote: !n an" case. and . tas& whose statistic c"cle is (7 minutes should be registered. 'easurement Function.C$ overload times.BSC 'easurement Function.properl" planned and the proportion between ..'T. !udge whether A-Interface signaling overloads through traffic statistics . tas& whose statistic c"cle is (7 minutes should be registered even in normal s"stem running state. such as .page re<uest times.BSC 'easurement Function. a .'T. !n normal circumstance. 'easurement Function. .. The congestion is mainl" caused b" the following: () -nreasonable 6A planning. *) Terrestrial resource unavailable +) Traffic volume is large and the capacit" expansion is needed. and .C$ and A%C$ is proper. BSC should register .page re<uests from 'SC. 'easurement Function. To 4udge whether the channel congestion occurs mainl" is to chec& the channel bloc&ing rate in traffic statistics s"stem. $ereafter the channel congestion refers to dedicated channel congestion. 'easurement Function. li&e the remote railwa" station.

Troubleshooting A-Interface signaling uplink overload !f A !nterface signaling downlin& does not overload. =bserve BSC>s .'T. this indicates that 'SC sends too man" messages 5generall" a large amount paging messages) to BSC. 'easurement Function. must find wa"s to release the overload.Signaling lin& receiving rate 50). of some or all SS2 signaling lin&s exceeds 1/0. this indicates that BSC sends too man" messages to 'SC. So this results in the downlin& overload of A !nterface SS2 signaling lin&. number of lin&s should be increased.. $owever. !n the case the uplin& overload occurs. tas& reflects the average situation of 'T. of some or all SS2 signaling lin&s exceeds 1/0. !f an A !nterface signaling lin& has been bro&en for a long time.C$ overloads can be seen from the statistic result of .Signaling lin& sending rate. whether the congestion occurs and where the congestion occurs can be &nown. 'easurement Function. Troubleshooting A-Interface signaling downlink overload .'T. B" comprehensivel" anal"?ing the problem. 'easurement Function. !f both the uplin& and downlin& overload. !f the . But if the . there is little possibilit" for the uplin& overload. So this results in the A !nterface SS2 signaling uplin& overload. !f detecting the lin& overloads in routine maintenance. The multiple times of burst lin& congestion might not ma&e the average result exceed the standard range.BSC 'easurement Function. tas&. The statistic result of . this case rarel" happens. observe the statistic result measured before it is bro&en. this might be caused b" the abnormalit" of A !nterface SS2 signaling downlin& load. =nl" after . inform 'SC maintenance personnel to handle the problem.Signaling lin& receiving rate 50). !f onl" downlin& overloads. tas&. temporaril" close some BTSs of the module where the overloaded lin& is located. !f the . it is impossible that uplin& overloads but downlin& does not overload. lin& sei?ure in a statistic c"cle. ote: 1/0 is a dangerous warning limit for the lin& load capacit". The number of signaling lin& interruptions due to congestion also can be seen from other statistic items of . !n the case the s"stem runs normall".Signaling lin& sending rate. it is impossible that the uplin& overloadsA even if A !nterface signaling downlin& overloads. is *@+ times as that measured in normal case and fre<uent .There are man" examples in which lin& flashing on3off or lin& interruption in a long period is caused b" the downlin& overload of A !nterface signaling. becomes lower than 1/0 should closed BTSs be started up.'T.

do not reset the BTS. !n this case. The cause of 'SC sending overlarge number of pagings to BSC might be 'SC3B68 fault. After CSS problem is solved and A !nterface signaling lin& is recovered. The direct cause of A !nterface signaling downlin& overload is generall" overlarge paging volume. no response from remote. no need to ta&e an" action and the s"stem will automaticall" recover. there will be a large number of messages sent at A !nterface and this will result in A !nterface signaling downlin& congestion. then "ou ma" reset these important BTSs. Cormall" there should be some complete 6A updating procedures or call procedures and this indicates that the BTS signaling lin& congestion is being released. !f no complete 6A updating or call procedure can be seen within a long time. The reset will onl" dela" the congestion release.There are man" cases of this problem. or use the signaling anal"tic instrument to trace the Abis !nterface signaling of some cells. and there are large number of . observe the statistic result of . 'easurement Function. tas&. !f this condition cannot be met. Supposed that transmission of all BSS BTSs has been interrupted or BSS service has been being interrupted for a long time due to other reason. Dithin the (/ minutes after the interruption is recovered. "easures for signaling link not overloaded !f this problem occurs. BSS will automaticall" and graduall" recovers within a certain period of time. immediatel" contact the 'SC maintenance personnel to solve the problem. "ou ma" unplug the E(s of some BTSs to speed up the recover". this indicates that BTS wor&s abnormall" and it is necessar" to reset the BTS.SCC. the BSC maintenance personnel should immediatel" contact the CSS maintenance personnel to locate the problem source at CSS side and then ta&e effective solutions. !n this case. "ou ma" perform Abis !nterface signaling tracing for a certain cell through BSC maintenance s"stem. !f "ou want to speed up the congestion release for important BTSs. !f C8 messages 5=) F C8 messages 5!) G C8EF messages 5!) and the difference is obvious. #uring the resetting. !n this case.SCC. 'SC signaling processing probabl" is fault". the 'Ss waiting for 6A updating or the 'Ss in conversation state can complete the necessar" procedure through these ad4acent cells. #e active to learn the running status of other #$$s . or S'C suddenl" sends overlarge number of point to point messages. !n the case that these important BTSs have other ad4acent cells whose congestion has been released. alarms. there are methods for different conditions. After A !nterface signaling lin& recovers. !n this case.

II& . Congestion Resulted from LAC I ' I& )escription The S#CC$ congestion rate of two cells of a BTS reached 1.H(0. To understand the range of the problem is helpful for problem locating. the traffic volume reached (.andling process () Chec&ed the statistic items related to TC$ and S#CC$ measurement function. The configuration of this BTS was S 5(3(3() and the TC$ traffic volume of each cell did not exceed +Erl at bus" hours. it can be concluded that the fault is located in CSS side. .H(0.!f there are other BSSs within the same 'SC and the same location area 56A).:Erl. !n this case. *) S#CC$ congestion rate I Attempted S#CC$ sei?ures meeting an S#CC$ bloc&ed state3Attempted S#CC$ sei?ures 5all). the possible causes for S#CC$ sei?ure are: 5a) The signaling before the conversation is established 5b) Signaling in handover 5c) Signaling of 6A updating in 'S idle mode. Locating Radio channel Congestion Anal%sis  Congestion due to unreasonable 6A planning  6arge traffic volume resulting in S#CC$ congestion and TC$ congestion  S#CC$ congestion resulted from increase of burst of traffic volume  Congestion resulted from T89 fault  Congestion resulted from interference  Congestion resulted from terrestrial resource unavailable i& CO '($TIO )*( TO * R(A$O A#L( LA +LA $)CC. but the number of S#CC$ sei?ure re<uests was high and it reached +/+* at bus" hours. !f it is found that multiple BSSs have the same problem regardless their manufacturers and if no the same operation has been performed for all fault" BSSs. The result showed that TC$ traffic volume was low.. the on site maintenance personnel ma" also learn the running status of other BSSs. immediatel" contact CSS maintenance personnel to report the fault. and the congestion rate reached 1.

the congestion rate was / and traffic volume was /. After the modification at BSS side.2HErl) 5Cumber of available TC$s was :)A the number of attempted TC$ sei?ures 5excluding handover) was normal 5+(. the 6AC border should be located in the most outer site instead of in the site with high traffic 5such as the border area) so as to reduce the fre<uent 6A updating. 1) The 6AC of this BTS was /7// and the 6AC of the ad4acent cells was /7*/.+) As TC$ traffic volume was normal 5*. So the great number of S#CC$ sei?ures was probabl" caused b" lots of 6A updating.OL*"( R($*LTI ' I TC. CO '($TIO A ) Anal%sis +ossible causes: • • The traffic volume of S#CC$ and TC$ is larger than the normal value. The congestion was solved. The congestion is resulted from the burst traffic increase li&e the locations for festival gathering and entertainment show etc. %enerall". the corresponding modification at 'SC side should also be made. CO '($TIO $)CC. tr" to use the subscriber>s geographical distribution and subscriber>s behaviors for 6AC division so as to reduce the 6A updating at the border of the 6AC. !t is recommended the T89s of a 6AC should not exceed +//. III& Conclusion () !n the 6AC planning..*2Erl. the 6AC boarder should be bevel instead of being parallel or vertical with the street. The 6A range cannot be too large or too small. )iagnosis method: Chec& the traffic volume of the congested cell through BSC traffic statistics s"stem. if there are two or more than two 6ACs. the division can be made based on the geographical features such as mountain and river to reduce the overlapping depth between cells of different 6ACs. Troubleshooting: . the division based on street or the border locates at the place with high traffic 5such as shopping center) should be avoided. Then number of attempted S#CC$ sei?ures was *H. Change the 6AC of this BTS to /7*/. For the border area between the cit" and suburb.)A and the number of attempted handovers was normal 5(1:). ma&e sure that the cells with the same C%! should not exist. *) To modif" 6AC number. ii& LAR'( TRA--IC . For the large cit" with high traffic. !f these geographical features are not available. to avoid fre<uent 6ocation updating.

Besides. iii& $)CC. !n addition. The S#CC$ congestion is also li&el" to occur at the time for messages being intensivel" sent. For the congestion resulted from burst traffic. the transmission interruption recover" ma" also cause the same problem. But "ou ma" ta&e some measures to release the congestion.OL*"( R($*LT() -RO" I CR(A$( O. )iagnosis method: Chec& whether S#CC$ bloc&ing rate and traffic volume are over high and TC$ traffic volume is normal or lightl" low but there are TC$ channel re<uests through BSC traffic statistics s"stem. onl" S#CC$ signaling is used so TC$ congestion is not caused. !n this case. Chec& whether 6AC configuration is reasonable. the expansion is the onl" solution. 'oreover. CO '($TIO TRA--IC . iv& CO '($TIO R($*LT() -RO" TR/ -A*LT Anal%sis +ossible causes: . the unreasonable 6A planning might also result in S#CC$ congestion due to the excessive 6A updating. such as to increase the configured S#CC$s and to enable the d"namic ad4ustment between S#CC$ and TC$. TC$ traffic volume is rather small. "ou ma" enable the directed retr" function to assign the calls to the channels of the ad4acent cell. Troubleshooting: This problem is hard to be avoided. as S#CC$ is congested.For the normal increase of traffic volume. resulting in S#CC$ congestion. especiall" at the railwa" station near the tunnel. in the condition that the congested cell has the appropriate ad4acent cell. For example. !n above two cases. !n addition. Dhen the train passes b" this station or stops at this station. whether the capacit" expansion is needed depends on the operator. !f the 6AC is unreasonable. the configured capacit" is limited. As these areas are remote. large number of 'Ss dropped from networ& performs 6A updating.#*R$T O- Anal%sis +ossible causes: • • This situation mostl" occurs at the area along the railwa". modif" the configuration. some measures can be used to release the congestion. the transmission problem should be solved first.

1) After the assignment fault has been excluded. chec& whether the antenna J feeder connection is correct and whether antenna J feeder BSD8 is normal. it might be that the T89 is damaged or antenna J feeder connection failure. !f "es. if there is TC$ signal coverage near the cell and the TC$ fre<uenc" is the same as BCC$ fre<uenc". !n this case do not directl" reset the T89. bloc& the suspected T89. For example. the interference signal also is decoded into access signal and this leads to S#CC$ congestion. v& CO '($TIO R($*LT() -RO" I T(R-(R( C( Anal%sis +ossible causes: The interference on radio interface can result in congestion. Chec& whether the unbloc&ing can solve the problem.!n the case a T89 of a multi T89 cell is out of service. !f ever"thing is normal. *) 8eplace the T89 that is surel" fault" as indicated in the alarm. 7) For the T89 without abnormal alarm but the cell where the T89 is located is congested. it is certain that the T89 is fault". )iagnosis method: . replace the T89 to verif" whether the T89 is fault". For the uncertain T89. +) !f T89 is normal but the channel is constantl" in !#6E state. *) Chec& whether the state of the channel with T89 is B or =. and no traffic occurs within a long time and the assignment to the channels of this T89 fails. %enerall" it is uplin& 8x channel fault. Troubleshooting: () !f the congestion seems to be resulted from assignment causes. this ma" lead to the channel congestion. the assignment might be fault". chec& whether there is T89 alarm 5the state of the board is in red color). the handover access on this TC$ might be decoded into random access and this leads to S#CC$ congestionA in the circumstance that the 8x sensitivit" is ver" high. this indicates the bloc&ed T89 is fault". !f the cell congestion is solved. solve the assignment problems. )iagnosis method: () After the possible traffic causes have been excluded.

)iagnosis method: Chec& the proportion of the congestion caused b" . number of S#CC$ re<uests obviousl" increased. *) Chec& the interference band statistics to see whether the interference exists. !n principle. Then chec& the A !nterface and Abis !nterface data configuration to solve the terrestrial resource problem. the congestion might be caused b" cable connection fault. Troubleshooting: 'odif" data configuration to eliminate the interference.AILA#L( R($*LT() -RO" T(RR($TRIAL R($O*RC( Anal%sis +ossible causes: The occurrence of A !nterface or Abis !nterface fault during the channel assignment can result in the assignment failure and the cause is . . This can also have impact on congestion rate.territorial resource not available.. through BSC traffic statistics s"stem. Troubleshooting: 'odif" data configuration. Dhen the congestion occurred. (/A"+L($ A& $)CC.() Chec& the data configuration to see whether an" TC$ fre<uenc" uses the near BCC$ fre<uenc". TC$ should not use the fre<uencies of BCC$ fre<uenc" set. vi& CO '($TIO * A. !f the data configuration is correct. Congestion Resulted from Co-fre0uenc% Interference I& )escription Burst S#CC$ congestion at a BTS often occurred.territorial resource not available.

S#CC$ congestion occurred. The baseband and 8C attribute of this cell were normal and nothing abnormal could be found through maintenance console. 1) The congestion disappeared after B cell>s BS!C was modified on site to ma&e it different from A cell>s one. II& . #& A Cell1s Congestion Rate is too .andling process !n principle. III& . besides the S#CC$ congestion.robabl" the B cell>s 'S that was located somewhere between A cell and B cell was performing handover access and the access to B cell is hard. =therwise. The statistic result of the statistic tas& 5the statistic c"cle is *1 hours) showed that the TC$ congestion rate of this cell is (70@:/0 and the congestion occurred almost ever" hour. over :/ S#CC$ re<uests are reported within +//ms and the re<uests are the same. it is found that the TC$ fre<uenc" of a cell 5cell B) (/&m from this cell 5cell A) is the same as BCC$ of cell A and the BS!C of B cell is also the same as that of cell A. Therefore. the traffic statistic result of this BTS showed that the TC$ bloc&ed state in a cell 5: T89) was ver" serious. *) After the data configuration is chec&ed. The assignments for the first several re<uests failed and other re<uests were re4ected.. BCC$ signal also has interference on the TC$.. the traffic volume of this cell was ver" low 5usuall" it was about /. +) .igh I& )escription A BTS>s configuration was S5 :313* ).!dle. . so the handover access signal is decoded into random access and A cell allocated channels for ever" re<uest.Erl at bus" hours)A at the same time attempted TC$ sei?ures meeting a TC$ bloc&ed state was /. TC$ should not use the fre<uencies of BCC$ fre<uenc" set. Dhen the congestion rate was high. The channel state of all basebands in this cell was .andling process () Chec& the channel state of BT through far end maintenance console so as to primaril" 4udge that TC$ sei?ure failure occurs in BT1 and BT7 of this cell. From a certain date.II& Anal%sis () The on site signaling tracing found that: when the congestion occurred. So this resulted the congestion.

Congestion Resulted from Transmission I& )escription The S#CC$ of a newl" built BTS was mostl" in bus" state while the TC$ in !#6E or bus" stateA the conversation after the successful dialing was normal. There were 6A. The number of S#CC$ allocation failures was about (. :) 8eset 8C1 5T891) and 8C7 5T897). chec&ed the statistic result measured at the last night. attempted TC$ sei?ures. as well as 8C1 and 8C7. II& Anal%sis The common causes for S#CC$ congestion are as follows: • • • #ata configuration error Cumber of S#CC$s is not enough 8F fault . Exchanged T891 with T897 and then the dialing test for the loc&ed fre<uenc" 5on T891 and T897) showed that TC$ sei?ure failure remained. the port indicator flashed occasionall". This indicated that the 8C1 and 8C7 were fault". The statistic c"cle is +/ minutes. H) !n the second da". 2) Dent to the BTS site to unplug3plug T891 and T897.) 8eplaced T891 and T897. BT7. The dialing test for the loc&ed fre<uenc" 5on T891 and T897) showed that TC$ sei?ure failure remained. #uring the self loop of B!E. 1) At the night of the following da". C& $)CC. Then the dialing test for the loc&ed fre<uenc" 5on T891 and T89 7) showed that no TC$ sei?ure failure occurred. The problem was solved. the statistic result of the tas& registered in step+ showed that there was no TC$ congestion./// per hour 5at bus" hours). This tas& should contain the following statistic items: TC$ Sei?ure failures. . 8C1 and 8C7. TC$ congestion was not found in all periods.*) Bloc& BT1 and BT7. !n the second da".# failure alarm and its recover" alarm 5interval between these two alarms is within ( second) and these two alarms were generated ever" (/ minutes. TC$ congestion rate and attempted TC$ sei?ures meeting a TC$ bloc&ed state. the statistic result of the tas& registered in step+ showed that the congestion still remained. 7) -nbloc& BT1. +) 8egister a traffic statistic tas& for this cell.

Congestion Resulted from Lots of #urst LA *pdating I& )escription !t was found that in one BSC the radio connection success ratio was low. a traffic statistic tas& whose statistic c"cle was 7 minutes was registered. The statistic result showed that the 6A updating was mostl" concentrated in a certain 7 minutes.E8 $=-8 in the cell where the congestion occurred at bus" hours. one *'$? transmission board in the access networ& where this BTS passed was found to be fault". II& . Then the statistic tas& related to transmission was registered but the statistic result showed that nothing was abnormal. S#CC$3. +) 8eplaced the T'. After consulting the train timetable. Each cell was configured with . And the problem was solved after this *'$? transmission board was replaced. But several decades of S#CC$ congestion occurred in each cell at bus" hours. the same problem still occurred in this BTS and the other BTS+/ wor&ed normall".andling process () Co problem was found during the data chec&ing. The configuration of the BTS was S 5 (3(3( ). 1) The transmission test was performed 5another newl" built BTS had the same problem).and T89 of this BTS but the problem remained. The test found that there were transmission errors. +) To verif" this possible cause. )& $)CC. it was found that there were . The statistic result showed that most of S#CC$ sei?ures were caused b" 6A updating. *) This BTS was far from BSC. The anal"sis of traffic statistics showed that the problem was mainl" caused b" the S#CC$ congestion of some specific BTSs. So the possible data error and hardware fault at BSC side could be excluded. it was found that most BTSs that had this problem were located at the border of two 6As along the railwa". The traffic statistics of S#CC$ was still abnormal. So it might be the S#CC$ congestion was caused b" burst 6A updating. After the B!E port of this BTS was exchanged with that of other BTS+/. For the site location. After the test section b" section. channels.• • Co TC$ or severe TC$ congestion Bad transmission <ualit" III& . *) A related traffic statistic tas& was registered.andling process () The traffic statistic result showed that there ware +//@1// S#CC$ sei?ures . Cormall" this configuration could support +//@1// S#CC$ sei?ures.

So lots of 6A updating was performed in a short time when the train passed b" and this resulted in the congestion. enable the S#CC$ d"namic allocation function. 1) 'ore S#CC$s were configured. there were man" TC$ sei?ure failures in each cell in traffic statistics. 7) As the man" cells of this module had the same problem. . The deterioration of the congestion rate of this module lowered the deterioration of the whole networ&. 1) The main cause for re<uested terrestrial resource unavailable was the fault at Abis !nterface or A !nterface. the possibilit" for Abis !nterface to be fault" was little. This indicates that the re<uested terrestrial resource unavailable is the main cause for the high TC$ congestion rate of this module. "ou must have a definite ob4ect in view. So the" needed to be chec&ed.andling process () The version upgrade and networ& expansion had been made not long before. As there are so man" data.igh TC. So the fault was primaril" located in this module and this module should be anal"?ed with emphasis.1@7 trains passing b" in this 7 minutes. The further anal"sis of the cause for too man" TC$ sei?ure failures showed that most of TC$ sei?ure failures were TC$ sei?ure failures 5re<uested terrestrial resource unavailable). TC$ congestion rate 5excluding handover) reached 10. the redundant S#CC$s should be configured. *) The problem might be related to the modification of data configuration. (& . So the emphasis was given to the related hardware or data of A !nterface. III& Conclusion () For the BTS located in the border of two 6As along the railwa". Congestion Rate Resulted from Incorrect CIC $etting I& )escription The TC$ congestion of an office &ept high. The anal"sis of the traffic statistics at bus" hours of the current da" showed that the cells with high congestion rate mainl" concentrated in one module of BSC(. *) For the S 5(3(3() BTS. +) As TC$ congestion rate 5excluding handover) I TC$ sei?ure failures 5excluding handover)3 Attempted TC$ sei?ures 5excluding handover). The TC$ congestion rate before the version upgrade is low. This module controlled the most BTSs of this cit". II& .

) !t was found that the C!C of the first +* timeslots of this module group / was :77+7 but the circuit of this module group / was corresponding to the circuit from BSC to 'SC. sorted the data and then chec&ed. =pened the trun& circuit table. #"namicall" set the circuit number to be /@+(. H) The traffic statistic result in the following da" showed that the cell congestion rate of this module was lowered. 2) Then chec&ed the data configuration of the trun& of this module. So it was obvious that the C!C number was incorrect. the TC$ sei?ure failures 5excluding handover) of each cell were greatl" decreased and the congestion rate of the whole networ& 5excluding handover) was dropped from 10 to *0. . .:) Co fault was found in chec&ing A !nterface hardware of this module.