Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I85fdecbf20de83a6f925765a46b5cd14765da03e
|
|
Change-Id: Ida97f25ab4bf7e4d0f03b13396cb37cdfe99ef40
|
|
The CBCH (as per GSM specs) always maps on sub-slot 2 of either
the SDCCH/4 or SDCCH/8 that it replaces. However, the way how we
express it as RSL-style channel number (0xC8) doesn't allow room
for any sub-slots. The top 5 bits are used for expressing CBCH, while
the bottom 3 bits are used for the timeslot number (TN).
So when transforming from channel number to lchan, we must handle the
CBCH case specially by using a hard-coded sub-slot number of 2.
Change-Id: I44e2f763d5d25311167f435f2ca7e030b2a3f009
Related: OS#1617
|
|
This fixes a bug introduced in "CBCH: Move processing via L1SAP"
commit 02d99db08b13589e1417c3448a07747f8805ba88
Author: Harald Welte <laforge@gnumonks.org>
Date: Fri Aug 24 23:37:45 2018 +0200
where the full channel number 0xc8 was used instead of the
(right-shifted) C-bits only.
Change-Id: I0fd8d7762e9cc3319a534f261e8857a1aa2220e0
|
|
It's very confusing if some log messages log chan_nr as decimal, while
most log it as hexadecimal. Let's standardize on hex everywhere.
Change-Id: Ia6566d5bbee8124fb7c689c962ce34d714208503
|
|
Also print a newline at the end of print_hwversion().
In the process of rewrite, fix several warnings in the few lines of this functions:
osmo-bts/src/osmo-bts-litecell15/main.c: In function ‘print_hwversion’:
osmo-bts/src/osmo-bts-litecell15/main.c:162:12: warning: passing argument 1 to restrict-qualified parameter aliases with argument 4 [-Wrestrict]
snprintf(model_name, sizeof(model_name), "%s Rev %c",
^~~~~~~~~~
model_name, (char)rev);
~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:168:12: warning: passing argument 1 to restrict-qualified parameter aliases with argument 4 [-Wrestrict]
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~~~~~~~~~
model_name, model);
~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:162:47: warning: ‘ Rev ’ directive output may be truncated writing 5 bytes into a region of size between 1 and 64 [-Wformat-truncation=]
snprintf(model_name, sizeof(model_name), "%s Rev %c",
^~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:162:3: note: ‘snprintf’ output between 7 and 70 bytes into a destination of size 64
snprintf(model_name, sizeof(model_name), "%s Rev %c",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
model_name, (char)rev);
~~~~~~~~~~~~~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:168:47: warning: ‘ (’ directive output may be truncated writing 2 bytes into a region of size between 1 and 64 [-Wformat-truncation=]
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~
osmo-bts/src/osmo-bts-litecell15/main.c:168:44: note: using the range [0, 4294967295] for directive argument
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:168:3: note: ‘snprintf’ output between 9 and 75 bytes into a destination of size 64
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
model_name, model);
~~~~~~~~~~~~~~~~~~
Change-Id: I079b056a04fe77d2f7f361ff5899232cb70b5a93
|
|
Change-Id: I7efb7280363b3a021b30c3b4eacb3aab70e9c8da
|
|
Fixes following compilation warning:
osmo-bts/src/osmo-bts-litecell15/lc15bts_vty.c:244:3: warning: implicit declaration of function ‘lchan_deactivate’
Change-Id: Id9b144d068d53393e1c1887aad285ae757156ec6
|
|
There is a big difference between both L1 and L2 frames. In the
first case, a TDMA frame is assumed, while a L2 frame is the
result of decoding a few bursts (e.g. 4 for xCCH) arrived
on a few TDMA frames.
Anyway, the purpose of l1if_process_meas_res() is to handle
measurements, not frames.
Change-Id: Ic4362c2869e658c2f42664b4009a30e777f8048c
|
|
The unit test that tests lchan_meas_process_measurement() only inputs
test data to lchan_meas_process_measurement() but it is not checked if
the interval end could be detected or not.
- Add a return code to lchan_meas_process_measurement()
- Ensure that the return code is checked in the unit-test
Change-Id: I9e00ce683e8c44528804f65181dbfed9e85e3aed
Related: OS#2975
|
|
The function is_meas_overdue() was introduced to allow
lchan_meas_process_measurement() to detect when the end of a measurement
interval has been missed. Interval ends may be missed when the SACCH
block of the related measurement interval gets lost. This is due to the
fact that the SACCH block is used as a trigger to start the measurement
result computation.
The idea behind is_meas_overdue() was to check the frame number of the
current measurement against the frame number of the previous measurement
in order to see if there was a measurement for SACCH in between or not.
Unfortunately SACCH and TCH Voice data is not necessarly processed in
order by each phy. Depending on the phy there may be a jitter between
the timing of SACCH and TCH Voice. Depending on the phy this jitter may
be enough to mess up the timing so that we see a SACCH block earlier
than expected. So we can not use the current frame number of TCH Voice
measurements to check for missed SACCH blocks.
Change-Id: Idfdbf64c1f965f35c12559b3995e2b746c74ee9e
Related: OS#3502
Related: OS#2975
|
|
Change-Id: I6a1147e2a3858475c99c99ceb33d7d416f3cac6c
|
|
Convert the if-cascade to a switch().
For any unexpected pchan kind, reject the chan mode immediately instead of
going on to invoke gsm_bts_has_feature on feature = _NUM_BTS_FEAT, and log the
error.
Tweaked-by: neels
Change-Id: Ieaded9258554b15fcc4b7f05d5a8847175b7962f
|
|
Add log context to chan_mode error in rsl_rx_mode_modif().
Tweaked-by: neels
Change-Id: I945cf1ca8660ad5daf097edab1833bbc74b6185f
|
|
Fix the chan mode checking for RSL Chan Mode Modif: do not reject
all modes on dyn TS.
In rsl_rx_mode_modif(), bts_supports_cm() should never
be fed with dynamic pchan kinds (e.g. GSM_PCHAN_TCH_F_TCH_H_PDCH).
Feed instead the return value of ts_pchan() that is to say,
the actual pchan type (e.g. GSM_PCHAN_TCH_F).
Change-Id: I7f0c835b25289931bccf96e982ea5564c8be4192
|
|
Change-Id: I376111e71d1c7be35a8fd7e392488adc34e21941
|
|
This patch adds scheduler support for the channel combinations that
substitute SDCCH index 2 for a CBCH in either a SDCCH/8 or SDCCH/4.
Change-Id: Icc15603079a1709ec094f400a9bcf0008211890f
Closes: OS#1617
|
|
for some historical reason, CBCH handling was not using the normal
L1SAP boundary. Let's change that and traverse L1SAP just like for
e.g. BCCH which is quite similar to CBCH handling.
This also has the added benefit of logging CBCH via GSMTAP.
Change-Id: Ibdba4c5e808330f8406f441a97fe0e81170fce97
Closes: OS#3534
|
|
Whenever a CBCH is used, this results in a new physical channel
combination on the relevant timeslot. The chan_nr_by_sapi() function
must handle those cbch-enabled PCHAN types.
Change-Id: I963909bcec8392ec445d0bcf53a2a8d7d9535444
|
|
Normally, the "Common Channel" related RSL messages should actually
contain such a common channel. However, since cell broadcast is
implemented inside what's essentially a downlink SDCCH, we should add
some explicit exceptions.
Before this patch, any RSL SMS BC CMD would have been discarded and
an RSL Error Indiciation returned.
Change-Id: I2f7f1dd43505cc27cd33489d8b0e8c981cd93880
Closes: OS#3533
|
|
When adding a new measurement also log the frame number by the modulus
of the measurement interval to simplify debuggung
Change-Id: I77a4d947dab32de0d5717ebf13bd8de6179dfe6a
|
|
The parameter bs_ag_blks_res, which is loaded into the BTS via the SI3
setting, defines how many of the CCCH blocks shall be used for AGCH. The
remaining CCCH blocks will then be available as PCH for paging.
Unfortunately there is no unit-test yet that verifies that all of the 8
different settings for bs_ag_blks_res.
- Separate the the decision logic that checks if a given fn is part of
an AGCH into a function to have it available in the unit-test.
- Add a test that checks all possible bs_ag_blks_res settings.
Change-Id: Ib9652f4013a4da3766852f8f03ce9ec5590f6989
Related: OS#1575
|
|
At the moment the measurement calculation of osmo-bts works by
collecting the measurement reports the phy emits during a measurement
interval. Normally one would expect a well defind fixed number here, but
some phys will not emit a measurement report for lost blocks. Also
blocks and their reports may get lost because of cpu overload etc.
The computation that is executed at the end of the measurement interval
computes over all received measurement. This evenutally means that
missing measurements will not taken into account and the result will
look better than it is in reality.
To fix this, the interval must be of a defined size and in cases where
less measurements as expected were collected, the algorithm must assume
they have been received with a 100%BER and take that into account.
However, all RSSI and TA/TOA related computations should continue to
rely on actual measurement data.
- make sure the algorithm works over a fixed interval
- replace missing measurements with 100%BER
- fix and extend unit-tests
Change-Id: Idd30fc07603ad7d042c1fb416e247c3bf7d35c8b
Related: OS#2987
|
|
The lookup table that control the measurement interval endings do not
make clear what their indexes refer to. Lets give them more distinct
names.
rename sdcch8_meas_rep_fn102 to sdcch8_meas_rep_fn102_by_ss
rename sdcch4_meas_rep_fn102 to sdcch4_meas_rep_fn102_by_ss
rename tchf_meas_rep_fn104 to tchf_meas_rep_fn104_by_ts
rename tchh0_meas_rep_fn104 to tchh0_meas_rep_fn104_by_ts
rename tchh1_meas_rep_fn104 to tchh1_meas_rep_fn104_by_ts
Change-Id: I3dc891e1860109f803c1bfa46445e8fef35586d9
Related: OS#2975
|
|
The tests TC_meas_res_sign_sdcch4 and TC_meas_res_sign_sdcch8 are
failing mainly because lchan->ts->nr is confused with lchan->nr.
There is also a small problem with one of the formulas that compute
fn_missed_end.
- Add explainatory comment to the lookup tables on what the index
is refering to
- use lchan-nr instead of lchan->ts->nr when dealing with SDCCH/4/8
- simplfy and fix the formula
- increase the testcoverage of the unit tests, give SDCCH/4/8 also
a thorough check.
Change-Id: I5d555a21003943bf720c53f3a611029ba45339a9
Related: OS#2975
|
|
The function ts45008_83_is_sub() is an integral part of the measurement
calculation as it automatically tags incoming measurements as SUB
measurements. This is important in the context of DTX. Unfortunately
there is no unit test for this function yet.
- Add unit test for ts45008_83_is_sub()
Change-Id: Ia26774859f4bf31baee075896905079368bddd42
Related: OS#3502
|
|
The Table that lists the fn%104 frame number masks that define which of
the incoming measurements to be recognized as SUB measurements contains
one wrong number.
For comparison see also:
3GPP TS 05.08, chapter 8.3 Aspects of discontinuous transmission (DTX)
- Change 29 to 20 in ts45008_83_tch_hs1[]
Change-Id: Id3698551d94866f418e662b9fe81429b16e2621c
Related: OS#3502
|
|
We do not test is_meas_complete() individually yet, but it is an
integral part of the measurement processings since this function decides
where a measurement interval ends.
- Add unit tests that test TCH/F, TCH/H, SDCCH/4 and STDCH/8
Change-Id: I8f89d9e7092cd65ba4d5c5649140692dcc20bdd6
Related: OS#2987
|
|
For enabling PDCH on a dynamic timeslot, PDTCH and PTCCH SAPIs shall be
enabled. While osmo-bts-sysmo uses the lchan->type to determine which SAPIs to
enable (see lchan_activate() in osmo-bts-sysmo/oml.c:
sapis_for_lchan[lchan->type]), the osmo-bts-trx code instead relies on the
chan_nr indicating RSL_CHAN_OSMO_PDCH = 0xc0 (see trx_sched_set_lchan() in
common/scheduler.c and the PDTCH,PTCCH entries in trx_chan_desc[]).
The 0xc0 cbits are a non-standard invention specifically used for only Osmocom
style dyn TS, so the chan_nr for IPA style dyn TS will and should never include
this cbits pattern. Hence gsm_lchan2chan_nr() correctly always returns the
TCH/F equivalent chan_nr for IPA dyn TS.
Because trx_chan_desc[] relies on the 0xc0 in the chan_nr to activate the PDTCH
and PTCCH SAPIs, internally patch the 0xc0 cbits over the chan_nr in
osmo-bts-trx/l1_if.c for channel de-/activation, iff lchan->type == PDTCH.
This is technically a convoluted mix-up of the cbits usage. Nevertheless, it is
the simplest way to make IPA dyn TS behave the same as Osmocom dyn TS in
scheduler.c.
Apparently, IPA style dyn TS have never worked for osmo-bts-trx before?
Related: OS#3493
Change-Id: I0eed8a135f2ab7e7c0d15ad5c76430b7fe54df3d
|
|
Change-Id: I678ae63626f05a5bb6d890ff37a09e09739bc104
|
|
osmo-bts-virtual uses UDP multicast to communicate with its virtphy
counterpart. At the momemnt SO_REUSEADDR is not applied for those
multicast connections because OSMO_SOCK_F_UDP_REUSEADDR is not set. This
makes prevents the proper function of UDP multicast.
- Make sure OSMO_SOCK_F_UDP_REUSEADDR is set
Change-Id: I7f27758b7aa786c8dbae669cbcde10baab8e4845
Depends: libosmocore I1399a428467ca12f1564a14eb8ffb294d4f59874
Related: OS#3497
|
|
This reverts commit 9bffa87c1195d2977d49244fbc3e3c0c9b65c318.
This commit was not intended to be merged yet.
Change-Id: Ibd8c0899451ae3c17bc07d4e112e32b4897405c9
|
|
for SDDCH4 channels, the detection is not working correctly since the
function uses the lookup table for SDCCH8 interval endings there. This
needs to be corrected. Also there are two unnecessary assignments in
the code which should be removed.
- use correct table (sdcch4_meas_rep_fn102 instead of
sdcch8_meas_rep_fn102.
- remove unnecessary assignments to last_fn_mod
Change-Id: If8a269ecd3f9fa4eeadf379114db816ef5c77d77
Related: OS#2975
|
|
Send DTX TCH fill frames according to GSM 05.08, section 8.3.
Change-Id: I7bff00b8cf41dc1b0e6e668173bebce23be0d253
Related: OS#1950
|
|
Rewrite an if-statement to better match the description given
in GSM 05.08, and quote the relevant paragraph in a comment.
Since this entire block of code only runs for SDCCH and TCH,
this new condition should provide the same result expect that
in accordance with the standard we now stop sending fill-frames
on a signalling TCH if DTX is in use.
Also note that this code should already cover parts of the
patch proposed at https://gerrit.osmocom.org/c/osmo-bts/+/5753
The changes to osmo-bts-litecell15/l1_if.c proposed there
should be equivalent to the fill-frame logic in this
existing common BTS code which is handling RTS IND.
Change-Id: Ibaf3ecbd0bde4f37e799d5e2f5d00dc695e0139a
Related: OS#1950
|
|
the measurement interval end is detected by using the measurement
indication that is related to the SACCH block as a trigger to start the
computation. If the measurement indication for the SACCH gets lost
because the block could not be received then the processing is not
executed. This may cause wrong results or when it happens condecutively
an overflow of the measurement sample buffer.
- Store the frame number of the last received measurement indication
- Use the stored frame number to check if an interval was crossed when
the next measurement indication is received. If we detect that we
missed the interval, catch up by running the computation and
start the next interval.
Change-Id: I3a86cd8185cc6b94258373fe929f0c2f1cf27cfa
Related: OS#2975
|
|
At the moment only lchan_meas_reset is reset on channel activation.
All other states are not reset. This may lead to irretations in the
first measurement interval if there are still leftover messages from
a previous connection. Lets ensure everything is reset to zero by
zeroing out the whole .meas struct in struct lchan.
- Add a centralized function that does the reset
- Call that function from rsl_tx_chan_act_ack() in rsl.c
Change-Id: I880ae3030df6dcd60c32b7144c3430528429bdea
Related: OS#2975
Related: OS#2987
|
|
In l1sap.c we call lchan_new_ul_meas() and lchan_meas_check_compute()
directly in sequence. Lets unify thos two steps inside measurement.c so
that we only need to call one function from l1sap.c.
Change-Id: If48bc7442dfaab8c36b93949f741de6e836e792a
Related: OS#2975
|
|
The previous implementation unconditionally subtracted nanosecond
values from different time measurements, causing overflow if the
current measurement was taken in less of a fraction of a second
than the past measurement. Use timespecsub() instead, which
accounts for nanoseconds correctly.
This is a similar bug as fixed in osmo-pcu for issue OS#3225
While here, switch variables which are calculated based on
struct timespec to 64 bit types. While probably not strictly necessary
in practice, this makes the types used in calculations more compatible.
Change-Id: Idfd9c807e35cd7fb5c80625b9746121f81c24599
Related: OS#3467
Related: OS#3225
|
|
Each logical channel (e.g. SACCH, SDCCH, etc.) has a counter of
lost L2 frames. Let's use a bit better name for it, and correct
its description in the 'l1sched_chan_state' struct definition.
Change-Id: I92ef95f6b3f647170cfd434a970701406b0a7c82
|
|
During SACCH FILL processing, update lchan SI values only
for lchans which follow BTS-global default values, keeping
lchan-specific overrides in place.
Change-Id: I515bbd9983fa894507386b241863a9aa4d279497
Fixes: eee7247ebe0d0a54a54b53b739bdd434dfceb511
Related: OS#3173
|
|
When a SACCH FILL is received, loop over all lchans and update
their copies of system information data.
This change makes BTS_Tests.TC_sacch_multi_chg pass.
Change-Id: I3e63eeb5fcf320fb029de16e4d327e153cc34567
Related: OS#3173
|
|
Upper layer requires us to trigger all events coming from lower layers
in order to keep the RTP clock in sync. In this case, this is done by
sending an empty payload to indicate there's no data to send.
Change-Id: I0bdfb529f35253ca7e531bb9984a3839c3bfe7e8
|
|
Change-Id: I28f01e3f7fff6f1fb52a3c593a837f4f924bb2d9
|
|
Other backends use already msgb in lower layers and eventually call
add_l1sap_header to push TCH data up the stack.
backends using common/scheduler.c (bts-trx, bts-virt) are the only ones
not yet using msgb in lower layer but only creating the msgb
immediatelly before sending it in _sched_compose_tch_ind. Let's add a
log message there too to have similar output in all BTS backends.
Change-Id: Ia90b051f308abcd8b88b84e861da593844b0d81a
|
|
Change-Id: Ia427c216cd096d313b234ca244eb71837450e2a9
|
|
Change-Id: I8303364270e73718e57f8efc2f375817b9496ffc
|
|
All code in osmo-bts goes through APIs in libosmotrau (osmo_ortp.h),
hence direct dependency is not needed. Fixes OBS warnings:
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bts-trx/usr/bin/osmo-bts-trx was not linked against libortp.so.9 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bts-virtual/usr/bin/osmo-bts-omldummy debian/osmo-bts-virtual/usr/bin/osmo-bts-virtual were not linked against libortp.so.9 (they use none of the library's symbols)
Change-Id: I96a9b5f0678331dcf66c007928866a124d8700de
|
|
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
|
|
The latest octphy firmware release (octsdr-2g-02.11.00-B1927-alpha),
introduces a 16X oversampling option which is not yet supported in
osmo-bts.
- Add oversampling flag in phy_link.h
- Add VTY commands to enable/disable oversampling
- Add phy messages to enable/disable oversampling
- Add conditional compilation to preserve support for legacy
header files and firmware
Change-Id: Ib78f92bfe03ff20aa0a257763c90844fb7b87cf0
Related: SYS#4257
Patch-by: Octasic inc.
|