As Dieter has pointed out, we currently send incorrect information
in the rest octets, particularly about our GPRS capability. Since
the format of the rest octets is highly complex, and we don't
actually need any of those features yet, we might just fill them
with padding.
* add bts->band field plus corresponding VTY and commandline argument
* add trx->nominal_power and trx->max_power_red fields
* add rsl_chan_bs_power_ctrl() to control TRX RF power for a given TS
* add rsl_chan_ms_power_ctrl() to control MS RF power for a given lchan.
This is Harald's reworked MNCC base, slowly heading towards integration
into master. The key changes are:
* provide much more structure to the data in gsm_mncc
* encode_* and decode_* functions now take a structure rather than tons
of individual arguments (whose order nobody can remember)
* make sure we don't have copies of the same code everywhere by introducing
mncc_set_cause() and mncc_release_ind()
* save horizontal screen space if possible
* make sure we break lines > 80 characters
When trying to operate a nanoBTS900 on channels for 1800
or the other way around the "SET BTS ATTRIBUTES" message
will be nacked. Dispatch all nacked messages from abis_nm
via signals. Handle this in bsc_hack.c, print a small hint
and exit the application as this is considered a fatal
unrecoverable error (the exit is in the app, so a library
can be more robust).
The GSM1800 requires us to use channels between 512-885. When
failing to provide such a channel the OML layer will fail and
no RSL connection will be opened.
Add a sanity check before creating the gsm_network and fail
when the channels are not within the allowed range.
Assume no one is operating a BS11 in the 1800 spectrum.
Harald Welte
Andreas Eversberg