If len is < 0, it means osmo_amr_rtp_dec() failed and some of the out
variables there are not set. We should check the return code before
continuing and using potentially uninitialized values.
Change-Id: I76020c6b5dc8d3e52e8c5be8cdecdf8a0bb52ed9
Before a massive refactoring of the scheduler structures [1] it was
impossible to have a clean hierarchy, in which the burst buffers
get allocated as children of their parent timeslot structures.
This change makes it easier to read talloc reports and simplifies
memory management, offloading free()ing of the burst bufferes to
talloc.
Change-Id: Idb1ceaf83c433d2d0eb84d77c2187a00a657905c
Related: [1] I7c4379e43a25e9d858d582a99bf6c4b65c9af481
This scenario is actually expected when the call is being set up or torn
down, since we may not be receiving RTP from the MGW to send to the MS.
Hence, let's lower the log level to DEBUG to avoid having log clogged
for each call start/stop if INFO is used.
Related: SYS#5676
Change-Id: Ib7f274b97cc66d671316eae429ee4baf16831534
It cannot happen that msg1 is NULL and msg2 is not null, since they are
deuqueed from same place. Only possible combinations are:
msg1!=NULL && msg2!=NULL
msg1!=NULL && msg2==NULL
Change-Id: Ifd789844b1a7dfba596664de440d4c20b9f4c78f
The burst is properly pre-filled to _sched_dummy_burst in
bts_sched_init_buffers(), so we are fine doing nothing on C0.
Related: SYS#5676
Related: SYS#4919
Fixes: 300e31ed13
Change-Id: Ia7045724a1a3206f5890c0b12843711ad2360ed8
This reverts commit 8a85b71167.
This is actually the wrong fix. Proper fix comes as a follow-up patch,
since the root cause happens earlier in upper layers. No msg with
l2h=NULL should reach this point of code ever.
Change-Id: Ie23d94924f824bd7e89437ccf73b260f542477c6
PCU idle blocks are identified by being 0 length, and hence msg->l2h
being null. Don't try to encode those, but simply discard them silently.
In case there's a missing block in C0, we want to log the event since
the BTS is expected to send something on C0.
Related: SYS#5676
Related: SYS#4919
Fixes: 300e31ed13
Change-Id: I57e215fedeb415db4e67fdc56bf0f1410b5f7130
With this change the error case is moved at the end of the function,
which is more usual. At the same time, one goto tag can be removed,
simplifying the function.
This is also a preparation for next patch improvinga bit the logic
around same place.
Related: SYS#5676
Related: SYS#4919
Change-Id: Ifbd95ccbebf4d810b1fe0a162722e63fe69106b8
This adds a --enable-systemtap configure option, which will then
add static tracepoints to the generated osmo-bts-* binary.
At this point, only two sets of tracepoints are supported, and
only in osmo-bts-trx: ul_data_{start,done} and dl_rts_{start,done}.
The probes are intended to be used for analyzing the amount of time
needed for processing of uplink bursts / generation of downlink bursts.
Change-Id: Ibb4962253f1a195dc1a54405bac058ccb2545799
osmo-bts-trx/l1_if.c lchan_init_lapdm() for CCCH is already done when
trx_set_ts_as_pchan() calls:
"lchan_set_state(&ts->lchan[CCCH_LCHAN], LCHAN_S_ACTIVE);"
Change-Id: I7a9c3660b9aab57ff8765e2f1526349599630cd9
* Move way too verbose command description to the manuals.
* None of these commands apply immediately, correct the attributes.
** Remove meaningless call to l1if_provision_transceiver_trx().
* Make 'maxdlynb' hidden, so it only appears in the expert mode.
* One GMSK symbol actually corresponds to 550m.
Change-Id: I46839cf56bba2dcdc70303cd393e86d35aa2f3f5
trx_phy_inst_open() already guards against NULL trx ptr when calling
trx_sched_init(). Later on, in same path, trx_phy_inst_close() can be
called which ends up calling trx_sched_clean(trx), this time not being
guarded against NULL trx. This fixes Coverity CID#240498.
Fixes: CID#240498
Change-Id: I00afc739559d57dd98db68c76f2a85006c15e875
- one gsm symbol is 0,00000369 seconds
- 2*550m/c = 0,00000366 seconds
-> one ta symbol is a DISTANCE of 550m (or a RTT of 550m*2) between bts and ue.
-> no idea why this was constrained to TA/2.
Change-Id: I8d79080c82411e6427eec37d008614fa5d5e1ace
Related: OS#5140
Currently, only osmo-bts-trx is capable of reporting the interference
levels to L1SAP. Thus it does not make sense to trigger the averaging
logic and send empty reports over the A-bis/RSL and the PCUIF.
Change-Id: Ic17eb46bdca3c33ac4d6e560a093b635b75424a5
Related: SYS#5313
Starting from [1], interference levels on PDCH timeslots are also
reported over the A-bis/RSL. They may be useful for the BSC to
determine whether dynamic PDCH timeslots might be better used for
new circuit switched connections, or whether alternative PDCH slots
should be allocated for interference reasons.
* Handle GSM_LCHAN_PDTCH in lchan_report_interf_meas().
* Rework pcu_tx_interf_ind() to accept 'struct gsm_bts_trx'.
* Call pcu_tx_interf_ind() from l1sap_interf_meas_report().
Regarding pcu_tx_interf_ind(), it's better to call this function
from the upper layers once, rather than calling it from various
places in the model specific code.
[1] I5b4d1da0920e788ac8063cc765fe5b0223c76758
Change-Id: I3fbaad5dbc3bbd305b3ad4cb4bfb431a42cfbffc
Related: SYS#5313
It helps better understanding the code, and will allow handling
situations where for instance a POWERON in in transit while the BTS is
instructed to shutdown, hence a POWEROFF needs to be sent.
Change-Id: Iaf62217ceab7420afa4140cba61e1c2f983c61b4
config.enabled is always true in that state. Hence, those paths can be
securely dropped since only add confusion.
Change-Id: Icf00c52e61ddedd8e32eb37223cea5686005e6a3
Prior to this patch, the power ramping started when the PHY is
available, but that doesn't necessarily mean the RCARRIER is enabled.
Due to this, it was spotted a situation where BTS bootstrap failed after
PHY turning up, when RSL connection establishment failed. Hence
bts_shutdown_fsm triggered a shutdown while an active power ramping up
was ongoing...
Change-Id: I17208b74ea2649b1bbb717aee0aa355e42b7e860
This may happen if bts_shutdown starts a poweroff procedure while
POWERON was still not sent to the TRX. In this case, we want to go back
to initial closed state to fullfill expected state when BTS is shutdown.
Change-Id: Id660fa1018ef175ab237733b37629c56313c061d
Recent commit added code to reset trx_provision_fsm state fields in orer
to support re-using the FSM once BTS is reconnected to a BSC.
However, some values being reset there are not set up when reconnecting
to the BSC, but rather configured through VTY at startup. Hence those
values should be kept.
Fixes: 32b51eca7d
Change-Id: I5c31241327b98386c313cd9377cf76c009456105
GSM/EDGE Evolution and Performance, Section 12.3 suggests Temporary
Overpower as another solution to improve SACCH/FACCH performance in
case of bad C/I. The idea here is that you increment the DL transmit
power by 2..4dB only for FACCH/SACCH bursts, while keeping all voice
bursts at the lower (normal) level as determined by BS power control.
SACCH blocks can be recognized by the channel type, since they're
always transmitted in specific frames of a multiframe. FACCH blocks,
however, are not predictable and can substitute voice blocks at
(almost) any time. Thus we need to mark FACCH bursts as such in
the logical channel handlers (using TRX_BR_F_FACCH).
Change-Id: Ie8a626fefccf1eb07271058e5126ec106cb1abcf
Related: SYS#5319
Thanks to [1], there is no need to patch chan_nr for PDCH anymore.
The upper layers are now expected to use the correct values.
[1] I01680140c7201bf5284b278bceaea8ae01c122b2
Change-Id: I26eb2081eddb4ce900a7867897bc69c3f77dbd73
Related: OS#5238
In functions responsible for Downlink burst scheduling, it may happen
that the buffer, containing a complete set of to be transmitted bursts,
a) is not yet allocated or b) was de-allocated intentionally. In this
case, we return early to avoid NULL pointer dereference. The returned
value is then checked against 0 in _sched_dl_burst().
Returning 0 makes _sched_dl_burst() apply per-burst attenuation, as
well as the A5/x encryption (if enabled). And this makes no sense
in either of the cases mentioned above.
Moreover, in the BCCH power reduction mode, this causes some bursts
(bid > 0) of idle PDTCH/PTCCH blocks to be transmitted at full power,
breaking the energy saving feature.
Change-Id: I18aa73cc950fdfac030b63f7a434a71b4596095d
Related: SYS#4919
This step is required while turning off the BTS without killing the
process. Right now only osmo-bts-trx supports this feature, so this
function is only available and used by osmo-bts-trx.
Later on, when the feature is support more generally, we can move call
to this function to common place like bts_shutdown_fsm or alike.
Change-Id: I3253112700a31b85db82dc7ccadec8542bac745e
Once the TRXC link is available, we can signal SW_ACT which will
transit rcarrier and bbtransc NM FSMs to Disabled Offline and announce
availability to be configured to the BSC through transmission of
Software Activated Report.
Change-Id: I6e62ec2fdd4cae58b52d83fa851552f7ed51c821
In OML, if Set Attributes comes first for Channel object and then for
BTS object, BSIC will still not be set. Hence, when applying Channel
(TS) specific TSC, the code would compare against an unset value,
enabling use of TRXC extensions (which osmo-trx doesn't support)
without need for it, since actually the TSC of the TS matches the BSIC
of the BTS once both are set.
In order to fix it, don't check for the BSIC when receiving the OML
messages, but rather later when we apply the settings to the the lower
layers once trx_provision_fsm allows for it.
Fixes: 3c1151f945
Change-Id: I49fc7e35acb44ecc4f37ae71acd4c684248548e7
Get rid of this helper function, which is a remain of past epochs
(pre-FSM). In the current uses, there's only 2 real cases: the "if" path
upon SET BTS ATTR received (and even that one should be moved as per
what the code comment states), and the one happening when the TRX is
closed.
it really makes no sense to DISABLE the TRX as a result of SET BTS ATTR.
Change-Id: I48adfeecd722684152c589bcba827079b0a78c3a
In oml_rx_set_bts_attr, arfcn for C0 is assigned from NM_ATT_BCCH_ARFCN.
The rest of the TRX get their arfcn from oml_rx_set_radio_attr()
NM_ATT_ARFCN_LIST.
Change-Id: I8aa9652622107fe0a707b2cbcbe8be6c71e19087
This will allow in the future advertising children objects that the
parent object has been configured. It is useful for instance to let TRX
know that the BTS is configured.
Change-Id: Ie319465fd0e991bab8451ea34ec72ff3702533d2
This way it can be changed together with operative/availability state,
and changes announced to the BSC if present.
This commit presents no real change in osmo-bts behavior, since the only
place where adm_state is passed different than -1 is in
st_op_disabled_notinstalled_on_enter(), which is actually never called
(yet) since it's the initial state and no other states transition later
to it.
However, this will change in the future once we support re-connecting to
a (possibly different) BSC, which means objects will need to be moved to
that state to restart the whole OML install procedure on the new BSC.
Change-Id: Ifdc6a1dfb673c0ab915ddf2a9d372928f4f86b4c
All generated RTP that originates from the BTS relates to uplink. When
generating AMR BAD frame RTP packets, we must use ul_cmr/ul_ft and not
dl_cmr/dl_ft.
Change-Id: Ifa009819791cf7df2dd8201f442b0dae06f622a4
Related: SYS#5549
The AMR transmission phase directly depends on the frame number. The
transmission phase is used to tell if a received AMR frame contains a
CMI (frame type that is currently used) or CMR (frame type that the
receiver should use) codec identifier. The formulas in the present
implementation seem to be correct but they do not reflect the numbers in
the spec very well, nor do they have unit-tests. Lets replace them with
more readble functions and test those functions with unit-tests.
Change-Id: I94a934a6b3b397b4cd0e9da3577325de58814335
Related: SYS#5549
CMR and FT are updated each time an AMR voice frame is received from the
radio interface. The transmission phase decides whether the voice frame
contains CMR or FT. The code follows the transmission phase and keeps
ul_cmr and ul_ft up to date.
In contrast to the AMR frames on the radio interface, an AMR RTP packet
always contains the CMR and the FT value.
When generating the RTP payloed, The present implementation uses the CMR
in the position where the FT should be and the FT is ignored. This is not
correct.
Change-Id: I6bb10ff3c76f67b9830787497653b546cf27fe8e
Related: SYS#5549
If for whatever reason the transmit queue of a TCH/{F,H} contains
neither speech frames nor signalling blocks, osmo-bts-trx would
currently transmit garbage. Of course, this causes decoding
errors at the MS side.
Ideally, we should employ an ECU (Error Concealment Unit) for the
given codec in use. However, a simpler solution is to transmit
dummy LAPDm frames over FACCH. This is what e.g. nanoBTS does.
Change-Id: I868afecbcb6890f40c8f146e3ce00e836b794dd3
Related: OS#4823
They will gain support to be activated as SDCCH/8 soon too.
Related: SYS#5309
Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68
Change-Id: Ia617d20fc52f09dbab8f4516c06fa1efac08e898
The BCCH carrier (sometimes called C0) of a BTS shall maintain
discontinuous Downlink transmission at full power in order to
stay 'visible' to the mobile stations. Because of that, early
versions of 3GPP TS 45.008 prohibited BS power reduction on C0.
However, in the recent 3GPP TS 45.008 there is a feature called
'BCCH carrier power reduction operation'. This is a special
mode of operation, where the variation of RF level for some
timeslots is relaxed for the purpose of energy saving.
In BCCH carrier power reduction operation, for timeslots on the
C0 carrier, except timeslots carrying BCCH/CCCH, the output power
may be lower than the output power used for timeslots carrying
BCCH/CCCH. In this case the maximum allowed difference in output
power actually transmitted by the BTS is 6 dB.
The power reduction operation can be controlled by the BSC by
sending BS POWER CONTROL on the A-bis/RSL with the Channel Number
IE set to 0x80 (RSL_CHAN_BCCH). This makes osmo-bts reduce the
transmission power on inactive timeslots of the BCCH carrier.
This is a non-standard, Osmocom specific extension, so indicate
support of this feature to the BSC in the feature vector. Also
add a VTY command to allow enabling/disabling the power reduction
locally. Add some signalling notes to the A-bis/RSL manual.
For more details, see 3GPP TS 45.008, section 7.1.
Change-Id: I3dcee6e910ccc61c5c63c728db9ea04327e2fc98
Depends: I69283b3f35988fc7a1a1dcf1a1ad3b67f08ec716
Related: SYS#4919
The PDCH multiframe contains 48 data slots, 2 PTCCH slots, and
2 IDLE slots. The later two can be used for the interference
measurements, since the UEs shall not transmit on them.
bts_report_interf_meas() is called every 104 TDMA frames, what
corresponds to 2 PDCH multiframe periods. Report interference
levels on PDCH timeslots from this function.
Change-Id: I56f83db5264c246ec1b4b8a973105a4fc09931fb
Related: SYS#5313, OS#1569
We already do the intereference measurements on inactive logical
channels. For the active channels we can still use the IDLE
slots, on which the UEs shall not transmit Uplink bursts.
Change-Id: Ic3030dba5eb223177298aa4e43559a93dc3d1392
Related: SYS#5313, OS#1569
In trx_sched_ul_burst(), treat all BURST.ind and NOPE.ind mapped
to inactive logical channels as interference. Average the RSSI
values on the fly using a sliding average with constant a=0.5.
Report averaged values for each logical channel every 104 TDMA
frames (SACCH period) by calling gsm_lchan_interf_meas_push().
Change-Id: I4686448e42a40df56c1d27a14fd0a4d43fd144a5
Related: I78b6d8beffa5228a28231b75728e7aebdd3cb23c
Related: SYS#5313, OS#1569
Starting from TRXDv2 [1], trx_if_send_burst() would keep batching
PDUs to the static buffer, unless it's called with br = NULL, so
we cannot dereference br in the logging statement.
Of course, we could also store TDMA frame number in a static
variable, but I don't think it's worth it just for logging.
Change-Id: I4a361777fc40bdedcebbe54df6274bc5573f77a8
Fixes: [1] I9b4cc8e10cd683b28d22e32890569484cd20372d
Fixes: CID#236232
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
The TSC (Training Sequence Code) value in 'struct gsm_bts_trx_ts'
is always initialized in oml_rx_set_chan_attr() during the OML
bootstrapping, so there is no need for gsm_ts_tsc() - remove it.
Store the initial TSC value in 'struct gsm_bts_trx_ts', so we can
apply a different TSC value during the RSL CHANnel ACTIVation.
Store the Training Sequence Code/Set in 'struct trx_dl_burst_req'.
These values are indicated to the transceiver (TRXDv2 PDUs, 'MTS'
field) and used by the new TRX_{GMSK,8PSK}_NB_TSC macros.
Change-Id: I3744bc308b99ef941e6e9d139444e414abebc14b
Related: SYS#4895, OS#4941
This change implements TRXD PDU batching approach b), which is described
in section 25.3.4 of the user manual [1]. This approach is quite easy
to implement on the transceiver side, so we can enable it by default.
.Example: datagram structure for combination b)
----
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=0 | BATCH=1 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=1 | BATCH=1 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=2 | BATCH=1 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=7 | BATCH=0 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
----
Other PDU batching approaches can be introduced later.
[1] https://downloads.osmocom.org/docs/latest/osmobts-usermanual.pdf
Change-Id: I9b4cc8e10cd683b28d22e32890569484cd20372d
Related: SYS#4895, OS#4941
In [1] I forgot to update tx_fcch_fn(), where we assume that the
burst buffer is already zero-initialized and do not call memset().
This results in sending dummy bursts on FCCH (instead of zeros).
Change-Id: I491b3b5702b3cfca45c12c002b41e60c629b05b9
Fixes: [1] Iec78989517865b3275a9784d1042a5ebd1d2815f
Currently, in bts_sched_fn() we send a Downlink burst to the PHY
immediately after calling the associated logical channel handler.
Together with the obvious performance advantages, this approach
imposes some serious limitations. The code has already become
quite complex with the introduction of the baseband frequency
hopping, and now it's not possible anymore to extend it further.
TRXD PDU batching, which is essential for VAMOS implementation,
requires us to make the scheduler more flexible at the expense of
increased memory consumption and additional CPU cycles. This patch
splits up Downlink burst scheduling into 3 main steps:
1. bts_sched_init_buffers(): initialization of per-TRX Downlink
burst buffers allocated by phy_instance_create(). For C0/TRX0
all timeslots are pre-initialized with dummy burst.
2. bts_sched_fn(): generating burst bits for all active lchans.
3. bts_sched_flush_buffers(): sending everything to the PHY.
This approach allows us to a) get rid of the ugly tail in bts_sched_fn()
that was responsible for sending dummy bursts on C0/TRX0; b) implement
the PDU batching and have several variants of bts_sched_flush_buffers()
providing the alternative batching approaches later on; c) implement
PDU merging for the upcoming shadow transceivers.
Change-Id: Iec78989517865b3275a9784d1042a5ebd1d2815f
Related: SYS#4895, OS#4941
We assume that it's legal to have dangling PHY instances that are
not associated with any TRX instances in the configuration file.
Obviously, such PHY instances have pinst->trx set to NULL.
The DSP based models seem to handle dangling PHY instances without
any problems, so let's ensure that we always check pinst->trx
against NULL in the osmo-bts-{trx,virtual} specific code.
Change-Id: Ib7d9cb7ae47fead723fa46454cd64bf6e88756bb
Fixes: CID#236092 "Dereference before null check"
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
In change [1] together with the actual implementation I introduced
a serious bug to bts_sched_fn(): if a timeslot is configured to use
frequency hopping, both 'pinst' and 'l1h' pointers are *overwriten*
in the inner loop, so the Downlink burst is re-directed to the
approproate PHY instance. However, if a subsequent timeslot is not
hopping, the Downlink burst would be re-directed to the wrong PHY
instance because both pointers were overwriten during a previous
iteration.
Let's move the 'struct phy_instance' pointer to the inner loop, so
it's properly re-initialized for each timeslot iteration.
Change-Id: I9afbbef8dc5d885763356470c27d4392dce8e815
Fixes: [1] I68f4ae09fd0789ad0d8f1c1e17e17dfc4de8e462
Related: SYS#4868, OS#4546
trx_phy_instance() does assert() that the given TRX pointer is
not NULL. In bts_sched_fn() it can never be NULL, so drop it.
Change-Id: I896ff5117588f2229cc54619ce62fd027a9ef25f
Historically the logical channel handlers like rx_data_fn() used to accept
quite a lot of arguments. With the introduction of additional measurement
parameters it has become clear that we need to group the arguments into
structures. This is why both 'trx_{dl,ul}_burst_{req,ind}' structures
were introduced.
However, both channel type and burst ID were kept untouched, so until
now we had them being passed between the scheduler functions here and
there. This change is a logical conclusion of the original change
mentioned above.
As a part of this change, the new LOGL1SB() macro is introduced. It
does accept a pointer to 'trx_{dl,ul}_burst_{req,ind}' and expands the
context information for the old LOGL1S() macro.
Change-Id: Ic5a02b074662b3e429bf18e05a982f3f3e7b7444
First of all, there is no reason to use a void pointer because
it's always 'struct phy_instance'. Also, no need to encapsulate
this pointer into 'role_bts' because there are no other roles in
osmo-bts (we used to have shared headers years ago).
This commit also fixes a bug in test_sysmobts_auto_band(), where a
pointer to 'struct femtol1_hdl' was directly assigned to trx.pinst.
Change-Id: I9bd6f0921e0c6bf824d38485486ad78864cbe17e
For a long time, we see this annoying -Wstringop-truncation warning:
In function ‘parse_rsp’,
inlined from ‘trx_ctrl_read_cb’ at trx_if.c:647:6:
trx_if.c:416:2: warning: ‘strncat’ output may be truncated copying
between 0 and 45 bytes from a string of length 1495
416 | strncat(rsp->cmd, buf_in + 4, p - buf_in - 4);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There is no real need to use strncat() in parse_rsp(), because we
do not concatenate any strings but simply copy TRXC response parts
from the input buffer to the corresponding 'name' and 'parameters'
buffers. Let's use memcpy() instead. This also fixes the warning.
Change-Id: Ia10adf7d76abe9a423b07e828852fbfb53b95125
If the PHY is not powered on and we are not supposed to send any
bursts to it, then trx_if_send_burst() should just return early.
Change-Id: I578bd5a731ad88ebff283c75bb7eb268d9e7e787
Related: SYS#4895, OS#4941, OS#4006
If somehow the TRXC logic negotiates a non-supported TRXD PDU version,
then it's a serious bug in the code. Let's add an assert() for that.
Change-Id: I301377bcebd5e2bbcfc18b3637253ef261bb5b2e
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
This is a preparatory change for the upcoming TRXDv2 support:
* move common TRXDv0/v1 header parser into a separate function;
* move burst handling into a single, version independent function;
** determine modulation and burst length in trx_data_parse_pdu_v0();
Change-Id: I7aedd85a8d4f6d6191cd3b75272a688208fb2879
Related: SYS#4895, OS#4941, OS#4006
All these functions need the PHY instance pointer for logging,
they don't really need a pointer to 'struct trx_l1h'.
Change-Id: I626b4392a8bc57a3fe5e8c931aa1ce9dd505676c
Related: SYS#4895, OS#4941, OS#4006
The 'CHDR' stands for 'Common Header', but this does not apply to
TRXDv2 because TDMA frame number may not be present in the batched
PDUs. Let's avoid potential confusion by removing it.
Change-Id: I80495df474c432f4c0a4cfa6f917821d7b35859a
We do have TRXC/TRXD documentation in osmo-gsm-manuals repository.
This big comment is out of sync with what we have in the manuals,
so let's better remove it to avoid maintaining docs in several places.
Change-Id: Ibfcefcbb5f30fe9b6c691578a93e6fedd5644b30
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
* Calling l1if_provision_transceiver_trx() yelds nothing.
* It does not apply immediately, full restart required.
Change-Id: I93c9e19d0543f19528cec842b8be332b4d93214e
If for whatever reason it fails to initialize the TRXD or TRXC
interface, trx_phy_inst_open() would return an error. This
would cause bts_model_phy_link_open() to call trx_if_close()
on each of the PHY links, including those that were never
opened. This leads to a segfault in trx_if_close().
Make sure that in trx_if_init() we properly init 'struct trx_l1h',
so it's safe to call trx_if_close() at any time and in any state.
Change-Id: I1f128813528f505fede04799e84456f6271058d0
The measurement results / TCH indications that are handed when decoding
the TCH/H are off by two bursts. Since a measurement result / TCH block
is expected every two bursts anyway the problem can only be noticed when
a FACCH transmission is going on and the frame numbers of the BFI TCH
blocks appear to be missaligned towards the FACCH block.
The reason is that the incoming bursts are shifted into a 6 burst wide
buffer. The decoding functions always look at the beginning of that
buffer while the bursts are shifted into the buffer from the end. A
facch will always fit exactly in that buffer but TCH/H blocks are only
4 bursts wide and thereofre they need two additional bursts until they
reach the coverage of the decoding function. Lets fix this by putting
the correct frame number (from two bursts before) into the remap
functions in order to get the correct beginning of the block.
Since the FACCH transmission uses six blocks it takes out two TCH
blocks. This means that if we count the FACCH block we end up with a gap
of one TCH voice block. Lets generate a dummy measurement to compensate
the gap. This will also match the behavior of the osmo-bts-sysmo phy.
Change-Id: I1ad9fa3815feb2b4da608ab7df716a87ba1f2f91
Related: OS#4799
By reordering the instruction, we scheduler the timerfd prior to
processing the FN on the upper layers. This means the first timerfd
expiration even will happen more inline with the expected time, that is,
CLOCK IND time + GSM_TDMA_FN_DURATION_nS.
Let T(trx_sched_fn) be the time spent executing function trx_sched_fn().
With previous order, the timerfd would have been scheduled later, which
in the end would mean expiration would happen at time CLOCK_IND +
GSM_TDMA_FN_DURATION_nS + T(trx_sched_fn), hence ending up with an extra
skew of T(trx_sched_fn) added by ourselves.
This extra skew added may be important specially at startup time (when
this code path is used), since usually the load in the system is high
and skew is usually already higher, which means helping crossing
unacceptable thresholds which may end up in osmo-bts-trx stopping with
"No clock from osmo-trx" reason.
Change-Id: Ie2ba35cd87f0bd4078ac3b4b5ec2eacad36c4258
These fields are always aready set by the only caller of the function
trx_setup_clock(), so there's no use in re-setting them.
Change-Id: Id8a7141984e07eb11abae08e0c63ae7ebc333511
Pau Espin
Vadim Yanitskiy
Harald Welte
Eric Wild
Philipp Maier