| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch improves the virtual physical layer designed to replace the
air interface. The purpose is to get rid of the hardware requirements
and be able to start testing and implementing layer 2 communication
functionality on one machine. Multicast sockets are used to enable
bidirectional communication between the BTS and the MS process.
The GSMTAP protocol designed for wireshark capturing is used to
encapsulate the payload on the virtual physical layer.
* Working mcast socket communication and extraction of its
functionality.
* Fixed OML and RSL startup sequences.
* Icludes tests for mcast socket and virtual UM.
* Ecapsulation and parsing methods to and from GSMTAP messages.
* Basic handlers for file descriptor callbacks from incoming mcast
messages.
* Multiplexing to different channels based on GSMTAP header channel
type.
|
|
|
|
The header file octphy/octvc1/gsm/octvc1_gsm_default.h is not
visible to the configure script when the octphy header files
are referenced via --with-octsdr-2g instead having them
installed in /usr/local/include. This results in a failed
AC_CHECK_MEMBER check for tOCTVC1_GSM_TRX_CONFIG.usCentreArfcn,
even if header files with multi-trx support are used.
The configure.ac script manipulates the CPPFLAGS in order to
make the octphy include files visible to AC_CHECK_ and restores
the original CPPFLAGS when done. This is required when
--with-octsdr-2g is used. AC_CHECK_MEMBER is executed
before the CPPFLAGS are manipulated. This causes no issues
if the headers are properly installed to /usr/local/include,
but does not work when --with-octsdr-2g is used.
This commit moves the AC_CHECK_MEMBER command into the section
where the manipulated CPPFLAGS are valid in order to fix the
problem described above
See also commit: f5494e84e898f947190466d30d5f932bac0fadf9
Change-Id: I7bdfa4449cd6061c395cce315b372c2833520e37
|
|
The multi-trx had to be removed because of build conflicts
with octphy header that lack the struct members for needed
to support multi-trx.
For details see the following revert-commits:
ed6b48e4a5fba07c3ecccf689991799ae13a2aaa
c9a1f284acf518cb4e62c3898e20398ed53807c3
This commit reintroduces multi trx support and ads an ifdef
decision to ensure that header files without multi-trx
support still work.
Change-Id: I7f9b2906cc149c817183745b4c96bcc7f9ebdad0
|
|
Change-Id: Ifee0434dfa275f9faa517c740fd8577930f37188
|
|
Explicitly set AC_CONFIG_AUX_DIR.
To reproduce the error avoided by this patch:
rm install-sh # in case it was already generated.
touch ../install-sh # yes, outside this source tree
autoreconf -fi
This will produce an error like
...
configure.ac:16: error: required file '../ltmain.sh' not found
configure.ac:5: installing '../missing'
src/Makefile.am: installing '../depcomp'
autoreconf: automake failed with exit status: 1
See also automake (vim `which automake`) and look for 'sub locate_aux_dir'.
Change-Id: I02153ad52faf1465e9f7821378e04118f17352d2
|
|
The user can now use ./configure --with-litecell15=/my/local/path
|
|
|
|
This commit adds basic support for the Litecell 1.5. Multi-TRX is not
supported yet. Instead, multiple instances of the BTS can be launched
using command line parameter -n <HW_TRX_NR> to specify if TRX 1 or
2 must be used by the bts. Note that only TRX 1 opens a connection to
the PCU. Full support for GPRS on both TRX will come at the same time
than the multi-TRX support.
The BTS manager has been adapted to match the new hardware but otherwise
it has not been improved or changed compared to the one used on the
SuperFemto/Litecell (sysmobts).
|
|
This adds support for a new PHY to OsmoBTS, the Octasic OCTSDR-2G
PHY. This is a proprietary GSM PHY running on a familty of Octasic DSPs.
|
|
This also ensures that a missing ortp library dependency is discovered
at configure time already
|
|
This reverts commit 94a05abb98fcb1a5002f327888635f3af860c9a9.
The tests don't work well with subdir-objects, so we have to live with
the warnings meanwhile until somebody finds time to find the magic spell
to solve the autotools quest.
|
|
|
|
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
|
|
|
|
|
|
|
|
|
|
|
|
The code is quite complete, TCH and PDCH channels are not yet tested.
|
|
We should only calibrate the clock if there is a GPS fix. Start
gpsd to determine if there is a fix or not. Work around trimble
decoding issues (sent an email upstream). We need to gain some
more experience to see if there memory leaks. We also need to
re-schedule the calibration depending on the outcome.
|
|
|
|
In order to support transmit power reduction by thermal management
as well as the variety of new internal / external PA configurations
of BTSs, we need a slightly more complex system.
Also, as at high power a single dB can be quite a big difference,
we are now doing all computations in milli-dB(m), i.e. 1/10000 bel.
Ramping is now used both for up and down ramping, as that is useful in
cases where you want to gracefully shut down a cell by shrinking its
radius, gradually handing over subscribers to neighboring cells.
Furthermore, this code is becoming part of the 'common' codebase, as it
is not really specific to how sysmobts is working.
The user can specify a single aggregate value for external system
gain/attenuation. Let's say you have 1dB loss of antenna cable, so you
can put that as 'user-gain -1' into the config, which means that a
'transmit power of 20dBm' will be compensatet for that and the TRX is
instructed to output 21dBm to compensate the cable loss. Similarly,
external PAs can be described by a positive user-gain.
One of the next steps will be to communicate those values and the
nominal power capability of the specific BTS to the BSC, so the BSC will
automatically show correct signal levels in the VTY and log files.
The code includes provisions for future extensions regarding
* an external and an internal PA with calibration tables
* a thermal attenuation setting to be controlled by the site manager
|
|
Limit the range from 0 to (_MAX_SYSINFO_TYPE - 1) instead of
0 to 31. This way we will never access the lchan->si.buf[] out
of bounds. This is only a theoretical issue though as the code
filling the lchan->si.buf for the SACCH will not have valid
>= _MAX_SYSINFO_TYPE. Add a small regression test to check we
still schedule all SIs.
Fixes: CID 1040765
|
|
We could have a dedicated configure/cflag for the header files
but for now search in the standard directories.
|
|
Add function for requesting the temperature information to the
microcontroller. I have added a function that we can extend
for requesting more information but in this case we only need to
know the temperature.
I have added to a microcontroller temperature handling function
in the manager for monitoring this information.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
|
|
The first test checks the AGCH may queue length computation.
The second test fills the queue by calling bts_agch_enqueue() with a
mix of IMM.ASS and IMM.ASS.REJ. Then it drains the queue by calling
bts_ccch_copy_msg(). After each of both steps, statistics are printed
out.
Sponsored-by: On-Waves ehf
|
|
libosmoabis has a BTS-side implementation of the IPA protocol for years,
and osmo-bts should have used that all the time. Unfortunately it had
its own local hack, this patch is migrating to the libosmocore
implementation.
|
|
|
|
During development one switches from GSM900 to GSM1800 and GSM850 to
GSM1900. This commit attempts to make this switch more easy.
GSM1800 and GSM1900 have overlapping ARFCNs. This means that the
mapping from bands to arfcn is not injective. Because of that I
removed the code to deduce the band from the ARFCN. This was done
in commit 8c3d807b3fc785ffb18aeb97355150c92221e8a0. The auto-band
option allows to move between GSM900/GSM1800 and GSM850/GSM1900.
Add a simple testcase with these auto-band configurations.
|
|
This was found and debugged by Sylvain. The BTS will always support
A5/0 so we do not keep track of that, the first bit of the flags is
used for A5/1, second for A5/2... but for RSL there is an offset to
go from RSL to A5(x). Add a testcase and change the code.
|
|
* Comment out the osmo-bts-bb/Makefile as we have removed it from
the SUBDIRS and are not packaging the code right now
* Add missing include files for the build
|
|
|
|
Add autoconf support to set the path to the OpenBSC include directory
so that openbsc/gsm_data_shared.h can be found there.
|
|
Right now osmo-bts requires access to one OpenBSC header file and
this requires that openbsc and osmo-bts git are in the same directory.
Begin with making the location of the OpenBSC sourcecode configurable.
This approach will allow to build osmo-bts on our Jenkins installation
but now has the risk of more code including the openbsc/*.h header files.
|
|
Check that adding a paging command works, check that it is expired
after the first call to paging_gen_msg. The test will be extended
to test the scheduling and selection of the various paging messages.
|
|
|
|
|
|
|
|
This only implements creating, binding, connecting and free'ing RTP
sockets, not yet anything regarding receiving or transmitting codec
frames on them.
You will need the rtp branch of libosmocore for libosmotrau
|
|
|
|
|
|
This code re-works osmo-bts to add support for the upcoming sysmocom BTS.
It also tries to add some level of abstraction between the generic
part of a BTS (A-bis, RSL, OML, data structures, paging scheduling,
BCCH/AGCH scheduling, etc.) and the actual hardware-specific bits.
The hardware-specific bits are currently only implemented for the sysmocom
femtobts, but should be (re-)added for osmocom-bb, as well as a virtual
BTS for simulation purpose later.
The sysmocom bts specific parts require hardware-specific header files
which are (at least currently) not publicly distributed.
|
|
|
