Feature #3761
closedSeparate TDMA scheduler into a library (libtdmasched)
Added by fixeria about 5 years ago. Updated over 1 year ago.
100%
Description
The current TDMA scheduler implementation is tightly integrated with both L1CTL and TRX interfaces, i.e. Downlink frames are being passed to the L1CTL handler, and Uplink bursts are being sent to the TRX interface handler. This is one of the reasons why we don't have even basic unit test coverage.
As the primary solution, I suggest to abstract the scheduler from both interfaces (by extending the existing prim API), and create a separate library (libtdmasched, libgsmsched?), so trxcon application could be linked against it, as well as the further unit tests.
Related issues
Updated by ptrkrysik almost 5 years ago
- Target version deleted (
Improvement of the higher layers of OsmocomBB)
Updated by laforge almost 2 years ago
- Related to Feature #5599: trxcon: integrate with osmo-trx-ms added
Updated by laforge almost 2 years ago
- Tags set to ARDC
- Target version set to SDR based MS
Updated by laforge almost 2 years ago
- Status changed from New to In Progress
21:24 < fixeria> I am currently working on osmocom-bb. In particular, I am separating the scheduler from
trxcon into a shared library (so that osmo-trx-ms can be linked against it).
21:25 < fixeria> all symbols exposed by the new library (libosmobb-l1sched.so) need to be prefixed somehow
21:26 < fixeria> so I would like to know your oppinion, what looks better: 'osmo_bb_l1sched_' or
'osmobb_l1sched_'?
21:27 < fixeria> and does it really make sense to have 'bb' in the prefix?
As you were not online in IRC, I'm responding here: I would think it makes sense to call it 'ms' e.g. osmo_ms_l1sched?
Updated by fixeria almost 2 years ago
laforge wrote in #note-4:
As you were not online in IRC, I'm responding here: I would think it makes sense to call it 'ms' e.g. osmo_ms_l1sched?
'osmo_ms_l1sched' looks good to me, thanks!
Updated by fixeria almost 2 years ago
- % Done changed from 0 to 90
After a week of intensive work, I think I am done with separating the scheduler:
https://cgit.osmocom.org/osmocom-bb/log/?h=fixeria/libl1sched
Below are some notes for Hoernchen regarding the integration with osmo-trx-ms.
After the usual sequence of autoreconf/configure/make you'll find libl1sched.a in ./src/.libs/. Yes, this is not a shared library yet, because so far I have been mostly working on refactoring code and making the API abstract from L1CTL/TRXC/TRXD and even from GSMTAP.
You'll need to implement the following functions:
/* External L1 API, must be implemented by the API user */
int l1sched_handle_config_req(struct l1sched_state *sched,
const struct l1sched_config_req *cr);
int l1sched_handle_burst_req(struct l1sched_state *sched,
const struct l1sched_burst_req *br);
/* External L2 API, must be implemented by the API user */
int l1sched_handle_data_ind(struct l1sched_lchan_state *lchan,
const uint8_t *data, size_t data_len,
int n_errors, int n_bits_total,
enum l1sched_data_type dt);
int l1sched_handle_data_cnf(struct l1sched_lchan_state *lchan,
uint32_t fn, enum l1sched_data_type dt);
Like it's done in the trxcon app: https://cgit.osmocom.org/osmocom-bb/tree/src/host/trxcon/src/trxcon.c?h=fixeria/libl1sched&id=f3bbdd6620b50a0fa3dc239a0bea9013cd3a62d6#n105. Both l1sched_handle_data_ind() and l1sched_handle_data_cnf() can be simply copy-pasted, because osmo-trx-ms will be using L1CTL too.
Let me know if I can help you with that.
Updated by fixeria almost 2 years ago
I gave ttcn3-bts-test a run and found the following regressions:
- Segmentation fault when trying to send L1CTL FBSB.conf message (fixed).
- Sending L1 SACCH header = { 0x00, 0x00 } in cached SACCH PDUs.
- You'll see "FIXME: no direct access to trx->{tx_power,ta}" during compilation.
- Makes
TC_rsl_ms_pwr_dyn_{ass_updown,max}andTC_ms_pwr_ctrl_{constant,pf_ewma}fail.
Other than that everything seems to work as before.
The only missing thing is configurable logging category. Currently libl1sched is using DSCH and DSCHD.
Updated by fixeria almost 2 years ago
fixeria wrote in #note-7:
- Sending L1 SACCH header = { 0x00, 0x00 } in cached SACCH PDUs.
- You'll see "FIXME: no direct access to trx->{tx_power,ta}" during compilation.
- Makes
TC_rsl_ms_pwr_dyn_{ass_updown,max}andTC_ms_pwr_ctrl_{constant,pf_ewma}fail.
Correction: this is actually the case for dummy Measurement Reports composed by trxcon itself, not for the cached ones.
Updated by fixeria over 1 year ago
fixeria wrote in #note-7:
The only missing thing is configurable logging category. Currently libl1sched is using
DSCHandDSCHD.
https://gerrit.osmocom.org/c/osmocom-bb/+/28743 trxcon: move osmocom/bb/{trxcon->l1sched}/l1sched.h [NEW]
https://gerrit.osmocom.org/c/osmocom-bb/+/28744 trxcon: make l1sched logging configurable, append trxcon->fi prefix
commit 035b5d2e27909de435da4f638742bc7add0593f5
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Fri Jul 22 07:21:11 2022 +0700
trxcon: make l1sched logging configurable, append trxcon->fi prefix
This change adds struct l1sched_cfg, which needs to be passed to
l1sched_alloc(). This structure allows to configure logging
categories for common and data messages, as well as a logging
context callback. The later is used to prepend some context to
the l1sched related logging: let's use trxcon->fi for that.
Change-Id: I26da1a506b02502a3a6a887533c35fb09c13c429
Related: OS#5599, OS#3761
Updated by fixeria over 1 year ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
All patches have been merged, so this ticket can be closed.
fixeria wrote in #note-7:
I gave ttcn3-bts-test a run and found the following regressions:
- Sending L1 SACCH header = { 0x00, 0x00 } in cached SACCH PDUs.
- You'll see "FIXME: no direct access to trx->{tx_power,ta}" during compilation.
- Makes
TC_rsl_ms_pwr_dyn_{ass_updown,max}andTC_ms_pwr_ctrl_{constant,pf_ewma}fail.
I created https://osmocom.org/issues/5635 to track this.
