We shall always send traffic frame indications, even if received
frame is incomplete or decoding was failed. This is required
for proper Measurement Reporting.
Change-Id: I99e134699796c7075299459e96b2f2d462636619
We shall always send data frame indications, even if received
frame is incomplete or decoding was failed. This is required
for proper Measurement Reporting.
Change-Id: I7beee7e797f488d04c3b59bee9501ce823717092
Since this change, each lchan handler shall manually indicate
a type of both message indications and confirmations.
Change-Id: I02e0b87d61c127d2f6f5b9532909af78332bf707
- change 'l1ctl_tx_data_ind' symbol to 'l1ctl_tx_dt_ind' in
order to indicate that it's used for both DATA and TRAFFIC;
- introduce a 'traffic' flag, which is used to define either
TRAFFIC or DATA indication type;
- pass L2 payload and its length separately from the
Downlink info header.
Change-Id: I9fe65ee9b2d772576b86b7bc85d53518530d1579
- change 'l1ctl_tx_data_conf' symbol to 'l1ctl_tx_dt_conf' in
order to indicate that it's used for both DATA and TRAFFIC;
- introduce a 'traffic' flag, which is used to define either
TRAFFIC or DATA confirmation type;
Change-Id: Iedd569086a264dc7d8740abea5c6e5ca21e299f6
Both functions are almost identical, and the only difference is
the message type they set. Let's combine them into a single
function and introduce a 'traffic' flag, which can be
used to define a message type.
Change-Id: I288f5d7b6cd242c4793973dcb3d2b1b6925d61a7
Each L1CTL message gets its own length pushed in front before
sending. This isn't specified in the 'l1ctl_proto.h', but
assumed in the code. Let's clarify this.
Change-Id: I118d00613aeaf5ff0bad1188fa5f7450d4ca8122
There are two types of L1CTL messages: received and to be
transmitted. Let's use proper names to indicate this.
Change-Id: I7c17687579282fa389bca35dc7edbc3582e55701
If at the moment of transmission there are no frames in TX buffer,
then either a dummy LAPDm frame (0x01, 0x03, 0x01, 0x2b ...) or a
silence frame (depending on a codec in use) shall be transmitted.
This is required for proper measurements on the BTS side.
Change-Id: Ie590990f2274ea476678f6b2079f90eeadab6501
This new flag is intended to indicate that continuous burst
transmission is assumed on particular logical channel. In other
words, if a logical channel has this flag, but there is nothing
to transmit in a TX buffer, then either a dummy LAPDm frame or
a silence frame shall be sent.
Change-Id: I25fcf9eeb787ffe5378d92532439e67d7d42fa65
The sched_frame_clck_cb() is responsible for UL burst transmission.
Iterating over each timeslot, it chooses a proper lchan handler
according to a current frame number and a multiframe layout in use,
takes a L2 UL frame from a TX buffer, and finally calls the chosen
handler in order to to encode and transmit a taken frame.
A handler should be called only for activated logical channels...
but for some long time, there was a bug, so each lchan was
processed, including inactive ones. It's time to fix this.
Change-Id: I33e3ecc14be3ae64dfd02789c7f0970c945582c9
The llist_for_each_entry_safe() should be used instead of the
llist_for_each_entry(), because it's safe against removal
of llist entry.
Found using Valgrind's memcheck tool.
Change-Id: I65234971ec152df038c5388da537a503060c215b
There's no need to express ToA value as a float. Let's 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.
Inspired by Idce4178e0b1f7e940ebc22b3e2f340fcd544d4ec.
Change-Id: I99c0f38db08a530d5846c474aba352aa0b68fe86
The command line help states '-i' is for 'TRX IP address', which is
the remote IP address at which the TRX is to be found. Hoewever, it
was used as the local (bind) IP address of the socket used towards
the TRX. This is my attempt at fixing this. A more complete solution
probably allows to specify both local (bind) and remote (connect)
address, just to be clear.
Change-Id: If0252b15e9c7942687c6dc470951d777f7af651c
In order to avoid clashes with OsmoTRX, which may be also
running on the same host, let's use a different port range
starting from 6700 by default.
This idea was introduced as a result of OS#2984.
Change-Id: I66b5f25aaba3b836448ed29839c39869b5622bed
Related: OS#2984
Since both TA and AGC loops should be implemented in transceiver,
this TODO is meaningless. Let's drop it.
Change-Id: I84979712e2a1b849acaee53d5cd50de4e1e357c2
As there is no any order relation between logical channels, it's
better to use the linuxlist API instead of talloc array.
Change-Id: I5a78582c77ed1ab33817d240e065dc4cd4708199
Previously, when resetting or deleting a timeslot, we did not
deactivate the logical channels, relaying on talloc hierarchical
nature. This approach may cause some problems, e.g. on embedded
systems with emulated talloc API.
Change-Id: I8c34c793df87bd8c79b7bf1f05b949faf10520e8
Let's assume that a logical channel, which was already in use,
is activated again for a new connection. As we don't reset the
state variables, such as burst masks or ciphering data, it may
cause an unexpected behaviour.
In order to avoid this, let's always reset the logical channel
state after deactivation.
Change-Id: I91e736a97cb05b167614cb488a00d847a9a859e0
Initially it was expected that a TCH transmit queue could contain
TCH and FACCH primitives only. But there are also SACCH primitives,
which are also being stored there.
So, let's drop the assertations from the sched_prim_dequeue_tch(),
and return NULL if nothing was found.
Change-Id: Iae37057d35883c09a76f0612e52c2d14d9ff91cb
This change implements the A5/X ciphering support transparently
for the logical channel handlers. In other words, a DL burst is
deciphered before being passed to a handler, and an UL burst is
ciphered before being sent to transceiver.
The implementation mostly relays on the libosmocore's A5 API.
Change-Id: Ib53418d8c0f394fdece09cf5cc240887cb0bb5af
Having a possibility to preprocess UL burst before sending to
transceiver is required for the further ciphering support
integration and probably some other tasks.
Change-Id: Ia6eead5d4f51d7c0bf277b9d5ebb0a74676df567
Previously we used to compare two consecutive first primitives,
taken from a transmit queue. This approach may cause some delay,
which is critical for FACCH e.g. in case of handover.
Let's walk through a whole transmit queue to find a pair of
both FACCH frames, and only then decide what to do.
Change-Id: I925cca77bfaa255dd095bc882c901d41c9bc4633
Previously, each lchan handler used to obtain and delete primitives
from a timeslot's tranmit queue itself. This approach entails many
potential problems and bugs:
- The lchan handlers shall not do that by definition, they
should encode and decode frames according to GSM 05.03.
- In some cases (e.g. TCH), a single transmit queue may contain
primitives of different types (e.g. TCH, FACCH and SACCH). At
the same time, the lchan handlers don't care and don't even
know about each other. So, this could cause an unexpected
behaviour in some cases.
This change separates all primitive management routines,
providing a new API for obtaining and dropping them.
"Write programs that do one thing and do it well."
Change-Id: I29503ece51903784bc53541015285234471c8d15
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
Both SACCH and FACCH messages have the same 23-byte length, both
are being queued together within a single transimt queue. So,
previously a SACCH frame could be picked by TCH burst handler,
and then sent as a FACCH frame. Let's fix this.
A FACCH primitive may have one of the TRXC_TCH* logical channel
types, while SACCH primitives have one of the TRXC_SACCH*.
Change-Id: Ia7090384f3ff74c9d94997265135acbceffa0ffe
Previously, we used to drop a frame if decoding wasn't successful.
This way, the higher layers didn't even know about that, so the
local counters and Measurement Reports were incomplete.
This change makes scheduler to forward L2 frames in any case,
setting the num_biterr for each of them. In case of decoding
error, a dummy (payload filled by 0x00) L2 frame will be sent.
Change-Id: I31011d8f3ca8b9a12474cd0bc653faed18391033
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
There were some BTS specific variables, which are meaningless.
This change cleans them up, and also groups some measurement,
encryption, and AMR specific variables into sub-structures.
Change-Id: Ie753a7e3e7fa2b433d8319b3a05b85b8583d7be2
Since the 32e5641d, the gsm0503_rach_encode() is deprecated, and
the library provides new API with extended (11-bit) RACH support.
Change-Id: I1955fe46eebd173d6eddd1d47ee9f7318b9b4e2d
The time at which the phone is allowed to transmit a burst of
traffic within a timeslot must be adjusted accordingly to prevent
collisions with adjacent users. Timing Advance (TA) is the
variable controlling this adjustment. The TA value is normally
between 0 and 63, with each step representing an advance of
one bit period (approximately 3.69 microseconds).
As trxcon doesn't perform actual burst transmission, this value
needs to be forwarded to the transceiver, which will take care
about the timings.
Change-Id: Ia8c0848827ab2b4cd7cf1efe128b28d5c06ec84e
The 'SETMAXDLY' command is used on the BTS side to limit maximal
Time of Arrival for access bursts. As we don't receive RACH
bursts on the MS side, the command is useless.
The 'SETRXGAIN' command is used on the BTS side to set initial
receive gain value for TRX. On the MS side it's possible to set
that parameter via command-line options of TRX.
Change-Id: I3e61b4b48193004cdcb241cefabb44c12db93120
In order to get the transceiver more time to process bursts,
the L1 scheduler should process the frames and send the bursts
in advance (a few frames before), like OsmoBTS does. By default,
the advance value is 20 frames, but this can be adjusted using a
new command line option of trxcon '-f'.
Change-Id: Ic258a169f3554f931d6277e18ca060d029b77f32
Since 8c4f5457 in libosmocore there are some limitations on FSM
and FSM instance names. This change adjusts the names of both
l1ctl_fsm and trx_fsm instances.
Change-Id: Icaaac3f51bdcfe4f7723060179b8730c3a06529b
There is no (performance) reason to use fprintf instead of LOGP.
Second one provides more useful information, such as a file name
and a line number.
Change-Id: I86dda5b3d746c7802442e4226578a06c04941721
For some reasons, the function, which is used to flush a queue of
transmit primitives, was intended to flush a list of msgb instances
instead of trx_ts_prim, so memory was being cleaned incorrectly.
Moreover, the items weren't actually removed from queue.
Change-Id: Ia84b57350a5c2eee0afebc65f62e30eaddb141d4
The training sequences, data / traffic indication and confirmation
helpers are used by several lchan handlers, like xCCC and TCH. It
would be better to have them all declared within a shared header.
Change-Id: I71980f09a0c0e023370e1a651afc24fff2491552
The l1ctl_info_dl header is expected to be a part of a
L1CTL_DATA_CONF message, but was missing previously.
Change-Id: Ia8dfaed924fd84395ba9ae539164eaa94f52d30b
This change introduces shared primitive management functions,
exposed from the l1ctl_rx_data_req() implementation:
- sched_trx_init_prim() - allocates memory for a new primitive
and its payload. Initializes primitive's header, setting
the logical channel type and the payload length. After
initialization, the talloc context of a primitive is
a trx instance, which passed as the first argument.
- sched_trx_push_prim() - decodes the timeslot index from
chan_nr and pushes a primitive to its transimt queue.
The talloc context of primitive is changed to the
parent trx_ts instance after queuing.
Both functions will be used for handling both L1CTL_TRAFFIC_REQ
and L1CTL_RACH_REQ.
Change-Id: I8169a1ef4ef54d91b50f3e213e4842f54af8b499
L1 Data is quite verbose, while Control is typically limited.
And if you would need to debug some Control message handling,
the Data messages wont overflow your terminal anymore. This
change introduces a new logging category named 'DL1D'.
Change-Id: Id830c8bf913f7a8ddc87c47f70a337ee4623abd8
When the L1CTL_CCCH_MODE_REQ is received, we don't need to
reconfigure anything if the current mode matches requested.
Change-Id: Ib8a511e4edd7210b1806f47e83f316be00a8cbb1
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's better to pass a trx_lchan_state instance directly from
caller to lchan handler instead of passing trx_lchan_type. This
way a handler wouldn't need to find lchan itself.
Change-Id: I47a40542b03ab31da12b0abb1c263c83662ff018
Previously, the chan_nr, received from L2, was parsed in a wrong
way, so in some cases only one logical channel was activated or
some messages (such as Measurement Requests) were sent on
incorrect channel (e.g. on SDCCH instead of SACCH).
This change reimplements the sched_trx_chan_nr2lchan_type(), and
introduces a new function sched_trx_set_lchans(), whics will
parse chan_nr and (de)activate required channels.
Change-Id: I480311c65ef93bbc1644ec708dd2a68fd33091e0
To be able to decode one xCCH message, it's required to have
all set of bursts collected (4/4). Otherwise we should not
even try to decode an incomplete set.
Change-Id: Iaa63462efe19b8e96102fc8c8d8c968a2df2c70e
We should make sure that required timeslot is not only allocated,
but also configured, i.e. has a correct multiframe layout.
Change-Id: I1d0b870c389802b51c709d089b80ac3fb3565fa8
As we know the count of timeslots per GSM TDMA frame, it would
be better to have an array of pointers to trx_ts instances instead
of linux list, which is more usable for lists with unknown length.
Change-Id: I9510a5cddde22950ceb8422e0990d59f05ed4d60
Both SCH_EVENT_CLCK_IND and SCH_EVENT_CLCK_LOSS were not handled,
moreover there is no purpose to keep them.
Change-Id: I8efac459a40f4287e3325890809991d5ef46e9b1
Local clock counter can be corrected using frame number values,
obtained from burst header on DATA interface.
Change-Id: I5a813e3dc1b960831343b8ecb80718291f20e80d
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
Previously, L1CTL_RACH_REQ / L1CTL_RACH_CONF messages were
handled without l1ctl_info_ul / l1ctl_info_dl header, what
caused incorrect data parsing.
Change-Id: I145d137f2cc7de234965e4fe64d9367ed6ccb999
Previously, all L1CTL_FBSB_CONF messages were sent without
required l1ctl_info_dl header, what caused unpredictable
behavior on higher layers (L2 & L3). Let's fix it.
Change-Id: I8dae597bb4c09df36f80944434ce3624569f2cf8
Previously, we had both length and string matching of request and
response. To be able to implement commands with additional params
in the future, this change drops the length matching part.
Change-Id: Id4c50115f5f1b1da450ff8b8dcfd6ccf572d23f5
We need to know BSIC value, before sending RACH requests.
So, let's store it in trx_instance and update as soon as
the first SCH burst is received after L1CTL_FBSB_REQ.
Change-Id: I49574c3661f79f3b4941db6c651baebab2665c1b
Initially, it was assumed that TX lchan handler will only
compose a burst and return a pointer to the buffer. A burst
itself could be sent somewhere outside, e.g. by caller.
It would be better to send bursts exactly from handler, because
in this case it isn't required to have an external buffer.
Change-Id: Ic9dcdd366e68cec38c5840ed8f8cdda8236d67c7
For some reasons, OsmoTRX sends 158-byte long sequences on DATA
interface, where the latest two bytes aren't used.
Change-Id: Ie9295e9b0d8956d9e87e2ced8cca9d5e68040f88
Previously, the content of L1CTL_FBSB_REQ message was only used
to obtain a new ARFCN and retune transceiver. Now, since we have
working TDMA scheduler, some other params (like ccch_mode) may be
used too.
Change-Id: Iccabba376d67e091b55a604a2ae87f2aa86362e5
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 change introduces the following state machines:
- trxcon_app_fsm - main application state machine.
This state machine handles different events, raised
from program modules (such as trx_if.c or l1ctl.c).
- l1ctl_link_fsm - L1CTL server state machine.
- trx_interface_fsm - TRX interface state machine.
The program modules (such as trx_if.c or l1ctl.c) should be as
much independent from each other as possible. In other words,
one module should not call methods from another, e.g. L1CTL
handlers are not able to send any command to transceiver directly.
Instead of that, they should use shared event set to notify the
main state machine about something. Depending on current state
and received event, main state machine 'decides' what to do. This
approach would allow to easily reuse the source code almost 'as is'
anywhere outside the project.
Change-Id: I7ee6fc891abe5f775f5b7ebbf093181a97950dea
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
Harald Welte