Currently the nanoBTS bootstrap code requires a high delay
otherwise we are not bringing the device up properly. Changing
the init code turns out harder than it seems like. So this is
a workaround for that to allow a high speed RSL/OML connection
after the bringup.
The line driver can have a default TS delay. It is set to the
current default for the nanoBTS and the BS11. For the ipaccess
case we will set the delay lower for the RSL connection and
inside the ipaccess-config we can set it low right away to
have fast firmware flashing and such.
In case we can not find the SCCP connection we still want to
free any pending transaction ids and reset the BSC inside the
endpoint. In most cases this should be already done when the
SCCP connection or the whole BSC is gone.
When allowing to reallocate an allocated endpoint we will need
to free it first. When freeing we will free the call id and other
ids that we would have leaked otherwise.
Remember that we have seen a CC and have a valid destination
local reference now and only send a fake RLC to the MSC when
we had connections in this state.
For now close the connection when having a short read. This might
be due a network issue (loss of segment) or similiar. As we are not
handling these issues well, let us close the connection.
This routine should operate on different packets and the
dummy load is smaller than a legitimate RTP header so it
is unlikely we will filture out genuine traffic.
The reason is the dummy load might be send more than once.
When setting a new MSC timeslot to a SCCP connection check if
any of the existing connections have this timeslot, if so we will
send a DLCX down the stream to make sure it is closed there, when
we will CRCX this new timeslot we will happily reallocate it.
When the SCCP connection goes away, or we get a DLCX from the
network, or the BSC is gone we will send a DLCX message down the
stream as well.
When we receive a CRCX from the network we will forward the CRCX
as usual and send a dummy MDCX after it.
For the DLCX and the dummy MDCX we send a custom MGCP message
that will not provoke an answer. Even if the downstream MGCP GW
will answer we will ignore it due the dummy transaction id that
is not used anywhere else.
This change should make sure that we close the dowstream endpoint
all the time, even when the DLCX arrives after the SCCP connection
is torndown.
This can be used by higher level code to send one dummy
message from the audio port to the network. This can be
used to make the remote discover the nated port of this
endpoint.
When sending a MSG to the MSC try to find the to be used "src" reference
by comparing the reference on the BSC and the BSC connection. Only this
tuple needs to be unique.
Actually only when looking at the SRC REF we need to compare the BSC as the
dest reference should be unique but we are just making the check a bit stronger
to make it look symmetric.
If we find the connection of a different BSC at least log the
BSCs that had duplicated references. We should also dump the
src ref and such but i am not doing this right now.
Be able to tune the RACH settings of the BTS via the vty interface,
by default they are initialized to -1 which means we will use the
content of the static array (BTS default) and can be changed via
the VTY interface. I have verified the setting on the nanoBTS with
wireshark and I have tested writing the config file.
Add some code to count TCH/H and TCH/F and also handle
the neci bit of the network. Our channel allocator will
allocate a TCH/F if we request a TCH/H but can not allocate it.
Only page if we have a load that is acceptable for paging. This
option is off by default, and can be enabled per bts. The idea
is that when we have no resources right now we will not page as
it will only create more RACHs and increase the load.
This is causing a regression with AMR audio. The nanoBTS
is sending a MDCX NACK with Cause 0x52. Reverting this
commit makes it work again.
This reverts commit b54dda4cef.
Instead of throwing a huge pile of paging commands to the BTS
we will submit one paging command every half second. This way
we can have different messages between the paging commands.
This is a band aid and not a proper fix. Reduce the time between two
IPA commands even if it is breaking rugby sized BTSs, limit the paging
commands we send during one iteration through the event loop. This should
prevent us from killing ourselves in a RACH loop.
We do not assing a GSM Subscriber to Mobile Originated calls, when
requesting a SDCCH and then starting call control we will crash here
due trying to copy a NULL subscriber from the lchan to the other.
We do not need to know the IMSI at the BSC so it is okay to not
copy the subscriber around, we could even kill all subscriber handling
in the future.
It might be that we run down to zero available slots but the BTS
might not send us a load indication. This can happen if we think
we send paging requests and the BTS disagrees and considers them
as errors and does not count the paging message.
When we drop to zero we will start a credit timer to give us extra
credit after six seconds, if we get a CCCH load indication before
we will stop the timer.
