This is the first step towards the goal of moving the scheduler
into a separate library.
Change-Id: Ifa6137c239c215a3d323213ee74d34b419622be4
Related: OS#5599, OS#3761
File '.version' must be also listed in EXTRA_DIST, otherwise I get:
echo 0.0.0 > ../../.version-t && mv ../../.version-t ../../.version
/bin/sh: line 1: ../../.version-t: Permission denied
Change-Id: I65f7c505f5a231bab114c45f5fdd7421601dfbc0
Related: OS#5599, OS#3761
Unlike xCCH, TCH/H channels are using block diagonal interleaving,
so every single burst carries 57 bits of one traffic frame, and 57
bits of another one. Moreover, unlike TCH/F where both traffic
and FACCH/F frames are interleaved over 8 bursts, a FACCH/H is
interleaved over 6 bursts, while a traffic frame is interleaved
over 4 bursts.
This is why a TCH/H burst transmission can't be initiated on
an arbitrary TDMA frame number. It shall be aligned as of
stated in GSM 05.02, clause 7, table 1.
This change introduces two basic functions:
- sched_tchh_block_map_fn - checks if a TCH/H block transmission
can be initiated / finished on a given frame number
and a given channel type;
- sched_tchh_block_dl_first_fn - calculates TDMA frame number of
the first burst using given frame number of the last burst;
and some auxiliary wrappers to simplify the usage of
sched_tchh_block_map_fn().
Change-Id: Iaf4cb33f1b79df23f8a90c8b14ebe0cd9907fbb9
It's good to write, keep and make the source code as much modular
as possible. So, Tte primitive management code was separated to
the 'sched_prim.c' and going to be extended in the near future.
Change-Id: Ifec8c9e4f2c95c72b00772688bcb5dc9c11d6de7
This change implements basic TCH/F lchan handlers for both data
reception and transmission. Only FACCH (signaling), FR and EFR
payloads are supported at the moment.
Change-Id: If6b0eaede2b484484d2a824e7219ff04483266a1
The training sequences array is currently used by xCCH handlers,
but will be also used for handling both TCH/F and TCH/H bursts.
Moreover the code that forwards decoded L2 payloads to L1CTL
protocol handlers was separated into a new shared function.
Change-Id: I34c3de351362ebd9a070f49bb78d7bd976784b04
It would be better to have xCCH, SCH and RACH burst handlers
in separate files, because as much code we add to a single
file, as harder it becomes to read and understand one.
Change-Id: I456a60e68b32b792e63dd03ae97159dc101fd4bf
The core of scheduler is a simple clock counter, which relays
on system time for now. One was a bit simplified and migrated
from OsmoBTS.
Due to system time is not an ideal clock source, the counter
should be periodically corrected by clock indications from BTS.
Change-Id: I27d85bd3e2c8bca3f876f73517027b9fe43c9825
Now it's possible to handle the following requests
from layer23 apps:
- L1CTL_FBSB_REQ
- L1CTL_PM_REQ
- L1CTL_RESET_REQ
- L1CTL_ECHO_REQ
It should be noted, that the L1CTL_PM_REQ isn't
handled correctly yet, due to required task isn't
implemented on the TRX side yet. Instead of this,
temporary we are sending some fake responses.
Change-Id: I343eca3e20922ddd83e06231811200b26da442f3
This is the second side of the 'OsmocomBB <-> SDR' bridge.
Most of source code taken from the OsmoBTS project.
Change-Id: I96fa3ada05d010f31af419a4950fd8ae2b62ef34
There are two sides of the 'OsmocomBB <-> SDR' bridge. One of
them is the L1CTL interface, which is used by existing layer23
applications to drive GSM L1. Exactly this interface is provided
by the osmocon application, but instead of forwarding messages
between both host software and firmware we need to handle incoming
messages from layer23 applications, perform some GSM L1 specific
conversations (coding, mapping, interleaving, etc.), then finally
forward them to transceiver through the scheduler. And vice versa.
This code is just a basic implementation of UNIX socket handlers,
so currently we can only accept and drop connections from layer23
applications.
Change-Id: I58d069bcc7742b42c0bf95e52063933bf2c352ff
This app is similar to the osmocon, but designed to
connect L2 & L3 apps with SDR transceiver insted of
obsolete Calypso based hardware.
Change-Id: Ie3c17f19aad9c26f3c49966a7c96b65911f62369
Vadim Yanitskiy
Vadim Yanitskiy