When starting the first time there are no tables, doing a revision
check will fail and bsc_hack will exit without tables created. Do
the revision check within db_prepare and allow new tables to be
created before.
As it turns out, we start to allocate SDCCH for voice calls. Since we
don't yet implement switching from SDCCH to TCH during call setup,
this leads to various problems.
This is only relevant for TRX1, since TRX0 will always opwerate at constant
power. However, when channels on TRX0 are activated, we should provide
a reasonable BS poewr level.
* send more pending messages after RP-ACK of DELIVER has been received
* send pending messages after RP-SMMA has been received
* clear the transaction when sending CP-ACK in MT/DELIVER case
* always use the same transaction ID (since my assumptions about
SMS transactions were wrong)
* try to deliver messages through existing lchan rather than starting
paging
* send pending SM's after LOCATION UPDATE ACCEPT has been sent
You can now type commands like
'sms send extentsion 1003 This is a test message'
to trigger paging and delivery of the message 'This is a test message'
to the subscriber with extension 1003. There's also a variant that uses
the IMSI of the subscriber.
Messages sent this way are only attempted to deliver immediately. If
immediate delivery fails, there is no attempt to store it in the database.
SM's need to be transferred over their own RLL connection on SAPI3, rather than
the default SAPI0 connection that we're using for signalling like 04.08
RR/MM/CC.
This is not that much of a problem in the case of SMS SUBMIT from the MS to
the netwrok. In that case, the MS will start its primary RLL connection
with SAPI3, and we can just respond with SAPI3.
However, in the case of SMS DELIVER to a MS, we first page the MS, it then
establishes SAPI0. We then need to explicitly request the establishment of
a SAPI3 RLL connection, before we can send CP-DATA with our RP-DATA and DELIVER
RPDU
Now that we have the bsc_rll.c code, we can actually wait for a paging
response, and from the paging response request the establishment of the SAPI3
connection. We will be called back once that connection is open and can
successively start transmission of the SM.
A caller can call rll_establish(lchan, link_id) and a callback to the GSM RLL
code. He will get called back if the RLL link is established or receives some
error message, or the establishment times out.
We need this for proper SMS implementation, where we need to restablish a SAPI3
RLL link before transmitting the actual CP-DATA messages.
we now have the full path from the MS into the database (SUBMIT), as well as
back from the database to the MS (DELIVER). The database gets correctly
updated once a SMS has been successfully delivered.
What's still missing is the periodic scan over all undelivered messages,
trying to deliver them to the respective MS. So far, you have to manually
trigger this on the telnet interface with 'sms send pending 1'
The existing code always paged for a TCH/F, which is really wasteful
when considering the delivery of SMS messages.
Also, increase the verbosity of the debug message a bit.
So far, we immediately disable the RF channel without following a proper
RLL RELEASE procedure. This patch changes this.
If we locally terminate the connection, the channel allocator now triggers a
RLL RELEASE REQuest, which is responsed by the MS with a RLL RELEASE CONFirm,
based on which we send the RF CHANnel RELease to the BTS.
If the MS terminates the connection, we receive a RLL RELEASE INDication,
based on which we trigger RF CHANnel RELease to the BTS.
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.
We nowuse the interactive VTY layer to configure OpenBSC. You can
create BTS's, set their parameters as well as TRX's and their
timeslots on the telnet UI.
What is lacking so far:
1) we only read the config file once and don't properly react
to changes performed at runtime
2) ip.access BTS supportis not integrated yet
There are three config files as examples
* openbsc.cfg.1-1: single BTS, single TRX
* openbsc.cfg.1-2: single BTS, dual TRX
* openbsc.cfg.2-2: dual BTS, dual TRX
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.
Harald Welte
Harald Welte