Age | Commit message (Collapse) | Author | Files | Lines |
|
Original OpenBTS transcievers add 2 bytes of padding to the end of data
bursts, having in total 158 bytes. As those two extra bytes are being
ignored after the initial validation, let's relax this validation a bit
in order to accept transcievers that decide no to send these two extra
bytes.
Change-Id: I94c3cb160bfed0ba9c41ed7ef5f8d8a65b81ad07
|
|
* move TA related globals into phy_link
* move power loop related globals into phy_link
* prefix corresponding vty vars with osmotrx
Change-Id: I01d7c1abad67e51b886a4ecf2de072929d67da27
Related: OS#1848
|
|
It was introduced in fe6c75d24a1751341bcee91cb45c7ac7f5d07da3:
* fix typo in config write
* add missing vty help string
Change-Id: Id42359dfbb8ad02f34dd2540db66f3ed69ad5181
|
|
Use Obj. Class and TRX# from abis_om_fom_hdr of incoming request instead
of BTS' MO to properly distinguish between BTS-level and TRX-level
attributes.
Change-Id: I8b5a5ab8bd07daf2500b66dec428b89b7f8cd852
Related: OS#2317
|
|
New libosmocore has some plugin system which requires dlopen(). So we need
to make sure we always link with libdl, even when building statically.
Note that this doesn't fix static build of tests - they are still failing
with some errors.
Change-Id: I8315d6e032e34528def268a49fd88d07bc06ab2e
|
|
When somebody kills the process, it's best to handle the signal
and to use the opportunity for some cleanup. We always did this
in the BTS on SIGINT, but never on SIGTERM. Let's change it.
Change-Id: I10009c08b7178988f646e2b6035197b9640ac9b5
|
|
4dB.
We tend to start MS with high power to make sure distant phones get good QoS,
but this also means that we need to reduce their power rather quickly. OTOH
we can't make this step too high because this may lead to power output
oscillation. From my (manual, limited) testing 4dB looks like a reasonable
compromise.
Change-Id: I58785513e5739474b881ed7f2a312ecc690e7e60
|
|
Change-Id: I2464e872f81021cbc3ccbc4e2e32c394d6afcf70
|
|
The following two commits from 2014-12-06 introduced a new variable to control
MS power - ms_power_ctrl, but kept the old ms_power variable in place. They
have also changed the meaning of the ms_power variable - it now keeps original
RSL configured value. So when much later osmo-trx-bts code was merged to master
the code was compiling fine and this change in the meaning was overlooked.
In osmo-bts:
579651bf300de002731dfd3bd39985c9fd15616c power/sysmobts: Add a manual ms power level control
In OpenBSC:
f6f86b0eec18da165db136b14bf2db87fde4b4ac osmo-bts: Introduce new struct for a power loop in the BTS code
Change-Id: I713e39b882db32a0d17aa04790d16fa79afa1fb1
|
|
Implement API functions bts_model_ts_connect() and
bts_model_ts_disconnect() in order to support dynamic timeslot
allocation.
Change-Id: Ia109d4bfade7bc28442127581f4bb0289146ea71
|
|
There are currently two ways to specify power reductions to be sent to
osmo-trx from osmo-bts-trx:
* osmotrx tx-attenuation oml
* osmotrx tx-attenuation <0-50>
None of them is enabled by default, which means if none of them is
specified in the config file of osmo-bts-trx, SETPOWER cmd won't be sent
to osmo-trx, which in turn won't turn on the transciever.
Let's enable osmo tx-attenuation oml by default and leave it up to the
bsc to decide which power reduction to use. If the user wants to
configure a specific tx-attentuation, it can still do so in exactly the
same way he used to do it.
Change-Id: Ia8640751630ee37e5f5d1f470bad892a08e80654
|
|
In openbsc.git Change-Id I61c18a7f021fcb1ec00d34a745f4e3ab03416c2d
we changed the gsm_bts_alloc() function signature to include
a second argument (the BTS number). This broke omso-bts, and this
commit is intended to make it build again.
Change-Id: I7ef7654d48c1cfc7e4ecb0b771553ec0740ce2bf
|
|
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
|
|
Change-Id: I339db0e5f3fd5e44bac974f2447afc80388802af
|
|
Those global variable declarations for non-existing variables were
introduced in 8a8d73a691c709403be4adbe8f2a7150b4d5998a, 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
|
|
There's very little point in sending fill frames (such as empty PAGING)
or dummy UI frames via GSMTAP all the time. They serve no purpose other
than to bloat the log files and make it more difficult for users to find
the interesting bits among all this noise.
Change-Id: Icd18dafb235933c9e6aa9d98ddd8fac1522cc9ac
|
|
So far, L1SAP code is hiding RSL_CHAN_OSMO_PDCH from the bts specific
code below L1SAP. This is some kind of a hack/workaround, making code
and debug output / logs more difficult to understand.
So let's teach the lower layer how to treat RSL_CHAN_OSMO_PDCH and
remove the "hiding" code from the common l1sap.c code.
Change-Id: Iaaa833febe45b82166d3901f10cc5466a7591c19
|
|
Change-Id: Id851578c53255866537a16a0be6c3e9268e6ccbc
|
|
Change-Id: I007e5f0ce9709026331817e55148749e21d8b015
|
|
The RSL Channel ID is best read / interpreted as hex value, not as
decimal, primarily due to the fact that it is a bit-mask of various
fields.
Change-Id: I9b72a67407870b485e7f7e8a72fa1ad30fc8ed4d
|
|
In bts_model_l1sap_down() we want to identify BCCH/CCCH channel numbers,
but our check is a bit non-specific. Let's make the check more specific
to only cover the BCCH, Uplink CCCH and Downlink CCCH C-bits as defined
n 3GPP TS 08.58 Section 9.3.1
Change-Id: Ia20ab09b96c87c0dfbfaf98e5b2a8d36423fac67
|
|
There are plenty of functions stubbed out in osmo-bts-virtual, let's
print a NOTICE level log message to be able to correlate any kind of
erroneous behavior with the fact that a given function has no actual
implementation.
Change-Id: Ib607d192f90af7fb2d5a8747de5527f39e3cfefa
|
|
Change-Id: I46b1cc6e5502829e0c1dc84a184cd2002fbd2b18
|
|
Otherwise it fails to read the default config file.
Change-Id: I316a8ea73091c7e76a175314b890e4d86e9c3010
|
|
Change-Id: I6e35fb9c1a6391e5185a62e9efd2f8ffba13cf0d
|
|
Change-Id: I3ad15a9edbfe74de3deb7298441d54fd9d0178ad
|
|
Change-Id: I9c2e166e6f182f703ccf49aa883c223e377c8421
|
|
Change-Id: Ib057b5e5219ad2acfaee2dcc9ade098daa9ac985
|
|
That's mostly changes related to lc15bts-mgr from
https://gitlab.com/nrw_noa/osmo-bts branch nrw/litecell15 based on
eb5b7f80510b603579f7af6d7d5ead296c2fa260 commit:
* adjust comments to simplify further diffs
* add libsystemd dependency to lc15bts-mgr
* add software watchdog which uses it
* ocxo calibration and gps related code
Change-Id: I475a330af771891ba3c897294ce0dd57ec2ba8db
Related: SYS#3732
|
|
RTS.ind, DATA.* and TCH.* primitives are L1P, not L1C.
Change-Id: I4a32b83225e931ced561fdf457fa962e8ad44bd2
|
|
Change-Id: I35b103c512993fc52d4e608f07115a4bb4b21022
|
|
In a larger simulated network with multiple BTSs it is normal that one
BTS will see GSMTAP frames for an ARFCN that is not an ARFCN used by the
local BTS. This is just normal operation.
Change-Id: Ic68cace9648ccb17500c94b6ede8814674aa9c29
|
|
That's mostly changes related to lc15bts-mgr from
https://gitlab.com/nrw_noa/osmo-bts branch nrw/litecell15 based on
eb5b7f80510b603579f7af6d7d5ead296c2fa260 commit.
I wanted to incorporate vty and hardcoded paths changes so we can use it
from this point without major backward-incompatible changes as a base
for future ports.
Change-Id: Iabbaedc84aaaa594150a4e5445c16dd1f6f89858
Related: SYS#3679
|
|
* remove typo in logging
* add missing return statement
* fix compilation warnings
* add detailed logging for supported GSM band and related errors
Change-Id: I73bccd81ec56845ba11b939937b295eb0f51b4a8
Related: SYS#3728
|
|
Better match upstream lc15 code:
* fsync on parameter write
* use permanent storage directly for parameters
Change-Id: Iac150bf2ebffc5fa9544b0f3b19cd647996fc8b6
Related: SYS#3728
|
|
* move common code into separate function
* print error similar to parameter reading code
Change-Id: Icf3285d7bb921d212cb8945e835be2c81189fb87
Related: SYS#3728
|
|
When no SI 2bis, nor 2ter, nor 2quater is in use, then the code in
bts_sysinfo_get() will return null, causing the transmission of a dummy
frame (0303012B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B) instead of a
system information message. This is - at least - very odd and might not
be backed by the specification. We should simply send any other system
information message instead of sending a frame that does not have a
valid SI header.
While 030301 might be a valid, empty UI frame on a DCCH, it is not a
valid frame for the BCCH, where the header is structured differently.
In fact, bts_sysinfo_get() should never return NULL and always return a
valid BCCH message.
This bug was found while developing
http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo/Test.ttcn
Change-Id: Ifeaed27d1d7ba9994fb8ce67d660648bcc8efece
Closes: OS#2365
|
|
returns 0
It is important that we reliably terminate the BTS in case any of the
VirtPHY multicast sockets dies for whatever reason.
Change-Id: I5ae3fdd7cc35fdf235550a3b8362020fdd287c13
|
|
The addresses in the original code make little sense:
* 224.0.0.1 is "All systems on this subnet" and not routed
outside the local ethernet segment
* 225.0.0.1 is in a RESERVED range that shouldn't be used
Change-Id: Iba1ae69f3f193a33f1da343c6562f67bd8d3557f
|
|
Frame number will restart at 0 after each superframe (approx. 6.1 sec)
if enabled. Can be enabled by preprocessor define.
Change-Id: If3adf14df5fcd8daf53363c27b3772c42d7122e9
|
|
The defaults must be set during bts_model_phy_link_set_defaults()
and can then later be overridden by the vty (from the config file).
They should only be written back to the file if they differ from
the default settings.
Change-Id: I5d7f2c1dc8bc3d11db5c607b664730e4dcd58c96
|
|
Timeslot is not encoded in the chan_nr accessible in the channel
description but was taken from there and so it was always 0.
Change-Id: I881a1c61ea47399c9b1385fb220cd587e3593e82
|
|
This patch adds a virtual physical layer designed to simulate the
Um air interface between BTS and MS. It does so by encapsulating MAC
blocks (Layer 2 PDUs) via GSMTAP and sending them through multicast UDP
streams, both in uplink and in downlink.
The purpose of this is enable testing without any radio hardware or
related licenses.
OsmocomBB has recently received as similar patch-set, adding a virty_phy
executable that can be run on a PC instead of the classic 'layer1'
firmware on a real phone.
Using GSMTAP means that one can use unmodified wireshark to decode the
messages exchanged on the virtual Um layer.
This code was originally started by Harald in January 2016, continued
by Sebastian Stumpf in late 2016 and early 2017, and finally completed
by Harald in July 2017.
Change-Id: I1bf7670975b1e367c1c62983020865a043542622
|
|
The number of SI2quater messages might be updated dynamically by
BSC (via 'bts 0 resend-system-information' command for example). Log it
but do not return error.
Related: OS#2357
Change-Id: I9625be879c672e20543cc40af288828143ffb983
|
|
The octasic phy stamps the SACCH channel that carries the
measurmenet indication with the frame number of the last
SACCH that falls within the measurement period.
The higher layers expect the frame number to be aligned
to the SACCH channel after, which marks also the beginning
of the next measurement period.
Make the octphy code compatible to the higher layers by
remapping the measurement indication frame number.
Change-Id: I8ecb27c018bf4ad5151878a6ad34026fd0f801a1
|
|
The end of the measurement reporting period is not aligned with the
SACCH block where the results are reported. The tables that are
used to detect the end of the measurement period are therefore
wrong. The frame number of the SACCH block must be used and not the
TDMA frame number (modulo 104) of the measurement reporing interval.
The tables are oriented to the frame number of the first SACCH block,
at the beginning of an interval. However, when a SACCH block is received
it will always contain the result of the recently passed measurement
reporting period.
To match the tables, introduce another lookup table to remap each
SACCH block that ends to the matching beginning block number.
Change-Id: I1eef894e6f15b4449fc8926bebb118624efc7924
|
|
l1_if.c does not generate struct osmo_phsap_prim l1sap properly.
The frame number is not included in this struct. This renders the
logic that processes the reported measurements non functional,
since the logic (see measurement.c) is not able to detect the
end of the measurement period. This commit fixes the problem by
adding the missing frame number to the l1sap structure.
Change-Id: I09241d6cc2ff09e71a3d723d90e4468108a27ae1
|
|
ph_data_req() and ph_tch_req() are generating empty (idle)
frames when no data (msg == NULL) is available. Since the
phy is able to generate idle frames internally, there is
no need to waste Host CPU cycles by doing this in software.
Remove the empty frame generation and exit the function
cleanly.
(Patch by Octasic Inc.)
Change-Id: Ib857b7dab490ad426c48d6a9e5e6fa10ef5a0838
|
|
This commit also fixes a missing end of line in the log output of handle_ph_data_ind
Change-Id: I049f58d51333d3590361db5c0105e6899a862af6
|
|
Internal l1sap dump_gsmtime has been moved to libosmocore as osmo_dump_gsmtime.
Remove use of internal function and replace with the libosmocore version.
Depends on libosmocore Ib5452e2c20f53006c0f6d197fb055728947125d8
Change-Id: Ia2f89965d970ed5bbb8c0d4f591a043e58c4bd66
|