[Pawa]

Hi dear experts!

In my network we use ALU B10 and recently faced a rather strange behavior from Samsung mobiles.
They can get only 1+1 for PS even if radioconditions are perfect and cell load for voice is very low. in the same moment in the same place just after test with samsung nokia N95 got 4+1 time-slots.
obviously i have different throughputs for these two cases.

moreover i tested several Samsung’s models: U700, Z720 and U600 too. all showed the same behavior.

Could it be because of some incorrect GPRS settings? Or other specific issues?
we have 40% of mobiles = samsung so is looks like a real problem

Please help, dear experts!!
thanks alot in advance

br, Pawa

[pix]

hi pawa,

I don’t see any ticket regarding samsung mobiles specifically.
But i know about some conditions in which a MS is granted only 1 PDCH per TBF.
Do you notice congestion on the Ater or Abis interfaces ?
-> Check “GCH deficit” per “BTS” (choose object mode = BTS in the NPO)
-> check busy GCH per Ater (object = Ater, or GPU)
-> What about in the MFS ? check DSP load and PMU power budget (per GPU) ?
What is the value of this parameter : Ater_Usage_Threshold_Short_Data

But if you tested other MS at the exact same time and they didn’t show this behaviour, then it is very probable that there is a problem with samsung MS… but it’s not possible to distinguish different types of MS and allocate only a certain number of PDCH…
Did you activate the PFC ?
EN_PFC_FEATURE

What about
EN_RA_CAP_UPDATE

A possibility is that the Samsung MS are establishing TBF with the one-phase access method, but the MFS does not get their real multislot class !
The RA CAP UPDATE might help.

Also what is your GPRS_MULTISLOT_CLASS_DEF_VALUE ?

The problem could also come from the SGSN, that is not sending the right multislot class to the MFS for those MS. (the SGSN is the one telling the MFS what is the multislot class in case of DL TBF)

Regards
pix

[Pawa]

thank you very much, Pix!

you are right, there are no congestions on this BTS, neithe in air-interface nor in Abis or Ater/
I’ve just checked deficit indicators you mentioned

– EN_PFC_FEATURE = not supported

– EN_RA_CAP_UPDATE = disable

– GPRS_MULTISLOT_CLASS_DEF_VALUE = 8

i’m going to activate RA_CAP_UPD and repeat my test.
as i understand the most probably cause of the problem is wrong definition of MS’s multislot class – by MFS or by SGSN.
Do you think it is possible to find it out through L3 messages from TEMS?

tanks you again
i’ll report about my results

br, pawa

[pix]

hi,

the RA CAP UPDATE might help, let me know…

you could try to do the following : do a UL ping (from your MS to the GGSN, for example), with a “big” size:

ping -l 5000 (ip_ggsn)

by doing that, the MS will actually do a UL TBF with a 2 Phase Access, where it updates the MFS with its multislot class.
In this scenario, the MS will send a packet resource request.
the MFS will reply with a packet downlink assignment, with full pdch allocation.

In other scenario, the MS will only do a 1 phase access (because the msg sent by MS initially is small, like a ftp request or http request)
then the MFS will transfer the http page with a dl tbf. This dl tbf is established with a packet downlink assignment message. In which you should find full pdch allocation as well. The difference is that here, the MFS retrieved the multislot class from the SGSN.

So scenario 1 (ul ping) = multislot class info retrieved from MS.
scenario 2 (browsing or ftp dl transfer) = multislot class retrieved from sgsn.

i’m very interested in your results 🙂

regards
pix

[Author]

Posts