Age | Commit message (Collapse) | Author | Files | Lines |
|
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.
|
|
It can happen that OpenBSC decides to close the lchan but we
still receive some measurement reports until the BTS has decided
to close the channel.
|
|
* Untested code for sending the SMS BROADCAST COMMAND.
|
|
The spec seems to say we do not need to include the full MA,
even for Phase1 phones but that is not so clear...
|
|
1.) memset the gsm48_chan_desc to avoid sending dummy data
2.) According to the GSM08.58 9.3.5 the Mobile Allocation
shall be included but the empty (by setting the length
to zero).
3.) use msgb_tlv_put and calculate the length via the l3h
msgb_l3len and assign it.
|
|
|
|
@fingerprint:
This caused Motorole EZX phones (Neptune LTE chipset) to discard
all immediate assigns and thus be unable to perform location updating.
|
|
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.
|
|
This is breaking the filtering for the Measurement Report case, revert
the patch for now.
This reverts commit 69e8f8285bf080ad2050fbc20f861bc8621e5c75.
|
|
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.
|
|
Thanks to Sylvain for the hint that lead to this fix.
|
|
|
|
We now not only include the 04.08 channel description but also
the 04.08 Mobile Allocation nested IEs
|
|
When we build an IMMediate ASSign CoManD for a hopping channel,
we need to include the length of the MA in the total length of
the 04.08 message
|
|
Also, make sure the bit ordering in the pre-computed MA is correct,
as well as the cell channel description of the target cell being
present in the HO CMD.
|
|
We now compute the Cell Channel Description for SI 1 by bit-wise
OR of the ARFCN bitmask of each timeslot on all the TRX of the BTS.
Also, support generating a GSM 04.08 Channel Description IE for
the hopping case (with HSN/MAIO instead of ARFCN).
What's still missing now: Sending the 04.08 Mobile Allocation IE
|
|
This can be used by handover, early assignment to indicate the
close of the old channel...
|
|
|
|
When we issue a RF Channel Release in case of a failure we receive
RLL release indications after the channel was tearn down and we
issue another RF Channel Release as a result. The channel allocator
might have already allocated this channel and we release the channel
again with another MS on it.
Make rsl_rf_chan_release take an error argument and make it set
a new state in case of an error and change the RF Channel Release
ack to not set the state back to none in case of an error but wait
for a timeout that is a bit higher than T3111.
I tested this with removing the battery during a phonecall and
waiting for the channel failure. With this test we only send the
release once.
|
|
|
|
We assume that the lchan_free will initiate the release and
that when we handle the RLL release indication or the release
request as part of the shutdown sequence.
|
|
The current channel release has a couple of issues we will
need to fix in a set of upcoming commits.
The issues include:
1.) sending release twice
2.) reassigning the channel inbetween the relase..
|
|
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.
|
|
Add two new counters to count the RF Failures and the RLL Release
failure and make them available via the vty interface.
|
|
For GSM V1 FR, the payload type is fixed to 3 in the RFC.
But for the other codecs, the payload type is dynamically assigned
between 96 and 127. Here, we use a static mapping internal to OpenBSC.
This patch is needed to make a rather old 139 unit (with sw version
120a002_v149b42d0) work with something else than FR codec. I also tested
this patch on a newer 139 (with sw version 120a352_v267b22d0) to make
sure it didn't add a regression. More testing with newer EDGE units
should be done by whoever has some of theses.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
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.
|
|
Setting the state through a dedicated method allows us to
track the state transitions and check if they are done in
a proper way.
|
|
The theory is that the BTS is almost dead and sends out
a incomplete message and we crash with that. I have not
been able to completely verify that.
|
|
|
|
We use the (currently unusued) flags member of the bts_trx_ts structure
to track if a dynamic TCH/PDCH is currently on PDCH mode or not.
|
|
The logging/debugging code is generic enough to move it into libosmocore
while keeping OpenBSC specific definitions in openbsc itself.
This commit uses the logging support present in libosmocore-0.1.2,
you will have to update your library to this version.
|
|
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.
|
|
the 0.1.1 API is cleaned up and removes all exported global static
arrays (like rlm_cause_strs). There are now proper accessor functions.
|
|
|
|
|
|
This library is intended to collect all generic/common funcitionality
of all Osmocom.org projects, including OpenBSC but also OsmocomBB
The library currently includes the following modules:
bitvec, comp128, gsm_utils, msgb, select, signal, statistics, talloc, timer,
tlv_parse, linuxlist
msgb allocation error debugging had to be temporarily disabled as it depends on
'debug.c' functionality which at the moment remains in OpenBSC
|
|
If the lchan has AMR as speech codec we also need to send the
multirate config IE in the channel activation. This is already
done for the RSL Channel Modify message.
|
|
|
|
Also, use this new function to dump lchan state on VTY and to
improve readability of RSL log messages.
|
|
This state will help us to differentiate between channels where we have
requested the release, and channels that are actually released.
|
|
In many cases we actually want a name / unique ID for the lchan,
not just for the on-air timeslot... especially in SDCCH/8 case,
where 8 SDCCHs share one timeslot...
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|