Age | Commit message (Collapse) | Author | Files | Lines |
|
This bumps the PCU API version and thus requires a new version of the
code on the sysmoBTS side!
|
|
In case that the counter S reached 0, it will stay 0. Subsequent received
good and bad SACCH frames must not cause to trigger radio link failure
again. Once the BSC has been indicated about link failure, it will release
channel.
The counting of S has been moved to a seperate function.
This patch will ensure that the link failure is indicated only once. But
even if the link failure would be sent multiple times, the BSC should
ignore it. The BSC releases the channel and may only reuse it after confirm
from BTS. (There cannot be any link failure indications after confirm of
channel release.)
The allowed timeout value range is 4..64, as defined in TS 05.08, so if the
BSC sends an attribute with value out of range or other failure criterion,
the Set BTS Attributes message is NACKed.
|
|
Looking at the problem, it's a surprise that the old code was working at
all... (Thanks to jolly for pointing this out)
|
|
As per Chapter 9.3 of TS 08.58, we have to use RSL_IE_CHAN_NR instead
of the zero we were implicitly using so far.
|
|
Chapter 5.2 applies to MS procedure, but 5.3 (BSS procedure) defines no
exact criterion, so I decided to use the procedure equivalent to MS.
The criterion is based on a counter S, which is initialized to a preset
RADIO_LINK_TIMEOUT, which can be configured via VTY. Whenever a received
SACCH block is bad, S is counted down by one. If SACCH block is
successfully decoded, S is counted up by two, but never above initial
RADIO_LINK_TIMEOUT value. If S reaches 0, an RSL Connection Failure
Indication with cause RF Radio Link Failure is sent to BSC, which then
aborts channel.
Use link timeout value from BSC via OML attribute.
How to test:
- Set "debug" for "meas" logging.
- Start silent call to an attached mobile.
- Remove battery from mobile or shield mobile.
- Watch S count down.
|
|
Issue the RfDeactivate.REQ before sending the MphClose.REQ. Ideally
we would issue MphClose.REQ after the RfDeactivate.CNF but this is
not possible right now.
The current approach makes the following warning of the DSP go away
on shutdown. This was tested with my E71 and an active silent-call
using a SDCCH.
DSP Warning:
[ERROR] : DeviceMng_ValidateL1Handle() => Invalid layer 1 handle
|
|
If the CRCX does not indicate the remote IP address, then we still were
binding to 0.0.0.0 and used that address successively in the CRCX_ACK.
As a workaround, we now use the source IP address of the RTP socket,
assuming that the outbound routes to BSC and the MGW are identical.
This is of course not always true, but I don't think there are any
better alternatives...
|
|
for whatever reason i decided that a port number in
osmo_rtp_get_bound_ip_port() needs to be a int * and not a uint16_t * at
the time, so we have to deal with this here rather than breaking the
ABI.
|
|
After we create a socket and bind it to INADDR_ANY, we cannot yet use
getsockname() to resolve the locally bound IP. This only works after
the socket has been connected to the remote IP. So we have to move the
osmo_rtp_get_bound_ip_port() to a code section after
osmo_rtp_socket_connect() has already happened.
With the code prior to this commit, unless "rtp bind-ip" was used in the
config file, we reported "0.0.0.0" as the "Source IP AddresS" in the IPA
CRCX ACK to the BSC. This is of course wrong, as the BSC will then use
this "0.0.0.0" as destination address for the incoming RTP stream :(
Please note that for this fix to work, you also need a libosmoabis.git
with commit d426d458ca96ba29793e35b1b2a73fbcb3b2c888 which actually
causes osmo_rtp_socket_connect() to actually issue connect() on the
socket at all.
|
|
Instead of explicitly having to specify the local IP address for RTP
sockets in the BTS, we just use "0.0.0.0" instead, which gets
translated to INADDR_ANY.
We still accept the configuration directive in old config files, but
when we write, the line will no longer be re-written to the file.
TODO: IMHO, the IPA RSL CRCX/MDCX actually permit the BSC to specify the
IP address on the BTS side, and we probably simply ignore this at this
point.
|
|
As we currently don't use any BSC-based MS power control in either
OpenBSC nor in OsmoBTS, this bug has never shown up so far.
Thanks to Andreas Eversberg for spotting this.
|
|
|
|
These attributes are saved in paging_state, we don't need to save them a
second time in struct gsm_bts_role_bts. Add get and set methods for
these attributes and use them consitently in the VTY code.
|
|
This was experienced by Daniel on his 64bit machine. The paging
expiration time was too high and not set by the code at all. Using
gdb watchpoints he found the place where the memory is written. The
issue is that the size of the pointer (8) and not the size of the
data structure was copied (3).
Fix the issue by assigning the de-referenced value. gcc generates
the same code as if we had written:
memcpy(&ps->chan_desc, chan_desc, sizeof(*chan_desc));
|
|
This was found and debugged by Sylvain. The BTS will always support
A5/0 so we do not keep track of that, the first bit of the flags is
used for A5/1, second for A5/2... but for RSL there is an offset to
go from RSL to A5(x). Add a testcase and change the code.
|
|
Right now osmo-bts requires access to one OpenBSC header file and
this requires that openbsc and osmo-bts git are in the same directory.
Begin with making the location of the OpenBSC sourcecode configurable.
This approach will allow to build osmo-bts on our Jenkins installation
but now has the risk of more code including the openbsc/*.h header files.
|
|
The method was not returning anything and the callers did not use
the result. Change it to void for now.
|
|
The rsl.c code was calling the paging request with a const pointer,
change the signature to make the code const.
|
|
Address the compiler warning and truncate the value by hand.
|
|
This may be adding bells and whistles that nobody wants to touch, but at
least for current analysis/optimiziation they are useful to have. Later
on they should probably be removed again and/or obsoleted by OML
messages for configuration of paging behaviour by the BSC.
|
|
This is mainly as OpenBSC is adjusting the amount of paging commands it
sends based on this magic value 0xffff.
|
|
This is required for CPUs < armv6, to access 16 and 32 values at right
memory locations.
|
|
|
|
... as jolly correctly pointed out.
|
|
|
|
The confirm is required, so PCU knows when an IMMEDIATE ASSIGN message has
has been sent on PCH. The PCU will start packet flow after that confirm.
|
|
|
|
|
|
|
|
Use "-P -M" to enable PCU and direct access.
|
|
|
|
The client (PCU) can check if it is compiled with a different version.
|
|
|
|
Thanks to Andreas for spotting this.
|
|
|
|
A special command line option "-P" is used to enable socket interface
and signal available GPRS MO object to BSC.
|
|
During init process, signals might be sent. PCU receives these signals and
requires that BTS instance is already in the list.
|
|
|
|
|
|
This is required for PCU to send IMMEDIATE ASSIGNMENT messages on PCH.
A message in a paging record is sent only once.
|
|
|
|
The paging needs to expire when the expiration time is smaller
than the current time.
|
|
We now bring the GPRS related MO up in DEPENDENCY state and parse
the various NS, BSSGP and RLC parameters as set by the BSC via 12.21/OML.
|
|
|
|
|
|
As the careful commitlog reader Andreas points out: When the BSC does
not sent NM_ATT_MAX_TA, then it would be zero instead of the specified
default value of 63.
|
|
The total count of RACH or PCH slots should never be zero, as they
constantly increment. However, just as a safeguard, we introduce
an explicit handign to avoid divide-by-zero situations
|
|
We now count the total number of RACH slots, the number with rx level
above the busy threshold, and the number of valid access bursts.
This data is used to generate RSL CCCH LOAD INDICATION for the RACH.
|
|
As Holger pointed out, it may well be the case that there are no system
information messages to be sent at TC=4, and we should avoid a modulo by
0. I'm simply sending SI2 instead now, as it isn't forbidden to send it
more often than the minimum at TC=2...
|
|
|