aboutsummaryrefslogtreecommitdiffstats
path: root/openbsc/src/system_information.c
AgeCommit message (Collapse)AuthorFilesLines
2010-07-30Add more RSL <-> Osmo SI type mappings, export osmo_sitype_strs[]Harald Welte1-2/+16
2010-06-20[BSC] SI: make sure we initialize the data field, not the bitvec structureHarald Welte1-2/+2
2010-06-20[BSC] Keep a SYSTEM INFORMATION cache for each BTSHarald Welte1-21/+90
This will later be useful for handover where we need to copy the cell channel allocation into a normal 04.08 message
2010-06-20[BSC] Implement per-timeslot ARFCN lists for frequency hoppingHarald Welte1-1/+18
We now compute the Cell Channel Description for SI 1 by bit-wise OR of the ARFCN bitmask of each timeslot on all the TRX of the BTS. Also, support generating a GSM 04.08 Channel Description IE for the hopping case (with HSN/MAIO instead of ARFCN). What's still missing now: Sending the 04.08 Mobile Allocation IE
2010-06-16si13: Use the correct pseudo length for the SI13 messageHolger Hans Peter Freyther1-1/+2
The GSM04.08 Section 10.5.2.19 specifies the L2 Pseudo Length and the length does not include rest octets, so we will need to use a zero for the length. The patch is coming from Dieter Spaar.
2010-06-02[GPRS] Change SI13 to NMO_II, as some phones (like G1) dislike NMO_IIIHarald Welte1-1/+1
I still believe NMO_III is what we want, but as indiciated some phones absolutely refuse to even connect to the GPRS network in this mode :(
2010-05-31[GPRS] Make sure SI13 rest octets look like those of the ip.access BSCHarald Welte1-7/+7
2010-04-18GPRS: actually enable indicating EDGE capability in SI13Harald Welte1-1/+4
2010-04-18GPRS: change 'gprs enabled <0-1>' to 'gprs mode (none|gprs|egprs)'Harald Welte1-1/+9
This causes some config file breakage but sounds like a much cleaner approach than to have two separate config variables for this.
2010-04-18GPRS: Add Support for the GPRS Cell Option Extension Info IEHarald Welte1-0/+10
Extension Information is part of the GPRS Cell Options IE, as specified in Chapter 12.24 of TS 04.60. It is needed for indicating EDGE capabilities of the BTS to the MS. This simply adds the code to encode this IE as part of SI13, but does not actually use the code yet.
2010-03-22gprs: remove (the already unused) si13_templateHarald Welte1-16/+0
system_information.c and rest_octets.c don't need a template...
2010-03-22GPRS: set SI3 GPRS indicator dependent on bts->gprs.enabledHarald Welte1-1/+3
2010-03-22Create new gprs-conf branch with the non-SGSN part of the gprs branchHarald Welte1-7/+25
This new gprs-conf branch is intended to contain everything needed to configure GPRS in the nanoBTS, but without implementing the SGSN/GGSN functionality. The SGSN/GGSN development will happen in a branch based on this branch called "gprs-sgsn"
2010-03-04move some gsm48 utility functions to libosmocoreHarald Welte1-9/+9
* gsm48_generate_lai() gsm48_generate_mid_from_tmsi() gsm48_generate_mid_from_imsi() * gsm48_cc_msg_names[]
2010-02-20split 'libosmocore' from openbsc codebaseHarald Welte1-1/+1
This library is intended to collect all generic/common funcitionality of all Osmocom.org projects, including OpenBSC but also OsmocomBB The library currently includes the following modules: bitvec, comp128, gsm_utils, msgb, select, signal, statistics, talloc, timer, tlv_parse, linuxlist msgb allocation error debugging had to be temporarily disabled as it depends on 'debug.c' functionality which at the moment remains in OpenBSC
2010-01-07[system_information] Initialize the buffer before moving itHolger Hans Peter Freyther1-2/+4
In the case of ipaccess we are doing a ++output but then still try to write 23 bytes into it and on my system this is leading to a stack corruption.
2010-01-07[system_information] Return how much byte were written into outputHolger Hans Peter Freyther1-9/+10
2010-01-06[si] Go through the system_information structs and add static_assertsHolger Hans Peter Freyther1-0/+16
The structs are correct, the problem is coming from the rest octets
2009-12-24system_information: Fix BCCH Allocation when only 1 BTS presentSylvain Munaut1-1/+7
The current code used the variable bitmap format, but that's not possible since in this format the base ARFCN is part of the set. That lead to a neighbor list containing ARFCN 0. Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2009-12-19system_information: ip.access wants L2_PLEN, BS-11 doesn'tHarald Welte1-7/+20
It seems that depending on the manufacturer, there is a need to include the L2 pseudo-length in the SI5+SI6 messasges (SACCH FILLING) Thanks to Dieter for pointing this out.
2009-12-17logging: introduce log levels at caller siteHarald Welte1-4/+7
This introduces a new LOGP() macro together with LOGL_* definition to support multiple log levels (severities) throughout the codebase. Please note that the actual logging system does not use them yet, in this patch we simply introduce the new macros at the caller site.
2009-12-16[system_information] Print more debugging about what's going onHarald Welte1-6/+15
2009-12-14system_information: use bitvec to generate frequency listsHarald Welte1-66/+49
We use a 1024-bit-sized bitvec to generate the BA and neighbor frequency list. This bitvec is still generated from the list of all BTS's inside the BSC, but this patch is the first step to generalize this, i.e. generate arbitrary neighbor lists.
2009-12-14[system_information] fix bit map 0 frequency list generationHarald Welte1-2/+9
Our frequency lists for GSM900 were completely wrong, as the bit map 0 encoding was not used correctly. This patch should fix it.
2009-12-05[system_information] fix BCCH list generation for GSM900Harald Welte1-0/+2
We have to make sure to skip the global list header
2009-12-01Replace template-based SYSTEM INFORMATION with real implementationHarald Welte1-0/+427
Before this commit, OpenBSC used templates for the SYSTEM INFO 1, 2, 3, 4, 5 and 6 messages. Those templates were patched in various places to reflect the network config like ARFCN. Now, we actually generate those SI messages ourselves, using values from the configuration file, and even calculating neighbor cell lists. All bts'es that you have configured in OpenBSC will end up in the neighbor cell list - which should be more than sufficient for the current small-single-site networks.