This helps us to detect the frequency error of BS-11 if it is located
next to the nanoBTS 900.
If 'ipaccess-config -l' is called, it will produce a report like
<0020> ipaccess-config.c:85 TEST REPORT: test_no=0x42 test_res=0
<0020> ipaccess-config.c:108 ==> ARFCN 220, Frequency Error 22
<0020> ipaccess-config.c:108 ==> ARFCN 1, Frequency Error -37
<0020> ipaccess-config.c:108 ==> ARFCN 10, Frequency Error 0
<0020> ipaccess-config.c:108 ==> ARFCN 20, Frequency Error 11
<0020> ipaccess-config.c:108 ==> ARFCN 53, Frequency Error 5
<0020> ipaccess-config.c:108 ==> ARFCN 63, Frequency Error -4
<0020> ipaccess-config.c:108 ==> ARFCN 84, Frequency Error 11
<0020> ipaccess-config.c:108 ==> ARFCN 101, Frequency Error 0
<0020> ipaccess-config.c:108 ==> ARFCN 123, Frequency Error -52
where in this case the ARFCN 123 is the BS-11 with a frequency error
larger than all the other (regular) BTS in the vicinity.
Currently we send the attribute changes in a send and forget
fashion. But sometimes the nanoBTS is sending us a NACK, e.g
with a invalid unit id. Start handling the NACK and provide
an error message to the user. The error message is not yet
describing the cause of the error but this is a slight progress
to the previous silent failure.
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
Harald Welte
Holger Hans Peter Freyther