Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
From our header files v2.4 onwards, we include some macros that allow us
to do compile-time checks for the API header version. As older headers
don't have those macros, we have to fall back to assume it will be v2.2
|
|
Use "-P -M" to enable PCU and direct access.
|
|
Different applications can now connect to L1 forward proxy or access DSP
directly, if they use different message queues.
|
|
we have to hand off the PH-RTS.ind to the PCU interface _before_
we allocate a response msgb/primitive.
|
|
In case of PDTCH, the PCU has to process measurements, not the BTS.
|
|
A special command line option "-P" is used to enable socket interface
and signal available GPRS MO object to BSC.
|
|
|
|
the user has to explicitly enable it in the VTY
|
|
|
|
We now count the total number of RACH slots, the number with rx level
above the busy threshold, and the number of valid access bursts.
This data is used to generate RSL CCCH LOAD INDICATION for the RACH.
|
|
Once we get RF-ACTIVATE.conf from L1, we now enable the corresponding
LED. We also switch it off on RF-DEACTIVATE.conf. We do _not_ switch
it off when osmo-bts crashes or terminates before RF-DEACTIVATE.conf.
The latter is intentional, as RF may very well still be active at that
point. The re-spawning script will re-set the DSP and therby turn off
the RF and then disable the LED.
A better solution might be to do all this in the kernel driver for the
DSP.
|
|
|
|
|
|
We used to send some crap before, which most phones happily accepted but
some (particularly the Wavecom Q2686) didn't really like at all.
|
|
this allows the BTS to loop-back any incoming data on a TCH
|
|
|
|
This allows us to do RF measurements (EDGE EVM and the like) even
without having any PCU/RLC/MAC code as of now.
To use it, configure PDCH type timeslots (e.g. TS 7) in the BSC and then
use "trx 0 7 activate 0" to manually activate the PDTCH lchan on top
of that timeslot. The BTS will now happily transmit EDGE/8PSK data.
|
|
The ciphering parameters in L1 are persistent accross MPH
deactivate/activate, so we need to make sure to always initialize them
cleanly at RSL CHAN ACT time. This has the added benefit that we can
also activate channels that have encryption enabled from the very
beginning (required for encrypted handover).
|
|
We now check if the received message is an LAPDm I frame in order to
determine if we have received the first valid encrypted message on the
radio link. This relates to the fact that we often see 'old' UI frames
coming up from L1, even after it has confirmed decryption has been
enabled.
|
|
When the RR CIPH MODE CMD is transmitted to the MS, we need to tell the
L1 to enable decryption on RX. After the first received frame has been
decrypted successfully, we will enable encryption also on transmit.
This has been tested with A5/1 so far, but A5/2 and A5/3 should work
exactly identical.
|
|
Our header files use HW_FEMTOBTS guards to select the older femtobts
design. Use the same macro in the bts code.
|
|
|
|
there are VTY commands that can be used to filter which particular
L1 sapis (channel types) should be sent in GSMTAP.
|
|
the default source is the OCXO
|
|
|
|
|
|
This #define helps us to distinguish the subtle API differences between
the earlier v1 (2011) hardware and the later v2 (2012) model.
|
|
rc might not be initialized when going through the default
statement but also hitting a break inside the switch case
statement for GsmL1_Sapi_Sacch.
l1_if.c:530:2: warning: Undefined or garbage value returned to caller
return rc;
|
|
|
|
|
|
This solves a lot of the problems we've been seeing in the context
of large jitter (uRTP) or classic RTP with SID frames
|
|
Using osmo-bts-sysmo and this code, it is now possible to do FR and AMR
based voice calls on TCH/F.
A lot of CPU is wasted in the conversion between the RTP formats and the
L1 specific formats for the codec frames. All data needs to be shifted
by four bits, and the order of bits needs to be reversed in every byte.
|
|
|
|
|
|
when we activate the SCH in the DSP, we start a 5-second timer. If
we ever do not receive any MPH-TIME.ind primitives from L1 within
that time frame, we stop the process (and will be re-spawned)
|
|
|
|
|
|
|
|
|
|
|
|
The sequence is as follows:
0) start osmo-bts
1) start connection attempts to BTS
2) issue L1-RESET.req
3) receive L1-RESET.conf
4) issue RF-ACTIVATE.req
5) receive RF-ACTIVATE.conf
6) receive attributes for TRX
7) receive opstart for TRX
8) issue MPH-INIT.req
[...]
The important point here is: We don't want the BSC to set TRX attributes or do
TRX opstart before our RF related hardware is initialized.
|
|
|
|
|
|
the RACH burst detection in the physical layer is appranetly providing many
false positives, and we need to raise the bar a bit in order to not allocate
channels in a useless way...
|
|
* gather measurements from each PH-DATA.ind
* check every TDMA frame about meas period expiration
* compute averages after period expired
* put MS DL MEAS REP into RSL MEAS RES messages, include UL meas
bugs:
* L3 INFO content seems to have some offset
* is_sub is not set anywhere
* measurement periods might have up/downlink offset
|
|
|
|
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.
|