Hello Nordin,
On Fri, 03 Jul 2009 14:44:50 +0200, "Nordin" bouchtaoui@gmail.com wrote:
I hope this will at least try to do a LOCATION UPDATE REQUEST. But it suprises me that older mobilephones don't care about SI 1 (and maybe more information on the BCCH) and just try to register whatever in the BCCH is.
I have further investigated the problem. Besides the fact that the channel allocation in SYSTEM INFORMATION 1 is not correct for GSM 1800, this is probably not the reason for the problem.
Most certainly its just one wrong bit, the GPRS indicator in the SYSTEM INFORMATION 3 rest octets.
The current setting is
0x80, 0x00, 0x00, 0x2B
but it should be
0x80, 0x00, 0x08, 0x2B
What might lead to some confusion is the meaning of "L" and "H" in the specification of CSN.1. For the rest octets the bit value is determined by a comparsion (XOR) to the padding byte 0x2B. So the value 0x08 above actually means "L" for the GPRS indicator, which means "No GPRS".
Its seem that some phones are really sensible to this setting, some other GPRS capable phones just don't care and register to the network even if there is no GPRS.
Best regards, Dieter
Hi Dieter,
thanks for further looking into this.
On Sat, Jul 04, 2009 at 11:41:52AM +0200, Dieter Spaar wrote:
I have further investigated the problem. Besides the fact that the channel allocation in SYSTEM INFORMATION 1 is not correct for GSM 1800, this is probably not the reason for the problem.
Most certainly its just one wrong bit, the GPRS indicator in the SYSTEM INFORMATION 3 rest octets.
The current setting is
0x80, 0x00, 0x00, 0x2B
but it should be
0x80, 0x00, 0x08, 0x2B
What might lead to some confusion is the meaning of "L" and "H" in the specification of CSN.1. For the rest octets the bit value is determined by a comparsion (XOR) to the padding byte 0x2B. So the value 0x08 above actually means "L" for the GPRS indicator, which means "No GPRS".
where did you find this XOR? I just searched through 04.07 and 04.08 and didn't find any indication thereof. Sure, the padding bit sequence ix 0x2b, so all spare bits have to be padded with that. But where did you get the XOR from?
Also, this would mean that if we put explicitly 0x2b into the padding of our messages, then it would result in all-zero 0x00 on the air, since
0x2b xor 0x2b == 0x00
I'm now looking at an actual abis trace from a production cell with GPRS enabled, and it has
"0x80, 0x00, 0x80, 0x0b"
as SI3 rest octets.
During early start of the BTS, SI3 rest octets are set to
"0x80, 0x00, 0x83, 0x2b"
Maybe that helps
Regards,
Hi guys,
I also figured that out and played with the Rest Octets of SI 3, but with no succes. It's true what you said about the Rest Octets Dieter, and it took me some time to figure that out for me Harald.
Wether the result is L or H depends on the result of the tested bit XOR'ed with the bit which is part of the value 0x2B. So actually you should XOR all octets with 0x2B (but only for those who expect an H or L as result). This value is not just a random, it is also specified by the CSN.1 standard. It would be much clearer if GSM spec put an example and not some abstract description which kills my braincells.
Anyway, I'll try your Rest Octets examples, maybe it helps for me. Concerning the SI 1, I modified the Cell Channel Description of the SI 1 myself, according to the DCS1800 standard, but turns out it didn't work for me. I assume SI 1 is hardcoded ofcourse.
Harald Welte schreef:
Hi Dieter,
thanks for further looking into this.
On Sat, Jul 04, 2009 at 11:41:52AM +0200, Dieter Spaar wrote:
I have further investigated the problem. Besides the fact that the channel allocation in SYSTEM INFORMATION 1 is not correct for GSM 1800, this is probably not the reason for the problem.
Most certainly its just one wrong bit, the GPRS indicator in the SYSTEM INFORMATION 3 rest octets.
The current setting is
0x80, 0x00, 0x00, 0x2B
but it should be
0x80, 0x00, 0x08, 0x2B
What might lead to some confusion is the meaning of "L" and "H" in the specification of CSN.1. For the rest octets the bit value is determined by a comparsion (XOR) to the padding byte 0x2B. So the value 0x08 above actually means "L" for the GPRS indicator, which means "No GPRS".
where did you find this XOR? I just searched through 04.07 and 04.08 and didn't find any indication thereof. Sure, the padding bit sequence ix 0x2b, so all spare bits have to be padded with that. But where did you get the XOR from?
Also, this would mean that if we put explicitly 0x2b into the padding of our messages, then it would result in all-zero 0x00 on the air, since
0x2b xor 0x2b == 0x00
I'm now looking at an actual abis trace from a production cell with GPRS enabled, and it has
"0x80, 0x00, 0x80, 0x0b"
as SI3 rest octets.
During early start of the BTS, SI3 rest octets are set to
"0x80, 0x00, 0x83, 0x2b"
Maybe that helps
Regards,
-
Dieter Spaar -
Harald Welte -
Nordin