Age | Commit message (Collapse) | Author | Files | Lines |
|
service sets led to orange before/while osmo-bts is being started.
osmo-bts-lc15 sets led to green while operating. (unchanged in here)
service sets led to red when osmo-bts stops running.
Change-Id: If351f49d1ead359192d0d80bbc381afd3459c940
|
|
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
|
|
Valid range is currently set to 1000-200000.
Change-Id: Ibf60ab290acf0423c7617591a86403d63266e5d3
|
|
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
|
|
The sysmobts- and lc15bts- mgr have different semantics for the same
command line option (-n: writing to EEPROM vs writing to ROM). and
different default value. Hence it make sense to use separate files,
similar to osmo-bts-*.service
Change-Id: I645a81e30d7146ff26720391db763b6d585037e6
Related: SYS#3728
|
|
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
|
|
* add trx-calibration path
* change GSM band to 900
Change-Id: I50bc4a4314a8b48e4000de445f4f05795e1a2d8b
Related: SYS#3722
|
|
* 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
|
|
* unify description
* provide common BTS-independent aliases
Change-Id: Ia067dc5b0bdef07b90ab57f89e8ba6b2a794eb4a
|
|
Recent introduction of VIRT-PHY broke .deb build. Fix it by installing
osmo-bts-virtual as part of Debian package.
Change-Id: I1ca7eb51019247eb95c6bac752d6e2c4406ce5a2
|
|
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
|
|
* remove deprecated everything log level
* remove copy-pasted sysmobts-mgr.cfg from root directory
Change-Id: I8f392991097267665e9094189d24e7cf94a5d5d2
Related: OS#71
|
|
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
|
|
Change-Id: I368d4a378e20028603b09825eee766abb9195774
|
|
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
|
|
We should print meaningful error messages in case a user doesn't have
the required local PATH set up, or doesn't specify a required command
line argument.
Change-Id: I30a2935f93ade69222b1e0c3e212ee10e17c1823
|
|
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
|
|
After latest changes, l2 expects to receive an event for every TCH
frame, that is, no TCH frame event should be lost on that layer. We
should now then be safe returning always GSM_RTP_DURATION.
The code which used to calculate the variable duration is left there to
assert that indeed we are not longer having this kind of issues.
Change-Id: I9d112c6db142be138e71393e77129e6d069d9973
|
|
Depends on libosmo-abis Id6099372b6231c0a4b6ea0716f46f5daee7049e1
Change-Id: Ie9053674aa4f43aac20dbd5c865d70317360abbc
|
|
We want to always call l1if_tch_rx and l1sap_up in order to avoid losing triggering
events on the upper layer.
With this change, the upper layer will increase correctly seq + ts for
RTP. It will then send an RTP packet with only the header and no payload, which is
not correct but at least we avoid drifting the RTP clock. Upcoming patch
in the series solves this issue.
This patch assumes that we are not lossing data events from the physical
layer and that we receive an event every 20ms, even if the MS is not
transmitting due to DTX.
Depends on libosmocore If4ae20c22b881e94585dad710f17b9e37f77bf82
Change-Id: If5df8940fab833eb4e3ed851880b66987d356031
|
|
Change-Id: Ib8efd2095fcf759276299b516d495219105c1f2b
Related: OS#1861
|
|
The dsp-trace-flags command line argument was removed
in 9684099ae905e6e61cbc326035d0b37c480f6172
Change-Id: I8dbcdc7080ca3f7d7968aeef24422faa75d925fe
|
|
Change-Id: Ie674c7ec40838af36308c6998f227fa452ace4b4
|
|
This whitespace keeps being automatically fixed by editor, polluting my
patches.
Change-Id: If0ba1321ed326c1498e3f60b611bd962f2a9484a
|
|
L1C is for L1-Control primitives, while TCH channels are L1 Data
channels.
Change-Id: I07ea3a7326bfcb62271d58deb0743311f6d97c8b
|
|
The value string table octphy_cid_vals lacks the strings for
cOCTVC1_MAIN_MSG_APPLICATION_INFO_CID and cOCTVC1_MAIN_MSG_APPLICATION_INFO_CID
(Patch by Octasic Inc.)
Change-Id: I9843137b55534a29938d5c2308244a6950de788f
|
|
This reverts commit 3f97e4b1fcdc788345ab7740bd4fb8a3d73f5526.
Change-Id: Ib50c813c470bf6ea740fe6667431eaa1a23fdd8d
|