Hi,
I am trying to develop a mobile loop (uplink) for the receiver in receiver_impl.cc. gr-gsm currently synchronizes, finds the start of a burst, using FCHH and SCHH signals. These are all downlink signals. There is no provision for synchronizing to uplink signals. I was wondering if there were any uplink bursts that the receiver could synchronize to.
I can try to synchronize with autocorrelation of the training sequence, but I was wondering whether there are any better options out there. Any help would be appreciated.
TIA Nikos
Hi Nikos,
On Thu, Jul 21, 2022 at 03:32:26AM +0300, Nikos Balkanas wrote:
I am trying to develop a mobile loop (uplink) for the receiver in receiver_impl.cc.
Despite working in GSM related development for a long time, I'm not sure what a 'mobile loop (uplink)' is.
In any case, if you want to receive uplink signals you are building a BTS, and there is a robust, fully working (and production deployed) GSM BTS-side receiver in osmo-trx https://osmocom.org/projects/osmotrx/wiki/OsmoTRX
gr-gsm currently synchronizes, finds the start of a burst, using FCHH and SCHH signals. These are all downlink signals. There is no provision for synchronizing to uplink signals.
Yes. While I am not an author of gr-gsm, the entire point of the project was to implement the mobile station (MS) side, as for the BTS side there were long known and working implementations in both the OpenBTS, and later OsmoTRX/BTS and YateBTS projects.
Hi Harald,
From my understanding, gr-gsm architecture is entirely different than a BTS. In a BTS you are P2P connected to the mobile over a dedicated frequency. Timing is strictly controlled there and there is no need to find the start of the burst. Much like in a client-server architecture BTS issues a request and waits for the answer over a dedicated channel (socket) gr-gsm works more like tcpdump, except that packets are in purpose obfuscated, the medium is spread out and with errors. That makes it easier to listen to, than in tcpump, where actually you have to "sit" on the same cable, but more difficult to understand it.
It will be much easier to implement than a BTS, since I don't have to implement the whole spec, just listen and display a few bursts. For GSM these are only half a dozen, and are already implemented:) Listening to uplink traffic is different than receiving it. It just completes gr-gsm's original function. Much like tcpdump, listening to traffic, doesn't make tcpdump either a client or a server;-)
BR Nikos
On Thu, Jul 21, 2022 at 8:10 AM Harald Welte laforge@osmocom.org wrote:
Hi Nikos,
On Thu, Jul 21, 2022 at 03:32:26AM +0300, Nikos Balkanas wrote:
I am trying to develop a mobile loop (uplink) for the receiver in receiver_impl.cc.
Despite working in GSM related development for a long time, I'm not sure what a 'mobile loop (uplink)' is.
In any case, if you want to receive uplink signals you are building a BTS, and there is a robust, fully working (and production deployed) GSM BTS-side receiver in osmo-trx https://osmocom.org/projects/osmotrx/wiki/OsmoTRX
gr-gsm currently synchronizes, finds the start of a burst, using FCHH and SCHH signals. These are all downlink signals. There is no provision for synchronizing to uplink signals.
Yes. While I am not an author of gr-gsm, the entire point of the project was to implement the mobile station (MS) side, as for the BTS side there were long known and working implementations in both the OpenBTS, and later OsmoTRX/BTS and YateBTS projects.
--
- Harald Welte laforge@osmocom.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
-
Harald Welte -
Nikos Balkanas