Age | Commit message (Collapse) | Author | Files | Lines |
|
If chan_state->ongoing_facch is set, this code's logic
suggests that both msg_facch and msg_tch could be NULL.
Don't dereference msg_tch unconditionally.
Change-Id: Icf5584396c5b925d55ca9380dd4f869ae5d72da3
Related: CID#172047
|
|
Change-Id: Ifd9a3be6189b3288526e12260d68a982b089404e
|
|
The existing implementation used a simplistic macro, which was wrong
in many ways:
1) it returned a negative value for "fn % 51 < 5" conditions without
raising any error message or asserting
2) it returned a wrong block number for many different input frame
numbers, as it didn't account properly for the FCCH/SCH gaps between
the blocks
Let's replace the simplistic macro with a proper lookup table based on
TS 05.02, and let's OSMO_ASSERT() if this is ever called with non-CCCH
frame numbers.
Change-Id: I11fd6cc558bb61c40c2019e46f56c1fe78ef39f5
Closes: OS#3024
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Change-Id: I76dc47427ec26834859fb737bd319dc379ae8697
|
|
gsm_bts_role_bts was introduced at a time when we still shared
gsm_data_shared.[ch] between BSC and BTS, and where we then subsequently
needed a BTS-private structure. Since that sharing was abandoned quite
some time ago, we can merge gsm_bts_role_bts into gsm_bts and do away
with the bts/btsb dualism in a lot of the code.
Change-Id: I4fdd601ea873d9697f89a748cc77bcf7c978fa3e
|
|
Before this patch we had:
* osmo-bts-trx internally using 1/256th bit/symbol period
* osmo-bts-sysmo internally using 1/4 bit/smbol period
* PCU interface using 1/4
* L1SAP interface using 1/4
* measurement processing code on top of L1SAP using 1/256
So for sysmo/lc15/octphy we are not loosing resolution, but for
osmo-bts-trx we're arbitrarily reducing the resolution via L1SAP
only then to compute with higher resolution again.
Let's change L1SAP to use 1/256 bits and hence not loose any resolution.
This requires a corresponding change in libosmocore for l1sap.h, which
is found in Change-Id Ibb58113c2819fe2d6d23ecbcfb8b3fce4055025d
Change-Id: If9b0f617845ba6c4aa47969f521734388197c9a7
|
|
There's no need to express TOA as a float:
* We receive it as signed 16bit integer in units 1/256 symbol periods
* We pass it to L1SAP as signed integer in 1/4 symbol periods
So turn it into an int16_t with 1/256 symbol period accuracy throughout
the code to avoid both float arithmetic as well as loosing any precision.
Change-Id: Idce4178e0b1f7e940ebc22b3e2f340fcd544d4ec
|
|
There are use cases for the multiframe scheduler tables outside the
context of the entire scheduler. Let's prepare for that.
Related: OS#2978
Change-Id: I6a501e66c47809ae3cdc55bef2cb6390ee0096b1
|
|
Measurement reports fed into L1SAP so far had their frame number always
set to zero, resulting in higher-layer common code above L1SAP to never
detect the end of the measurement period, which in turn caused no RSL
MEAS REP to be sent.
Related: OS#2978
Change-Id: I67837d19515ea335614928570c12dd5027104c6b
|
|
In Change-Id I5703b46c8a59fe00a3cdc063bcf72872980ec5e5 we introduced
LOGL1S and starte to use in in common/scheduler.c as well as
osmo-bts-trx but somehow we didn't introduce it in osmo-bts-virtual
at the time. Let's catch up.
Change-Id: I0b5fd3b7982b9119becda844531108f64c68d19f
|
|
Let's make sure whenever we do have a frame number, we print it as
context in the related log line
Change-Id: I751d5ddb3322fce489bc241459738cbcc55c890b
|
|
The problem is that measurement processing above L1SAP requires/expects
those PRIM_INFO_MEAS indications from the bts specific parts. Otherwise
it will never generate even uplink-only measurement reports to the BSC,
which is a violation of Abis protocol specs.
Change-Id: I48f73293cb4f0ab4c657dfd00e7ddd032a3c030f
|
|
Don't simply crash if creation of the multicast socket fails
Change-Id: Ie87b6684b3aa7f21742e4cf21533e980485c1230
|
|
Most of the BTS models do not or do register not all of thier
features to the the feature list.
- Update/extend the feature lists for all BTS-Models
Change-Id: I26765a64153368016921c2ac115b1c4aec9bc5e4
|
|
Commit 5eb17e28acdd6fba22a1f2e60f4d55aaef18b47a added this warning when
implementing the full function. However, other backends seem to be also
passing the primitive from the stack to l1sap_up without any visible issues.
Furthermore, according to the documentation of l1sap_up, it takes ownership of the
msgb, but doesn't take ownserhip of the prim itself.
Change-Id: I45fe40e3377eac999d1dac5356678195381d94ca
|
|
Almost all log statements in scheduler_trx.c were using the wrong
logging subsystem. Let's fix this. Also, make it more obvious from
the log subsystem help text
Change-Id: I4312f8ab0414eb38db0d62f05c95ab961f500c14
|
|
* copy-paste gsm_data_shared.* from OpenBSC master
* remove corresponding configure check and option
* remove .deb dependency
Actual refactoring with removal of unnecessary structures/parts, moving
common OpenBSC/OsmoBSC parts into libraries etc. are left for further
patches.
Current patch will make coexistence with *BSC easier and will simplify
our build infrastructure.
Change-Id: I9f004fb5c4c1db29d4792dfd281d388c7063da13
Related: OS#1923
|
|
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
|
|
Change-Id: Id851578c53255866537a16a0be6c3e9268e6ccbc
|
|
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: 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
|
|
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
|