* Add per-BTS DTX settings
* Configure Uplink and Downlink DTX separately
* Deprecate global DTX option (it was never tested/used anyway)
* Use libosmocore function for DTX indicator in System
Information (previously it was incorrectly assigned for half-rate
channels)
Related: OS#22
Change-Id: I3d55168475ad47044b6238b55846ea22bdd518a4
Reviewed-on: https://gerrit.osmocom.org/40
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
Rather than having a 'private' structure for kc, sres and rand, we
now finally (with 4 years delay) use osmo_auth_vector from libosmogsm,
which encapsulates authentication vectors that can be either GSM
triplets or UMTS quintuples or a combination of both.
gsm_auth_tuple becomes a wrapper around osmo_auth_vector, adding
use_count and key_seq to it.
key_seq is no longer initialized inside gprs_gsup_messages.c, as there
is no CKSN / key_seq inside the message anyway. If a usre of the code
needs key_seq, they need to manage it themselves.
This fixes a bug in the following circumstances:
* BSIC is set to 0 in the config file
* No TSC is explicitly specified at the BST level in the config file
In this case, we ended up using BSIC=0 and TSC=7, as TSC=7 is our
default initialization value.
The TSC of the CCCH/BCCH must always be the BCC, which is the lower 3
bits of the BSIC. Having configuration options for both the BSIC _and_
the TSC at the BTS level therefore makes no sense, as it only adds ways
in which users can configure non-oprational configurations. So we
remove the bts->tsc member, and keep only the ts->tsc members that allow
us to configure a timeslot-specific TSC that's different from the BTS
TSC (= BCC).
Implement sending MDCX on the newly allocated channel and send
the data to the same destination as the currently connected one.
This way the receiver can implement RTP RFC Appendix A.1 and
deal with the new source.
For the LCR rtp-bridge audio should directly flow to the
remote system. In contrast to the original patch audio
will now flow directly from the BTS to the remote system.
This assumes that BTS and the remote system are in the
same network segment and can directly communicate.
There are various limitations in the first iteration of
the implementation:
We could (and in the future) should delay the assignment
but currently we are forced to pick the channel and move
it to the audio state. In case we are located on a SDCCH
we always need to change but if we are on a TCH we could
send the ipa.CRCX and change the audio state a lot later.
The net effect is that the audio codec selection needs to
be done in the NITB code and not in the system connected
to it.
This only works with ip based systems. For E1 systems one
could still use the RTP socket or even try to move this
out of the process.
There is no code for handover handling and it relies on
the remote system dealing with the SSRC change of the
system.
In case foreign simcards are used we can not do authentication
and ciphering. In case a TMSI is re-used too early and we do
page using TMSI we can't know which of the two MS is responding
to us. We could change the "secure channel" routine to ask for
the IMSI and only then stop the paging.
As we don't have ciphering there is not much use in using the
TMSI. Add a mode "no assign-tmsi" that will not assign the TMSI
during LU. Now CM Service Request and Paging Response will
work using the IMSI. There can't be a clash with that.
[ciaby fixed the vty write to use the right name]
The code to do that doesn't belong to the control interface, so
abstract it out to a separate function gsm_bts_set_system_infos().
[hfreyther: Fix the coding style...]
The idea of "subscriber_get_channel" was that different
requests would be coordinated. At the same time we have
seen that the "queue" can get stuck at both 31C3 and the
rhizomatica installations.
Voice calls and SMS do not need coordination. We should
be able to send SMS on a voice channel and switch the MS
from a SDCCH to a TCH in case we establish a voice call.
The SMS code itself needs to coordinate to obey the limit
of one SMS per direction but this should be enforced in
the sms layer and not on the subscriber.
Modify the code to have a simple paging coordination. The
subscriber code will schedule the paging and register who
would like to know about success/failure.
This allowed to greatly simplify the paging response
handling for the transaction code (and in fact we could
move the transaction list into the subscriber structure
now). The code gained to support to cancel the notification
of a request (but not the paging itself yet).
TODO: Cancel paging request in case no one cares about it
anymore.
We had issues with odd behavior on the nanoBTS which lead
to the introduction of the "broken" state. On busy multi
BTS cells (e.g. rhizomatica) with wifi backhaul the timeout
we set to wait for a RF Channe Release ACK is sometimes too
little and channels are marked broken that look to be okay
(besides the still to be determined delay).
In case of a sysmoBTS we now know that we can change the
state of a broken channel back to normal in case we do
receive the right response.
Manually verified using the Smalltalk BTS code
PackageLoader fileInPackage: 'FakeBTS'
bts := FakeBTS.BTS new.
bts btsId: '1903/0/0'.
bts connect: 'localhost'.
bts waitForBTSReady.
test := FakeBTS.OpenBSCTest new.
test bts: bts.
test requireAnyChannel
... wait for NITB output
<0004> abis_rsl.c:223 (bts=0,trx=0,ts=0,ss=0) Timeout during deactivation! Marked as broken.
... process pending messages
stdin next
<0004> abis_rsl.c:735 (bts=0,trx=0,ts=0,ss=0) CHAN REL ACK for broken channel. Releasing it.
So the channel went from broken to unallocated.
Create a control command to read and modify the gprs mode. Use
the get_string_value to indicate if the value was found or not.
This is useful for the ctrl interface where I didn't want to
replicate "none", "gprs" and "egprs". Share code to verify that
a BTS supports the mode.
Related: SYS#591
In case a BTS is dropped, iterate over the list of BTS and check
if a dependency is now missing and then drop the BTS. This check
could lead to check of 256*256 checks (e.g. all BTS on each other
in the chain and the master is being dropped). The performance
aspect of it doesn't matter for our usecase. We expect to have
pairs of BTS right now.
E.g. for the sysmoBTS2050 we have the requirement that the first
board connects before the second due clocking. The easiest point
to enforce this is the BSC. Add a simple bitmask based system to
allow to express dependencies for IP based systems.
Currently every subcriber object directly refers to the gsm_network
which contains a flag shared by every related subscriber
(keep_subscr). This adds a dependency on gsm_network even if only the
function defined in gsm_subscriber_base.c are used.
This patch adds a new struct gsm_subscriber_group which contains the
keep_subscr flag and a back reference to the network object. The
latter is not dereferenced in gsm_subscriber_base.c, so it can safely
be set to NULL when only that part of the gsm_subscriber API is being
used. It also changes that API to use gsm_subscriber_group instead of
gsm_network parameters.
Since there are some places where a pointer to the gsm_network is
needed but where only a gsm_subscriber is available, a 'net' back
pointer is added to the group struct, too. Nevertheless subscr group
and network could be separated completely, but this is not the topic
of this commit.
Sponsored-by: On-Waves ehf
Increase the bcch_change_mark and generate a new copy of the
system information. Make the method public, add a small test
case. Manually verified using the FakeBTS. I don't know if
the MS will re-read these SIs.
Related: SYS#739
This is an incompatible database schema change. Store the type of
the address in the database for both the sender and the receiver.
Currently it is possible to use SMPP to store a SMS and the NPI
and TON will be lost on the delivery of the SMS. The schema is
changed to make the delivery always use the right NPI/TON. This
patch is not ready for the master branch as there is no upgrade
path for the HLR yet.
The test has been manually verified. Executing the select for
the subscribers showed:
sqlite> select * from Subscriber;
1|2014-03-23 12:12:46|2014-03-23 12:19:09|2620345||445567|1||0|
This created a subscriber with the right IMSI, MSISDN and has
it authorized.
Fixes: SYS#275
Each RP-DATA should have a unique msg reference. Currently 42 is
used for all of these. Remember the last reference we used and
increment it on the next SMS. Do not track if the reference is
still in use a clash is a lot less likely now. First unless SMPP
is used only one SMS is delivered at a time, second the transaction
space is a lot smaller than the one for the reference.
E1 based BTS use TRAU muxer to decode TRAU frames. After changing
channel from one timeslot to another (due to handover or assignment),
the TRAU muxer must be updated. The call reference of the call is
disconnected from the old channel and connected to the new channel.
This option is a workarround for a bug found in Nokia InSite BTS firmware
version 3.0.0. There is no RELease CONFirm message for local end release.
Nokia MetroSite with firmware version 4.178.16 is not affected.
TS 04.06 Chapter 5.4.4.4 "Local end release procedure" states that a
confirm must be sent by layer 2 when receiving a local end release
request.
In order to correctly switch a channel (handover or assignment), local
end release is required.
We were expiring subscribers during active calls. This is because
the T3212 is stopped under certain conditions but we didn't stop
that timer at all.
Remember if T3212 timer was stopped due something done by NITB and
update the expiration time at the end of the radio connection, as
the phone should restart it when returning to MM Idle.
It is a bit difficult to decide when we should set the flag. E.g.
in a CM Service Request we don't know if we accept the service and
during a LU we already send MM messages before we accept or reject
the subscriber.
The easiest is to set the flag when receiving a paging response
on known subscribers and at the end of the authentication process.
Do not expire a subscriber that has an active connection that is
marked with the flag, e.g. we would still expire a subscriber that
is being paged.
Manual tests executed/passed:
* gst LUTest.st verified that a expiration date was set
* gst SMSTest.st (doing another LU but forcing a timeout on the
SMS sending). Verified that the expire_lu was updated.
A CM service request must be acknowledged also, when encryption is already
enabled.
Without encryption enabled, the security status is GSM_SECURITY_NOTAVAIL,
which causes a CM service acknowledge. On initial CM service request, the
security status is GSM_SECURITY_SUCCEED, if encryption is enabled. This
will not lead to an acknowledge, because the cyphering command implies an
acknowlege. An additional CM service request requires an acknowledge, so
I added a new security status: GSM_SECURITY_ALREADY
The message was corrupt at several points. They are fixed now and
successfully tested.
A default T3122 timer value of 10 is defined by default now. If set to 0,
the reject message will not be sent. Note that when using existing configs
with T3122 value set to 0.
Set the subscriber expiry timeout to twice the duration of the location
update period and provide functions subscr_expire() and
db_subscriber_expire() to mark subscribers offline that have missed two
location update periods.
This patch increases the DB revision to 3, so the hlr will be
incompatible with prior versions.
We should allow 0 for T3212 as well to disable the location update
period. In that case we will need a way to indicate that in the
database.
nat: Catch up with controlif_setup API change
We now save a control handle reference in the nat
osmo-bsc: Catch up with controlif_setup API change
We now save a control handle reference in the gsm network
so far, osmo-bts/sysmobts used to be entered as "sysmobts" type in the
configuration file. However, there are some differences in the
protocol/behaviour and we should reflect that by a new BTS plugin (with
lots of code reuse from the nanobts driver).
We want to have multiple MSCs but we also have some data
that is only present on a per BSC basis. Right now the
MSC data is not allocated with talloc, so we have some
change in the talloc contexts.
gsm_data_shared.h includes e1_input.h of libosmo-abis, add the
LIBOSMOABIS_CFLAGS to Makefile.am, remove AM_LDFLAGS at the same
time as we only build .a archives.
This is a big patch that ports openBSC over libosmo-abis.
Sorry, the changes that are included here are all dependent
of libosmo-abis, splitting them into smaller pieces would
leave the repository in some intermediate state, which is
not desired.
The main changes are:
- The directory libabis/ has been removed as it now lives in
libosmo-abis.
- new configuration file format for nanoBTS and HSL femto, we
need to define the virtual e1_line and attach it to the OML
link.
- all the existing BTS drivers (nanoBTS, hsl femto, Nokia site,
BS11 and rbs2000) now use the new libosmo-abis framework.
- use r232 input driver available in libosmo-abis for bs11_config.
- use ipa_msg_recv instead of old ipaccess_read_msg function.
- delete definition of gsm_e1_subslot and input_signal_data.
These structures now lives in libosmo-abis.
Most of this patch are deletions of libabis/ which has been
moved to libosmo-abis.
This patch also modifies openBSC to use all the new definitions
available in libosmocore and libosmo-abis. In order to do that,
we have replaced the following:
- DINP, DMI, DMIB and DMUX by their respective DL* correspondences.
- SS_GLOBAL by SS_L_GLOBAL
- SS_INPUT by SS_L_INPUT
- S_GLOBAL_SHUTDOWN by S_L_GLOBAL_SHUTDOWN
- SS_INPUT by SS_L_INPUT
- S_INP_* by S_L_INP_* sub-signals
- E1INP_NODE by L_E1INP_NODE vty node
This patch has been tested with:
- one nanoBTS
- the HSL femto with the examples available under libosmo-abis
- BS11 with both dahdi and misdn drivers.
This should not introduce any functional changes, it just re-arranges
some definitions in the header file, and introduces the ROLE_BSC
define that we enable for the BSC-specific fields.
The daemons set up nanoBTS and HSL femto sockets by default, ie. the
three sockets to support these two drivers are open even if we have
no BTS of that kind.
This patch enables on-demand socket creation, ie. we only enable them
if we have one BTS at least that requires it.
I added two new attributes to the gsm_bts object, they are:
* the start() function includes the code that we need to run to start
the BTS. This new function contains the socket creation in the
particular case of nanoBTS and HSL femto.
* the started boolean, which is used to know if we have already
started the BTS, ie. we have already invoked start().
Note that, I have splitted the bts_model_*_init() function into two
functions, the _init() functions that register the BTS driver
and the _start() functions that start BTS driver on-demand.
While I was at it, I added several changes/cleanups to this patch:
* Group all bts_model_*_init() calls into one function bts_init(),
which is called in the initialization path of osmo-nitb and
osmo-bsc.
* Add openbsc/bss.h that contains the declaration of
bsc_bootstrap_network, bsc_shutdown_net and bts_init.
* Add missing e1inp_init() in osmo-bsc.
* Fix missing declaration of hsl_setup in openbsc/e1_input.h
Max
Harald Welte
Andreas Eversberg