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.
Using this option, you can use two BS-11 connected to the same E1
link. The first BS-11 needs to have BPORT0 and BPORT1 objects created with E1
Line Configuration attribute "multi-drop". The second BS-11 is configured with
only BPORT0 in star configuration, and needs to have the OML signalling on TS6
instead of TS1. Also, a kernel patch providing a second virtual E1 interface
is needed.
Fix two bugs in OML software download code where we allocate data structures
using talloc, but free() them using the system memory allocator. Spotted by
dexter.
Each BTS gets its own E1 line data structure. They are meant to bind
each to their own (virtual?) mISDN device.
BTS0 uses TS01 (siganlling) and TS02/03 (TRX0), TS04/05(TRX1)
BTS1 uses TS11 (siganlling) and TS12/13 (TRX0), TS14/15(TRX1)
BTS2 uses TS21 (siganlling) and TS22/23 (TRX0), TS24/25(TRX1)
In order to use multiple mISDN cards, we need to:
1) move driver initialization out of line initialization
2) make sure we allow partial (virtual) E1 cards with < 30 B-channels
* remove old HAVE_TRX1 definition, replace it with '-1' commandline argument
* make sure we actually configure the OML TRX attributes with a different
ARFCN than TRX0
* make sure we configure timeslot 0 of TRX1 also in TCH/F mode
This code is untested, but if you have a dual-trx BS-11, and the second TRX
is activated, you should be able to run bsc_hack with the -1 option to enable
and use the second trx. It works like this:
* TRX1 shares E1 timeslot 0 for signalling
* TRX1 RSL link uses TEI2 (TRX0 uses 1)
* TRX1 on ARFCN+2, i.e. if you have TRX0 on 122, TRX1 will be 124
* we only need one piece of code to calculate rsl_ie_chan_mode from
our run-time data structures (gsm_lchan)
* add some more channel modes for TCH/H and data
* use enum's to make the compiler warn us about unhandled enum values
* make sure the caller determines the (signalling,speech,data) mode
only after the LCHAN_MODIFY we know the final mode of the channel,
so we have to postpone our IPAC_BIND until then to make sure we set
the correct speech codec.