Project

General

Profile

Actions

Feature #3761

closed

Separate TDMA scheduler into a library (libtdmasched)

Added by fixeria almost 4 years ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
trxcon
Target version:
Start date:
01/20/2019
Due date:
% Done:

100%

Resolution:
Spec Reference:
Tags:

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

Related to OsmocomBB - Feature #5599: trxcon: integrate with osmo-trx-msFeedbackHoernchen07/01/2022

Actions
Actions #1

Updated by ptrkrysik over 3 years ago

  • Target version deleted (Improvement of the higher layers of OsmocomBB)
Actions #2

Updated by laforge 5 months ago

  • Related to Feature #5599: trxcon: integrate with osmo-trx-ms added
Actions #3

Updated by laforge 5 months ago

  • Tags set to ARDC
  • Target version set to SDR based MS
Actions #4

Updated by laforge 5 months 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?

Actions #5

Updated by fixeria 5 months 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!

Actions #6

Updated by fixeria 5 months 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.

Actions #7

Updated by fixeria 5 months 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} and TC_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.

Actions #8

Updated by fixeria 5 months 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} and TC_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.

Actions #9

Updated by fixeria 5 months ago

fixeria wrote in #note-7:

The only missing thing is configurable logging category. Currently libl1sched is using DSCH and DSCHD.

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
Actions #10

Updated by fixeria 4 months 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} and TC_ms_pwr_ctrl_{constant,pf_ewma} fail.

I created https://osmocom.org/issues/5635 to track this.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)