Project

General

Profile

Actions

Feature #3423

open

Receiver: hard-coded GSM 05.02 channel configuration

Added by fixeria over 5 years ago. Updated 8 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...

Actions #1

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 #2

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 #3

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 #4

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 #5

Updated by fixeria about 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 #6

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

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 #8

Updated by ptrkrysik 9 months ago

  • Status changed from Stalled to Closed
Actions #9

Updated by fixeria 8 months ago

  • Project changed from gr-gsm to OsmocomBB SDR PHY
  • Status changed from Closed to Stalled
  • Assignee deleted (ptrkrysik)
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)