Sometimes sending one Access Burst is not enough, so we need to repeat
sending it a few more more times changing the 3 LSBs randomly. This
is what we already do in the mobile app, but not in the modem app.
* Rename GRR_EV_RACH_{REQ,CNF} to GRR_EV_CHAN_ACCESS_{REQ,CNF}.
* Rename VTY command 'grr tx-chan-req' to 'grr start-chan-access'.
* Add an intermediate state GRR_ST_PACKET_ACCESS.
** The GRR_EV_CHAN_ACCESS_REQ transitions to this state.
** One RACH.req gets transmitted when entering this state.
** The GRR_EV_CHAN_ACCESS_CNF confirms transmission of a RACH.req.
** Upon the timeout (300 ms) expiry, a loop state transition happens.
** After 3 loop-transitions, transition to GRR_ST_PACKET_NOT_READY.
Change-Id: Iab6d9147f6e0aeb99239affacf318a3897fd6ffe
Related: libosmo-gprs.git If0de3ed86b1e2897d70183f3b0f4fbfd7d2bda80
Related: OS#5500, OS#6131
Before this patch, the RTS:ind was crafted up in the stack when
receiving the DL_BLOCK.ind. This created some problems since the
internal low level state has to be updated in between signalling
DL_BLOCK.ind and RTS.ind, as there's a fn-advnace of one block between
those 2 signals (hence the timeslot allocation has to be applied at the
time when the fn-advance is applied).
This is actually not fixing the whole issue, since there's several
timeslots and hence the following events will have the internal timeslot updated
during the event in the middle, hence potentially causing problems in the
remaining TS:
DL_BLOCK.ind(FN=N, TS=1), RTS.ind(FN=N+4, TS=1), DL_BLOCK.ind(FN=N, TS=2)
In any case, this decoupling already improves the situation and is step
needed anyway towards fully fixing the problem (by, for instance,
maintaining a timeslot state duplicated both for DL and Ul directions,
since they drive based on differnet FN time (1 PDCH block).
Change-Id: I1494e0aac7555f6e01b4b435b77140afc42c098e
iWOW TR-800 is a packaged GSM modem module based on Calypso+Iota+Rita
chipset; it is fully quadband, and reverse engineering of its PCB
confirms that this module is nothing but a mass-produced version of
the core of TI's legendary Leonardo+ reference platform. The same
module is also known as FreeCalypso Tango - a rebranded version of
the same hardware module with different firmware and a different
Responsible Party for official support.
FreeCalypso HQ is contributing OsmocomBB support for this Calypso
modem module for two reasons:
1) Harm reduction - sooner or later someone in Osmocom universe is
going to run OBB firmware on TR-800 once they lay their hands on
this hardware, and the resulting operation will be less harmful /
closer to correct if we provide the basic board support patch.
2) There exists a large surplus of FreeCalypso Caramel2 development
boards that are based around FC Tango modules. Having this hw
supported by both firmwares will hopefully increase the chances
that these boards will find loving homes, as opposed to continuing
to gather dust in a cardboard box.
Legal and ethical disclaimer: OsmocomBB firmware running on ANY
Calypso+Iota+Rita target is *known*, through confirmed observations
with a measuring instrument (R&S CMU200), to put out radio transmissions
that are *severely out of spec*, and this defect does NOT go away
with the present patch which merely adds support for a different C+I+R
board target. The present patch has been produced as a harm reduction
measure, to reduce (but not to zero) the harm that will be caused
by parties who run OsmocomBB firmware on C+I+R hardware despite having
been advised not to. As the party seeking to reduce rather than cause
that harm, Mother Mychaela and her related business entities explicitly
disclaim all liability for damage that will be caused by parties who
continue running OsmocomBB firmware despite having been repeatedly
advised to switch to manufacturer-approved published-source firmware
instead.
Change-Id: I84d564f052f12a25ea3bfb9c78860e9dc6262be8
This patch adds support for TCH/[FH]2.4, TCH/[FH]4.8, TCH/F9.6 and
TCH/F14.4 (including FACCH). Additional changes made:
* enlarge the maximum TCH burst buffer size to 24 * (2 * 58) bytes;
* enlarge per-l1cs UL/DL burst masks to hold up to 32 bits;
* enlarge per-l1cs DL meas ring buffer to 24 entries;
* enlarge L1SCHED_PRIM_TAILROOM from 256 to 512 bytes;
* enlarge L1CTL_LENGTH from 256 to 512 bytes;
Change-Id: I0d7389a9a5f7019b9316ab1c0115797ff54a0e41
Depends: libosmocore.git Ib482817b5f6a4e3c7299f6e0b3841143b60fc93d
Depends: libosmocore.git I0c7a9c180dcafe64e6aebe53518d3d11e1f29886
Depends: libosmocore.git I4685376c8deb04db670684c9ebf685ad6fc989fa
Related: OS#4396, OS#1572
This commit fixes recent previous commit filling in the fn field. The
dl->frame_nr is network order, and we want to pass a host order integer
in the primitive. Use the tm.fn which already includes the proper value
calculated from dl->frame_nr.
Fixes: d524c17d90
Related: OS#3626
Change-Id: Id96015c8b419932abb8095c6cb85aceef34e366f
The pointer and size must given for the SV portion of the character
array only.
Fixes: CID#314049, CID#314048
Change-Id: Ieff4ca886dec71aae1b6ecf2b623d600426580da
During initial GMM Attach, the GMM layer generates an internal
local TLLI and uses it to do the GMM Attach. Only at the time it
receives the GMM Attach Accept with the assigned TLLI from the network
then explicitly informs other layers about the TLLI update.
Hence, the GMMREG user doesn't really know about the TLLI in use until
the GMM Attach success happens (gmmreg-attach.cnf).
During that time, the TLLI at the app is basically unassigned
(0xffffffff). Hence, during that same time a TLLI update hook in
GMMRR-Assign.req will not work since the app is unaware of the remporary
local TLLI, so no match can be done.
In that specific scenario, that's fine, since anyway it is waiting to
receive the GMMREG-Attach.cnf, which will indicate the assigned TLLI to
it.
In summary, not being able to match the TLLI in GMMRR-Assign.req is not
bad per se, so soften the log error there.
Change-Id: I31c04288789393391084000fbdbcdcedb11d0b68
trxcon's scheduler is currently emitting DATA.cnf whenever the last
burst of a DATA.req has been transmitted. This sounds logical, but
makes the implementation quite complex. It's even harder to implement
sending of DATA.cnf properly for CSD specific channel modes, which are
to be implemented in a follow-up patch.
The DATA.cnf prims trigger sending of L1CTL DATA.cnf/TRAFFIC.cnf,
which are interpreted as Ready-to-Send by the upper layers (layer23).
Additionally DATA.cnf prims trigger sending of GSMTAP PDUs containing
the respective Uplink frames.
This patch changes the l1sched logic, so that a DATA.cnf primitive
is emitted whenever the respective DATA.req is dequeued and encoded
using the lchan specific channel coding function. This simplifies
the code a lot and prepares for the upcoming CSD support.
As a bonus, this patch fixes an inconsistency between TDMA FNs reported
in Uplink and Downlink GSMTAP PDUs. Now we're indicating the first Fn
in both cases, so Uplink is consistent with Downlink.
Change-Id: Ie09a24cd950a93edd871a9fbc5b47ec96c24cceb
Related: OS#4396, OS#1572
Right now the existing code is switching to state IDLE and hence running
grr_st_packet_idle_onenter() which attempts stuff like starting an attach.
This is all done while the L1CTL RESET + FBSB is still in progress. We
should instead wait to receive confirmation from those.
As an easy implementation for now, simply switch to the
GRR_ST_PACKET_NOT_READY state, which will move to GRR_ST_PACKET_IDLE
once it starts receiving CCCH blocks (aka it will already have gone
through L1CTL RESET + FBSB completely).
Change-Id: Ie797b36701d10c6052500c637a08b061bb1e4bd7
Signal RLC/MAC layer that the lower layers is in packet idle mode ready
to use CCCH (such as packet-access-procedure).
Change-Id: I05050e840a3b267b3b3a278588ee113b45bfbd4c
This works-around a race condition happening when the upper layers
are sending L1CTL RESET.req immediately followed by L1CTL FBSB.req.
The problem is that the TRXC logic is considering the transceiver
powered on until a response to CMD POWEROFF is received.
Change-Id: I967ce047eb198f1eaf8446bb4c1f87a98d3de264
Related: OS#5500
This is needed in order to provide updated TLLI when submitting new user
data from the tundev to the SNDCP layer.
Change-Id: I5c6a2c371ae6d65bf4fe23e665ec939da37112be
In case when an Uplink TCH/[FH]S frame needs to be transmitted, but
there is no frame available in the Tx queue, transmit an intentionally
invalid block with inverted CRC3. This will induce a BFI condition in
the BTS side receiver. See also the related osmo-bts-trx patch.
Change-Id: I16ff09a220da13c2c76538bc43354afc4e688794
Depends: libosmocore.git Iade3310e16b906efb6892d28f474a0d15204e861
Related: osmo-bts.git I78106802a0aa4af39859c75d29fe0e77037899fe
Whenever decoding fails or a FACCH setaling happens, simply send an
empty DATA.ind to the upper layers. On the Uplink path, use a dummy
LAPDm func=UI frame (with random padding) whenever possible.
Crafting TCH frames with zeroes is not really needed and moreover makes
it hard to distinguish between valid speech frames and BFIs. This also
used to be the case for osmo-bts-trx, but not anymore (see the related
patch).
Change-Id: I20391b860fbc2ce8f0f03d7ba95ef7a098c0f9db
Related: osmo-bts.git I8f9fb5b8c5b2cad4b92ac693c0040779f811981a
Unlike FACCH/F, which steals one TCH frame, FACCH/H steals two TCH
frames. This is what prim_dequeue_tchh() aims to implement, but
the current implementation is not 100% correct.
The problem is that we're attempting to dequeue and drop two TCH frames
in one go, whenever we get a FACCH/H frame. Most likely, there will be
no 2nd TCH frame in the Tx queue at that time, so it will never be
dropped and will clog the queue.
Let's replicate what osmo-bts-trx does:
* dequeue and drop the 1st TCH frame when sending 1st/6 burst of FACCH,
* dequeue and drop the 2nd TCH frame when sending 3rd/6 burst of FACCH.
Change-Id: I513d6805ddf97783c002be285fb3ca7893e42377
Related: OS#4396, OS#1572
Centralized dequeueing of Tx prims in l1sched_pull_burst() is a working
approach, but doing this in each logical channel handler individually
is a lot more flexible. This is how it's done in osmo-bts-trx, and
this allows implementing FACCH support for CSD channels.
Change-Id: I3d6c2136ff1855ab0aa9062b20b2a64fd0e5fe28
Related: OS#4396, OS#1572
In ad8f7794 I changed both tx_tch[fh]_fn() to use a switch statement
and introduced a regression by removing special treatment of FACCH:
@@ -238,10 +237,16 @@ int tx_tchf_fn(struct l1sched_lchan_state *lchan,
- if (msgb_l2len(lchan->prim) == GSM_MACBLOCK_LEN) {
- /* Encode payload */
- rc = gsm0503_tch_fr_encode(buffer, msgb_l2(lchan->prim), GSM_MACBLOCK_LEN, 1);
- } else if (lchan->tch_mode == GSM48_CMODE_SPEECH_AMR) {
@@ -459,10 +458,15 @@ int tx_tchh_fn(struct l1sched_lchan_state *lchan,
- if (msgb_l2len(lchan->prim) == GSM_MACBLOCK_LEN) {
- rc = gsm0503_tch_hr_encode(buffer, msgb_l2(lchan->prim), GSM_MACBLOCK_LEN);
- lchan->ul_facch_blocks = 6;
- } else if (lchan->tch_mode == GSM48_CMODE_SPEECH_AMR) {
Now if the channel mode is GSM48_CMODE_SPEECH_AMR, UL FACCH/[FH] frames
will be fed to osmo_amr_rtp_dec(), which is definitely wrong. Fix this
by doing all AMR specific checks in a separate function, which is
called only for speech frames.
Change-Id: Ie217bbb389b5abb95d241781ffe3f5c7b1c188c0
Fixes: ad8f7794 "trxcon/l1sched: remove redundant TCH/[FH] prim length checks"
Related: OS#4396
We need to distinguish between Uplink and Downlink TBF assignment in
grr_rx_imm_ass(), because matching the Request Reference IE makes
sense only for the Uplink TBF assignment.
Uplink TBFs are requested by the UEs by sending RACH, while Downlink
TBFs are assigned by the network itself. The Request Reference IE
is only valid for Uplink assignments and shall be ignored in messages
assigning Downlink TBFs.
Change-Id: Idb9b3203147be3b42256c0bcab3ecdabcf2d2fa9
Related: OS#5500
In change 67943df4 I broke handling of the logging category mask in
the mobile app. Adding this option results in a segfault:
ERROR: osmo_log_info == NULL! You must call log_init() before
using logging in log_parse_category_mask()!
Assert failed osmo_log_info src/libosmocore/src/core/logging.c:329
As can be seen, the problem is that we are calling
log_parse_category_mask() before initializing the logging.
As possible solution, I could rearrange the code to parse command
line options after calling osmo_init_logging2(). This would fix
the segfault, but would not fully solve the problem.
If we call log_parse_category_mask() before parsing the config file,
then logging configuration in the config file overwrites the logging
configuration specified via the command line. But we want the
opposite: the command line setting should overwrite the config file
parameters. This is handy because there is no need to edit the
config file if you quickly need to test something.
So let's call log_parse_category_mask() after parsing the config file.
Change-Id: I1b2b7804bf99b71f96e9197f7824cfd20431e8a1
Fixes: 67943df4 "layer23: fix parsing of command line options"
libosmogsm has recently deprecated the use of osmo_auth_gen_vec
and the osmo_sub_auth_data structure in favor of newer versions
of this API. Let's migrate to it
Change-Id: I1d9751c5f74a59e7310d07d54a3fdbac213324bd
Depends: libosmocore.git Ie775fedba4a3fa12314c0f7c8a369662ef6a40df
Found by clang:
gsm48_cc.c:54:6: warning: logical not is only applied to the left
hand side of this comparison [-Wlogical-not-parentheses]
if (!cc->mncc_upqueue.next == 0)
^ ~~
Change-Id: Ic7ffd3aa25339e24a31bae1b7428f1f93e261858
The idea behind advancing Uplink TDMA Fn is to give the transceiver,
which is usually a separate process, some additional time to receive
and prepare Uplink bursts for transmission. This comes at a price
of having an additional delay between Uplink and Downlink.
Given that trxcon, as a standalone application, is primarily used in
conjunction with fake_trx.py for running ttcn3-bts-test against
osmo-bts-trx, there is no reason to advance the Uplink TDMA Fn.
Change-Id: I838b1ebc54e4c5d116f8af2155d97215a6133ba4
Related: OS#5500
trxcon was heavily inspired by osmo-bts-trx, and among with many other
scheduling related parts also inherited the timer driven clock module.
This clock module is driving the Uplink burst scheduling, just like it
does drive the Downlink burst scheduling in osmo-bts-trx. Just like
in osmo-bts-trx, the clock module relies on periodic CLCK indications
from the PHY, which are needed to compensate for the clock drifting.
The key difference is that trxcon is using Downlink bursts as the CLCK
indications, see 'bi.fn % 51' in trx_data_rx_cb(). This is possible
because the MS is a clock slave of the BTS: the MS PHY needs to sync
its freq. and clock first, and only after that it can Rx and Tx.
So far we've had no problems with the clock module in trxcon until we
started adding GPRS support and integrated the l1gprs. While the CS
domain is quite flexible in terms of timings and delays, the PS domain
is a lot more sensetive to the timing issues.
Sometimes it happens that the trxcon's clock module is ticking quicker
than it should, resulting in Uplink PDCH blocks being scheduled earlier
than the respective Downlink PDCH blocks are received:
20230502021957724 l1sched_pull_burst(): PDTCH/U Tx time (fn=56103)
20230502021957744 (PDCH-7) Rx DL BLOCK.ind (fn=56103, len=23): ...
20230502021957747 l1sched_pull_burst(): PDTCH/U Tx time (fn=56108)
20230502021957765 l1sched_pull_burst(): PDTCH/U Tx time (fn=56112)
20230502021957767 (PDCH-7) Rx DL BLOCK.ind (fn=56108, len=23): ...
20230502021957768 (PDCH-7) Rx UL BLOCK.req (fn=56112, len=54): ...
20230502021957784 l1sched_pull_burst(): PDTCH/U Tx time (fn=56116)
20230502021957784 TS7-PDTCH dropping Tx primitive (current Fn=56116, prim Fn=56112)
This is impossible in reality, because Uplink is intentionally lagging
behind Downlink by 3 TDMA timeslot periods. In a virtual setup this
causes sporadic dropping of Uplink PDCH blocks, as can be seen from
the logging snippet above, and significantly degrades the RLC/MAC
performance for GPRS.
Let's remove the internal clock module and trigger the Uplink burst
transmission each time we receive a Downlink burst. This helps to
overcome the GPRS scheduling issues and replicates the approach of
osmo-trx-ms more closely.
Change-Id: Ic8a5b6277c6b16392026e0557376257d71c9d230
Related: OS#5500
Vadim Yanitskiy
Pau Espin
Mychaela N. Falconia
Harald Welte