This patch adds extended processing of the high-resolution TOA256
measurement values. It adds reporting of the following values
for each RSL MEAS REP for uplink measurements:
* minimum TOA256 value during reporting period
* maximum TOA256 value during reporting period
* standard deviation of TOA256 value during reporting period
Change-Id: Iea4a4781481f77c6163d82dcd71a844a5be87bf2
This way we give the opportunity to the BSC to release the channel
quicker, otherwise it has to wait until T3101 expires.
Same procedure is already done in rsl.c rsl_rx_imm_ass() when we return
an error (hard limit AGCH queue len reached) from bts_agch_enqueue().
Related: OS#2990
Change-Id: Id9927c0789054ce3ecc7b30380585a1ffe05db5a
The current implementation does not allow the user to specify a port
range in which the BTS is allowed to allocate a local RTP port. Also
the ports the BTS picks do not match the policy described in RFC3550.
An RTP Port must be at an even port number and the matching RTCP
port must be at the following (odd) port number. The BTS currently
picks random port numbers for both.
- Add a VTY command to specify a port range in which the BTS may
assign local ports.
- Pick ports as described in RFC3550.
Change-Id: Id75f1dfaf898ed8750d28b1c4840e188f4cfdc87
Related: OS#2825 OS#2635
The existign code only sent an ERROR REPORT, but it failed to actually
send a proper NACK to the related request. This is confusing, as the
operation should always be ACKed or NACKed, and not simply result in no
response.
Change-Id: Ic374a8e5e239ffe37082a54cdb94cb6ac9723e83
Closes: OS#3254
Whenever we encounter an error condition during processing of RSL CHAN
ACT or RSL MODE MODIFY, it's insufficient to simply send an RSL ERROR
INDICATION, but we also must send a proper NACK back to the BSC.
Change-Id: I4dd7ff2fd2cdbc6e892cd329c826ac1bc3b16bb9
The code actually always *wanted* to make lchan activation fail in
case we don't support the algorithm, but it failed ot do so.
The problem is encr_info2lchan() which uses bts_supports_cipher() to
determine if the cipher is supported. However, if bts_supports_cipher()
returns 0 (not supported), it uses this value as return value of
encr_info2lchan() where '0' means success (standard osmocom convention).
This results in channel activation proceeding, which it shouldn't.
Change-Id: I46275b8fc2a1a74f68b4cc60e0f64ba226b108cd
Related: OS#3254
This logging turned up while I was debugging dynamic timeslots:
- OML Set Channel Attributes logging.
- a specific dyn TS pchan error.
- show pchan and lchan types on CHAN ACT ACK and REL ACK logging.
- on RSL message Rx, log the current pchan kind in detail, using
gsm_ts_and_pchan_name(). This logs the underlying pchan as well as the
current pchan mode a dyn TS is in.
- move 2 dyn TS logging from DL1C to DRSL, where all the other dyn ts logging
is.
Change-Id: Ia89c134060e85f7065afd5642d1c541c65dd25ea
In early rsl_rx_chan_activ(), do not use rsl_tx_chan_act_acknack() to trigger
sending a NACK, instead use rsl_tx_chan_act_nack() directly.
Rationale: the previously used rsl_tx_chan_act_acknack() may decide to omit the
NACK, particularly based on the lchan->rel_act_kind. lchan->rel_act_kind
indicates whether the Chan Release or Activation was explicitly requested via
RSL, and thus whether an ACK/NACK should go back to RSL or not. This gets set
only late in rsl_rx_chan_activ(). We cannot set it on top, because we need to
first establish whether the Chan Activ is permitted or not. In case of early
rejection of the Chan Activ, we do not want to modify the lchan state, but
merely reply with a NACK, unconditionally.
Before this patch, NACKs that rsl_rx_chan_activ() wants to trigger would
possibly be not be sent out on RSL, because lchan->rel_act_kind is not
explicitly initialized until later.
Fixes: BTS_Tests.TC_dyn_ipa_pdch_act_tchf_act_nack
Change-Id: Ic981f768cc024f0acd3d7ae55846cfbc7bc089ce
When an RF CHANnel RELease request is received on an already released lchan,
there is no "REL NACK" message or similar, we just ACK the release.
When ACKing the release, make sure to reflect the same chan_nr that the release
was asked for, since the lchan state may actually reflect a different chan_nr.
Factor the actual Rel Ack message sending out of rsl_tx_rf_rel_ack(), which
makes all sorts of decisions around normal Rel Ack: add static tx_rf_rel_ack(),
with chan_nr argument instead of deriving chan_nr from the lchan.
Use this to directly ACK an unusual Chan Rel with the chan_nr that came in with
the request.
Fixes: BTS_Tests.TC_dyn_osmo_pdch_unsol_deact
(after I6b790e866ce4e66d9385b286b727ae41a83d3e67)
Change-Id: Iceaa2e87874ced42d664a2a0b01a1c59e46a19b3
For ip.access style TCH/F_PDCH, this fixes switch-back to PDCH in case the TCH
use employed encryption.
For Osmocom style TCH/F_TCH/H_PDCH, do the same, purely out of sanity. Roughly
the same should already be happening during PDCH Chan Activ, but make sure to
clear all these fields, so they are cleared even if IEs are missing.
From both dyn TS code paths, call new clear_lchan_for_pdch_activ(), which
clears the same fields that are normally overwritten by an RSL Chan Activ.
Related: OS#3238
Change-Id: I8451039683b54bee910c97c5a3e6873e0ff1b160
When the PCU is not connected, we immediately call rsl_tx_rf_rel_ack() because
we don't need to wait for a PDCH deactivation. Fix: properly mark rel_act_kind
= LCHAN_REL_ACT_PCU to invoke identical behavior as when the PCU were involved.
(When the PCU is connected, a PDCH release on an Osmocom style dyn TS causes an
actual release of the PDCH TS, and then triggers an rsl_tx_rf_rel_ack() with
rel_act_kind == LCHAN_REL_ACT_PCU.)
Clarify the code flow: rc == 1 is the special case of no PCU being connected,
so have that in a separate if{}.
Change-Id: I654b963815b32fcbce050c2e15f3190c97bc259f
When a release of PDCH is complete, actually set the dyn.pchan_is to NONE.
Failure to do so currently caused errors on activation of an Osmocom style dyn
TS as TCH, in the shape of:
rsl.c:636 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK
rsl.c:164 (bts=0,trx=0,ts=2,pchan=TCH/F_TCH/H_PDCH switching PDCH -> NONE) RSL rx DCHAN: mismatching chan_nr=0x12
rsl.c:2611 Rx RSL CHAN_ACTIV for unknown lchan
rsl.c:710 0x12: Sending Channel Activated NACK: cause = 0x64
The Tx RF CHAN REL ACK shows that we're through with PDCH release, but the
following line showing "chan=TCH/F_TCH/H_PDCH switching PDCH -> NONE" shows
that the state still reflects active switching. Thus the DCHAN code decides
that the chan_nr = 0x12 reflecting a TCH/H on TS 2 is a mismatch and NACKs the
TCH activation.
(For ip.access style TCH/F_PDCH, the ts->flags are cleared in
ipacc_dyn_pdch_complete()).
Related: OS#3235
Change-Id: Ic06c8f0fe82ae8a06afa5defd93a685010687965
Use a switch statement and ample comments to clarify what is done and why.
Cosmetically prepares for Ic06c8f0fe82ae8a06afa5defd93a685010687965.
Related: OS#3235
Change-Id: I8a9953b011a4516972aae468754494f57ebc0a3f
It seems that the IPA PDCH ACT ACK contains not only the channel number,
but also the frame number. Let's make sure we're as close as possible
to other implementations to ensure maximum interoperability.
Change-Id: Ibe7988e9ef374e8c7d9429777fb32322d90c2024
When writing chan_nr_is_dchan() in Change-Id: I43a78bec63aeb36dd67043d237b27fe880209349,
I apparently only looked at TS 48.058 without considering the osmocom
extension to it for PDCH activation. The result is complete breakage
for "osmocom style dynamic PDCH" support.
This patch fixes the mistake by making the compare more specific.
Change-Id: I18e0774fdd48966bc95261e715f798464b8b681f
Related: OS#3131, OS#1853
gsm_bts_role_bts was introduced at a time when we still shared
gsm_data_shared.[ch] between BSC and BTS, and where we then subsequently
needed a BTS-private structure. Since that sharing was abandoned quite
some time ago, we can merge gsm_bts_role_bts into gsm_bts and do away
with the bts/btsb dualism in a lot of the code.
Change-Id: I4fdd601ea873d9697f89a748cc77bcf7c978fa3e
The current log output logs connect_ip connect_port
speech mode and payload type over multiple lines and without
logging context (lchan name). Also the logging level
incorrectly set.
- shrink log output into one line.
- add context (lchan name)
- encode ip/port into human readable form
Change-Id: I61044edc0672b268aeebf48b59a772887703399f
Closes: OS#3001
Normal Abis RSL MEasurement Results contain only the "MS Timing Offset
IE" in units of full symbols. In some use cases it is important to have
higher-accuracy timing information exposed to the BSC.
We do this by adding the average timing offset value during the last
measurement interval in 1/256th symbol accuracy to the "Supplementary
MEasuremen Information" part of the TS 48.058 9.3.25 Uplink Measurements
IE.
In order to avoid any compatibility issues, this feature is only enabled
if the new vty config command "supp-meas-info toa256" at the bts node
is enabled.
Change-Id: Ie85e53b47d4041cc4e6d7b78406ae8b79b2d9397
In case a DLCX _with conn-id_ is issued without any CRCX before,
we ran into a NULL pointer dereference in adding the connection
statistics. Let's handle this gracefully and simply return empty
statistics.
Change-Id: If8b71266c847b90cdc51695b9f47b527c51bd70c
Closes: OS#2996
In case a DLCX is issued without any CRCX before, let's handle this
gracefully and simply ack the DLCX anyway.
Change-Id: I7c5bedccfc5a7cf552a9ce3a2dc712081c7ce177
Closes: OS#2996
This patch adds generation of a DELETE INDICATION when the BTS AGCH
queue overflows due to too many IMMEDIATE ASSIGN CMDs, as required
by the specs.
The AGCH queue length in OsmoBTS so far is at 1000 entries, which I
consider way too high. But that is for another patch.
Change-Id: Ied3306e85cbdc6f3476b10dc4bb0463cd728b274
Related: OS#2990
This reverts commit d5fdcfe6d9, which
introduces a new function lchan_meas_update_ordered_TA whose
functionality I still haven't yet managed to fully understand. It
appears to be adjusting the requested timing advance (lchan->rqd_ta) but
outside osmo-bts-trx/loops.c code. This is odd, as rqd_ta is a state
variable of that loops.c code.
So for one part, it is a failure of encapsulation. The TA loop code
should be self-contained, particularly as it is only used for
omso-bts-trx, and not for the other BTS models. The new
lchan_meas_update_ordered_TA() function is used from common code,
applicable to all BTS models.
The resulting interaction between loops.c code and this new (now
reverted) function cause the TA value to only ever grow, despite the MS
never moving at all.
Change-Id: I5a5adac6f18f94a5b51758a5ace8ef6ddfd23e80
Related: OS#2989
osmo-bts has a table of pchan/channel mode combinations for every
bts. This table models the codec capabilitys of the BTS hardware.
However, having the speech codec apabilities modeled inside the
BTS feature list would be much more comfortable and since the
feature list is communicated back to the BSC we would get the
codec capabilities inside the BSC domain as well.
- remove the pchan/channel mode tables
- set speech codec variants for each BTS type
- fix bts_supports_cm so that it queries the feature list
Change-Id: I977dc729ba856631245aedf76afd48eac92166f7
If the Channel Number IE points to a common channel, we cannot
accept such messages in code paths that only process dedicated
channels, such as RLL/DCHAN/IPA.
Related: OS#2972, OS#2971
Change-Id: I43a78bec63aeb36dd67043d237b27fe880209349
If we receive a message for a dedicated channel, whose channel number
structure doesn't match with the physical channel (timeslot) type,
we must properly reject this. For RSL CHAN ACT it means sending a NACK,
and for all other cases it means sending an RSL ERROR REPORT.
Related: OS#2972, OS#2971
Change-Id: Iebd2571726d1284a7431b3f9b23ad3185e832ed1
When the BSC sends a MODE MODIFY request with an unsupported
codec, the BTS must respond with a negative acknowledge.
Currently the codec parameter is not checked at all, which may
lead into malfunction or crash of the BTS.
- Introduce a mechanism to check the codec/rate against a
table that is set up in the phy specific code.
- Add tables with supported codec/rate combinations for
octphy, sysmobts, and trx.
Change-Id: Id9b222b7ab19ece90591718bc562b3a8c5e02023
Related: SYS#3212
The function rsl_tx_mode_modif_nack() uses abis_bts_rsl_sendmsg().
This function relys on msg->trx to be set (see abis.c). However,
rsl_tx_mode_modif_nack() creates the message buffer, but does
not set msg->trx.
- Make sure that msg->trx is set properly
Change-Id: Ib5990db11df1b25dc5d321193731426b11f8005a
When the RSL_IE_CHAN_MODE is is missing, then the message buffer
is freed and the channel mode modify is nacked using
return rsl_tx_mode_modif_nack()
The function rsl_tx_mode_modif_nack uses abis_bts_rsl_sendmsg()
which returns 0 on success. This eventually leads into a double-
free in rsl_rx_dchan() which frees the message buffer on all
return codes except 1.
- Remove the excess msgb_free() in the error handling path.
Change-Id: I946a927ba35aa115520b1248eefccd91832f69f6
Wireshark was showing a Malformed packet alert, and further
ivnestigation showed that "Resource Information" TLV was missing in the
packet. See GSM 08.58 sections 8.6.1 and 9.3.21 for more information.
Indicating interference level is not yet implemented, but at least now
we avoid sending a malformed packet.
Patch has been validated against a running setup with wireshark in my local PC.
Related: OS#2735
Change-Id: Ie97170811aaf8a089febfa20380ab48ea174056a
The RTCP Sender Description is supposed to contain useful information
to identify the source of the RTP stream. So far, it only contained
compile-time default data of libortp. Let's put the BTS UnitID, the
lchan number and the OsmoBTS version in there.
This change requires libosmo-abis Change-Id Ice794f9e0c6caeea1c67520c12efbfa375d1fb82
Change-Id: Id6ce7188354d3a0517661c9648854ec829ef1cac
Related: OS#2701
The respective errors/events occur as a result of calling osmo_rtp_*
API, and are clearly more fitting into the DRTP category than the DRSL,
even though the respective actions are triggered by RSL.
Change-Id: I52e6f9865492a2f757a37860eb92a3dc49e174ef
Previously the received SI was copied to si_buf unconditionally which
means that the first SI2q message is always overwritten be the last one.
Fix it moving check for SI2q ahead of generic code and moving generic
copy into else branch of SI2q check.
Change-Id: Ib8031d2f0e00368283a40b4aadb3eea616038d04
Related: OS#2357
If SI13 becomes unavailable in runtime than send 0-length message with
BCCH SAPI to PCU to indicate that SI13 have to be removed.
Change-Id: I72aef8bd98f21c4b5ea6eed21fc56b30d85bfc1b
Related: OS#2400
* explicitly set SAPI when sending data_ind to PCU
* drop unused receiving code for BCCH SAPI
* send SI13 when PCU is connected
* send SI13 when new SI is received
Change-Id: I9e83ef792585aa962f99897d9973cef12f186bcf
Related: OS#2400
The number of SI2quater messages might be updated dynamically by
BSC (via 'bts 0 resend-system-information' command for example). Log it
but do not return error.
Related: OS#2357
Change-Id: I9625be879c672e20543cc40af288828143ffb983
* change BCCH Info handler to explicitly support multiple SI2quater
messages sent from BSC
* change SI scheduler to send SI2q in round-robin way
That's resubmission of 340cff51f4 and
186c6bac07 with memory initialization
order change to fix the issue detected by osmo-gsm-tester - see OS#2338.
Change-Id: Ib595733cde108387bc7ee76b1b11ada6a235f13c
Related: OS#1660, OS#2338
This reverts commit 340cff51f4.
osmo-gsm-tester detected a regression due to this commit, when running
osmo-bts-trx. The modems timed out when waiting for them to register with the
osmo-bts-trx network. osmo-bts-sysmo is apparently not affected. No further
details on the failure cause are known yet. The failure is shown for example by
http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/868/
Change-Id: I15bca30ddc09a7a3044096626016f6130d07636c
This reverts commit 186c6bac07.
osmo-gsm-tester detected a regression due to commit
340cff51f4, which above commit apparently depends
on. Revert this along to avoid conflicts.
Change-Id: I456e9add788393ca781213cef31b5bc3d48fd531
Check for impossible index and count values of SI2q messages. The limit
is defined in 3GPP TS 44.018 Table 10.5.2.33b.1
Change-Id: I351f8e8641a1cb9548154803da70bfde46ee180d
Fixes: CID 170749
* change BCCH Info handler to explicitly support multiple SI2quater
messages sent from BSC
* change SI scheduler to send SI2q in round-robin way
Change-Id: I3aeb90804edab1b0325c3eb7347526ae995dbf51
Related: OS#1660
The debug log does not print much information about the measured
rxlev and rxqual values. This commit adds debug output to make
measurement debugging simpler
Change-Id: Ic871eed6dcbc7d10aca6cd11dbc803b3e6da449f
Pau Espin
Harald Welte
Philipp Maier
Neels Hofmeyr
Neels Hofmeyr