21 Jul
2022
21 Jul
'22
8:20 a.m.
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(a)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(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)