Hi Piotr,
I just wrote a simple (more or less working) GNURadio block for connection with OsmocomBB. It is named "TRX Interface" and currently only capable to transform (in Osmocom bursts are followed by a bit different header) and send received bursts through the UDP link.
If you remember, I had a problem with UDP source port. So, I spent some time and finally solved this challenge. My first idea was to inherit the existing 'Socket PDU' implementation and I started to look for a way I could do that. After a few minutes of searching, I have found your mails with the same question, and a brief answer from Sylvain, that it is impossible :(
So, I have copied actual implementation, stripped out everything related to TCP and implemented a feature to set UDP source port. Now I am able to receive all DL bursts, coming from GR-GSM to my trxcon application.
At the moment I am working on TDMA scheduler, which is almost finished. It's time to start writing GR-GSM blocks for burst transmission. The following thoughts / questions are in my mind:
- TX should be simpler than RX, because we don't need to detect bursts and correct any errors.
- Both receiver and transmitter should be time synchronized. I think, the SCH clock from the 'GSM Receiver' block may be easily shared. Moreover, actual clock indications could be forwarded to my block.
- If I am correct, to transmit a burst, one should be converted to symbols. How can we do that?
- We cannot simply use the existing 'GMSK Mod' block, because GSM uses TDMA. Right? If so, point me to the right direction.
P.S. This message is posted at the baseband-devel mailing list.
With best regards, Vadim Yanitskiy.
Hi Vadim,
I'm very happy to hear from you again.
Sorry for the long delay. I don't know why I don't see your e-mail addressed to me in my e-mail client.
W dniu 22.06.2017 o 15:11, Vadim Yanitskiy pisze:
Hi Piotr,
I just wrote a simple (more or less working) GNURadio block for connection with OsmocomBB. It is named "TRX Interface" and currently only capable to transform (in Osmocom bursts are followed by a bit different header) and send received bursts through the UDP link.
(...)
So, I have copied actual implementation, stripped out everything related to TCP and implemented a feature to set UDP source port. Now I am able to receive all DL bursts, coming from GR-GSM to my trxcon application.
At the moment I am working on TDMA scheduler, which is almost finished. It's time to start writing GR-GSM blocks for burst transmission. The following thoughts / questions are in my mind:
It's great that you figured it out. I'm more than interested to help you to push this topic forward. Will you be able to tell me how to compile and run the software so I will be able to test it on my side?
- TX should be simpler than RX, because we don't need to detect bursts and correct any errors.
Yes, from point of view of digital signal processing TX is much simpler.
- Both receiver and transmitter should be time synchronized. I think, the SCH clock from the 'GSM Receiver' block may be easily shared. Moreover, actual clock indications could be forwarded to my block.
To answer this I will need to know more about what hardware you plan to use to receive and transmit. With i.e. USRP on a hardware level you have the synchronization. If you plan to use RTL-SDR + some transmitter then we will probably need some way to provide synchronization at a hardware level too. As for GSM Receiver - it sends bursts together with GSMTAP header which contains frame number. So you can identify bursts.
If I am correct, to transmit a burst, one should be converted to symbols. How can we do that?
We cannot simply use the existing 'GMSK Mod' block, because GSM uses TDMA. Right? If so, point me to the right direction.
We will need to write some modulator for bursts. We can adapt the code from osmo-trx or use portion of the code from GMSK Mod block. Using GMSK Mod block might not be a good idea because of 8.25 symbols long guard periods between bursts. The quater bit long shifts might be a problem.
Can you tell me what you would like to do on OsmocomBB side and what to do on the GNU Radio side? I'm asking because have some idea how to make a low level part of GSM TRX in GNU Radio.
What hardware you want to use (RTL-SDR to receive and Calypso phone to transmit)?
Hi Piotr,
I'm very happy to hear from you again.
Glad to see you too!
It's great that you figured it out. I'm more than interested to help you to push this topic forward. Will you be able to tell me how to compile and run the software so I will be able to test it on my side?
Thanks! I definitely need to create a page on wiki about that. This is a brief guideline how to run OsmocomBB on SDR:
1) You will need to clone a fork of GR-GSM from GitHub: https://github.com/axilirator/gr-gsm/tree/fixeria/trx I am going to send a pull request, as soon as I finish some things and clean up the code according to your requirements.
2) Build GR-GSM as usually, and you will see a new GNURadio block named 'TRX Interface' in gnuradio-companion.
3) Clone my branch of OsmocomBB: git clone git://git.osmocom.org/osmocom-bb -b fixeria/sdr_phy
4) Make sure you have a fresh version of libosmocore, and build OsmocomBB without firmware (we don't need it anymore):
cd osmocom-bb/src/ make nofirmware
5) Go to the 'apps/trx/' directory, and launch the 'grgsm_trx.py' application. One will init a simple follow graph and actual TRX interface.
6) Go to the 'osmocom-bb/src/host/trxcon/' directory, and run the 'trxcon' application, which is used to connect OsmocomBB L2&3 applications with transceiver application.
./trxcon -d DAPP:DL1C:DSCH
7) Go to the 'osmocom-bb/src/host/layer23/src/misc/' directory and run the 'ccch_scan' application, and you will see how it actually works ;)
./ccch_scan -a ARFCN -i 127.0.0.1
To answer this I will need to know more about what hardware you plan to use to receive and transmit. With i.e. USRP on a hardware level you have the synchronization. If you plan to use RTL-SDR + some transmitter then we will probably need some way to provide synchronization at a hardware level too. As for GSM Receiver - it sends bursts together with GSMTAP header which contains frame number. So you can identify bursts.
I think, exactly devices like USRP should be our primary hardware platform. I use UmTRX - USRP based board, designed exactly for mobile networks. At the same time, I would prefer to keep in mind further possibility to use the project with separate RX and TX hardware.
We will need to write some modulator for bursts. We can adapt the code from osmo-trx or use portion of the code from GMSK Mod block. Using GMSK Mod block might not be a good idea because of 8.25 symbols long guard periods between bursts. The quater bit long shifts might be a problem.
Yeah, I had a little discussion on #gnuradio IRC, and some guy consulted me a bit. One problem, we will probably deal with, is GNURadio scheduling engine and block buffers. At the same time, the trxcon application can send TX bursts in advance. As much frames before as it's required to normal TX operation. This is how OsmoBTS does.
He also described an exemplary algorithm of TX operation:
1) Take in your bits (burst) 2) Up sample 3) Pulse shape with an interpolating fir filter with a Gaussian response 4) Feed that into a frequency modulation operation with the correct gain 5) Then channel filter those with an FFT filter 6) Use a frequency rotator of you need to freq shift the signal within your DSP bandwidth 7) And perform a final up sampling and antialias filter before TX.
What do you think?
Can you tell me what you would like to do on OsmocomBB side and what to do on the GNU Radio side? I'm asking because have some idea how to make a low level part of GSM TRX in GNU Radio.
OsmocomBB's side does all burst transcoding operations itself, so we only need to modulate and send requested bursts in time. We will also need to perform power measurements, but let's focus on TX for now.
What hardware you want to use (RTL-SDR to receive and Calypso phone to transmit)?
No, we need to build a Calypso independent PHY for OsmocomBB. See my answer above.
With best regards, Vadim Yanitskiy.
Hi Vadim & Piotr!
I've managed to get ccch_scan working with a RTL-SDR using Vadim instructions and this container I've created: https://hub.docker.com/r/pachulo/xenial-gr-gsm-osmocombb/
With something like this to start a container: docker run --device=/dev/bus/usb/002 -it --name test-osmocombb-trx pachulo/xenial-gr-gsm-osmocombb
And something like this to get more consoles inside the container: docker exec -ti test-osmocombb-trx /bin/bash
Thanks for this great addition to OsmocomBB & GR-GSM!
On Sun, Jul 16, 2017 at 7:00 PM, Vadim Yanitskiy axilirator@gmail.com wrote:
Hi Piotr,
I'm very happy to hear from you again.
Glad to see you too!
It's great that you figured it out. I'm more than interested to help you to push this topic forward. Will you be able to tell me how to compile and run the software so I will be able to test it on my side?
Thanks! I definitely need to create a page on wiki about that. This is a brief guideline how to run OsmocomBB on SDR:
You will need to clone a fork of GR-GSM from GitHub: https://github.com/axilirator/gr-gsm/tree/fixeria/trx I am going to send a pull request, as soon as I finish some things and clean up the code according to your requirements.
Build GR-GSM as usually, and you will see a new GNURadio block named 'TRX Interface' in gnuradio-companion.
Clone my branch of OsmocomBB: git clone git://git.osmocom.org/osmocom-bb -b fixeria/sdr_phy
Make sure you have a fresh version of libosmocore, and build OsmocomBB without firmware (we don't need it anymore):
cd osmocom-bb/src/ make nofirmware
Go to the 'apps/trx/' directory, and launch the 'grgsm_trx.py' application. One will init a simple follow graph and actual TRX interface.
Go to the 'osmocom-bb/src/host/trxcon/' directory, and run the 'trxcon' application, which is used to connect OsmocomBB L2&3 applications with transceiver application.
./trxcon -d DAPP:DL1C:DSCH
Go to the 'osmocom-bb/src/host/layer23/src/misc/' directory and run the 'ccch_scan' application, and you will see how it actually works ;)
./ccch_scan -a ARFCN -i 127.0.0.1
To answer this I will need to know more about what hardware you plan to use to receive and transmit. With i.e. USRP on a hardware level you have the synchronization. If you plan to use RTL-SDR + some transmitter then we will probably need some way to provide synchronization at a hardware level too. As for GSM Receiver - it sends bursts together with GSMTAP header which contains frame number. So you can identify bursts.
I think, exactly devices like USRP should be our primary hardware platform. I use UmTRX - USRP based board, designed exactly for mobile networks. At the same time, I would prefer to keep in mind further possibility to use the project with separate RX and TX hardware.
We will need to write some modulator for bursts. We can adapt the code from osmo-trx or use portion of the code from GMSK Mod block. Using GMSK Mod block might not be a good idea because of 8.25 symbols long guard periods between bursts. The quater bit long shifts might be a problem.
Yeah, I had a little discussion on #gnuradio IRC, and some guy consulted me a bit. One problem, we will probably deal with, is GNURadio scheduling engine and block buffers. At the same time, the trxcon application can send TX bursts in advance. As much frames before as it's required to normal TX operation. This is how OsmoBTS does.
He also described an exemplary algorithm of TX operation:
- Take in your bits (burst)
- Up sample
- Pulse shape with an interpolating fir filter with a Gaussian response
- Feed that into a frequency modulation operation with the correct gain
- Then channel filter those with an FFT filter
- Use a frequency rotator of you need to freq shift the signal within your DSP bandwidth
- And perform a final up sampling and antialias filter before TX.
What do you think?
Can you tell me what you would like to do on OsmocomBB side and what to do on the GNU Radio side? I'm asking because have some idea how to make a low level part of GSM TRX in GNU Radio.
OsmocomBB's side does all burst transcoding operations itself, so we only need to modulate and send requested bursts in time. We will also need to perform power measurements, but let's focus on TX for now.
What hardware you want to use (RTL-SDR to receive and Calypso phone to transmit)?
No, we need to build a Calypso independent PHY for OsmocomBB. See my answer above.
With best regards, Vadim Yanitskiy.
baseband-devel@lists.osmocom.org
-
Marc Peña Segarra -
Piotr Krysik -
Vadim Yanitskiy