Feature #3423
openReceiver: hard-coded GSM 05.02 channel configuration
20%
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...
Updated by ptrkrysik about 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.
Updated by fixeria about 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...
Updated by fixeria about 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'...
Updated by ptrkrysik about 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.
Updated by fixeria over 4 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
Updated by ptrkrysik over 4 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.
Updated by fixeria over 4 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.
