- This topic has 13 replies, 1 voice, and was last updated 13 years, 6 months ago by ako.
19th March 2008 at 10:49 #51596ShaonGuest
In dive test I have found in some special case where mobile cannot decodes BSIC but Rx Level is satisfactory. At this condition handover and cell selection donot occur.Can anyone help me regarding this matter?19th March 2008 at 11:19 #51597BilalGuest
What about C/I there?19th March 2008 at 12:17 #51598pixGuest
the BA list contains the list of neighbor BCCH frequencies, for instance 4 neighbours = 12, 15, 21, 26
during drivetest in the serving cell, the ms listens to these 4 frequencies continously.
Now imagine the situation where the ms enters an area, where it receives a frequency ’26’, but this freq belongs to a TCH from another distant cell actually. In this situation, there is no BSIC to decode.19th March 2008 at 12:36 #51599BilalGuest
Are you sure TEMS shows rxlev of every BA list frequency whether it is a BCCH or not? Till now my concept is that TEMS only shows the RXLEV of a frequency where it finds FCH and SCH and that is a BCCH.19th March 2008 at 13:23 #51600fedexGuest
yes indeed this is a strange situation.
The check on BSIC should perforrmed every 30 sec only !
The MS shall attempt to check the BSIC for each of the 6 strongest non-serving cell BCCH carriers at least every
30 seconds, to confirm that it is monitoring the same cell. If a change of BSIC is detected then the carrier shall be
treated as a new carrier and the BCCH data re-determined.
—————————-20th March 2008 at 05:43 #51601ShaonGuest
Well,so far I know this type of situation occcurs when there is strong interference. Thats why Bilal asked for C/I. Its impossible to find C/I of that cell as it will never be a serving cell untill its BSIC is decoded. I appreciate Pix for nice concept of TCH. But it is not possible bcause the site is almost standalone. Besides this some other problems arise in that site.
1.Handover not occured considering HOM=69
2.Call establishment problem
So I think the problem lies in Hardware may be combiner or CU.20th March 2008 at 06:55 #51602BilalGuest
Can you check ICM stats for the site? It can give you a clue if interference is the problem.20th March 2008 at 07:00 #51603AskariGuest
The problem usually occurs if that target BCCH is interfered. Since MS has to listen to that BCCH and send the decoded BSIC. If two neighbours closeby have the same BCCH with different BSIC then MS shall either not be able to decode bsic or show two different BSICs at different locations near sites.
If BSIC is not decoded / BSIC is decoded other than the one specified in the Neighbour list HO shall not be trigerred.20th March 2008 at 08:48 #51604paraHOGuest
If it can help instead of problem at receiver it may be transmitted… what if it not decoding problem but sent bsic identity at fault?
Just making thoughts…20th March 2008 at 10:06 #51605SahaonGuest
Analyzing this problem we found that pcm link is flucktuated 36 times in one hour. May be this is the problem as all hardwares are ok and no database inconsistency found.20th March 2008 at 10:09 #51606BilalGuest
I am unable to link PCM fluctuation with BSIC problem. Any thoughts?20th March 2008 at 10:37 #51607ShaonGuest
Probably at the time of flucktuation BSIC is not decoded20th March 2008 at 11:03 #51608ShaonGuest
hi all, actually one of our customer find a similar problem that after all the PCM link is down they got the signal of that BTS in the neighbor list, sometimes with & sometimes without BSIC. They forced to clamp that cell from MS and tried to make call from that but couldn’t.
thats why I m trying to relate this BSIC problem with PCM fluctuation.
Any explanation to this scenerio!16th April 2008 at 07:13 #51609akoGuest
I have an experience before that with cases of fluctuating PCM link (Abis), there was and alarm generated in the BSC indicating SDCCH congestion. This was in Nokia BSCs.