Feature #3423: Receiver: hard-coded GSM 05.02 channel configuration - OsmocomBB SDR PHY - Open Source Mobile Communications

Custom queries

all-by-project

Actions

Copy link

Feature #3423

open

Receiver: hard-coded GSM 05.02 channel configuration

Added by fixeria over 5 years ago. Updated 10 months ago.

Status:

Stalled

Priority:

Normal

Assignee:

Target version:

Start date:

07/27/2018

Due date:

% Done:

20%

Spec Reference:

Description

Unlike OsmoTRX, it's impossible to configure the desired channel configuration.
Please see GSM 05.02, section 6.4 "Permitted channel combinations".

In order to reduce the recourse consumption, it makes sense to implement some API,
which would allow both initial and dynamic timeslot configuration...

History
Notes
Property changes

Actions

Copy link

Updated by ptrkrysik over 5 years ago

Just a note that in my opinion we more need to be able to configure what
is configuration of burst types in given timeslot. We don't need to
inform it what exact logical channel types are bound to given timeslot.

Actions

Copy link

Updated by fixeria over 5 years ago

Well, I think e.g. this 'FCCH+SCH+CCCH+BCCH' combination clearly defines
which types of bursts we would expect on a given timeslot...

This is already implemented in OsmoTRX, have a look:

https://git.osmocom.org/osmo-trx/tree/Transceiver52M/Transceiver.h#n131
https://git.osmocom.org/osmo-trx/tree/Transceiver52M/Transceiver.cpp#n411

Also, trxcon is capable to send 'SETSLOT <TS> <TYPE>' command, which
AFAIR contains exactly a channel combination number...

Actions

Copy link

Updated by fixeria over 5 years ago

For sure, we may also implement an advanced channel combination option, which
would allow to specify required burst types manually, e.g. 'sb,fb,nb'...

Actions

Copy link

Updated by ptrkrysik over 5 years ago

In my opinion all the receiver should care is if it should expect in a
given timeslot:
-normal burst
-normal burst or dummy burst,
-normal burst or nothing,
-FCCH,
-SCH.

We can use the combinations as a set of predefined configurations of
burst types, but I wouldn't limit the receiver to those.

Actions

Copy link

Updated by fixeria over 5 years ago

Tracker changed from Bug to Feature
Status changed from New to Stalled
% Done changed from 0 to 20

Initial work can be found in a separate branch: https://git.osmocom.org/gr-gsm/log/?h=fixeria/mf_config

As it turns out, indicating a channel combination alone is not enough, because unlike the BTS, we don't
need to detect and demodulate bursts on all logical channels of a given timeslot configuration.
So, I am not sure if the current API is exactly what we need, it's too low level...

A possible solution is to define the most useful channel combinations from GSM 05.02 in Receiver,
either as it's done in trxcon and osmo-bts, or as it's done in the firmware of OsmocomBB:

https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_mframe.c
https://git.osmocom.org/osmocom-bb/tree/src/target/firmware/layer1/mframe_sched.c

and introduce a new TRXC command, that will be used to activate or deactivate particular
logical channels, e.g.:

SETLCHAN <TS> <LCHAN> <STATE>

SETLCHAN 0 FCCH 1
SETLCHAN 0 SCH 1
SETLCHAN 0 CCCH 1

SETLCHAN 1 TRXC_SACCH4_3 0
SETLCHAN 1 TRXC_SDCCH4_3 1

Actions

Copy link

Updated by ptrkrysik about 5 years ago

Receiver is a low level creature and it will have low level interface.
The entity that controls it will know about combinations that make sense
in current GSM networks.

However current API needs extension with ability to tell when (for which
frame number) change should take place.

Actions

Copy link

Updated by fixeria about 5 years ago

Ok, I am agree with you. There is no need to overload the Receiver with GSM 05.02 channel combinations, we can offload this to grgsm_trx or even to trxcon. Please see my initial (hackish and draft) attempt: https://git.osmocom.org/gr-gsm/log/?h=fixeria/mf_config.

Actions

Copy link