| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
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.
|
|
* Revert RTP_PAYLOAD change as it does not work on AMR
* Change paging to not send it as a bulk...
|
|
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 b54dda4cefe89665d98074cf3767858fa6ecdb6e.
|
|
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.
|
|
Make sure the paging timer is restarted after giving some credit
and send out paging requests.
|
|
|
|
|
|
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.
|
|
Conflicts:
openbsc/include/openbsc/abis_rsl.h
openbsc/include/openbsc/mgcp.h
openbsc/src/abis_rsl.c
openbsc/src/chan_alloc.c
openbsc/src/handover_logic.c
openbsc/src/mgcp/mgcp_network.c
openbsc/src/vty/command.c
openbsc/src/vty_interface.c
|
|
|
|
This is an ip.access specific 08.58 oddity. It reports 0xffff
available paging buffers if the paging load is below the 12.21
CCCH LOAD INDICATION THRESHOLD.
We use 50, since that is what it reports if the threshold == 0.
|
|
Implement a method to count the number of pending paging requests
per bts and print it on the VTY. This helps to see how big the
backlog of requests is for a given BTS.
|
|
Second attempt to use a syntax more comparable to 'Cisco',
I have never used such a system... let us see how this is
going.
|
|
|
|
|
|
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.
|
|
The actual 'Extension Length' field in the 'GPRS Cell Options' IE
is coded the length - 1, not the full length. Without this fix,
the code has an off-by-one error.
|
|
|
|
|
|
|
|
|
|
This causes some config file breakage but sounds like a much cleaner
approach than to have two separate config variables for this.
|
|
Extension Information is part of the GPRS Cell Options IE, as
specified in Chapter 12.24 of TS 04.60. It is needed for
indicating EDGE capabilities of the BTS to the MS.
This simply adds the code to encode this IE as part of SI13,
but does not actually use the code yet.
|
|
|
|
|
|
According to TS 08.18, BVCI=0 is for the SIGNALLING entity,
and BVCI=1 is for the PTM entity. Both should not be used
by the PTP entity that we're configuring here.
|
|
|
|
0 is a valid timeslot and we should not use it... use
a negative value to be save.
|
|
We can forget about the timeslot/multiplex when getting
the DLCX. This way we make room for the next connection
that might need to reuse this address.
|
|
Always initialize the pointer to a invalid value in case
we encounter a parsing error or such.
|
|
For the statistics we do need to have an allocated config,
otherwise we will nicely crash.
|
|
We will reset the multiplex in a DLCX message and then
we can reset the multiplex as well...even if the MGCP
connection is staying open. or at least this is a theory.
The MSC likes to leave a connection open during CallControl
when hanging up early enough in the process.
|
|
In case we have a stale SCCP connection with an Endpoint that
we want to reassign...use the newest (last) occurence of that
as it is most likely the one we want to handle.
|
|
This needs to be improved to print TS of the lchan, when
the connection was created, when we received the last IT.
|
|
|
|
By adding them to the end the VTY interface will only append
connections and not change the order on each invocation.
|
|
|
|
|
|
|
|
|
|
This might help to identify what is wrong with the config
of the BSC. Also using the result of TLVP_VAL as a char
pointer looks suspicious...
|
|
|
|
|
|
The address can still be specified on the cli and it will
overwrite the config in the config file.
|
|
|
