Receiver: hard-coded GSM 05.02 channel configuration
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...
#2 Updated by fixeria over 1 year 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:
Also, trxcon is capable to send 'SETSLOT <TS> <TYPE>' command, which
AFAIR contains exactly a channel combination number...
#4 Updated by ptrkrysik over 1 year ago
In my opinion all the receiver should care is if it should expect in a
-normal burst or dummy burst,
-normal burst or nothing,
We can use the combinations as a set of predefined configurations of
burst types, but I wouldn't limit the receiver to those.
- 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:
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
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.
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.