a661bcd086
Fix multiple problems around the sysmobts DSP access and headers: - Use the proper variable name to detect the choice: $enable_sysmocom_bts was not set anywhere and would actually be used from the current user env, if present, instead of from configure args. - Quote the $CPPFLAGS when assigning to oldCPPFLAGS and back. - When checking SYSMOBTS_INCDIR, do not allow an empty "-I" without a dir. - Ensure the --with-sysmobts path is used as an absolute path. - Error out if --with-sysmobts is paired with --disable-sysmocom-dsp. Also tweak reporting. The resulting behavior now is: ./configure --disable-sysmocom-dsp checking whether to enable direct DSP access for PDCH of sysmocom-bts... no ./configure --enable-sysmocom-dsp checking whether to enable direct DSP access for PDCH of sysmocom-bts... yes checking for sysmocom/femtobts/superfemto.h... no configure: error: sysmocom/femtobts/superfemto.h can not be found, see --with-sysmobts ./configure --disable-sysmocom-dsp --with-sysmobts=../../../sysmobts/layer1-api checking whether to enable direct DSP access for PDCH of sysmocom-bts... error configure: error: --with-sysmobts does not work with --disable-sysmocom-dsp ./configure --enable-sysmocom-dsp --with-sysmobts=../../../sysmobts/layer1-api checking whether to enable direct DSP access for PDCH of sysmocom-bts... yes, using -I/n/s/sysmobts/layer1-api checking for sysmocom/femtobts/superfemto.h... yes ./configure --with-sysmobts=../../../sysmobts/layer1-api checking whether to enable direct DSP access for PDCH of sysmocom-bts... yes, using -I/n/s/sysmobts/layer1-api checking for sysmocom/femtobts/superfemto.h... yes ./configure --with-sysmobts=/nonexisting/path checking whether to enable direct DSP access for PDCH of sysmocom-bts... yes, using -I/nonexisting/path checking for sysmocom/femtobts/superfemto.h... no configure: error: sysmocom/femtobts/superfemto.h can not be found in -I/nonexisting/path, see --with-sysmobts ./configure --with-sysmobts=/var/log checking whether to enable direct DSP access for PDCH of sysmocom-bts... yes, using -I/var/log checking for sysmocom/femtobts/superfemto.h... no configure: error: sysmocom/femtobts/superfemto.h can not be found in -I/var/log, see --with-sysmobts Change-Id: I2f5988730dbbcf3b21d8c647c499623843ed3da9 |
||
---|---|---|
contrib | ||
debian | ||
examples | ||
include | ||
src | ||
tests | ||
.gitignore | ||
.gitreview | ||
COPYING | ||
Makefile.am | ||
README.md | ||
TODO | ||
configure.ac | ||
git-version-gen | ||
osmo-pcu.pc.in | ||
osmoappdesc.py |
README.md
osmo-pcu - Osmocom Packet Control Unit
This repository contains a C/C++-language implementation of a GPRS Packet Control Unit, as specified by ETSI/3GPP. It is part of the Osmocom Open Source Mobile Communications project.
The Packet Control Unit is terminating the Layer 2 (RLC/MAC) of the GPRS radio interface and adapting it to the Gb Interface (BSSGP+NS Protocol) towards the SGSN.
The PCU interfaces with the physical layer of the radio interface. OsmoPCU is typically used co-located with the BTS, specifically OsmoBTS. For legacy BTSs that run proprietary sotware without an interface to OsmoPCU, you may also co-locate it with the BSC, specifically OsmoBSC
Homepage
The official homepage of the project is https://osmocom.org/projects/osmopcu/wiki/OsmoPCU
GIT Repository
You can clone from the official osmo-pcu.git repository using
git clone git://git.osmocom.org/osmo-pcu.git
There is a cgit interface at http://git.osmocom.org/osmo-pcu/
Documentation
We provide a user manual as well as a vty reference manual
Please note that a lot of the PCU configuration actually happens inside the BSC, which passes this configuration via A-bis OML to the BTS, which then in turn passes it via the PCU socket into OsmoPCU.
Mailing List
Discussions related to osmo-pcu are happening on the osmocom-net-gprs@lists.osmocom.org mailing list, please see https://lists.osmocom.org/mailman/listinfo/osmocom-net-gprs for subscription options and the list archive.
Please observe the Osmocom Mailing List Rules when posting.
Contributing
Our coding standards are described at https://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards
We us a gerrit based patch submission/review process for managing contributions. Please see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit for more details
The current patch queue for osmo-pcu can be seen at https://gerrit.osmocom.org/#/q/project:osmo-pcu+status:open
Current limitations
- No PFC support
- No fixed allocation support (was removed from 3GPP Rel >= 5 anyway)
- No extended dynamic allocation support
- No unacknowledged mode operation
- Only single slot assignment on uplink direction
- No half-duplex class support (only semi-duplex)
- No TA loop
- No power loop