Each timeslot can have its own Training Sequence Code value, which
may optionally be included in the NM_MT_SET_CHAN_ATTR message sent
over the A-bis/OML. If it's not present, then the TSC value for a
timeslot is derived from the BCC part of BSIC, which is always
included in the NM_MT_SET_BTS_ATTR message.
On the TRXC interface, the BTS global TSC value is indicated to the
transceiver using either of the 'SETTSC' or 'SETBSIC' commands.
The transceiver then applies this value for all timeslots by default,
however it can be redefined for each timeslot individually using
additional arguments of the 'SETSLOT' command (see section 25.2.4.1
in the user manual [1] for more details).
Currently, trx_set_ts_as_pchan() sends TRX_PROV_EV_CFG_TSC to the
transceiver provisioning FSM, together with the per-timeslot TSC
value. This event causes the FSM to modify the global TSC value,
that is going to be or has already been sent to the transceiver.
This is wrong, the global TSC value shall not be overwritten.
Remove the TRX_PROV_EV_CFG_TSC, and include per-timeslot Training
Sequence Code and Set in the data structure that gets passed together
with the TRX_PROV_EV_CFG_TS instead. Implement handling of the
optional per-timeslot TSC in trx_if_cmd_setslot().
[1] https://downloads.osmocom.org/docs/latest/osmobts-usermanual.pdf
Change-Id: Idc5796151e3e83f42d60c2d4cb7c35890d76a7f5
Related: SYS#4895, OS#4941
Starting from TRXDv2, several PDUs may be batched together and sent in
all together a single datagram. This requires us to increase the buffer
size that we use for sending and receiving TRXD messages. Let's use
65536 matching the default MTU value for 'lo' interface on Linux.
Given that 65536 is quite a big number, let's allocate a shared Rx/Tx
buffer statically to avoid [potential] stack overflow.
Change-Id: I729451c8ecdc7ff2631beb423f15523db16b3ee3
Related: SYS#4895, OS#4941, OS#4006
TRXDv2 brings significant changes to the whole PDU structure, not
just the header. Let's highlight this in the code / strings.
Change-Id: Id0274bd1ae5c419548596ed1852e6a28ec62b713
Related: SYS#4895, OS#4941, OS#4006
Since commit 221ee92551,
bts_model_trx_deact_rf() was being called when RF locking the TRX, which
was implemented by resetting the scheduler. This proved to be a messy
and wrong way to emulate disabling RF, since it modifies tate on lots of
structures from which it is later difficult to recover from, causing
bugs and issues like:
82a35a1dbfbe15a12c87eef420d1cahttps://osmocom.org/issues/4694https://osmocom.org/issues/4695https://osmocom.org/issues/4696https://osmocom.org/issues/4697
So for all these reasons, it is believed a good solution to avoid
resetting the scheduler and simply ask lower layers (osmo-trx) to take
care of disabling RF TX/RX on a given TRX. For TRX implementations not
supporting the newly added RFMUTE command, ramping down to -10dBm still
provides for a way to emulate RF locking. In any case, none of this was
supported until recently so it's not like we are breaking some feature
here.
Related: SYS#4920
Change-Id: I1423ddb390ef327ec7d4a27de2ac5dca663773a5
The state of each config required is now tracked through the "acked"
variables, this way the FSM can know when all configs are confirmed by
the TRX and can proceed to submit POWERON command.
With this version each TRX is still totally independent (there's an FSM
per TRX), which means POWERON can be sent on TRX0 before TRX!=0 are
fully configured. As a result, powe ramping may start before we know the
NOMTXPOWER of a TRX. This kind of issue will be fixed in next commit.
Related: SYS#4920
Change-Id: I1b736a4be5ce52a854f5767d8609153e1f4c08d9
This change is similar to what we did for Uplink bursts:
- group all Downlink burst parameters into a single structure,
- allocate it once and pass a pointer to lchan handlers,
- pass a pointer to trx_if_send_burst().
Given that the structure is allocated and (zero-)initialized in
trx_sched_fn(), we can get rid of some memset() calls in lchan
handlers and thus improve the overall performance a bit.
Change-Id: If3014e69746559963569b77561dbf7b163c68ffa
The nominal transmit power is still only configurable manually from
osmo-bts-trx VTY interface. Support to retrieve the nominal power
from osmo-trx will come later.
Change-Id: Ia7c353e4c199e0fc3bcab55c45a4abda2c66d2c1
This variable meaning has been changing its exact meaning over time
until finally not being really clear which kind of state it holds.
Initially it seemed to be used to identfy whether CLOCK IND were being
received. However, over time both osmo-bts and osmo-trx have evolved and
were fixed so that clock indications are only sent by osmo-trx after
POWERON command is sent. As a result, this state can be checked simply by
looking at the "powered" phy_link variable, which is only set to true
once the TRX has confirmed the POWERON command, and hence it is sending
CLOCK IND.
On the other hand, at some point in time "available" started to be set to 1
in bts_model_phy_link_open(), which means available is nowadays almost
always 1 from startup until the end (only dropped during bts_shutdown(),
when we are already exiting the process anyway).
As a result, !available condition in scheduler_trx.c:trx_fn_timer_cb can
almost never happen, because available is set to true already. Only
possibility would be if an old process of osmo-trx (not set up by this
BTS process) is still sending CLOCK INDs, but in that case we for sure
don't want to configure the BTS based on that, but ignore them until
this BTS process has again configured the TRX. So that whole check can
be dropped. We are better checking for "powered" state, which is far
more accurate, and we better do that in trx_if.c before calling
trx_fn_timer_cb().
Other uses of "transceiver_available" being used can be changed to use
plink->state!= PHY_LINK_SHUTDOWN, since available was already being set
to 1 at the same time the plink->state was being set to
PHY_LINK_CONNECTING.
As a result of this state handling re-arrangement, OS#4215 is fixed
since trx_if_powered() is used instead of previous state condition to
check whether data frames should be sent.
Related: OS#4215
Change-Id: I35f4697bd33dbe8a4c76c9500b82c16589c701d4
Use of variables in each code is confusing and mixing configuration with
POWERON/POWEROFF state (which is at least per phy inst and not per TRX,
since those commands are only expected on the 1st phy inst).
* field "poweron" becomes "enabled", and is used as an indicator for
actions to take during TRX provisioning (hether to power it on and
configure it or to power it off).
* poweron/poweroff state becomes "powered", and it is shared by all trx
in same phy_link, and is updated only after confirmation by TRX.
* poweron_set becomes poweronoff_set (because it's used by both POWERON
and POWEROFF), and becomes shared by all trx in same phy_link, since
those CMDs are usually sent by first phy instance of the link (the first
trx).
Related: OS#4215
Change-Id: Icd0b482f1454236432e1952220bbec9d178b8607
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
The setup is only needed once, so no need to set it every time we want
to schedule it.
Furthermore, it will ease new code introduced in follow-up patches,
which will schedule this timer under some circumstances without need to
send a message at the same time (because re-try of a cmd after a delay
is wanted).
This commit adds an alloc function and an init function to keep
different parts of the code decoupled and avoid exposing more
implementation details between them (like exposing the trx_if timer).
Change-Id: I3b6461d0130d25284e673c5efce0b3832c48bbb5
First the cached CMD sent (struct trx_ctrl_msg) is reworked to have the
cmdname and the params in different buffers for easier comparison with
RSP later.
For the receive path (trx_ctrl_read_cb), new function helpers are added
to parse the buffer into cmdname+params+code (parse_rsp) and to compare
if a given RSP matches the current CMD we sent (cmd_matches_rsp).
The reasoning behind this patch is that a way to check for parameters
when receiving a RSP will be needed in future work, as before this patch
checking of parameters is ignored. This commit is a preparation for commit
to check for duplicated responses.
Change-Id: I2474cbc3e4457cf04f78e1c168768295e1132034
Whether or not we are talking to an OpenBTS (SETBSIC) or OsmoTRX
(SETTSC) transceiver is a property of the phy_link, and not a property
of the BTS. Also, we *really, really* should never use global
variables. I'm very happy this is being cleaned up, finally.
Change-Id: I51aeb17661dfd63ff347f7b2c0d7ffa383ec814c
Those global variable declarations for non-existing variables were
introduced in 8a8d73a691, let's remove
them again. The source / destination IP address is a parameter of the
phy_link, and not a global variable.
Related: OS#1848
Change-Id: I94b5f934fc3bd00b0467d90029d3053b16594186
Related code / function structure still dates back to the pre-phy_link
days. Let's clean this up to make things less convoluted and reduce the
number of non-static symbols needed between code split over two files.
Change-Id: I1f30ae1f547a5c01c516d4a05032193294c25f2d
The new name makes it clear what the function actually does: Send burst
data via the trx interface.
Change-Id: I5031541d4ae4244a62a18acf71139db2874927fa
Originally `maxdly` command in osmo-trx was contrlling max TA for Normal Bursts.
This was not a proper behaviour, because it was used to "control maximum
distance a handset can attach from" which is controlled by Access Bursts max TA.
Osmo-trx was corrected to apply `maxdly` to Access Bursts and a new command was
introduced to contrl max TA for Normal Bursts - `maxdlynb`. This patch adds
support for this configuration command into osmo-bts-trx.
If you wonder why would you need that - some test equipment (namely R&S CMD57)
has really bad timing sync and can generate signal a few symbols off. That
prevents osmo-trx from properly receiving otherwise perfectly good bursts
generated by CMD57. This configuration is a solution for this.
Change-Id: Ib5d255299668ac1ef9f0ce95e016f55ba3c82277
Existing interfaces are coded with the implicit expectation of using
a burst sequence length of 148, which is constant with GSM and GPRS.
That changes with EGPRS, where the burst length may be 444 due to
the use of 8-PSK instead of GMSK modulation.
Setup the interface to accept and return a length value with the
burst sequence. This allows 444 length bit vectors to/from the
EGPRS decoder/encoder. Length is explicitly used as a identifier for
8-PSK vs. GMSK modulated sequences.
Change-Id: I90b46b46b11b6ce280e7f8232d5a2fccec2d4f18
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
Vadim Yanitskiy
Pau Espin
Vadim Yanitskiy
Harald Welte