This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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, -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)