This constant actually defines the maximum TRXD message length,
which includes the header and burst bits, not just burst.
Change-Id: I383125e1c4df039fc6b554833bc8736deacbe731
Otherwise t200_ms_dcch array values are left uninitialized with random
values, and passed later on to lapdm_channel_init2().
lapdm_channel_init2() will anyways fail during initial check on
get_n200_dcch() and return -EINVAL, so let's not print garbage or call a
function which will anyways simply return an error.
Catched due to some strange values seen in log (see D0 and D3):
osmo-bts/src/common/bts.c:421 (bts=0,trx=0,ts=0,ss=4) Setting T200 D0=1028672, D3=2, S0=520, S3=520 (all in ms)
Related: OS#4066
Change-Id: I3d7e1883811acf97aac97325739f2ff97fc2aa08
The timers are unfortunately completely broken, so let's go back to the
long default timeout values from 1ff0a2addd
See related issues OS#4066 and OS#4074
Change-Id: Ia44310245a348675dbbf3ffc3dc5b6d207fd62d3
This will generate the VTY/counter documentation for osmo-bts-virtual so
it will be missing documentation for device-specific commands/counters.
Change-Id: Idebb099b69924d6212db119f7a2f2861d4150d7e
Related: OS#1700
By using new libosmocore LAPDm API we can specify the GSM channel type
and hence enable the LAPDm code to use a per-channel-type specific N200
value.
At the same time, this new API also allows us to specify T200 values
when initializing the LAPDm channel, so we don't have to fiddle with
low-level lapdm data structures in what used to be oml_set_lchan_t200().
Change-Id: I0e814fbae13e0feddd148c47255dcc38cb718f48
Depends: libosmocore I90fdc4dd4720d4e02213197c894eb0a55a39158c
Closes: OS#4037
As per GSM TS 12.21, the LAPDm timers (T200) of the LAPDm instances
in the BTS are configured via OML from the BSC. While OsmoBSC
is sending them and OsmoBTS is parsing them, OsmoBTS stopped to
make use of them from commit 3ca59512d2
(January 2016) onwards.
The cause for this has been documented and discovered in May 2017
in https://osmocom.org/issues/2294 and it is quite obvious: LAPDm
timers are supposed to start when a given frame is actually transmitted
on the radio interface. PH-RTS.ind and PH-DATA.req are suppsed to be
used over a synchronous interface in some deeply embedded processor.
With OsmoBTS however, we have an asynchronous L1/L2 interface between
a DSP (osmo-bts-{sysmo,lc15,oc2g,octphy}) or OsmoTRX (osmo-bts-trx)
and we receive PH-RTS.ind quite some time ahead. So if we start T200
at that point, then it will start running way before it has been sent
or before the MS has had a chance to receive the message.
The "correct" way to handle this is to actually measure the difference
between frame numbers in PH-RTS.ind (uplink, advanced) and PH-DATA.ind
(downlink) or PH-TIME.ind, and then add that amount to the actual
timeout value. This ensures that the timers will time-out the
user-specified amount of time after the actual transmit.
Change-Id: If8babda9e3e5e219908911ddd9c0756b5ea0bca4
Closes: OS#2294
Closes: OS#3906
Let's keep some statistics about the min/max/average frame number
advance that we're observing above L1SAP when comparing the time in the
PH-RTS.ind and the frame number we observe in PH-DATA.ind of data
that was received on the uplink.
The statistics are currently only shown in the VTY, but this is a
precursor to using them to correctly advance the LAPDm timers in a
follow-up patch.
Change-Id: I8f739fdb808a614f080afbc4654641ec3df19eb2
Related: OS#2294
Related: OS#3906
Let's avoid fancy alignment in the description of logical channels
for the benefits of having better readability, the ability to add
more comments and fields without making it look ugly.
Get rid of value-string array 'trx_chan_type_names', since each
logical channel has its name defined in 'trx_chan_desc'.
Get rid of field 'chan' of 'trx_lchan_desc' structure since it's
not used anywhere, and not actually needed because the position
of each lchan description is defined by its TRXC_* type.
Replace both 'pdch' and 'auto_active' fields with more generic
bitmask field called 'flags', and define the following flags:
- TRX_CHAN_FLAG_AUTO_ACTIVE,
- TRX_CHAN_FLAG_PDCH.
Use RSL channel mode #defines from libosmogsm instead of having
hard-coded numbers. This increases readability.
As a bonus, let's add a human readable description to each lchan
definition, so it can be printed in the VTY some day.
Change-Id: I9d5d49ec569f133d37b8164b22607d4700474315
Backported from: I2fc61e1cdca4690a34e2861b9ee3b7c64ea64843
I7ab4958801b3422973b67ff0452b90afa8a3f501
This way we unify format. We take the chance to add related information
to some log messages which were not printing that information (and was
confusing when using more than one phy instance).
Change-Id: I5b17a01638ade9a6c41da73e550d5947fa92f568
At the moment, bts_supports_cm() is only called on reception of
RSL Channel MODE MODIFY from the BSC. The idea is to check whether
the indicated RSL channel mode is supported by a BTS model.
RSL Channel MODE MODIFY message may indicate a channel in signalling
mode, i.e. GSM48_CMODE_SIGN, which has always been rejected so far.
Let's assume that signalling is always supported, as there is
no special BTS_FEAT_* definition to check that.
This change should make BTS_Tests.TC_rsl_modify_encr pass.
Change-Id: I8ea98a3eb9dc15a04f665596ee276883eb824b9a
According to 3GPP TS 48.058, section 8.4.1, the Handover Reference
element must be included if channel activation type is 'handover'.
Let's properly reject CHANnel ACTivation messages with missing
RSL_IE_HANDO_REF. Otherwise such requests are misinterpreted
as regular (non-handover) channel requests.
Found using TC_ho_rach() TTCN-3 test case.
Change-Id: I9c50e1dbeb54c5470560adcdfb2bdf5abbe47993
It looks like the status LED on the sysmobts2100 never worked correctly
since lc15bts-mgr expects osmo-bts-lc15 to create and manage
/var/run/osmo-bts/state, but there is nothing to do so in osmo-bts.
This patch copies the functions from oc2g to manage the state file in
lc15.
Change-Id: Iad32a22fc72e2aba45e4f1b9ae585f6e0b8757ed
Related: SYS#4493
osmo-bts-oc2g no longer modifies the status LED and instead leaves that
to the bts manager. The service file now also creates a directory in
/var/run needed for osmo-bts to communicate with oc2gbts-mgr. This
status file is used by oc2gbts-mgr to figure out when the bts is
operational.
Related: SYS#4493
Change-Id: Ifae634c6c2ecec7d32298c0f266f91f3e81308f5
osmo-bts cannot provide GPRS service while osmo-pcu is not connected.
The BSC has no knowledge of the PCU connection state. Prevent MSs
from trying to register for GPRS while the PCU is disconnected by
erasing the GPRS Indicator in SI3.
Change-Id: I1a6f5c636c0fe098ee31c280d4572a3f8122b44b
Depends: I690cf308311f910005a325d50f5d5d825678d2b2 (libosmocore.git)
Depends: I08e0ca9a8d13c7aa40b9d90f34f0e13adb87d4e0 (libosmocore.git)
Depends: I8b1ee2405f6338507e9dfb5f1f437c4c2db2e330 (libosmocore.git)
Related: OS#3075
Remove the '~' from '|= flag', it is plain wrong.
This affects the correct parsing of DSP trace flags from the config
file only. The bug is not present in the interactive VTY command
at runtime.
Change-Id: I915971f49642967c969f5dd475e8faa960ef3960
The existing code ssumed that the RR SUSPEND REQ would be a
LAPDm/RSL unitdata request. I couldn't find any spec reference
that would support this. Rather, the message is sent via the normal
main dedicated channel, which is operated in ABM mode.
As the somewhat similar check for diverting measurement results
is in fact looking for UNITDATA, we have to untangle this slightly.
Change-Id: Ic75486f8edaefa9c07bd92515ba1832b1c482fa6
Related: OS#2249
Related: OS#4023
Example: The fact that the PCU has connected with a given version is not
a *failure* in the first place, particularly not a MAJOR one. Let's
allow callers of oml_tx_failure_event_rep() specify the serverity of the
event that they're reporting to the BSC.
Change-Id: I49af04212568892648e0e8704ba1cc6de8c8ae89
Rather than open-coding "Tx foobar..." in various functions (and
forgetting it in half of them), let's add a generic message into
oml_mo_send_msg().
Change-Id: I5dd4b1749e68fb7fc74cb2e3a778d2418f46b770
Some of our OML log lines were missing any context. Try making more
sense by printing any context information about the given managed
object, TRX, ... as we have it.
Change-Id: I60d1660c6d574f206d7b8cc10082b413142365dd
In case of a Combined CCCH (with SDCCH/4), the number of RACH slots
depends on the frame number. So in case of lost/skipped frame numbers,
we cannot simply compute the value for the current fn and then multiply
it by the number of frame numbers expired. Rather, we have to 'replay'
all missed frame numbers and individually determine how many RACH
slots happened in that frame.
Related: OS#3750
Change-Id: If4f8d2ea55fc722c64c330cde09e833b67ee98fe
We used a bogus multiplication factor of four when computing the number
of expired RACH slots. While there are four RACH slots per block (i.e.
4 times more RACH received than normal MAC blocks), that multiplier
doesn't apply here: We are calling this function per *frame* and not
per *block*. So the maximum number of RACH slots per *frame* is (in
most suual cases with a single CCCH) at maximum 1. Only some obscure
configurations with multiple CCCHs in a single cell would render higher
values. In any case, *blocks* never even enter this equation.
This wrong multiplier resulted in rather weird RACH load reports to the
BSC.
Related: OS#3750
Change-Id: I6b14fd6e7819f9164fb4a09b432a9f419e3b6e5c
While we re-set the PCH load counters after every report, we never
actually re-set the RACH load counters. This meant that the
period/window for RACH load averaging would always grow, rather than
being reset every load indication period.
Related: OS#3750
Change-Id: Icd9150ba56d77d031c3cf496c5936c2de52b364c
The spec is quite clear: If the MS Power Parameters IE is present, then
the BTS shall perform autonomous MS power control. If it's absent,
then the MS power shall be fied. Let's adjust our code accordingly.
Change-Id: Ie43a1fc9cc658677c8c945ae82d03b7bffbe52d5
Related: OS#1622
In the following commit, we introduced transmitting the
RSL DELETE INDICATION on AGCH overflow:
commit 19da7fdea8
Author: Harald Welte <laforge@gnumonks.org>
Date: Sat Feb 24 04:32:29 2018 +0100
So let's sync the manual with the code.
Change-Id: I988778bdb83271355dc11b1a30a59e1a5dba5fb2
Related: OS#2990
There's no point in open-coding what LOGPLCHAN was created to do:
Log some event while stating the name of the logical channel.
Change-Id: I6913ac8fb543811126b85a54118333155c03bc03
This adds the final missing part to full CBCH support:
* keep a tab on the current queue length for basic + extended CBCH
* keep rate counters about the number of sent / transmitted SMSCB
* send CBCH LOAD information via RSL to the BSC
Change-Id: I7068c7937a60a900c40439115bb84dc3ee0d061f
The function get_p_max_out_mdBm() returns a value in 1/1000th of dBm,
"milli-dBm", while trx->nominal_power is only whole dBm. We were
missing the required divider of 1000 ever since Change-Id
Ieff75d5becaa80a2097b6e744c75c2d16259c9a4 was merged in February 2017.
The good news is that this really only affected the VTY output and
not any actual operational aspect of the system.
Change-Id: If92d0b15c48dafc63776b82c7ff5f3c2b3505f68
Closes: SYS#4570
We meanwhile support the SMSCB Channel Indicator IE and hence
can send SMSCB on both BASIC as well as EXTENDED CBCH
Change-Id: I63cc9c8c4c8c80440a61a0687e1f0cb97cc723b7
The logic for Extended CBCH are the same as for the Basic CBCH, we just
need to
* duplicate our related state
* parse the optional RSL_IE_SMSCB_CHAN_INDICATOR IE
* start to send data on the Extended CBCH (TB=4..7)
Change-Id: If2c6dc7da1e2185ab75fc957f8d305ad8db22429
Closes: OS#3535
The BSC can not only send us each to-be-sent message separately, but
it can also configure a DEFAULT message, which is then to be sent
instead of the NULL message. Let's add support for this
Change-Id: I65a79215b54155d128c26d2ca11ff9ff3ed2cdba
Closes: OS#4013
There's no need to keep around a pointer to the next segment
in a SMSCB message. The way how the multiframe structure is
laid out (and how the tb number works), we can use the result
of a modulo-division on the frame number to determine which
of the segments/blocks inside a SMSCB message (page) we have
to transmit.
This also acts as a simplification in preparation of support
for the SMSCB DEFAULT type.
Change-Id: I48faa19fec4a0852e6112ca2faa98960c678d4c5
Related: OS#4013
The first block of "schedule" messages must be advertised with
a special sequence number coding, see Table 1 of 3GPP TS 44.012.
Change-Id: I473edf698eba7ff5008f2fd1ec1776f0aa013858
Closes: OS#4012
Vadim Yanitskiy
Pau Espin
Eric Wild
Daniel Willmann
Harald Welte
Oliver Smith