| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Due handover we might leave the BTS and if we ever allocate/release
a BTS dynamically we have a problem here.
|
|
When the cell becomes visible we will be bombed with location
updating requests and to reduce the load on the network we should
assign as many channels for it as possible. During load peek it
is even more important than to have a spare voice channel and in
general the LU procedure is pretty fast.
|
|
Currently every SAPI release indication will trigger the channel. It
was possible that we had SAPI=3 and SAPI=0 allocated and we tried to
release the channel by sending a RF Channel Release, the BTS answered
with a RF Channel Release ACK but also sent the SAPI Release Indication
which triggered a channel release here. So it was possible that we
would have released a newly allocated channel because of the SAPI
release of the old connection.
This code now works by releasing all SAPIs from highest to lowest,
then sending a SACH Deactivate and finally releasing the channel. This
approach is in use on the on-waves/bsc-master.
|
|
|
|
The bsc_handover_clear will release an in-progress handover
and free the lchana and the data associated with this handover
|
|
The transaction should not know on which lchan we are operating
as this can change due handover. Add untested code to share the
subscriber connection of the new and old lchan and move the pointer
in case of success/failure. Also on a clear command we will free
any resources allocated...
This code is not tested and needs to be debugged, but it should
have the right structure. I am going to fix a potential memleak
in the next commit.
|
|
A channel will be released in case of
* Errors via the clear_request callback...
* no more transactions and operations are going on.
This means that if we do something without a transaction
the channel might be closed down right away. The bug fix
will be to create a transaction/operation.
|
|
This is a big change to the way we use the subscriber
connection. From now on it is is dynamically allocated
and we will slowly move from a 1:1 lchan to conn to
having more than one lchan per connection.
This is the first commit, the subscr_con* methods will
move to gsm_data once the use_count is removed from the
connection, the freeing of the connection will also change.
|
|
|
|
The Channel Activate might be sent to a different TRX than the
Immediate Assignment. So we need to make sure that the channel
is activated before we send the immediate assignment for the RACH.
Another reason for that is according to GSM 08.58 we should take
the frame number from the activate and use it for the starting
time inside the immediate assignment message. We obviously do not
do this yet.
The code assumes that the BTS will either respond with a CHAN ACK
or a CHAN NACK if not the lchan will remain in the request state.
|
|
With handover and late/early assignment there might be two channels
for one subscriber and only the BSC knows which one to use, so use
the gsm_subscriber_connection everywhere...
|
|
|
|
|
|
This can be used by handover, early assignment to indicate the
close of the old channel...
|
|
Free all allocated channels on the TRX that failed, go through
lchan_free to signal higher layers and then force a reset of
the channel. Make the TRX and TS unusable by setting the operational
set to 0 (not really defined) which should be reset once the
RSL is coming up again.
|
|
Currently our GSM04.11 code is closing the link for SAPI=3
and this would mean that the whole channel would be scheduled
for close... where we only want to close everything when freeing
the lchan or handling an error.
|
|
|
|
This code simply enables the channel allocator to understand the
dynamic TCH/F / PDCH channel type as used by ip.access nanoBTS.
It does not actually try to switch the dynamic mode, but instead
sends signals to a (not yet present) dynamic switching algorithm.
|
|
Remove further usage of lchan from the gsm 04.11 bits
|
|
Prepare to split the BSC and the MSC part by putting the
MSC data for a connection into a "gsm_subscriber_connection"
struct and renaming the macros.
|
|
|
|
This returns true if the gsm_nm_state can be considered 'running'.
Note that we also accept availability==0xff (which is a code for
no value) because according to 12.21 it is perfectly valid.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
This enables us to reliably detect if a lchan is part of a silent
call or not.
|
|
this ensures we don't send paging requests to currently inactive transceivers.
|
|
When we allocate a channel, we send the RSL CHAN ACT REQ and wait until we get
a CHAN ACT ACK. Only the ACK will change the state, so there is a race where
we allocate that same channel to a different channel request before we get
the ACT ACK.
Introducing a new ACT_REQ state resolves this issue.
|
|
In case we have multiple TRX configured, but not all of them are
actually active/operational, we should not try to allocate channels
from such transceivers.
|
|
This is just the load at one given instant. We definitely also want to see
some averages and record the measurements in a database later.
|
|
This implements the handover algorithm (and associated parameters)
as described in Chapter 8 of the book "Performance Enhancements in
a Frequency |Hopping GSM Network" by Thomas Toftegard Nielsen and Jeroen
Wigard.
The parameters such as averaging windows are configured in struct
gsm_network. We keep some state to trakc up to 10 neighbors as
they are being reported from the MS.
This has so far only been tested in a network with two BTS that
have each other as neighbor. Networks with morge neighbors might
encounter bugs.
|
|
If a RF channel is assigned but no response is ever heard from
the phone, we will receive a CONNECTION FAIL from the BTS,
triggering a RF release freeing the channel. Then sometime later,
T3101 will expire as well and free the channel again ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
This introduces a new LOGP() macro together with LOGL_* definition to
support multiple log levels (severities) throughout the codebase.
Please note that the actual logging system does not use them yet,
in this patch we simply introduce the new macros at the caller site.
|
|
|
|
Fix minor bug with speech calls in case of NECI=1
|
|
The rationale is as following:
If we have NECI=1, then the phone will request a channel with CHREQ
"0100xxxx Originating speech call from dual-rate mobile station when TCH/H is
sufficient and supported by the MS for speech calls", then we will try to
allocate a TCH/H [as it is sufficient].
However, if there are no free TCH/H slots on the BTS, we abandon and can't
handle the MO call at all :(
|
|
Both GSM 04.08 RR and GSM 08.58 RSL need the multirate config
in the channel modify. Place the config in the lchan, change
the gsm48 methods to not take the argument, change the RSL
implementation to make use of it with the right IE.
The other code should use the t(l)v_put routines as well but
were left untouched for now.
|
|
Reset the whole array instead of just the first element.
|
|
Keep track of which SAPIs have been established either by the
BTS (from the MS) or by us. This can be used by the on-waves
BSC code to figure out if a new request should be made.
|
|
|
|
|
|
The channel allocator can be set in ascending or descending order.
Ascnending means we first try to allocate channels on TRX0, then TRX1, etc.
Descending means we first try to allocate cahnnels on TRXn, then n-1 down to 0.
|
|
|
|
|
|
We don't support CBCH anyway, and using CBCH will reduce the number of uesable
SDCCH/4 channels to 3 on TS0
|
|
There's now a new function called 'lchan_for_subscr()' which can be
used to determine if there is any existing lchan for this subscriber.
|
|
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.
|
|
For now, we assume that TRX1 (and higher) all have a TCH/F configuration
on all of their timeslots
|
|
|
|
|
|
This makes it much easier to do run-time configuration using the vty
interface.
|
|
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
|
