The GSM Software Project

CURRENT ACTIVITIES (2008-04-04): 
 1. Merging gsmsp's channel decoding and gsmdecode into gsm-tvoid (2008-04-04 DONE)
 1. Implementing channel hopping on USRP chip 

1. LICENSE

              GSM Software Project License
                 Version  1, January 2007

All code, information or data [from now on "data"] available from the GSM Software Project or any other project linked from this or other pages is owned by the creator who created the data. The copyright, license right, distribution right and any other rights lies with the creator.

It is prohibitied to use the data without the written agreement of the creator. This included using ideas in other projects (commercial or not commercial).

Where data was created by more than 1 creator a written agreement from each of the creators has to be obtained.

If the creator decides to release the data under a difference license (like GPL) then he is free to do so. This license is for all data not covered by a license.

Please contact steve [at] segfault.net for any questions.

2. About

2.1. What we want to do

We want to bring together all the folks that are interested in building a gsm receiver.

GSM is the worlds largest mobile phone standard. GSM 2.5 is currently in use and some countries are (slowly) migrating to GSM 3 (3G, UMTS, ..).

Available GSM analyzer cost a shitload of money for no good reason. Our goal is to build a GSM analyzer for less than $1000.

From there we have an unlimited number of possibilties of what we can do:

  1. Understand GSM and verify the implementation and what kind of data is flying through the ether.
  2. Analyzing debug traces from dct3 mobiles See DCT3 Debug Trace Project.

  3. Track/Locate a gsm mobile. This can be done with just 1 (!) GSMSP receiver.

  4. Crack A5 and proof to the public that GSM is insecure. See A5 Cracking Project.

  5. Create our own baby cells. Imagine running your own BaseStation in your house, university campus, convention or local area. Calling inside the baby cell would be free and calling others via an asterisk/skype gateway would be extremly cheap.

  6. Analyze and learn about OTA messages that the operator use to upgrade our phones (without our knowledge). (That's sim toolkit, ringtones, logos, ...)
  7. We can detect if a GSM MitM attack is happening in our area. (e.g. we can detect if somebody else is sniffing a conversation in a 7+ miles radius).

A seperate Project is designing their own RF board to receive GSM signals. Please take a look at http://wiki.thc.org/gsm/rfboard.

2.2. Who we are

This is a research project by people who feel passionate about GSM and gnuradio. We started this because we could not find a site where people can share ideas about homebuild GSM receivers/scanners and we think gsm software receivers are a cool thing to have. And DECT too...

2.3. Howto use this site

There is a mailinglist for discussions. To subscribe send an empty email to gsm-subscribe@lists.segfault.net .

To retrieve an archive please send a mail to gsm-get@lists.segfault.net for the last 30 messages. Please read the ezmlm howto for other commands.

Please feel free to edit this page and add your comments and ideas. Please start your comments with "(yyyy/mm/dd, name, comment here)".

Use our web-share at http://www.segfault.net/gsm/resources to upload and share files with others.

There are some photos online at http://wiki.thc.org/gsm/photos.

2.4. Contact

I can be reached at steve at segfault.net. (PGP Key)

Some of us are hanging out on the freenode IRC channel #gnuradio and #gsm.

2.5. Legal Issues

I have consulted a lawyer in London to find out if what we do is legal or not. These are the results:

There is no direct law that forbids what we are doing (Companies like Nokia and Sagem are doing exactly the same: Manufacturing GSM scanners that anyone (!) can buy). These are the legal implications in UK:

  1. Security Research in general is not forbidden.
  2. Designing a GSM receiver is ALLOWED (Nokia does it. Sagem does it).
  3. Publishing the design/research is ALLOWED.
  4. Receiving GSM signals is ALLOWED.
  5. Decoding (e.g. cracking) your own GSM signals is ALLOWED
  6. Decoding somebodys else GSM signals is NOT allowed (DANGER).
  7. Setting up a baby cell is allowed if you aquire a license (Any bank building in Canary Warf/London runs its own GSM baby cell).

The bottom line is: Publishing the research is ok. As long as you receive your own traffic and only send after you got the license you are on good ground.

This is based on UK law. European law is similiar (if not more relaxed). USA law might be completly different and I highly advice to check with a lawyer. If you do so please let me know the results.

3. NEWS

4. The Projects

This wiki started as a project for receiving GSM signals. Over time many other projects surfaced. Each of the projects deserves its own wiki. A short description and link to the wiki are listed here.

4.1. The GSM Receiver Project

Location: http://wiki.thc.org/gsm
This project is about receiving GSM signals using the USRP.

4.2. The GSM Sending and Channel Hopping Project

Location: http://wiki.thc.org/gsm/tx
This project is about sending GSM signals using the USRP and implementing channel hopping for receiving.

4.3. The OpenTsm Project

Location: http://wiki.thc.org/gsm/opentsm
Its goal is to modify the firmware of the Vitel TSM30 mobile phone. It will enable us to receive (trace) and send traffic and have fund with the mobile network.

4.4. The A5 Cracking Project

Location: http://wiki.thc.org/cracking_a5
The project is about cracking (decrypting) the A5/1 encryption algorithm used in GSM.

4.5. The GSM Decoding Project

Location: http://wiki.thc.org/gsm/decode
The project is about decoding and converting data from the Traffic CHannle (TCH). The project's goal is to convert the speech channel data into PCM/WAV/MP3 and the SMS data into text files.

4.6. The Debug Trace Project

Location: http://wiki.thc.org/gsm/debugtrace
The project is about using a nokia 3310 or similiar phone and turning it into a trace mobile. The webpage lists examples traces. Please submit interesting traces.

4.7. The SimCom Trace Project

Location: http://wiki.thc.org/gsm/simcom
The project is about using a SIM5210 module to receive debug information from the digital baseband. This debug information includes beacon and possibly TCH traffic.

4.8. The UMTS/3G Project

Location: http://wiki.thc.org/gsm/umts
The project just started and is about how UMTS works. The goal is to receive/send on UMTS and assess the security of UMTS.

4.9. The SIM Tookit Research Project

Locatoin: http://wiki.thc.org/gsm/simtoolkit
The project is about understanding how the SIM works and what's possible with the SIM. It's related to security and applets that are installed remotely (via OTA) by the operator.

5. The GSM/USRP Receiver Project

5.1. Priorities

An overview of our 4 most urgent problems. This chart changes over time. It shows what people are currently doing. (last updated: 2007/04/20).

  1. Viterbi / ISI: This is the single most important stuff people are currently working on. This can either fail the project or make it a success. The mission is to get better (error-free) bit data out of the GSM signal. We are currently suffering from high bit errors.

  2. Channel Hopping: Required if we want to go beyond camping on the BCCH. The theory is there. It has to be tested. (Especially if it's fast enough and/or if we have to flush the USRP buffer?!)

  3. Release: If we pack our source into a release tar-ball other people will be able to play around with it and come back with better ideas.

  4. Misc: Everything not covered above (like channel decoding)

5.2. Wanted

If you can help with any of the items below please contact steve or write on the mailinglist!

  1. Viterbi / ISI help
  2. Comp128v3 source or binary dump from any GSM baseband chip.
  3. GEA / GRPS encryption algorithm or source/binary from any GSM baseband chip.
  4. CDMA documentation.

5.3. Different approaches

I see three different ways to get this done:

  1. Use a commercial baseband transceiver chip (silabs.com? analog.com?). (Requires electronic engineer and those folks seem to be rare).

  2. Use the USRP (Universal Software Radio Peripheral) board from Ettus and develop the rest in software (C++ python) and/or verilog (firmware of USRP). (Still requires electronic engineer /ettus person. We are software developers. Anyone?)

  3. Patch the Baseband Processor of an existing mobile phone (possible but not portable).
  4. Attach the baseband signal of an existing mobile phone to a digitizer (for example the USRP or a simpeler AD/DA converter board with at least 1 Mhz samplerate) (This option is also not very portable and hard to connect to those tiny traces (has been tried). The best shot is using a very old big phone but then you only get the low 900 Mhz band (and not the 1800/1900 Mhz band)) (comment: 3 and 4 are also dead-ends in the long run as we would only be able to receive but certainly never be able to transmit. Both approaches also limit us to 1 channel (not?))
  5. Using a nokia phone or the MC351i from Siemens. For both devices is it possible to update the firmware on the baseband processor. This would mean we would have to disassemble the firmware and do binary patching. Probably limited to 1 channel (but we can use 128 phones at the same time:>). Not as flexible as the USRP.

  6. Use Analog's development board. This way we do not have to bother with DSP and can use example source!

  7. The Sagem OT460 is a trace phone which connects via USB to a PC. It comes with monitoring software. It captures data from the Control Channel (Channel Dm, uplink + downlink) and transfers the captured date in realtime to the PC.

  8. A Watkins Johnson 8691A receiver can trace 6 phone calls at the same time. It requires PC software that is impossible to get. The company currently refused that they even manufactures this device.
  9. The IZT CCT is a commercial multiband receiver with a bandwith of 16 mbit. It's connected via Ethernet. tkrauze@o2.pl is working on this one. We currently believe that the USRP is the cheaper solution but we are keen to compare results.

  10. Using http://www.comblock.com/ hardware to capture data to a IQ file, then using MATLAB and the modified GSMSim scripts to parse the file. Perhaps convert the COMBLOCK IQ file to the format from USRP for use with the GNURadio software. (Comblock setup RF amp >> COM-3006 >> COM-8002 >> COM-5003)

Using USRP and software is the right way to go. Vanu Inc apperently got a software gsm modem working (but not using ettus?!). PC's are fast enough. See gnu-radio list archive and search for Vanu.

What about MAX2323 Eval kit?

5.4. Project Stages and Schedule

and a litte time later a DECT (european standard for cordless phones) receiver. DECT is unencrypted in the most cases.

Comment from a RF engineer: About Stage 1. It seems not too difficult to develop the device that can read from air. Channel switching can be easily done using PLL based LO. The most critical part here is the DSP based GMSK demodulation. Do we have DSP-friendly people here? About Ready-to-use hardware. GSM air interface has very special requirements (band filter, LNA, AGC etc). It is nearly impossible to satisfy them using general purpose RF hardware. As for me, it should be dedicated device. There are two options here: to develop it from zero point using basic blocks (LNA, Mixer, Quadrature decoder etc) OR to use a semi-dedicated ICs which combine some needed functionality. I don't think we can use any of mass-volume GSM-chipset because it will be absolutelly unflexible, thus useless.

2007/01/25 Comment from an electrical engineer: Last year I looked into doing GSM receive operation only, and concluded that the easiest solution would be to use the USRP paired with a suitable RF daughterboard. They have a daughterboard that will tune the PCS band (receive only). The IF bandwidth is wide @ 43 MHz, but the USRP has a very large dynamic range. Also, GMSK is constant envelope, so if the A/D saturates it shouldn't be the end of things. I doubt it would meet all the GSM RF requirements, but it might be close enough to work, albeit with worse noise figure etc. However I remember thinking that the FPGA resources might be too limiting for the high-rate signal processing. More investigation would be necessary.

5.4.1. Receiving Stages

  1. Send signal through low-pass/fir filter
  2. Send filtered signals through GMSK block (already implemented in gnu-radio)
  3. Differentially deocde the bitstream
    - Find FCCH, SCH (get channel config, FrameNumber, ...)
    - 3GPP TS 04.03 MS-BSS interface, Channel structures
    - 3GPP TS 44.004 Layer 1 - General requirements
    - 3GPP TS 04.05 MS-BSS interface, Data Link layer - General aspects
    - 3GPP TS 04.06 MS-BSS interface, Data Link Layer
    - 3GPP TS 44.018 Layer 3 specs - Radio Resource Control (was 04.18, referenced by 04.08)
    - 3GPP TS 45.002 Multiplexing and multiple access on the radio path (was 0502)
    - 3GPP TS 05.03 Channel coding

  4. Concatenate GSM bursts
  5. De-interleave the correct blocks.
  6. Viterbi decode the blocks
  7. Check/Correct bit errors with FIRE code
  8. Parse GSM messages
    - GSM 04.07 Layer 3 - General aspects
    - 3GPP TS 23.108 Layer 3 specs - Core network protocols, stage 2
    - 3GPP TS 24.008 Layer 3 specs - Core network protocols, stage 3

5.4.2. Tips and Tricks

A collection of random tips and tricks.

  1. RF interface
    - EMPTY

  2. Decoding packets I
    - Search for the FCCH before the bits are differentialy decoded. Search for the 64 bit SCH trainigsequence before the differential decoding as well. This speeds up the process. Accepts FCCH's and SCH's with up to 11 bit errors (or even more?).
    - Once you know where the 156 bit bursts start always set the first 3 bit to 0. These first 3 bits are the training bit and ought to be 0. 5% of my received data has a bit error in the training bit. Otherwise the differential decoding process will propagate a bit error in the first 3 bits through the entire burst.
    - Skip dummy bursts (do not differential decode, do not de-interleave, do not convolution decode it).

5.5. Hardware requirements / Where to buy

(Offical approach. Receive only. visit ettus sales.)

Optional Antenna:

Note: A different antenna is required depending on the frequency range. You should have one for GSM900 and another one for GSM1800. The same antenna wont work on both frequency ranges.

5.6. First Steps

GSM Frequencies:

See also GSM/3GPP 05.05 and apicture of gsm frequencies.

Europe used 900Mhz only and later also started to use 1800Mhz. US started with 1900Mhz and later used 850Mhz. 850 Mhz is mostly used in rural areas but sometimes can be found in cities. T-Mobile is not available on the 850Mhz.

The frequency for receiving data from the BTS to the mobile is 45Mhz above the TX frequency.

5.6.1. Understanding GSM

These two articles give a fairly good understanding of how GSM looks like.

  1. http://www.pulsewan.com/data101/gsm_basics.htm

  2. http://www.cs.ucl.ac.uk/staff/t.pagtzis/wireless/gsm/radio.html

Another good article is availabe at http://www2.informatik.hu-berlin.de/~goeller/. I recommend reading the book "Signaling in Mobile Radio Communication" ISBN-10 3-936318-24-7, ISBN-13 978-3-936318-24-1. It comes with a GSM analyzing software (OTDrivePC) and many live off-the-air example traces that can be analyzed with OTDrivePc. It's a real mind-opener.

5.6.2. Beginners Guide to GSM in MatLab

We are proud to release a complete MatLab example and documentation of how to analyze USRP GSM data dumps in MatLab. The Beginners Guide to analzying GSM data in MatLab is part of the toolkit and contains step-by-step instructions on how to use MatLab and how to interpret the decodec GSM bursts.

Toolkit: GSMSP_Analyzing_GSM_data_in_MatLab.zip

This toolkit is based on the fantastic work from Jan and Arne. Please check out their Matlab GSM Simulator as well.

If you need help understanding MatLab please read The MatLab Manual.

5.6.3. Analyzing GSM data in Octave by Piotr

Download: GSMSP_Analyzing_GSM_data_in_Octave.tar.bz2

I've prepared version of "GSMSP Analyzing GSM data in Matlab" which runs under Octave with installed octave-forge functions.

To use it under *buntu you should install gnuplot and octave-forge (it depends on octave2.1). Run command:

$ sudo apt-get install octave-forge gnuplot

My changes:

  1. little changes in plots from plotframe2.m and find_fcch.m
  2. files doing similar things are now placed in their own directories
  3. new function file resample.m written by me - works like this from Matlab. This was needed because resample function from Octave doesn't work with GSMsim.

I think GSMsim is good reference implementation of Viterbi Equalizer for GSM. Tvoid has written already functions which works like this from files find_fcch.m, find_sch.m, calc_freq_offset.m and xlat_freq.m.

I think we can use Viterbi Equalizer which works like this from GSMsim and put it in functions of Tvoid release – in get_sch_burst() and get_norm_burst() (or in equalize()).

Regards

Piotr Krysik

5.6.4. Analyzing BS signals with Gnu Radio

Pawel uploaded a 945.6 Mhz USRP dump(Warsaw).

Screenshot from life application (not the recorded dump above):

  1. Screenshot 1

  2. Screenshot 2

  3. Screenshot 3

On the screenshots we can see frequency correction FCCH packet (only zeros are transmitted), and Training Sequence # 4 (1,1,1,1,0,1,1,0,1,0,0,0,1,0,0,0) in the middle of two different packets.

After fm demodulation block, due to differencial modulation in gsm, we can interpret high value of signal as a repeated bit and lower value of signal as a changed bit. One bit lasts about 3.69 microseconds, so you will have to switch to different scale/div.

Use Pawel's gnu radio script fix to read the data from a file (and not from a live feed).

5.6.5. Challenge 1

This is a challenge and the winner get's a FREE starter kit ($975):

Deadline: Sunday 18th of February 2007

The Challenge:

The one who can identify most frames and information from Robert's samples wins the challenge and gets the FREE USRP Starter Kit.

To take part in the challenge please submit:

to steve at segfault.net before the 18th of February 2007 23:59. Your work will be submitted to the Mailinglist and published on our website (http://www.thc.org/gsm)

I'll announce the winner of the USRP Starter Kit on the 19th!

The next big step is to get it working with gnu-radio.

5.6.5.1. Tore's results

Tore uses MatLab and the GSMsim plugins to extract informations from robert's off-the-air captures. Using the GSMsim plugin helps him to extract a lot of information in a short period of time.

5.6.5.2. Frank J.'s results

Also fank J.'s decides to use MatLab. Here are his results.

5.6.5.3. SignalScamp's results

Here are SignalScamp's Results. He uses MatLab to analyse robert_dbsrx_941.0Mhz_128.cfile. The three graphics show his results.

5.6.6. OT460 Trace Mobile - An Excursion

The Sagem OT460 does not offer the full functionality that we require. It is limited to the GSM Dm channel. Nevertheless it's an exciting device that comes with a powerfull analyzing software.

It has a limited 'transmit' functionality (message forcing). It comes with an average GSM layer1 decoder (trace -> Open all. Select 'layer message' window. Click on any message on the right. Click in menu bar on 'message decoder'. Click 'edit', enter your message and click 'decode')

The Sagem OT460 is a Trace Mobile. It connects to the PC via a USB cable. It can capture live data from the GSM Dm Channel. It captures frames from the entire GSM band at the same time. It comes with software to display and analyize the captures frames. It cost around 3499 EUR and is sold by sagem.com or www.ers.fr.

The OT460 is visible as a COM port under windows. It is possible to write custom software to configure and retrieve information from the OT460. An outdated protocol abstract is available. The full spec of the protocol is available for developers directly from sagem.com (you have to buy a OT460 first).

Dr.-Ing. Joachim Goeller was so friendly to capture some data for us. He used his own tool (EDGEView) to analyze the data and disassemble the packets.

Here is a Screenshot of the OTDrive Capture Software in action.

The first example is a off-the-air capture:

The second example is a capture when a phone was turned on, pin entered and then turned off again:

We might be able to use his EDGEView software to analyze our data as well. We can benchmark our captures against the OT460 device.

EDGEView is the successor of GSMView. GSMView is available on a CD that come with the "Signaling in Mobile Radio Communication" Book.

The EDGEView description files are available at http://www.segfault.net/gsm/EDGEView. The will become handy when we want to parse GSM messages.

5.6.7. Installing GnuRadio / Cygwin

I do not recommend using Windows / cygwin. Use Linux (ubuntu or gentoo) instead. This is a short howto install gnu-radio and usrp under windows / cygwin. If you run into problems please ask me or modify this text.

There are a couple of install guides on the net. They are all incomplete:

  1. http://gnuradio.org/trac/wiki/CygwinInstallMain

  2. http://www.comsec.com/wiki?Cygwin

These are the steps that worked for me:

Extract all source packages to /tmp. Source packages are installed with ./configure, make all install. It only depends on the parameters...

  1. export PATH=$PATH:/usr/local/bin:/usr/local/sbin

  2. export PYTHONPATH=/usr/local/lib/python2.4/site-packages/
  3. Install cygwin with python, swig, pkg-config
  4. install sdcc from http://sdcc.sf.net

  5. Install Boost C++ from http://www.boost.org

  6. Install LibUSB-Win32 to C:\LibUSB-Win32 (libusb-win32-filter-bin-0.1.12.0.exe) (Note: Apperently you can also just install libusb-win from the cygwin setup).
    - cd /cygdrive/c/LibUSB-Win32/src
    - make all
    - cp libusb0.sys libusb0.dll /tmp/gnuradio-3.0.2/usrp
    - now follow USRP Install Guide.

  7. Install Cppunit with this patch
    - cd cppunit-1.10.2; patch -p1 -u <../cppunit-win32.patch
    - ./configure --enable-shared --disable-static
    - make LDFLAGS=-no-undefined all install

  8. Install fftw-3.1.2
    - ./configure
    - make LDFLAGS=-noundefined all install

  9. Install gnuradio-3.0.2.
    - There is a conflict with the max() and min() macros and windows.h include from LibUSB-Win32. Apply this patch.
    - CFLAGS="-I/cygdrive/c/LibUSB-Win32/include" LDFLAGS="-L/cygdrive/c/LibUSB-Win32/lib/gcc" libusbwin32path="/cygdrive/c/LibUSB-Win32/bin" ./configure --with-boost-include-dir=/tmp/boost_1_33_1 --with-md-cpu=generic --disable-static --enable-usrp --enable-gr-usrp
    - make CPPFLAGS="-I/cygdrive/c/LibUSB-Win32/include"
    - make CPPFLAGS="-I/cygdrive/c/LibUSB-Win32/include" install

Use the example from Josh page to test your gnu-radio installation.

5.6.8. NetMonitor

Nokia phones can be used in Monitor mode. The NetMonitor software displays all kind of usefull information. It helps you to find out your current TMSI, the BCH you are on, the distance the the base station, neighbouring cells, signal strength and much more. Search in google for the software or use these links:

I used the netmonitor to confirm which beacon carrier i was able to find and to filter only packets for my TMSI.

edited: Not only Nokia phones can be used in net monitor mode, but majority of phones can be used, just check google or forum.gsmhosting.com about your phone.

5.6.9. BTS searching by Robert

Robert wrote a nice article on how to find a Base station manually using a USRP. His article is available at http://273k.net/gsm/find-a-gsm-base-station-manually-using-a-usrp/. It gives you a good introduction into the tools and some nice graphical results.

5.6.10. Build your own Antenna - by Robert

Robert explains how to build your own GSM antenne at http://273k.net/gsm/designing-and-building-a-gsm-antenna/.

5.7. Design Proposal

We talked via phone to better understand where our problem is and how we can split it into smaller pieces. Below is the email from Achilleas.

I spent some time looking at the Matlab code that was available
on the wiki and the uploaded off-the-air samples.
I think I have a much better understanding of what is going on now.
Here is how I envision a first-cut implementation of a receiver that
processes a single GSM frequency channel from the Base station to
the Mobiles.
1) The outermost loop (process) acquires FCCH bursts and
uses them to perform rough frequency correction (non-coherent operation)
and rough burst alignement. This process essentially cuts the input
stream into blocks of GUARD+156.25*OSR+GUARD samples (OSR=samples/bit),
each respresenting a burst (padded from left and right so that you don't
miss anything due to missallignment).
2) Next, SCH bursts are used (those follow FCCH bursts after 8 bursts)
for acquisition/tracking/estimation of
a) bit timing
b) channel impulse response
Simple least-squares (LS) channel estimation (oversampled) and
timing estimation (accuracy of 1 sample) can
easily be done here (they worked fine for me).
Both estimates seem to be pretty stable between two SCH
bursts, so at this point I do not even see a need for tracking.
Note1: ISI is significant. Modeling the GMSK signal as a filtered MSK
signal you get channel estimates of the form:
    0.0568
     0.0455
     0.0038
     0.0127
     0.0174
     0.0175
     0.0170
     0.0298
     0.0308
     0.1146
     0.1289
     0.1687
     0.1898
     0.1904
     0.1917
     0.1296
     0.1186
     0.0552
     0.0303
     0.0053
     0.0184
     0.0196
     0.0563
     0.0397
(this is the absolute values of the estimated channel for OSR=4).
Note2: I also noticed a slight drift (successive channel estimates
differing by a constant phase) which suggests that the frequency
correction is not perfect. The result is an unknown phase (almost
constant) within a burst. This was observed both on:
GSMSP_20070204_robert_dbsrx_953.6MHz_64.cfile
GSMSP_20070204_robert_dbsrx_941.0MHz_128.cfile
but not on
GSMSP_20070204_robert_dbsrx_953.6MHz_128.cfile
The SCH burst can be further demodulated to extract the information
about which training sequence is used in this cell.
In fact I was able to find that by simply correlating normal bursts with
all 6 possible training sequences and find the best match, so one can
avoid this step...so that physical layer processing does not depend
on higher layer information (but ultimately this cannot be avoided...)
Once timing information has been extracted (accuracy of 1 sample)
and a channel estimate is there, all other bursts can be processed
in the following way (this also holds for the SCH burst itself):
Matched filtering, symbol-spaced sampling followed by your favorite
detection technique (Viterbi, DFE, etc) to extract the information on
the MSK signal, followed by the differential processing to extract the
actual information bits.
So as a first order of business I see the implementation of 1 and 2a,
2b. I haven't given much thought as to what is the most efficient
way to implement this in gnuradio, but I may do that if I get some time...

5.8. ISI, Timing Recovery and others

This section is all about M&M clock recovery and ISI.

  1. Matched filtering and timing recovery in digital receivers - A good introduction.

  2. Book: Heinrich Meyr; Marc Moeneclaey; Stefan Fechtel: "Digital Communication Receivers : Synchronization, Channel Estimation"

5.9. Viterbi and Channel Estimation and Equalization

Piotr made a collection of documents that help to undestand Viterbi and channel equalization.

  1. How I Learned To Love Trellis. This article was very helpful for me at the beginning. It explains what Inter Symbol Interferences (ISI) are and introduces the concept of detection signals which contain such distortion using Viterbi algorithm.

  2. a MatLab implementation of a GSM Simulation Platform. Great documentation of receiver working in theory and, according to Tore's results, working in practice. Documentation contains brief theory of estimating channel impulse response and MLSE.

  3. GSM Simulator in Octave and Source. Octave is open source software available for everyone and has similar to MATLAB syntax. This implementation doesn't include synchronization (GSMsim has same form of finding first sample in a burst) but it has Least Squares channel estimation (GSMsim uses convolution of received sequence with known training sequence

  4. Equalization in GSM using a priori information. first 30 pages of it contains interesting theory in a straightforward from a especially channel estimation.

  5. 3GPP TS 05.05 "Radio Access Network; Radio transmission and and Reception. some raw data from ETSI regarding this topic, for example typical channel impulse responses in Annex C

  6. Soft output M-algorithm equalizer and trellis-coded modulation for mobile radio communication. Algorithm with reduced complexity.

  7. Adaptive T-Algorithm in MLSD/MLSDE Receivers for Fading Channels. Another reduced-complexity algorithm.

  8. Maximum-Likelihood Sequence Estimation of Digital Sequences in the Presence of Intersymbol Interference. Very theoretical and hard to read article which introduced MLSE detection.

  9. Channel Estimation Modeling. Least squares channel estimation and iterative channel estimation.

  10. http://www2.imm.dtu.dk/pubdb/views/edoc_download.php/2522/pdf/imm2522.pdf. Viterbi in UMTS.

We know of two open source projects that implement the algorithm:

  1. http://www.vovida.org/protocols/gsml/. The GSM Source Module Library (GSML) provides a library of modules which can be used to implement the GSM Signalling protocols.

  2. http://www.wireless3g4free.com/. 100% Software implementation of a UMTS receiver stack using Real Time Linux (RTLinux).

5.10. The Nokia Approach

The main development is happening on the USRP hardware. Nevertheless it seems that significant amount of data can be gathered by using a off the shelf nokia handset. Frank and Saugumas have choosen to investigate further and see what's possible.

TODO:

  1. Can we enable TCH (traffic) frames?
  2. Why do we not see the number that is beeing called in the Call Setup message?

Advantages:

Disadvantages:

In 2003 there was the Blacksphere Project. They reversed the undocumented debug protocol of DCT3 mobile phones. It is possible to enable a debug trace and receive many of the layer2/layer3 frames.

The latest project update to the dct3 debug tracer can be found at http://tudor.rdslink.ro/blacksphere/nokia.htm.

Nokia's Netmonitor can be used on the phone the tune to a certain BTS. It's currently unknown if a *bus command exists to change the tuner to a different frequency.

Gammu is a command line tool which we prefer. There exists also a gui (N-Monitor by Anderas Schmidt) for any DCT3 trace mobile. Please see Nuukiaworld for more details.

This command can be used to enable layer2/layer3 tracing. It generates the file out.xml and a lot of debug output.

gammu --nokiadebug nhm5_587.txt v20-25,v18-19

The out.xml file can then be parsed with gsmdecode:

gsmdecode -x <out.xml

The best mobile for testing is the Nokia 3310. You need a special MBUS data cable (NK-33) available at http://ucables.com/ref/NK-33.

If you are using a USB to SERIAL adapter you must configure it on com1 or com2.

The debug trace forwards most layer2/layer3 frames that the mobile processes. This includes the BCCH on the beacon frequency on the downlink and most frames the mobile sends (uplink). It does not forward TCH (traffic) frames.

Here are two traces.

We have created a sub project for sharing traces. Please take a look at the DCT3 Debug Trace Project and submit your traces to me.

Download: http://www.gammu.org We are using version 1.15.90. To make it work under windows you must install the windows binary and copy the nhm5_587.txt file from the source distribution into your c:\Program Files\Gammu 1.15.90\bin\ directory.

5.10.1. Decoding SMS

This trace was generated with a Nokia DCT3. It's downlink only. A SMS was send from the mobile to the mobile. The decoding was done with gsmdecode-0.2.tar.gz . I only display the relevant information for the receiving part of the SMS. If you are interested in the BCCH messages (BBis format, Immediate Assignment etc etc) please run gsmdecode with the -i command.

The trace file: sms2.xml

The following commands have been used to analyze the sms2.xml file:

gsmdecode -x <sms2.xml >sms2.txt

Some Facts:

Questions:

  1. Are all SMS send encrypted?
  2. Why is the destination length value wrong?
  3. Why do we receive a TMSI realloc message? Coincident?
  4. Why dont we see a AUTH REQ message?
  5. Why does the Paging Response from the BTS contain the IMEI and not the TMSI? This should not happen especially because the MS just send a SMS and the system should know the TMSI by now. IMEIs should not appear on the network!
  6. Negotiation only shows A5/3 and A5/2. What happened to A2/1? How is that negotiated?

SDCCH, Page response Message.

000: 01 73 41 06 27 03 03 33  - 19 81 08 29 64 30 07 01
001: 02 74 66 2b 2b 2b 2b
    0: 01 -------1 Extended Address: 1 octet long
    0: 01 ------0- C/R: Response
    0: 01 ---000-- SAPI: RR, MM and CC
    0: 01 -00----- Link Protocol Disciminator: normal GSM (not Cell Broadcasting)
    1: 73 ------11 Unnumbered Frame
    1: 73 ---1---- P
    1: 73 011-00-- UA frame (Unnumbered achknowledgement)
    2: 41 -------1 EL, Extended Length: yes [FIXME]
    2: 41 ------0- M, segmentation: N
    2: 41 010000-- Length: 16
    3: 06 0------- Direction: From originating site
    3: 06 -000---- 0 TransactionID
    3: 06 ----0110 Radio Resouce Management
    4: 27 0-100111 RRpagingResponse
    4: 27 -x------ Send sequence number: 0
    5: 03 -----011 Ciphering key sequence: 3
    5: 03 -000---- Ciphering key sequence: 0
    6: 03 00000011 MS Classmark 2 length: 3
    7: 33 -01----- Revision Level: Phase 2
    7: 33 ---1---- Controlled early classmark sending: Implemented
    7: 33 -----011 RF power class capability: Class 4
    8: 19 -1------ Pseudo Sync Capability: not present
    8: 19 --01---- SS Screening: Phase 2 error handling
    8: 19 ----1--- Mobile Terminated Point to Point SMS: supported
    8: 19 -----0-- VoiceBroadcastService: not supported
    8: 19 ------0- VoiceGroupCallService: not supported
    8: 19 -------1 MS supports E-GSM or R-GSM: supported
    9: 81 1------- CM3 option: supported
    9: 81 --0----- LocationServiceValueAdded Capability: not supported
    9: 81 ----0--- SoLSA Capability: not supported
    9: 81 ------0- A5/3 not available
    9: 81 -------1 A5/2: available
   11: 29 -----001 Type of identity: IMSI
   12: 64 -------- ID(7/odd): 246037010204766

Note: The Auth Request Message is missing here. Is this because the mobile is already authenticated to the BTS because we send a SMS before?

SDCCH, Cipher Mode Command Message

000: 03 20 0d 06 35 01 2b 2b  - 2b 2b 2b 2b 2b 2b 2b 2b
001: 2b 2b 2b 2b 2b 2b 2b
    0: 03 -------1 Extended Address: 1 octet long
    0: 03 ------1- C/R: Command
    0: 03 ---000-- SAPI: RR, MM and CC
    0: 03 -00----- Link Protocol Disciminator: normal GSM (not Cell Broadcasting)
    1: 20 -------0 Information Frame
    1: 20 ----000- N(S), Sequence counter: 0
    1: 20 ---0---- P
    1: 20 001----- N(R), Retransmission counter: 1
    2: 0d -------1 EL, Extended Length: yes [FIXME]
    2: 0d ------0- M, segmentation: N
    2: 0d 000011-- Length: 3
    3: 06 0------- Direction: From originating site
    3: 06 -000---- 0 TransactionID
    3: 06 ----0110 Radio Resouce Management
    4: 35 00110101 RRciphModCmd
    5: 01 ----000- Cipher: A5/1
    5: 01 -------1 Start ciphering
    5: 01 ---0---- Cipher Response: IMEISV shall not be included

Note: Not sure why next message is a TMSI realloc. Not needed but maybe the BTS decided that it should also assign a new TMSI to the mobile. Good as well.

SDCCH, TMSI Realloc

000: 03 42 35 05 1a 42 f6 30  - 00 04 05 f4 2d 81 fb 3e
001: 2b 2b 2b 2b 2b 2b 2b
    0: 03 -------1 Extended Address: 1 octet long
    0: 03 ------1- C/R: Command
    0: 03 ---000-- SAPI: RR, MM and CC
    0: 03 -00----- Link Protocol Disciminator: normal GSM (not Cell Broadcasting)
    1: 42 -------0 Information Frame
    1: 42 ----001- N(S), Sequence counter: 1
    1: 42 ---0---- P
    1: 42 010----- N(R), Retransmission counter: 2
    2: 35 -------1 EL, Extended Length: yes [FIXME]
    2: 35 ------0- M, segmentation: N
    2: 35 001101-- Length: 13
    3: 05 0------- Direction: From originating site
    3: 05 -000---- 0 TransactionID
    3: 05 ----0101 Mobile Management Message (non GPRS)
    4: 1a 00------ SendSequenceNumber: 0
    4: 1a --011010 TMSI Realloc Command
    5: 42 246      Mobile Country Code
    6: f6 03f      Mobile Network Code
    8: 00 4        [0x0004] Local Area Code
   11: f4 -----100 Type of identity: TMSI/P-TMSI
   12: 2d -------- ID(4/even): 2D81FB3E

SDCCH, SABM (SAPI=3) message:

000: 0f 00 53 19 01 22 01 00  - 07 91 73 60 48 99 91 f9
001: 00 16 04 0b 91 73 60
    0: 0f -------1 Extended Address: 1 octet long
    0: 0f ------1- C/R: Command
    0: 0f ---011-- SAPI: SMS and SS
    0: 0f -00----- Link Protocol Disciminator: normal GSM (not Cell Broadcasting)
    1: 00 -------0 Information Frame
    1: 00 ----000- N(S), Sequence counter: 0
    1: 00 ---0---- P
    1: 00 000----- N(R), Retransmission counter: 0
    2: 53 -------1 EL, Extended Length: yes [FIXME]
    2: 53 ------1- M, segmentation: Y
    2: 53 010100-- Length: 20
    3: 19 0------- Direction: From originating site
    3: 19 -001---- 1 TransactionID
    3: 19 ----1001 SMS messages
    4: 01 00000001 Type: CP-DATA
    5: 22 00100010 Length: 34
    6: 01 00000001 Parameter
    7: 00 00000000 Parameter
    8: 07 00000111 SMSC Address Length: 7
    9: 91 1------- Extension
    9: 91 -001---- International Number
    9: 91 ----0001 Numbering plan: ISDN/telephone (E164/E.163)
   10: 73 -------- Number(6): 37068499199
   16: 00 00000000 TP-MTI, TP-MMS, TP-SRI, TP-UDIH, TP-RP: 0
   17: 16 00010110 Reference number: 22
   18: 04 00000100 Parameter
   19: 0b 00001011 Destination Address Length: 11
   20: 91 1------- Extension
   20: 91 -001---- International Number
   20: 91 ----0001 Numbering plan: ISDN/telephone (E164/E.163)
   21: 73 -------- Number(10): 3706

Note: The 'segmentation' flag is set. Next SABM message is part of this message. I had to decode this message manualle. gsmdecode-0.2 does not support segmentation yet.

SDCCH: SABM (SAPI=3) message [continued]

000: 0f 02 45 67 95 67 f6 00  - 00 70 40 21 02 63 43 21
001: 03 61 f1 18 2b 2b 2b
    0: 0f -------1 Extended Address: 1 octet long
    0: 0f ------1- C/R: Command
    0: 0f ---011-- SAPI: SMS and SS
    0: 0f -00----- Link Protocol Disciminator: normal GSM (not Cell Broadcasting)
    1: 02 -------0 Information Frame
    1: 02 ----001- N(S), Sequence counter: 1
    1: 02 ---0---- P
    1: 02 000----- N(R), Retransmission counter: 0
    2: 45 -------1 EL, Extended Length: yes [FIXME]
    2: 45 ------0- M, segmentation: N
    2: 45 010001-- Length: 17
    3: 67 -------- Number(continoues, 8 left): 7659766
    7: 00 -------- Protocol Identifier: 0
    8: 00 00------ Data Coding Sheme: 0x00
    8: 00 --0----- Uncompressed
    8: 00 ---0---- Bit 0, 1 are reserved (no class!)
    8: 00 ----00-- Default Alphabet
    8: 00 ------00 (reserved or sim specific)
    9: 00 -------- 7 octets Parameters (unknown meaning?!)
   16: 03 ------11 CP-DATA Length: 3
   17: 61 -------- Data: "abc" (GSM 03.38)

Note: Why is length of destination address set to 11? It's only 6 bytes long.

SDCCH, CP-ACK

000: 0f 44 09 19 04 2b 2b 2b  - 2b 2b 2b 2b 2b 2b 2b 2b
001: 2b 2b 2b 2b 2b 2b 2b
    0: 0f -------1 Extended Address: 1 octet long
    0: 0f ------1- C/R: Command
    0: 0f ---011-- SAPI: SMS and SS
    0: 0f -00----- Link Protocol Disciminator: normal GSM (not Cell Broadcasting)
    1: 44 -------0 Information Frame
    1: 44 ----010- N(S), Sequence counter: 2
    1: 44 ---0---- P
    1: 44 010----- N(R), Retransmission counter: 2
    2: 09 -------1 EL, Extended Length: yes [FIXME]
    2: 09 ------0- M, segmentation: N
    2: 09 000010-- Length: 2
    3: 19 0------- Direction: From originating site
    3: 19 -001---- 1 TransactionID
    3: 19 ----1001 SMS messages
    4: 04 00000100 Type: CP-ACK

SDCCH, Channel Release (all done!)

000: 03 64 0d 06 0d 00 2b 2b  - 2b 2b 2b 2b 2b 2b 2b 2b
001: 2b 2b 2b 2b 2b 2b 2b
    0: 03 -------1 Extended Address: 1 octet long
    0: 03 ------1- C/R: Command
    0: 03 ---000-- SAPI: RR, MM and CC
    0: 03 -00----- Link Protocol Disciminator: normal GSM (not Cell Broadcasting)
    1: 64 -------0 Information Frame
    1: 64 ----010- N(S), Sequence counter: 2
    1: 64 ---0---- P
    1: 64 011----- N(R), Retransmission counter: 3
    2: 0d -------1 EL, Extended Length: yes [FIXME]
    2: 0d ------0- M, segmentation: N
    2: 0d 000011-- Length: 3
    3: 06 0------- Direction: From originating site
    3: 06 -000---- 0 TransactionID
    3: 06 ----0110 Radio Resouce Management
    4: 0d 00001101 Channel Release
    5: 00 00000000 RR-Cause (reason of event) = Normal event

5.10.2. Decoding TCH

We wanted to find out if the Nokia DCT3 mobile in trace mode also forwards TCH frames to the Computer. We did not receive any. Does his have to be enabled specificly?

Download: attachment:call_1525.xml The MS called the number 1525 and stayed connected for 2-3 seconds. The xml file contains uplink and downlink traffic as sniffed by default DCT3 tracer.

Some interesting packets below.

Question:

  1. I could not find where to phone calls 1525 (e.g. the number itself. anyone?)

SDCCH, from BTS to MS:

000: 01 73 35 05 24 31 03 33  - 19 81 05 f4 2e 48 41 15
001: 2b 2b 2b 2b 2b 2b 2b
    0: 01 -------1 Extended Address: 1 octet long
    0: 01 ------0- C/R: Response
    0: 01 ---000-- SAPI: RR, MM and CC
    0: 01 -00----- Link Protocol Disciminator: normal GSM (not Cell Broadcasting)
    1: 73 ------11 Unnumbered Frame
    1: 73 ---1---- P
    1: 73 011-00-- UA frame (Unnumbered achknowledgement)
    2: 35 -------1 EL, Extended Length: y
    2: 35 ------0- M, segmentation: N
    2: 35 001101-- Length: 13
    3: 05 0------- Direction: From originating site
    3: 05 -000---- 0 TransactionID
    3: 05 ----0101 Mobile Management Message (non GPRS)
    4: 24 00------ SendSequenceNumber: 0
    4: 24 --100100 MMcmServiceRequest
    5: 31 -011---- Ciphering key sequence: 3
    5: 31 ----0001 Request Service Type: MS originated call
    6: 03 00000011 MS Classmark 2 length: 3
    7: 33 -01----- Revision Level: Phase 2
    7: 33 ---1---- Controlled early classmark sending: Implemented
    7: 33 -----011 RF power class capability: Class 4
    8: 19 -1------ Pseudo Sync Capability: not present
    8: 19 --01---- SS Screening: Phase 2 error handling
    8: 19 ----1--- Mobile Terminated Point to Point SMS: supported
    8: 19 -----0-- VoiceBroadcastService: not supported
    8: 19 ------0- VoiceGroupCallService: not supported
    8: 19 -------1 MS supports E-GSM or R-GSM: supported
    9: 81 1------- CM3 option: supported
    9: 81 --0----- LocationServiceValueAdded Capability: not supported
    9: 81 ----0--- SoLSA Capability: not supported
    9: 81 ------0- A5/3 not available
    9: 81 -------1 A5/2: available
   11: f4 -----100 Type of identity: TMSI/P-TMSI
   12: 2e -------- ID(4/even): 2E484115

SDCCH, from BTS to MS:

000: 03 20 0d 06 35 11 2b 2b  - 2b 2b 2b 2b 2b 2b 2b 2b
001: 2b 2b 2b 2b 2b 2b 2b
    0: 03 -------1 Extended Address: 1 octet long
    0: 03 ------1- C/R: Command
    0: 03 ---000-- SAPI: RR, MM and CC
    0: 03 -00----- Link Protocol Disciminator: normal GSM (not Cell Broadcasting)
    1: 20 -------0 Information Frame
    1: 20 ----000- N(S), Sequence counter: 0
    1: 20 ---0---- P
    1: 20 001----- N(R), Retransmission counter: 1
    2: 0d -------1 EL, Extended Length: y
    2: 0d ------0- M, segmentation: N
    2: 0d 000011-- Length: 3
    3: 06 0------- Direction: From originating site
    3: 06 -000---- 0 TransactionID
    3: 06 ----0110 Radio Resouce Management
    4: 35 00110101 RRciphModCmd
    5: 11 ----000- Cipher: A5/1
    5: 11 -------1 Start ciphering
    5: 11 ---1---- Cipher Response: IMEISV shall be included

SDCCH, from BTS to MS:

000: 03 86 21 06 2e 0d c3 ff  - 05 63 21 2b 2b 2b 2b 2b
001: 2b 2b 2b 2b 2b 2b 2b
    0: 03 -------1 Extended Address: 1 octet long
    0: 03 ------1- C/R: Command
    0: 03 ---000-- SAPI: RR, MM and CC
    0: 03 -00----- Link Protocol Disciminator: normal GSM (not Cell Broadcasting)
    1: 86 -------0 Information Frame
    1: 86 ----011- N(S), Sequence counter: 3
    1: 86 ---0---- P
    1: 86 100----- N(R), Retransmission counter: 4
    2: 21 -------1 EL, Extended Length: y
    2: 21 ------0- M, segmentation: N
    2: 21 001000-- Length: 8
    3: 06 0------- Direction: From originating site
    3: 06 -000---- 0 TransactionID
    3: 06 ----0110 Radio Resouce Management
    4: 2e 00101110 RRassignCommand
    5: 0d -----101 Timeslot: 5
    5: 0d 00001--- TCH/F + ACCHs
    6: c3 110----- Training sequence code: 6
    6: c3 ---000-- Single Channel
    7: ff ........ Absolute RF channel number: 1023
    8: 05 ----0101 Power Level: 5
   10: 21 00100001 Channel Mode: TCH/F or TCH/H rev 2

SDCCH, from BTS to MS:

000: 03 22 19 83 01 1e 02 ea  - 88 2b 2b 2b 2b 2b 2b 2b
001: 2b 2b 2b 2b 2b 2b 2b
    0: 03 -------1 Extended Address: 1 octet long
    0: 03 ------1- C/R: Command
    0: 03 ---000-- SAPI: RR, MM and CC
    0: 03 -00----- Link Protocol Disciminator: normal GSM (not Cell Broadcasting)
    1: 22 -------0 Information Frame
    1: 22 ----001- N(S), Sequence counter: 1
    1: 22 ---0---- P
    1: 22 001----- N(R), Retransmission counter: 1
    2: 19 -------1 EL, Extended Length: y
    2: 19 ------0- M, segmentation: N
    2: 19 000110-- Length: 6
    3: 83 1------- Direction: To originating site
    3: 83 -000---- 0 TransactionID
    3: 83 ----0011 Call control. call related SS messages
    4: 01 00------ Send Sequence Number: 0
    4: 01 --000001 Call Alerting
    6: 02 00000010 L of IE Progress Indicator: 2
    7: ea -11----- Coding standard: GSM-PLMNS
    7: ea ----1010 Location: Network beyong interworking point
    8: 88 -0001000 Progress: In-band information or appr. pattern available

SDCCH, from BTS to MS:

000: 03 24 09 83 07 2b 2b 2b  - 2b 2b 2b 2b 2b 2b 2b 2b
001: 2b 2b 2b 2b 2b 2b 2b
    0: 03 -------1 Extended Address: 1 octet long
    0: 03 ------1- C/R: Command
    0: 03 ---000-- SAPI: RR, MM and CC
    0: 03 -00----- Link Protocol Disciminator: normal GSM (not Cell Broadcasting)
    1: 24 -------0 Information Frame
    1: 24 ----010- N(S), Sequence counter: 2
    1: 24 ---0---- P
    1: 24 001----- N(R), Retransmission counter: 1
    2: 09 -------1 EL, Extended Length: y
    2: 09 ------0- M, segmentation: N
    2: 09 000010-- Length: 2
    3: 83 1------- Direction: To originating site
    3: 83 -000---- 0 TransactionID
    3: 83 ----0011 Call control. call related SS messages
    4: 07 00------ Send Sequence Number: 0
    4: 07 --000111 Call Connect

SDCCH, from BTS to MS:

000: 03 88 0d 06 0d 00 2b 2b  - 2b 2b 2b 2b 2b 2b 2b 2b
001: 2b 2b 2b 2b 2b 2b 2b
    0: 03 -------1 Extended Address: 1 octet long
    0: 03 ------1- C/R: Command
    0: 03 ---000-- SAPI: RR, MM and CC
    0: 03 -00----- Link Protocol Disciminator: normal GSM (not Cell Broadcasting)
    1: 88 -------0 Information Frame
    1: 88 ----100- N(S), Sequence counter: 4
    1: 88 ---0---- P
    1: 88 100----- N(R), Retransmission counter: 4
    2: 0d -------1 EL, Extended Length: y
    2: 0d ------0- M, segmentation: N
    2: 0d 000011-- Length: 3
    3: 06 0------- Direction: From originating site
    3: 06 -000---- 0 TransactionID
    3: 06 ----0110 Radio Resouce Management
    4: 0d 00001101 Channel Release
    5: 00 00000000 RR-Cause (reason of event) = Normal event

5.11. The Ericcson TEMS Approach

Various Ericcson phones can be used for tracing. Womax is using the t28s together with the tems-investigation software. Screenshots:

  1. Cipher Mode Complete Command

  2. Classmark Change

More:

  1. http://www.ericsson.com/solutions/tems/index.shtml

5.12. The Vitel TSM30 Approach

This project has been moved to http://wiki.thc.org/gsm/opentsm. The goal is to modify and compile the source of the TSM30 and reflash it with our modifications. Projects are turning the TSM30 into a trace mobile and sending custom gsm messages. This in itself is cool. The research will also help us getting the USRP to send gsm messages and maybe building our own basestation.

5.13. The MADos Approach

MADos is a free open source OS for the Nokia DCT-3 series. We would like to evaluate if we can modify the source and send/receive gsm messages.

Download Source: MADos.rar

Links:

It seems that there is not DSP message control with MADos (yet). Little information about reversing the protocol between MCU and DSP is here: http://nokix.pasjagsm.pl/help/blacksphere/sub_100hardware/sub_dsp/sub_mdi.htm

5.14. Mysteries

This is a collection of mysteries. Here we collect everything that we can not explain. SOLVE A MYSTERY TODAY - EDIT THIS SECTION AND EXPLAIN IT!

5.14.1. Mystery 1: TMSI f

BCCH carrier. I see Radio Resource Management -> Paging Request Type 1 that contain a TMSI that is set to 'f'. I see hundrets of these packtes. Why f?

000: 15 06 21 00 01 f0 2b 2b  - 2b 2b 2b 2b 2b 2b 2b 2b 
001: 2b 2b 2b 2b 2b 2b 2b 
    0: 15 000101-- Pseudo Length: 5
    1: 06 0------- Direction: From originating site
    1: 06 -000---- 0 TransactionID
    1: 06 ----0110 Radio Resouce Management
    2: 21 00100001 Paging Request Type 1
    3: 00 ------00 Page Mode: Normal paging
    5: f0 -----000 Type of identity: No Identity

The lenght is set to 1. This means one octet follows: Just the type of identity but no actual number.

  1. Question: What is f in 0xf0?
    • Answer: "1111" = end marker code (3GPP TS 24.008, Table 10.5.4)
  2. Question: Why is this sent?
    • Anser: Sent to fill idle time on the CCCH.

5.14.2. Mystery 2: Unknown RRM 06 07

Received:

 05 06 07 c0 1c 04 aa 63 43 74 7f e0 12 e8 4a bc ...
 05 = Pseudo Length 1 (hu?)
 06 = Protocol discriminator: RRM
 07 = Hu? what this?
  1. Question: Why is pseudo length set to 1 but i still see valid data? It can not be 1 in the first place because no layer 3 message is only 1 byte long
  2. Question: What is 07?

5.14.3. Mystery: Pseudo Length 0 but data

Received (2 examples):

 01 06 03 df f4 a0 00 00 00 00 00 00 ...
 01 06 00 80 f7 81 70 db 09 13 69 26 ...
 01 = Pseudo Length 0

Length is set to 0 but packet contains data.

  1. Question: Anything hidden in here?
  2. Answer: These are Rest Octets. They are a GSM extention. Some rest octets and their coding are defined in GSM 04.08:10.5.2.16. Putting data in the rest octets came about with GPRS. In order to maintain compatibility with GSM, GPRS information can be transmitted in the rest octets and a GPRS capable phone will use the information, but a GSM phone will ignore it.

5.15. Converting ARFCN to Frequency

GSM-935:

frequency = 935 + 0.2 * ARFCN
Example (ARFCN == 27):
940.4 = 935 + 0.2 * 27

GSM-1800:

frequency = 1805.2 + 0.2 * (ARFCN - 512)
Example (ARFCN == 591):
1821 = 1805.2 + (591 - 512)

6. RELEASES

6.1. Tips and Tricks

  1. All releases are tested on live networks in the United Kingdom and the US (and many other countries).
  2. First find a beacon carrier. Either use the method that robert describes or use the Netmonitor to check your current beacon channel and calculate the frequency from it.

  3. Even when you have a perfect looking beacon carrier you might not receive any traffic. This is because of Inter-Symbol-Interference (ISI). Try to enhance the signal quality by using a directional antenna (yagi).
  4. Try setting decimation to 64 (or 32) in gsm_run.py (for gsmsp release) or in gssm_usrp.py (for gssm release).

6.2. Sample Data for peoples without USRP

You can analyze GSM traffic without a USRP as well. A lot of people captures data and uploaded them to the webserver at http://www.segfault.net/gsm/resources. You can download any of the files and analyze them with any of our releases even without a USRP.
If you are interested in any particular frequency range please ask on the mailinglist for somebody to sample a file for you.

If you own a USRP you can create your own capture file (cfile) like this (10 seconds, frequence 940.4Mhz):

usrp_rx_cfile.py -d 112 -f 940.4M -N 5714280 myfirstdump.cfile

6.3. Developer Source Code Access

The team releases stable tar packages every once in a while. They are listed below. There is also a anonymous git repository for the latest version:

$ git clone git://romeo.thc.org/gsm.git gsm

Compile gsm-tvoid and gsmdecode by running in both directories:

./bootstrap
./configure
make

To analyze the example dump file from robert pipe the output of gsm-tvoid into gsmdecode:

cd gsm-tvoid/src/pyton
./gsm_scan.py -SN -pd -d 112 -I GSMSP_940.8Mhz_118.cfile | ../../../gsmdecode/src/gsmdecode -i

Write-access is given to active developers. To become an active developer you must submit one useful patches to the mailinglist first. To create a patch please execute:

git diff >myname.diff

6.4. GSSM

2007/07/09
GSSM is joshua's release of a USRP GSM implementation. Please see http://wiki.thc.org/gsm/gssm for the release notes.

Download: gssm-v0.1.1a.tar.bz2.

6.5. GSM tvoid

2007/07/01
This is Tempest Void's GSM Software Project release. This is the most stable release and the latest version is available from the git server.

The release is availabe at http://wiki.thc.org/gsm/tvoid.

You should use this release if you want to:

Quick start to analyze a cfile dump:

cd gsm-tvoid/src/python
./gsm_scan.py -SN -pd -d 112 -I myfirstdump.cfile | ../../../gsmdecode/src/gsmdecode -i

6.6. GSMSP

A GNU radio GSM Software implementation. This is probably the easier package to start with.

Difference to GSSM:

  1. Compiles under windows/cygwin and linux/gentoo
  2. Works without wireshark. Come with a build in packet analyzer.
  3. Does not support live capture

Download: gsmsp-0.2a.tar.gz

6.7. Gsmdecode

Gsmdecode is used to decode the gsm messages from the gammu trace log and a nokia dct3 mobile. In the future GSMSP outputs the data in a format that gsmdecode can decode or we directly implement it into GSMSP (as a library).

2007/06/08 Download: gsmdecode-0.7bis.tar.gz source

Older versions:
2007/04/16 Download: gsmdecode-0.2.tar.gz
2007/04/19 Download: gsmdecode-0.3.tar.gz
2007/04/27 Download: gsmdecode-0.4 source or windows binary
2007/05/21 Download: gsmdecode-0.5 source or win32 binary

7. HELP

7.1. Donations

Go to http://www.segfault.net/gsm/ if you like what we are doing. Your sponsorship is appreciated. Contact steve [at] segfault.net for details or bank account information.

7.2. Who can help

7.3. How to help

8. Links

8.1. Similiar Projects

8.2. Specs & Docs

8.3. Suggested reading

8.4. Hardware