Age | Commit message (Collapse) | Author | Files | Lines |
|
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
API osmo_stats_vty_add_cmds never had a param list but has seem problem
(no "void"), so some users decided to pass a parameter to it.
Change-Id: Ia4d1a7914308d1481fe31fe0986265ead339e61e
Related: OS#4138
|
|
If gsm0503_tch_hr_decode() returns a negative error, we shouldn't
set the marker bit or pass the negative value as length value into
osmo_hr_check_sid().
Change-Id: If49ca6926c576a2b17507b6a95b6f3ca17877d66
Closes: CID#187645
|
|
If the BSC has instructed the BTS via RSL to not autonomously perform
MS power control, we are storing this in lchan->ms_power_ctrl.fixed.
However, osmo-bts-trx would simply ignore that flag in loops.c and
continue to compute new MS power values based on measurement results.
Change-Id: I628d1f4f1094c22248d372c11c2ecc504135b757
|
|
In the ms_power_val() function, don't increment the number of
valid RSSI values counter twice.
Change-Id: I19d9d933a69f7ad6252cbe51751d5db41790c698
|
|
This allows to clearly identify the phy instance owning those messages.
Change-Id: I90990e4dbcbb2fb4a3fcb24658bdf53e57030bcf
|
|
This command allows setting a maximum TRXD format version to negotiate
with TRX. osmo-bts-trx will hence end up using that version if supported
by TRX, or a lower one otherwise (or fail if TRX doesn't support any of
them).
Since now the maximum version can be 0, avoid going through SETFORMAT
negotiation in that case, since 0 is the default version. This way we
keep backward compatibility with TRX implementations that exit upon
receival of unknown commands (such as SC5 current one).
The VTY command is located in the "phy" node instead of the "phy
instance" node because instances of same phy are expected to use same
host with same implementation, so TRXD version to use should be the same
for both.
Related: OS#4006
Change-Id: I5eb1fdc002f9d7f4acf475356d8fc998dc8f6326
|
|
Change-Id: Iea0dad65e9bc511f99375fd3ee2eb44e47a6168f
|
|
Change-Id: I8d86dec7ebc039cbfd038c4342ff328b11281865
|
|
Change-Id: I893ec9c6c2ebad71ea68b2dc5f9f5094dfc43b78
Depends: (libosmocore) Ie2a66ebd040b61d6daf49e04bf8a84d3d64764ee
|
|
The radio link quality is defined by C/I (Carrier-to-Interference
ratio), which is computed from the training sequence of each
received burst, by comparing the "ideal" training sequence with
the actual (received) one.
Link quality measurements are used by L1SAP to filter out "ghost"
Access Bursts, and by the link quality adaptation algorithms. One
can define minimum link quality values using the VTY interface.
On the VTY interface we expect integer C/I values in centiBels
(cB, 10e-2 B), while the internal structures are using float
values in deciBels (dB, 10e-1 B). Some PHYs (sysmo, octphy,
oc2g, and litecell15) expose C/I measurements in deciBels,
while on the L1SAP interface we finally send then in centiBels.
Let's avoid this confusion and stick to a single format, that
will be used by the internal logic of OsmoBTS - integer values
(int16_t) in centiBels. This will give us the range of:
-32768 .. 32767 centiBels, or
-3276.8 .. 3276.7 deciBels,
which is certainly sufficient.
Change-Id: If624d6fdc0270e6813af8700d95f1345903c8a01
|
|
Change-Id: I72937e087288fe7681fafe4099e49849657924bd
Closes: CID#162019
|
|
It was noticed with old Sony Ericsson phones (like W595 and K510i)
that the service provided by Osmocom network becomes unreliable
from time to time. The RSSI indicator on those phones shows that
the signal is lost, so neither CS nor PS services are working.
As it then turned out, System Information 3 broadcasted on the
Um interface is different than the one received from the BSC.
In particular, the content of SI3 Rest Octets IE is different.
Among with the 'GPRS Indicator', which is actually expected to
indicate whether the PCU is connected or not, SI3 Rest Octets
on the Um interface contain both 'Optional Power Offset' and
'Scheduling if and where' IEs, which are not present in the
original messages from the BSC.
Moreover, as soon as the PCU is connected, 'GPRS Indicator' IE
contains different 'GPRS RA Colour' value, and informs the MS
that System Information 13 is sent on extended BCCH, which
is not even supported by OsmoBTS!
The culprit is in rsl_rx_bcch_info(), where we pass a pointer
to osmo_gsm48_rest_octets_si3_decode(). Instead of passing a
pointer to the beginning of SI3 buffer, we actually need to
shift it to the beginning of the SI3 Rest Octets IE.
This change makes my Sony Ericsson phones happy ;)
Change-Id: Ia962cf21903ba674057cf52746996dd3254bc1c6
|
|
Change-Id: I3d6cb6fc1b182d8520ba60e431ab9b74e71d5e3c
|
|
Change-Id: I1cb28a9d6c98993705b73937409276994f375dc0
|
|
Change-Id: I3da39d48052af1759297f4ad75c220b3046c0691
|
|
TSC (Training Sequence Code) is an optional parameter of the UL burst
indication. We need this information in order to decide whether an
Access Burst is 11-bit encoded or not (see OS#1854).
If this information is absent, we try to correlate the received synch.
sequence with the known ones (3GPP TS 05.02, section 5.2.7), and
fall-back to the default TS0 if it fails.
Since the new TRXD header version, the training sequence code is
indicated by the transceiver. Let's use it!
Change-Id: I1e654a2e49cb83c5f1e6249c0de688f99bc466b0
Related: OS#1854, OS#4006
|
|
C/I (Carrier-to-Interference ratio) is a value in cB (centiBels),
computed from the training sequence of each received burst,
by comparing the "ideal" training sequence with the actual one.
So far, there was no way to expose more measurements from OsmoTRX,
excluding both RSSI and ToA. Since the new version of TRXD header,
we can receive C/I indications and send the averaged (per 4 bursts)
values to OsmoPCU (as a part of PCUIF_DATA.ind).
Please note that we also need to attach C/I measurements
to the following L1SAP primitives:
- PRIM_PH_RACH.ind,
- PRIM_PH_DATA.ind,
- PRIM_TCH.ind,
but this will be done in the follow up changes.
Change-Id: Ia58043bd2381a4d34d604522e02899ae64ee0d26
Fixes: OS#1855
|
|
This change needs to be done in order avoid adding more and more
arguments to the UL logical channel handlers (such as rx_rach_fn).
Since we have different versions of the TRXD header, and may have
other burst-based PHYs in the future, some fields of an Uplink
burst indication have conditional presence.
Change-Id: Iae6b78bafa4b86d0c681684de47320d641d3f7c0
Related: OS#4006, OS#1855
|
|
Both TRX2L1 (Uplink) and L12TRX (Downlink) messages should use
the same TRXD header format (and version) as was negotiated.
Change-Id: Idbc598ef7c1871ee8da830f3fbe0a5cc386f873d
Related: OS#4006
|
|
This change introduces a new command for TRXD header format
negotiation - SETFORMAT. If the transceiver does not support
the format negotiation, it would reject this command with
'RSP ERR 1'. If the requested version is not supported by
the transceiver, status code of the response message should
indicate a preferred (basically, the latest) version.
The format of SETFORMAT command is the following:
L1 -> TRX: CMD SETFORMAT VER_REQ
L1 <- TRX: RSP SETFORMAT VER_RSP VER_REQ
where:
- VER_REQ is the requested version (suggested by the L1),
- VER_RSP is either the applied version if matches VER_REQ,
or a preferred version if VER_REQ is not supported.
If the transceiver indicates VER_RSP different than VER_REQ,
OsmoBTS is supposed to reinitiate the version negotiation
using the suggested VER_RSP. For example:
L1 -> TRX: CMD SETFORMAT 2
L1 <- TRX: RSP SETFORMAT 1 2
L1 -> TRX: CMD SETFORMAT 1
L1 <- TRX: RSP SETFORMAT 1 1
If no suitable VER_RSP is found, or the VER_REQ is incorrect,
the status code in the response would be -1.
As soon as VER_RSP matches VER_REQ in the response, the process
of negotiation is complete. Changing the header version is
supposed to be done before POWERON.
Change-Id: I8afe950bd1ec2afaf3347ff848ee46e69c4f5011
Related: OS#4006
|
|
Dynamic MS power control should only be active if a power parameters IE
was supplied.
Change-Id: I0bbe171a287b10d71fc853cd721f66e4c84db8c5
|
|
Since we may have different versions of the TRXD header, some new
fields of an Uplink burst indication have conditional presence.
Therefore we need a smart function to print them conditionally.
Change-Id: I68729dc98a1840d2aa9e091153d176a103d5a228
Related: OS#4006
|
|
This kind of debugging can be done using trx_sniff.py tool from
the TRX Toolkit [1]. Probably, this code was needed during the
initial development and testing.
[1] https://git.osmocom.org/osmocom-bb/tree/src/target/trx_toolkit
Change-Id: I50e0e5feeba4c3028f55209dd8e41e09ed5f70b1
|
|
The new version adds the following fields to the TRX2L1 message,
keeping the L12TRX message unchanged:
+------+-----+-----+-----+--------------------+
| RSSI | ToA | MTS | C/I | soft-bits (254..0) |
+------+-----+-----+-----+--------------------+
- MTS (1 octet) - Modulation and Training Sequence info, and
- C/I (2 octets) - Carrier-to-Interference ratio (big endian).
== Coding of MTS: Modulation and Training Sequence info
3GPP TS 45.002 version 15.1.0 defines several modulation types,
and a few sets of training sequences for each type. The most
common are GMSK and 8-PSK (which is used in EDGE).
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . . . . . X X X | Training Sequence Code (0..7) |
+-----------------+---------------------------------------+
| . X X X X . . . | Modulation, TS set number (see below) |
+-----------------+---------------------------------------+
| X . . . . . . . | IDLE / nope frame indication (0 or 1) |
+-----------------+---------------------------------------+
The bit number 7 (MSB) is set to high when either nothing has been
detected, or during IDLE frames, so we can deliver noise levels,
and avoid clock gaps on the L1 side. Other bits are ignored,
and should be set to low (0) in this case.
== Coding of modulation and TS set number
GMSK has 4 sets of training sequences (see tables 5.2.3a-d),
while 8-PSK (see tables 5.2.3f-g) and the others have 2 sets.
Access and Synchronization bursts also have several synch.
sequences.
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . 0 0 X X . . . | GMSK, 4 TS sets (0..3) |
+-----------------+---------------------------------------+
| . 0 1 0 X . . . | 8-PSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 0 1 1 X . . . | AQPSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 0 X . . . | 16QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 1 X . . . | 32QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 1 1 X . . . | RESERVED (0) |
+-----------------+---------------------------------------+
== C/I: Carrier-to-Interference ratio
The C/I value is computed from the training sequence of each burst,
where we can compare the "ideal" training sequence with the actual
training sequence, and then express that difference in centiBels.
== Limitations
- The only supported modulation types are GMSK and 8-PSK.
Messages with other modulation types will be rejected.
- IDLE / NOPE indications are not (yet) handled.
- The logical channel handlers do not (yet) handle optional
fields, such as TSC and C/I. This will be implemented
in the follow-up changes.
Change-Id: If61c71d20d590bf07bfd019afb33000a0b6135bd
Related: OS#4006
|
|
It may be necessary to extend the message specific header with
more information. Since this is not a TLV-based protocol, we
need to include the header format version.
+-----------------+---------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------+
| X X X X . . . . | header version (0..15) |
+-----------------+---------------------------+
| . . . . . X X X | TDMA TN (0..7) |
+-----------------+---------------------------+
| . . . . X . . . | RESERVED (0) |
+-----------------+---------------------------+
Instead of prepending an additional byte, it was decided to use
4 MSB bits of the first octet, which used to be zero-initialized
due to the value range of TDMA TN (0..7). Therefore the current
header format has implicit version 0.
Otherwise Wireshark (or trx_sniff.py) would have to guess the
header version, or alternatively follow the control channel
looking for the version setting command.
This change introduces a new structure 'trx_ul_burst_ind', which
represents an Uplink burst and the corresponding meta info. The
purpose of this structure is to avoid overloading the existing
functions, such as trx_sched_ul_burst(), with more and more
arguments every time we bump the version.
On receipt of a TRXD message, trx_data_read_cb() now parses
the header version, and calls the corresponding dissector
functions, e.g. trx_data_handle_(hdr|burst)_v0().
Change-Id: I171c18229ca3e5cab70de0064a31e47c78602c0c
Related: OS#4006
|
|
This constant actually defines the maximum TRXD message length,
which includes the header and burst bits, not just burst.
Change-Id: I383125e1c4df039fc6b554833bc8736deacbe731
|
|
Change-Id: Iec0d86f9be7243578ddc1ab322fc313cb5ac5d0b
|
|
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 1ff0a2addd04de5bfe1601e84b013c65e500faf0
See related issues OS#4066 and OS#4074
Change-Id: Ia44310245a348675dbbf3ffc3dc5b6d207fd62d3
|
|
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
|
|
The default values of 1s were *very* long, particularly for fast
channels such as FACCH. Let's use much more aggressive values
that are more in-line with various recommendations that cold be
found online, such as
https://pcstelconext.wordpress.com/2011/05/02/2g-timer-explanations/
https://www.erlang.com/forum/erlang/thread.htx?thread=2844
https://www.erlang.com/forum/erlang/thread.htx?thread=7180
https://de.slideshare.net/BisiAdebambo/138078380-gsmtimers-59637131
Change-Id: Ic1268ae2d769b12da6cdd4ac8375e4bc033a9e3e
|
|
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 3ca59512d2f4eb1f87699e8fada67f33674918b4
(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
|
|
Change-Id: I7f54fccdae6799e5f4d956a101e11c2d6f998546
|
|
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
|
|
Change-Id: I90b6d7fb1bb7ba2f8b1f500043635b0ae5cb4495
|
|
Change-Id: Ia954b797a9bb90660b6548ec0ffb218a1dcff37a
|
|
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
|
|
Change-Id: I07e39e69a42dd09841f5d03608ec0d0b2345139a
Fixes: CID#198663 Null pointer dereferences
|
|
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
|