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
In reality, trxcon does not switch back to BCCH itself. Neither
the firmware does, so let's correct this confusing log message.
Change-Id: Iad308ad980af4caa7d7d1b358ba7288885f96e04
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I73be012c01c0108fb6951dbff91d50eb19b40c51
Regarding the removal of burst_mask2str() from the TCH/H handler,
it does not make sense to print it because the mask is already
shifted and an earlier logging should already contain this info.
Change-Id: I42d20e2da73c21ca366dd246244cd716c8ccb459
Related: OS#4823
In a typical setup operating on the real radio interface, it's
the duty of the transceiver (e.g. osmo-trx) to send NOPE.ind to
the L1 implementation (e.g. osmo-bts-trx). However, in a
virtual environment for ttcn3-bts-test we use a fake transceiver,
which due to its simplicity cannot send NOPE indications itself.
The lack of queues and buffering does not allow us to implement
NOPE indications in fake_trx.py, so the easiest approach is to
generate them from trxcon. Send TRXD PDUs without the burst bits,
and fake_trx.py will tranform them info NOPE.ind for us.
Change-Id: I1c7f1315b8ef44f651efd6a22fb5b854f65c0946
Related: SYS#5313, OS#1569
Similar to what we do in osmo-bts-trx, group everything related to
an Uplink burst into a structure. Pass a pointer to this structure
to the logical channel handlers. This makes the code easier to read,
and facilitates sending NOPE indications to the transceiver
(will be introduced in the upcoming patch).
Get rid of sched_trx_handle_tx_burst(), and instead just call
sched_trx_a5_burst_enc() directly from sched_frame_clck_cb().
Change-Id: Id45b27180c233fdc42ae1ef0b195554dd299a056
Related: SYS#5313, OS#1569
158 is basically: 8 + 148 + 2, where the last two are padding bytes
sent by legacy TRXDv0 transceivers. We don't need them, so do not
drop PDUs without these leggacy padding bytes.
Change-Id: I6c0734bc4669ccde2a93940c9cf50fdbbd67cb00
This is what trxcon sends to the network before the first SACCH
block is received from the higher layers. The indicated values
are of course invalid because they're hard-coded.
According to 3GPP TS 44.018, table 10.5.2.20.1:
0 The measurement results are valid
1 The measurement results are not valid
Change-Id: I7da767e146aec7cef1de71e4d735d6a02b6c5642
Related: SYS#4918
Table 10.5.2.20.0 "Measurement Results Contents" in 3GPP TS 44.018
is clear on what should be used as padding - '0**', i.e. zeroes.
Change-Id: I4db6845c98aded10291134f416da98fd0f4f58e3
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: I6d80f3f2742d397e47f4f2970c951f2cf6d58172
Fixes: OS#4865
The signal handler was coded as if it was handling SIGABRT, but the
signal handler was not overwritten so it is actually used.
Change-Id: I5c597f3410fc97be138db6f3976df59f393819b6
Both REQ and CNF share the same message structure, so we can
cheat a bit by changing the message type and sending it back.
Change-Id: I6f403ed0506b4b1872361d9976d3186bfe514b52
Related: OS#4799
Some commands, such as SETTA or SETPOWER, are expected to be sent
when the transceiver is powered on. We should not drop Uplink
bursts while waiting TRXC response.
For now it's easier to comment out the state check completely,
because the existing TRXC state machine is quite messy.
Change-Id: Iefe6030200b11b29a5790d1f4aa4070ed1d9a493
In general, premature scheduling of to be transmitted bursts
inevitably increases the time delay between Uplink and Downlink.
The more we advance TDMA frame number, the greater gets this
delay. 20 TDMA frames is definitely more than a regular
transceiver needs to pre-process a burst before transmission.
Change-Id: Ia9b142b59d95f2cd7b2394596cf72c0bcd36d711
Related: OS#4487
When running together with fake_trx.py (mostly used back-end), it
is currently possible that Downlink bursts are received in a wrong
order if more than one transceiver is configured (multi-trx mode).
This is how it looks like:
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=629 rssi=-86 toa=0
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=629 ts=3 bid=1
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=630 rssi=-86 toa=0
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=630 ts=3 bid=2
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=631 rssi=-86 toa=0
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=631 ts=3 bid=3
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=633 (!) rssi=-86 toa=0
DSCHD NOTICE sched_trx.c:663 Substituting (!) lost TDMA frame 632 on TCH/F
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=632 ts=3 bid=0
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=633 ts=3 bid=1
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=632 (!) rssi=-86 toa=0
DTRXD NOTICE sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647)
since the last processed fn=633 (current fn=632)
so here a burst with TDMA fn=633 was received earlier than a burst
with TDMA fn=632. The burst loss detection logic considered the
latter one as lost, and substituted it with a dummy burst. When
finally the out-of-order burst with TDMA fn=632 was received, we
got the large number of allegedly elapsed frames:
((632 + 2715648) - 633) % 2715648 == 2715647
Given that late bursts get substituted, the best thing we can do
is to reject them and log an error. Passing them to the logical
channel handler (again) might lead to undefined behaviour.
Change-Id: I873c8555ea2ca190b1689227bb0fdcba87188772
Related: OS#4658, OS#4546
It's not something that we should be trying to fix, if the whole
TDMA multi-frame is lost. For some yet unknown reason, sometimes
the difference between the last processed TDMA frame number and
the current one is so huge, so trxcon eats a lot of CPU trying
to compensate nearly the whole TDMA hyper-frame:
sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647)
since the last processed fn=633 (current fn=632)
Let's just print a warning and do not compensate more than one
TDMA multi-frame period corresponding to the current layout.
Change-Id: I56251d0d2f6fa19195ff105d3bdfbc22df6db8cd
L1CTL is using the network byte order, because this protocol is
spoken between different devices and architectures. Somehow I
forgot about this while adding SETFH command back in 2018.
Change-Id: Ia2f70f0d5e35b6bf05e1fa6fb51a15c1bbe3ca4c
Related: OS#4546
It would make sense to send the ARFCN list in parameters of SETFH
command, if there was a clear distinction between transceivers in
fake_trx.py, i.e. which one is an MS and which is a BTS.
Right now, every Transceiver is an abstract entity that emits
and receives bursts. So when you convert an ARFCN to a pair of
Downlink/Uplink frequencies, you don't know whether it maps
as Rx/Tx or as Tx/Rx for a given Transceiver.
Of course, we could assume that this is an MS specific feature,
and a pair of Downlink/Uplink frequencies always corresponds to
Rx/Tx, but what if some day we would need to implement and test
a similar approach for the BTS side? Also, by sending frequency
values in kHz (rather than ARFCNs) we can avoid inconsistency
with the existing RXTUNE / TXTUNE commands.
Change-Id: Ia2bf08797f1a37b56cf47945694b901f92765b58
Related: I587e4f5da67c7b7f28e010ed46b24622c31a3fdd
Related: OS#4546
Since we're heavily using trxcon in ttcn3-bts-test, the logging
output should contain as much information as possible. Ideally
we should introduce the VTY interface (see OS#3666) and get
logging configuration options as a bonus. But let's just use
some beneficial hard-coded defaults for now:
- print category and level (huh, we use NOTICE everywhere?),
- do not print category-hex (who needs it anyway?),
- print extended timestamp, so we're in synce with other logs.
P.S. This configuration is based on my own debugging experience.
Change-Id: Ie3d259f3255d8af80e6780f850b808fa243f97b4
As was noted by Pau Espin Pedrol, there is a theoretical chance
that lchan->tdma.num_proc would overflow, so as a consequence,
subst_frame_loss() will be unable to compensate one
(potentionally lost) Downlink burst.
On practice, given the size of unsigned long and duration of a
single TDMA frame, it would only happen once in roughly ~6 years.
FRAME_DURATION = 4615 * 10e-6
ULONG_MAX = 2 ** 32 - 1
FRAME_DURATION * ULONG_MAX -> ~198212740 seconds
-> ~55059 hours
-> ~2294 days
-> ~6 years.
Chances are that trxcon would crash much earlier, or even GSM
would be completely forgotten after such a long time run, but
let's work this around and simply start counting from 1
if that overflow eventually happens.
Change-Id: I3d40ef09b06039a85df52af06ab38de314e1a434
It may happen that the burst reception would start from bid != 0:
<0005> sched_trx.c:263 (Re)configure TDMA timeslot #2 as TCH/H+SACCH
<0005> sched_trx.c:420 Activating lchan=TCH/H(0) on ts=2
<0005> sched_trx.c:420 Activating lchan=SACCH/TH(0) on ts=2
<0006> sched_lchan_xcch.c:96 Received incomplete data frame at fn=0 (0/104) for SACCH/TH(0)
<0006> sched_lchan_xcch.c:106 Received bad data frame at fn=0 (0/104) for SACCH/TH(0)
so in that case, both measurement processing and the frame number
calculation would yield incorrect and/or incomplete results. The
Rx burst mask can be used to eliminate this problem.
In particular, if we shift it left instead of cleaning, it would
never be equal 0x00 after at least one burst is received. This
would allow us to skip decoding of an incomplete frame at the
beginning when the logical channel was just activated.
Note that TCH/H handler is not affected because it already uses
the strategy described above, so we keep it unchanged.
Change-Id: Ib8ddf2edd5ef84f2ab12155f7a8874c9fc56d436
Related: OS#3554
It may happen that one or more Downlink bursts are lost on their
way to the MS due to a variety of reasons. Modern transceivers
supporting TRXDv1 protocol would substitute lost bursts with
so-called NOPE indications. Hovewer, neither fake_trx.py nor
grgsm_trx do support this feature at the moment.
We can still detect and compensate TDMA frame loss per logical
channels in the same way as it's already done in osmo-bts-trx.
In short, we should keep TDMA frame number of the last received
burst in the logical channel state, and using the appropriate
multiframe layout, check if there were any gaps between TDMA
frame number of the current burst and the stored one.
Change-Id: I3551d79796a3730565c2c70577e9d134e636f275
Using TDMA frame number of a burst with bid=0 is fine for xCCH,
but not for TCH and FACCH, because they use the block-diagonel
interleaving. A single block on TCH may be interleaved over
8, 4 or even 6 consecutive bursts depending on its type.
Since we now have the measurement history, we can attach TDMA
frame number to each measurement set, and then look up N-th
one when averaging the measurements in sched_trx_meas_avg().
Change-Id: I9221957297a6154edc1767a0e3753f5ee383173f
These BFI (Bad Frame Indications) substitute speech frames stolen
by FACCH/F or FACCH/H frames, so there can be no bit errors in
something that was not even transmitted over the air interface.
Change-Id: Icdb6209f75ead6581e3c18aeee0da9831aaa272a
According to 3GPP TS 45.003, clauses 4.2.5 and 4.3.5:
- one FACCH/F frame steals a single speech frame,
- one FACCH/H frame steals two speech frames.
A BFI (Bad Frame Indication) needs to be sent for each stolen
speech frame. This does not apply to CSD (data) channels though.
The BFI frames must have measurement data attached to them, and
due to their virtual nature (they do not actually come from the
air interface), the measurements must be crafted by trxcon.
Assigning a negative value to n_errors makes the code below the
'bfi' label craft fake measurement data. Otherwise, the actual
measurements belonging to the FACCH frame will be used.
Change-Id: Ia2f7c3cf7b1ef3737da6b1818cae2f001ee8768f
So far we used to store the sums of ToA and RSSI measurements in the
logical channel state, and after decoding of a block, we did calculate
the average. This approach works fine for xCCH and PDTCH, but when it
comes to block-diagonal interleaving (which is used on TCH/F and TCH/H
channels), the results are incorrect. The problem is that a burst on
TCH may carry 57 bits of one encoded frame and 57 bits of another.
Instead of calculating the sum of measurements on the fly, let's push
them into a circular buffer (the measurement history), and keep them
there even after decoding of a block. This would allow us to calculate
the average of N last measurements depending on the interleaving type.
A single circular buffer can hold up to 8 unique measurements, so the
recent measurements would basically override the oldest ones.
Change-Id: I211ee3314f0a284112a4deddc0e93028f4a27cef
Due to recent include dependency tree change in libosmocore, trxcon
fails now to build since it uncovered it's missing a header inclusion
for a symbol it is using:
osmocom-bb/src/host/trxcon/sched_trx.h:204:20: error: ‘GSM_MACBLOCK_LEN’ undeclared here (not in a function)
204 | uint8_t mr_cache[GSM_MACBLOCK_LEN];
| ^~~~~~~~~~~~~~~~
Change-Id: Ide22e525c106342b00171a8c08bb7265d19a651b
This feature may be useful for our TTCN-3 testing infrastructure.
By default it's disabled, and can be enabled using command line
arguments of the main binary:
./trxcon -g 127.0.0.1 ...
Change-Id: Iab4128fee5f18d816830fdca6c5ebebaf7451902
According to 3GPP TS 45.010, section 5.6.2, for packet-switched
channels the BTS shall monitor the delay of the Access Bursts
sent by the MS on PTCCH and respond with timing advance values
for all MS performing the procedure on that PDCH.
According to 3GPP TS 45.002, section 3.3.4.2, PTCCH (Packet Timing
advance control channel) is a packet dedicated channel, that is
used for continuous Timing Advance control (mentioned above).
There are two sub-types of that logical channel:
- PTCCH/U (Uplink): used to transmit random Access Bursts
to allow estimation of the Timing Advance for one MS in
packet transfer mode.
- PTCCH/D (Downlink): used by the network to transmit
Timing Advance updates for several MS.
As per 3GPP TS 45.003, section 5.2, the coding scheme used for
PTCCH/U is the same as for PRACH as specified in subclause 5.3,
while the coding scheme used for PTCCH/D is the same as for
CS-1 as specified in subclause 5.1.1.
The way we used to handle both PTCCH/U and PTCCH/D is absolutely
wrong - it has nothing to do with xCCH coding. Instead, we need
to use rx_pdtch_fn() for Downlink and tx_rach_fn() for Uplink.
Also, since we only have a shared RSL channel number for PDCH
(Osmocom-specific RSL_CHAN_OSMO_PDCH), there should be a way
to distinguish both PDTCH and PTCCH logical channels. Let's
introduce TRX_CH_LID_PTCCH for that.
Change-Id: I2d1e9b8a66f027047f8d7bdc3f82ff9d8ebcc25e
The gsm0503_pdtch_encode() returns negative number on error,
and the amount of encoded bits in case of success.
Change-Id: I7d75141142922909330c5e86be8734bb06cd57a4
During the handover the MS needs to release the existing dedicated
channel(s), establish the new one(s) as indicated by the network,
and then, depending on the synchronisation state, send one or more
HANDOVER ACCESS messages carried by Access Bursts.
In order to implement this, trxcon needs to be able to transmit
Access Bursts on any TDMA timeslot regardless of the logical
channel type and the associated handler, i.e. != TRXC_RACH.
The controlling side on L1CTL (layer23 or TTCN-3) needs to send
one or more L1CTL_RACH_REQ message(s) with properly populated
UL info header. Otherwise a regular RACH on TS0 is assumed.
Change-Id: Ia967820a536c99966ba2c60b63d2ea9edb093f46
Before this patch, prim_dequeue_sacch() used to ignore SACCH primitives
with odd length (e.g. 21, when sender forgot to push 2 octets of L1
SACCH header), so neither they were transmitted, nor rejected.
As a result, they would stay in the Tx queue until a dedicated
connection is released. The only way to notice such problem
was looking at the constantly growing talloc's report.
Instead of ignoring the primitives with odd length and keeping them
in the queue, let's pass them to a logical channel handler, so they
would be dequeued and rejected with a proper logging event.
Also, to simplify further debugging, let's print the final decision
of SACCH prioritization: whether it's a Measurement Report or not.
Change-Id: I3149fa518439470b397953306209eb859c83450a
According to 3GPP TS 05.02, section 6.4.1, CBCH replaces
SDCCH number 2 in both V (BCCH+CCCH+SDCCH/4+SACCH/4) and
VII (SDCCH/8+SACCH/8) logical channel combinations.
Unfortunately it is not clear whether we can use stolen UL slots
for RACH or not. For now, we should mark all of them as IDLE.
Somehow TRXC_SDCCH4_2 slots were left in the definition of
combination V (combined CCCH+BCCH). This is not critical,
but may be looking confusing. Let's fix this.
Change-Id: Id30f2fac3274de3edff4ae59f77d9c9cf8059155
The existing logic unconditionally wants to send a POWERON command
on TRXC whenever L1CTL_FBSB_REQ is received. That may cause some
problems when sending subsequent L1CTL_FBSB_REQ, e.g. due to signal loss.
Sending POWEROFF when transceiver is not powered on is normal though.
This can happen if trxcon is restarted while fake_trx was running.
The existing FSM state could unfortunately not been used, as it's a
mixture between the TRX connection state and the command/response state.
The current solution is just a work around. We definitely need to
introduce separate state machines for transceiver and its TRXC
interface.
Change-Id: I834e8897b95a2490811319697fc7cab6076db480
Both PRIM_IS_RACH() and PRIM_IS_EXT_RACH() macros to be used for
handover RACH detection in the follow up changes, thus we need
have them widely available. Let's also give them better names:
PRIM_IS_EXT_RACH -> PRIM_IS_RACH11
PRIM_IS_RACH -> PRIM_IS_RACH8
and introduce a new generic one for checking whether a given
primitive is RACH in general (either 8-bit or 11-bit) or not.
Change-Id: Ibc39c57fda000647be1829786f6423dcf3f435cd
It makes sense to do this first, before tuning to a different
ARFCN and changing the training sequence. Otherwise, if no
multi-frame configuration is found, trxcon would switch to
a different channel and then remain inactive there.
Change-Id: I274588ce3a9c49372b5da0629930afece46f799c
Having magic pre-calculated hex-masks gives one quite high chances
to shoot oneself in the foot, and decreases readability in general.
Let's do this pre-calculation during the compilation process, so
it's much easier to read, extend and spot potential bugs.
Change-Id: If945b3654e35c83fc0220fdd6d99c1c7a0503386
In I2fc61e1cdca4690a34e2861b9ee3b7c64ea64843 I introduced a regression.
TRXC_SDCCH4_CBCH should have TRX_CH_FLAG_AUTO, because it's a part of
GSM_PCHAN_CCCH_SDCCH4_CBCH multi-frame layout. If the controlling
side on the other end of the L1CTL link requests this particular
multi-frame layout, CBCH channel is expected to be active.
Change-Id: I3ed942106a03220417b5cb9176107af057120fbe
Let's avoid fancy alignment in the description of logical channels
for the benefits of having better readability, the ability to add
more comments and fields without making it look ugly.
Also, let's get rid of field 'chan' of 'trx_lchan_desc' structure
since it's not used anywhere, and not actually needed because the
position of each lchan description is defined by its TRXC_* type.
As a bonus, let's add a human readable description to each
lchan definition, so it can be printed in the VTY some day.
Change-Id: I2fc61e1cdca4690a34e2861b9ee3b7c64ea64843
PDCH channel support was introduced quite a while ago, but there
was no way to activate it via L1CTL so far. Let's fix this.
Change-Id: I3b66cab26108ab999a7fe969365ab57dc661399c
Wherever possible, use #defines from libosmogsm as opposed to magic
numbers. Using magic numbers in several places has the danger of
different programs/repositories having different views on what those
values mean.
Change-Id: I7ab4958801b3422973b67ff0452b90afa8a3f501
Related: OS#4027
Depends: libosmocore Change-Id I93e557358cf1c1b622f77f906959df7ca6d5cb12
OsmoBTS, BSC and TTCN3 used cbits == 0x18 for dynamic PDCH, while
trxcon wanted to use 0x18 for CBCH on SDCCH/4. Let's fix this and
bring everyone in agreement.
Related: OS#4027
Change-Id: Ia9a415628c659cbc2dd5dc65b875b7f935d6e211
According to the man page of recv(), the only difference of this
call from read() is the presence of flags. With a zero flags
argument, recv() is generally equivalent to read().
Change-Id: I6d43bbf8d52c5fbb8ee0592b7d1c1dfd2dd1548e
Since we only set both ARFCN and TDMA frame number of the DL info
header, other fields remain uninitialized. Let's memset() them.
Change-Id: Ib39c333f1724fefa5d8bd8a2315b77a5612f7fa9
This would allow to abstract both L1CTL and TRX interfaces
from each other in the upcoming refactoring.
Change-Id: I74a23c73b03bad822272b9cfe76c2501666912b7
According to 3GPP TS 05.03, section 5.3, two coding schemes are
specified for access bursts: one for regular 8-bit bursts,
another - for extended 11-bit packet access bursts.
According to 3GPP TS 05.02, section 5.2.7, there are two
additional training (synchronization) sequences for RACH
bursts: TS1 & TS2. By default, TS0 synch. sequence is used,
unless explicitly stated otherwise (see 3GPP TS 04.60).
According to 3GPP TS 04.60, section 11.2.5a, the EGPRS capability
can be indicated by the MS using an alternative training sequence
(i.e. TS1 or TS2) and the 11-bit RACH coding scheme.
Change-Id: I36fd20cd5502ce33c52f644ee4c22abb83350df8
Use static helper to prepare l1ctl_fbsb_conf - this simplifies
fbsb-related functions and make difference between timer callback and
regular response more obvious.
Change-Id: I43832d6a912a32ea5795ed0110981e0b714a7a61
Use static helpers to add l1ctl_info_dl to msgb - this simplifies
l1ctl_* routines and reduce code duplication.
Change-Id: I0b5b81f1fcd2984136e553a93735ea5456d2b3df
Instead of counting both RSSI and ToA measurements separately,
let's have a single counter in trx_lchan_state.meas struct.
Change-Id: I45454a3ac92b8cc85dd74092e4ab6eb350f20c9a
Both l1ctl_link_init() and trx_if_open() do accept 'tall_ctx' now,
so there is no need to expose the root context anymore. For
logging initialization, we can just pass a pointer.
Change-Id: I7a2231eb880a995d3296b94481a7799e6ff07489
The main changes are:
- return pointer to the allocated l1ctl_link or NULL,
- accept the talloc context as 'tall_ctx' argument.
Change-Id: I7fe1bc306494ac692c182dcfd2a2d9412929194b
The main changes are:
- return pointer to the allocated trx_instance or NULL,
- extend debug message with TRX address and base port,
- accept the talloc context as 'tall_ctx' argument,
- rename goto label 'error' to 'udp_error',
- rename argument 'port' to 'base_port'.
Change-Id: I39b24afee2f09d6a6c500cfc26ac45f206589c5c
Due to a mistake, average RSSI value of received bursts was not
converted to GSM RX level (range 0..63), so trxcon has been
sending incorrect values to the higher layers.
Let's fix this, and also prevent possible division by zero.
Change-Id: Id4659de899411ec1ba1718fdcb40aec562dbfd65
The idea of SETFH command is to instruct transceiver to enable
frequency hopping mode using the following parameters:
CMD SETFH <HSN> <MAIO> <CH1> <CH2> [... <CHN>]
Note: since the length of a CTRL command is limited to 128
symbols (BTW: why?), the amount of channels is also limited.
Change-Id: Id3d44e6a2796f1ce8523a49dedd5d484052a5c7f
Previously the wildcard address (i.e. '0.0.0.0') was hard-coded
as the bind address of TRX interface. Let's make it configurable
by introducing a command line option.
Note that the '--trx-ip' option was deprecated by '--trx-remote',
because it isn't clean whether it is remore or local address. It
still can be used, but was removed from help message.
Change-Id: Ic2f43632cc57bb6f722eba05219e438f97fecb95
This change extends sched_trx_chan_nr2pchan_config() with Osmocom
specific cbits related to CBCH, so now one can to decode
CBCH channels in dedicated mode (see L1CTL_DM_EST_REQ).
Change-Id: I9347c45638223cac34f4b48eb736e51a5055a36f
According to GSM TS 05.02, there are two ways to enable CBCH:
a) replace sub-slot number 2 of CCCH+SDCCH/4 (comb. V),
b) replace sub-slot number 2 of SDCCH/8 (comb. VII).
Unlike SDCCH/8 (case b), CCCH+SDCCH/4 can be allocated on TS0
only, and shall not use frequency hopping. This means that
implementing CBCH support on SDCCH/8 would require much more
efforts than on combined CCCH+SDCCH/4, as in last case CBCH
messages can be received without the need to switch from
idle to dedicated mode.
This change introduces a new ccch_mode item, which should be
used by the higher layers to indicate presence of CBCH channel
on C0/TS0, so the PHY would enable decoding of CBCH messages
on CCCH+SDCCH/4 (case a) in idle mode.
Regarding to CBCH on SDCCH/8 (case b), it makes sense to
extend the 'l1ctl_dm_est_req', so it would be handled in
dedicated mode on request from the higher layers.
Change-Id: Ia94ebf22a2ec439dfe1f31d703b832ae57b48ef2
According to GSM TS 05.02, section 3.3.5, Cell Broadcast Channel
(CBCH) is a downlink only channel, which is used to carry the
short message service cell broadcast (SMSCB). CBCH is optional,
and uses the same physical channel as SDCCH. More precisely,
CBCH replaces sub-slot number 2 of SDCCH channels when enabled.
This change introduces the CBCH enabled multi-frame layouts,
and two separate logical channel types:
- GSM_PCHAN_CCCH_SDCCH4_CBCH (lchan TRXC_SDCCH4_CBCH),
- GSM_PCHAN_SDCCH8_SACCH8C_CBCH (lchan TRXC_SDCCH8_CBCH).
Both logical channels are separately identified using
the following Osmocom specific cbits:
- TRXC_SDCCH4_CBCH - 0x18 (0b11000),
- TRXC_SDCCH8_CBCH - 0x19 (0b11001).
The reason of this separation is that we somehow need to
distinguish between CBCH on C0/TS0, and CBCH on CX/TS0.
Unlike TRXC_SDCCH8_CBCH, TRXC_SDCCH4_CBCH is enabled
automatically (TRX_CH_FLAG_AUTO), so CBCH messages
can be decoded on C0 while being in idle mode.
Change-Id: Iad9905fc3a8a012ff1ada26ff95af384816f9873
The 'ccch_mode' enum from 'l1ctl_proto.h' to be extended in the
near future in order to reflect persistence of CBCH. Thus it
should be handled in a switch statement.
Change-Id: I75e3b8deac1da296efb178e65ff6992b5c407b80
According to GSM TS 08.58, chapter 9.3.1, channel number 0x08
describes sub-slot number 0 of SDCCH/8+ACCH. This is definitely
wrong. In OsmoBTS we use an Osmocom specific extension for packet
switched channels - 0xc0, so let's use it here too.
Change-Id: I11925408d6e63baf1eac880839ecd717843fba6a
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
Enforcing pointer to a 'trx_instance' structure is not flexible,
because it is used as parent talloc context only.
Change-Id: I5ab2ef5cea76f955bf72ef54541b3b75cdc2d23f
Having access to a logical channel state is required by the
follow-up change, which will introduce a separate function
for dequeuing SACCH primitives.
Change-Id: Ibde0acf8e6be224b1007be707a636eaad68c8d36
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
The 'normal' math operations, such as addition and substraction,
are not applicable for TDMA frame numbers because they may result
in out-of-range values.
Having TDMA frame math helpers in a single place would allow
one to avoid possible out-of-range result mistakes.
Change-Id: Ibb66ba846cc3d6c2eaa88414569e5f3751128047
GSM48_CMODE_SIGN means 'signaling only', so we shall not send
bad frame indications in this state. Instead, it makes sense
to send dummy L2 frames like we do for xCCH channels.
Change-Id: Ie39d53522cafab265099076b3194fa96aff217ba
Despite the correct range of Timing Advance value is [0..63],
there is a special feature in OsmocomBB which allows one to
simulate the distance between both MS and a BTS by playing
with the signal delay.
This is why a signed 'int8_t' type is used in L1CTL protocol.
No need to limit the range, just forward it to TRX.
Change-Id: I06774b315b8451bf14083da6b2849d6e8594abc8
I am not sure we need the both control commands, as every burst
on DATA interface has a header that includes TX power.
Change-Id: Id14603e71df6dedb5a843bb3e20a320192dbca3d
Let's differentiate between 'expected' unimplemented messages
like L1CTL_NEIGH_PM_REQ and truly unknonw message types.
Change-Id: Id76993056fb514e6fb0242d505205316c61bb965
A BSC may allocate a dedicated channel on any ARFCN, not necessary
on the same one where a mobile station has requested this channel.
For some reason, the ARFCN info of L1CTL_DM_EST_REQ message was
not handled by trxcon. Let's fix this.
Related: OS#3526
Change-Id: I16ed5c64236c159bfa39002b05094c1f6c171f6b
In the most cases an ARFCN value is stored together with some
flags (e.g. DL/UL flag, DCS flag), so it should be taken into
account e.g. when printing. Let's use the proper naming.
Change-Id: I0b7634c80986dbff9d0da421c6a044cd36c9fd01
There is no need to check the range of timeslot number, which is
decoded from GSM 08.58 channel number (9.3.1) by applying 0x07
mask, because any result of this operation is always within
the correct range.
Change-Id: Ib84417099d303bd3ae3557f48a5c40b812c6cdfc
Use osmo_clock_gettime() to read the monotonic clock instead
of gettimeofday() which could drift backwards.
This requires switching the scheduler clock from struct timeval
to struct timespec. Expand some variables to 64 bits in order
to keep types used in calculations compatible.
The previous implementation unconditionally subtracted microsecond
values from different time measurements, causing overflow if the
current measurement was taken in less of a fraction of a second
than the past measurement. Use timespecsub() for the subtraction
instead which accounts for fractions of a second correctly.
Change-Id: Ic93f90685c6d6dc28dfc4ad48c998e0eac113cf8
Related: OS#3467
This field of the logical channel state structure was not used at
all as there is nothing related to A-bis / RSL in trxcon itself.
Change-Id: Iec1abf777a74cf57deadafa95e2337cba5d02842
When relying on GSM 04.08 channel mode (GSM48_CMODE_*), one should
distinguish between Bm (full rate) and Lm (half rate) channels.
This change prevents the scheduler from generating TCH/F BFI
instead of TCH/H BFI on the corresponding channels.
Change-Id: I4547aa7f6d38637692fef8a0122e85fb52039a46
Instead of passing the information about a logical channel, it
makes sense to pass the pointer to its state where everything
is stored. This approach would allow to avoid adding more
arguments every time, e.g. in case of AMR.
Change-Id: I91fe86fef43aac68776a58c9acc37ef2a9ee8042
Initially it was assumed that FACCH prioritization should be done
in the same way for both TCH/F and TCH/H. Moreover, it was not
possible to confirm this, because TCH/H was (and still) not
implemented yet. But according to the specs:
- unlike FACCH/F, FACCH/H transmissions shall be aligned
within a multiframe, i.e. can only be initiated on
particular frame numbers (see GSM 05.02, clause 7);
- unlike FACCH/F, a FACCH/H frame steals two TCH/F frames;
so the TCH/H (including FACCH/H) primitives should be handled
separately from the TCH/F (including FACCH/F) primitives.
Change-Id: I9b59f60e1cbac8fb8fd557b6c67b5e376c0a6bbb
The previous primitive dequeuing logic (especially for TCH/F
channels) was a bit complicated, and it could not be possible
to reuse the existing code parts in the upcoming implementation
of both TCH/H and FACCH/H channels without changing anything.
In particular, this change introduces two internal functions:
- prim_dequeue_one(), which merely dequeues a primitive
of a given channel type (e.g. TRXC_SDCCH4_0);
- prim_dequeue_tch(), which dequeues either a FACCH,
or a speech TCH primitive of a given channel
type (Lm or Bm).
So the logic of the TCH/F prim dequeuing function has become
cleaner, and the upcoming TCH/H prim dequeuing function, where
FACCH/H prioritization is more complex than FACCH/F, will
reuse the introduced functions.
Change-Id: Ib82ad2480ab1bc6b1df9576eb2bf5acbd398bf66
We used to trust (and still doing this) the messages coming from
L1CTL interface too much, and not to check the primitive length
before passing the payload to the libosmocoding API. As was
discovered and described in OS#3415, sending a L1CTL message
(either DATA_REQ, or TRAFFIC_REQ) with an incorrect length
(lower than expected) may cause heap overflow.
Let's explicitly check a primitive before encoding, and drop it
if its length doesn't match the expected value(s).
Change-Id: I258ee9f6d0124b183b1db23a73f1e523fcea89a8
Fixes: OS#3415
Currently Access Burst generated by trxcon
has 8 zero bits at the beginning. According to
the 3GPP 05.02 specification (Chapter 5.2.7
Access burst) custom 8-bit extended tail bits
sequence should be used:
(BN0, BN1, BN2 ... BN7) = (0,0,1,1,1,0,1,0)
After this fix trxcon sets correct 8-bit
sequence at the front of Access burst.
Change-Id: I1f624e783de6c585d2e292965c9e5810b0a4f27d
The main problem here is that the existing implementatin missing the L1
header in this message. A SACCH message doesn't have a 23byte LAPDm
message, but only a 21 byte LAPDm message prefixed by a 2-byte Layer1
header. So on the receiver in the BTS, right now the first two bytes of
the UL SACCH frame are misinterpreted as L1 header.
This it what causes RLL ERROR INDICATION on the Abis side, which is why
our BTS_Tests fail.
Change-Id: Id7776bf3604d0e8a32e04547e01b8bd377903272
Related: OS#3170
In order to be able to introspect not only the root application
context, but also all other contexts, e.g. allocated within
libosmocore or other libraries, let's enable tracking the
use of NULL contexts using the corresponding talloc API.
Change-Id: Id21cd5ee340def443f7a5d0b2b8f37f41188dd87
This is useless, and prevents us from finding potential memory
leaks at exit. Let's print talloc report instead of that.
Change-Id: Ibf04942070d654e97c3ed77d69ab19e44602758c
The osmo_init_logging() doesn't allow to specify a talloc context
for libosmocore logging subsystem, so this is why the new version
was introduced. Let's use it.
Change-Id: I06c4a1f7f839f774bc428e89cfac30132bae904d
the initial tch_mode is not always 0 (signalling) but can very well
be directly a codec mode, if the initial activation of the channel
is in speech mode as opposed to signalling
Change-Id: I96e4c89da1165e9c5287d863e0e65d811460c606
According to TS 144.006, section 5.2, the first octet containing
fill bits shall be set to the binary value "00101011" == 0x2b.
Change-Id: I8f0304bf84613a2dc07cb78aff0cb8bb4c5adf6c
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
Vadim Yanitskiy
Oliver Smith
Pau Espin
Harald Welte
Vadim Yanitskiy
Eric Wild