- This topic has 22 replies, 1 voice, and was last updated 6 years, 9 months ago by anuj.
15th November 2010 at 10:25 #64976DenisGuest
Hello dear colleagues!
ALCALTEL Gurus, i need your help very muchh!
Please, explain me what is the difference between MC02a and MC02d ??????
I can’t understand the description of this evil counter !
MC02d – case: Location Update request (“follow on” procedure) Whenever an 48.058 ESTABLISH INDICATION message is received from a CELL, with the L3 INFORMATION field containing a 44.018 L3 message with an MIE message type set to LOCATION UPDATING REQUEST and with an MIE Location updating type not set to a RESERVED value and a bit FOR set to 1. This counter is incremented only if the L3 info message received has to be forwarded to the MSC.
As far as i know, ALL LU messages must be forwarded to MSC in order to update location info in VLR. Am I wrong?
The question is very very important for me. Thanx alot15th November 2010 at 19:35 #64977pixGuest
the LU follow-on is when the MS performs a LU and asks for a TCH at the same time : during the sddch phase, the location update is performed and then the BSC allocates a TCH to the MS, for the call.
Basically, the MS wants to do a LU and then a call. I don’t know when this ever happen, i can’t find an example… if you have any idea, you’re welcome to share.
In terms of counters : how many MC02d and MC02a are counted at busy hour ? MC02d should be very low.
pix16th November 2010 at 01:56 #64978DenisGuest
Thanx for quick reply, mr. Pix!
Actually, i have some cells where MC02d >> MC02a (but one is outstanding!!! and MC02d equal ~150-180/per hour by cell).
ANd it’s not a temporary situation i am watching it for a month at least.
i’m not satisfied because
Imm_Ass = (MC02 + MC01 – MC02a)/(MC04 + MC148 – MC964)
and for this cell it equals ~ 150%!
so Call Setup Successful Rate is also > 100%
excellent of course :)s
but i’m going to understand all this stuff 🙂
despite of that i don’t know right now how to investigate the problem
i will be very very grateful fo your futher help
once – million of thanks again!
Denis16th November 2010 at 10:47 #64979pixGuest
i’m interested to know why your MS’s are asking for LU follow-on procedure !
In 3GPP TS 44.018
LU follow-on means ESTABLISH INDICATION contains a L3 message with an MIE message type set to LOCATION UPDATING REQUEST and with an MIE Location updating type not set to a RESERVED value and a bit FOR set to 1.
I’ll try to check out the 3GPP again.
pix16th November 2010 at 13:07 #64980fresherGuest
I am new to this portal can u explain what is 3GPP and i want to go in deep in gsm how to start?16th November 2010 at 13:16 #64981pixGuest
for GSM, check out series 44 and 45.
click on serie 44
then go to release 8 part.
and click on 8.12.0
pix16th November 2010 at 20:57 #64982DenisGuest
Mr. Pix! Thanx alot
i always have troubles with 3gpp site – it’s a nightmare if i need something to find there – too many releases, versions and other stuff
You just saved me from that!
I’m reading 44.018 🙂
I have some ideas about mc02d and i think i’ll be ready to share them tomorrow.
best regards, Denis17th November 2010 at 10:34 #64983DenisGuest
Hi all! Hi mr.Pix!
What can i say now? Some things 🙂
1) for such cells E2E CSSR is VERY low (about 20-40%). Mr.Pix i saw you were interested in this question – maybe it can be interesting to you.
What a peculiar situation!!!
on one hand: “legal” CSSR is higher than best 150%!!
on other hand: E2E CSSR is lower than the worst 20-40%!!
2) all these SDCCH successful seizures (due to MC02d) do not go into a calls. i think so because for night hours mc02d is about 130-150 per hour but mc140a is usually low – 1-5 per hour. Am i right?
hm… could it be a cunning device?
i would get some – to “improve” our KPIs ))))))))17th November 2010 at 13:44 #64984pixGuest
nice to hear from you 🙂
mc02d is used in the formula of the E2E CSSR
( ((MC718) + (MC142e) + (MC142f)) / ((MC01) – NZ((MC191))+ (MC02e) + (MC02d) + (MC02f) + (MC02h)))
it is a right assumption to say that the bad E2E CSSR is caused solely by mc02d. However, you can check it by taking the raw counters and apply the E2E CSSR formula yourself. (though i don’t think it is necessary here, it seems obvious)
i don’t know why you have your MS’s sending LU follow-on requests. If you have the proper tools, maybe you would find it is one specific model of phone that is behaving like this ?
pix17th November 2010 at 14:45 #64985DenisGuest
i think the only thing i can do – is to collect Abis traces.
but i have no experience in analyzis. so i already have questions
below you can see the Message “CHNRQRD” – channel required 🙂
all I’m able to see is Reference number and it = 19.
but how i can define the cause for the request? and TA? according to all sources this message must contain such info.
E-GSM 08.56 (LAPD 4.0.2) (LAPD) INFO (= info frame)
——-0 Address field ext. 0
——0- Command/Response 0
000000– SAPI 0
——-1 Address field ext. Last octet
0000001- TEI 1
——-0 Frame Type Information transfer format
0010011- N(S) 19
——-0 Poll Bit don’t poll
0101110- N(R) 46
E-GSM Alcatel Abis RMS, Release B9, ED03 Released (RMS) CHNREQIR (= Channel required)
00001100 Message discriminator 12
G bits Common channel managment msg
T bit msg is to be/was considerd transp…
00010011 Message Type 19
00000001 IE Name Channel Number
—–000 Time slot number 0
10001— C bits Uplink CCCH (RACH)
00010011 IE Name Request Reference
00010011 Random Access Reference 19
00011— T1′ FN mod 32 3
***b6*** T3 FN mod 51 30
—11001 T2 FN mod 26 25
00010001 IE Name Access delay
–000001 Access delay 1
00—— Spare 0
Many thanxes17th November 2010 at 14:57 #64986DenisGuest
oh, i forgot – it’s from K15 trace. I decided to train myself in Abis trace analyzis :))
uh, unclear …
once more – many thanxes, mr.Pix18th November 2010 at 15:27 #64987pixGuest
the cause of the request (cause establishment) is received by the BTS in the Channel Request from the MS, but is not forwarded to the BSC in the Channel REquired.
I just found out about this thanks to your question.
So on the abis, you cannot know what is the cause of the establishment. However you can see it in the “Establish indication” which is sent a bit later. It is in the encapsulated protocol “DTAP”, “Message Type”.
The GSM phase 2/2+ MS may indicate in the LOCATION UPDATING REQUEST message that it has a
follow-on request pending. If the network reports to the MS in the LOCATION UPDATING ACCEPT (which arrives at the end of the SDCCH “DTAP” phase, after authentication and ciphering)that the MS can proceed its follow-on request then the MS sends a CM SERVICE
REQUEST to the network (message transparent to the BSS).
In the Estab Indication, do you see “follow-on” = 1?
In the Loc Upd Accept, do you see the field related to “follow-on request”?
It is the MSC that decides to accept the follow-on or not.
If MSC accepts it, then the MS will send a CM Service Request after it received the Loc Upd Accept from the network.
pix19th November 2010 at 09:41 #64988DenisGuest
Hello, mr. Pix!
Thanx you very much for your help!
But I’m confused a little because of definition of for example counter MC964:
“Number of valid 48.058 CHANNEL REQUIRED message, received by the BSC, indicating the location update in their “establishment cause”. MC964 is incremented to one whenever the “RA” octet (Octet 2 of Request Reference IE) of valid 48.058 CHANNEL REQUIRED equals to “000xxxxx (Location updating and the network does not set NECI bit to 1)”.
From here it looks like the BSC should know if it get a CHN_REQRD with cause “locating update is needed”. What do you think?
and what does it mean “”Request Reference IE””? is it a “”IE Name Request Reference
“” in that message i listed in previous post? so it is 00010011
I think i’ll collect trace in night – when there are no real subscribers’ calls (very little at least), only our “unusual” MC02d requests. i thinnk it will be easier to analyze. Is it correct?
oh, just one more thing – this cell i want to investigate locates deep inside of LAC zone not next to LACzone boundary.all neighbours have the same LAC. so why do we see so many Loc Up requests??
Many thankex again
BR, Denis19th November 2010 at 10:57 #64989PixGuest
MC92xxx are counted by the BTS, not by the BSC ! (new B10 counters…)
IE Name Request Reference = Random Access Reference = 19
Trace during night is a good idea.
If cell deep into the LAC, then I would assume those subscribers are could not connect to their operators and then they try to attach to your network in order to establish a call.
Check the IMSI/TMSI of those MS !
pix19th November 2010 at 12:21 #64990DenisGuest
What a great lamer in GSM am I !!
I will write about my result )))