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.
Up until now, we only supported direct RTP streams between ip.access BTS.
With this commit, the user can specify '-P' to the command line to enable
a RTP/RTCP proxy inside OpenBSC. The nanoBTS will then send all their voice
data to OpenBSC, which will relay it to the respective destination BTS (which
can be the same BTS).
The default behaviour remains unchanged. Without '-P' on the command line,
RTP/RTCP is exchanged directly.
* explicitly set the "ip speech mode" IE during BIND and CONNECT messages,
depending on the speech codec used by the voice call
* more verbose debug messages regarding IPAC_BIND and IPAC_CONNECT
* do not always blindly specify RTP payload type, but use the value
returned by BIND_ACK, _if_ it is present.
The rtp_proxy.[ch] code is intended to be used as a transparent
RTP/RTCP proxy, relaying the media streams from one ip.access BTS
to another. In an 'ideal' network, this is obviously not needed,
since the BTS's can send those streams directly between each other.
However, for debugging, 'lawful interception', transcoding or interfacing
a TRAU/E1 based BTS, we actually need to process those RTP streams
ourselves.
There were many places in the code where we had to explicitly
reference the transaction_id and put it into a packet. By introducing
and optional gsm_trans parameter to gsm48_sendmsg(), we can implement
this code once rather than dozens of time.
since a subscriber is an element of the gsm_network, we have to ensure
subscr->net is always set correctly. We do this by using gsm_network
as an argument to all functions that resolve or create a subscriber.
Since a transaction is associated to a gsm_subscriber, and the subsciber
is part of a network, we don't need to have a dedicated transaction->network
pointer.
This changeset factors out gsm_transaction as something independent
of call control in preparation to re-use the code from SMS. A
transaction is uniquely identified by either its callref, or by
a tuple of (transaction_id, protocol, subscriber).
Since a transaction is associated to a gsm_subscriber, and the subsciber
is part of a network, we don't need to have a dedicated transaction->network
pointer.
This changeset factors out gsm_transaction as something independent
of call control in preparation to re-use the code from SMS. A
transaction is uniquely identified by either its callref, or by
a tuple of (transaction_id, protocol, subscriber).
since a subscriber is an element of the gsm_network, we have to ensure
subscr->net is always set correctly. We do this by using gsm_network
as an argument to all functions that resolve or create a subscriber.
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.
For further evaluation/analysis, this patch stores the classmark 1, 2 and 3
values of every equipment in the SQL database. We can use this non-volatile
data to determine the supported features for each handset that we've ever
seen on our network.
* describe data structures in gsm_04_11.h
* increae LCHAN RELEASE TIMEOUT for case of long SMS
* convert header field in sql table from NUMERIC to BLOB
* initial handling for validity period
* send RP ERROR messages with meaningful RP CAUSE in case of error
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.
If we receive one of those strange BS-11 "Cause 22" errors, we don't need
to check if the lchan use counter is > 0. If it was 0, the lchan gets
released anyway.
This was proposed by Andreas Eversberg. I made it conditional on the T200
timer expired cause, as I'm not sure if we really should give up that quickly
on other errors such as just simply receiving an unsolicited response.
* when paging callback is called, we need to consider a failed paging
operation (i.e. lchan == NULL)
* we have to zero-initialize every transaction that is allocated
after passing the mncc structure (contained in msgb) to the mncc layer,
we have to release its memory. This leak was discovered as a direct result of
using talloc.
* 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.
* 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
This patch fixes the PCAP logging. If frames are received from E1
interface, an 8 byte mISDN header (MISDN_HEADER_LEN) is in front of the
RSL packet. When frames are transmitted to the E1 interface, the
pcap_write_packet function will get a message buffer without the mISDN
header in front of the RSL packet. The pcap file was tested and the
output is correct.
Follow up patches should make use the msgb->l2, make the ipaccess
code use the pcap writing too...
Implement subscr_get_channel and subscr_put_channel to
a degree that SMS Submit and phone call scheduled at the
same time will deliver both (one after the other).
This is simulating a successfull request and is causing
a segfault. The test is done with a "mock object" in this
case a minimalistic paging implementation which is enough
to show the crash.
Compare that the callback data is supposed to be the same....
Reuqests for a subscriber a stored within the gsm_subscriber
datastructure and it will keep track how many channels are
allocated for this user and of which type to decide on policy...
e.g. attempt to submit SMS during a phone call and not doing
paging but a simple (immediate) assignment of the channel...
By calling _paging_request_stop with NULL for the lchan we
have never used the paging complete callback... I didn't
spot that when moving the code over and thought it is a great
simplification to not call paging_request_stop first and then
loop... *sigh*
restore the old behaviour. Call the callback first and then
free the requests.
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.
Andreas Eversberg is suspecting that some of these messages
are not balanced and we are seeing a leak here. The general location
updating request is guarded by the "location updating request" object
inside the lchan that will keep the channel open for at least five
seconds to get all the information we need.
Move the secret of how to find the BTS in a LocationArea into
the paging layer. This allows to implement different strategies
without changing other parts. E.g. we might want to try the BTS
were the device was seen last and then try...
There should be no semantic change and things should continue
to work. It is sadly not tested though.
Search for the MS at BTS in the location area of the
called_subscr. This makes the case work where caller and
receiver are not in the same location area. In fact this
looks like a breach of a BSC/MSC separation, I have no idea
if in true networks a BSC is managing BTS in different location
areas.
this patch implements the encoding/decoding of 04.08 call control information
elements. It adds new functions to be used for the application interface
patch, and is basis for the application patch (currently patch 36).
Please ignore warnings about unused static functions for now.
(Andreas Eversberg)
when paging is successfull, the paging_request_stop() function is called
with the current lchan, so the callback function will be called. for all
other bts', the paging_request_stop() function is called without lchan,
so the paging is stopped, but the callback function is not called.
this ensures that only one paging result is received when paging
multiple BTS. (Andreas Eversberg)
Harald Welte
Harald Welte