summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRefik Hadzialic2012-08-30 21:30:20 +0200
committerRefik Hadzialic2012-08-30 21:30:20 +0200
commit583dc7b3f903b1bf05780981508c7e9b24eb9c5a (patch)
tree2fb0df78a3061f5ec0df9e11249051e2591fc899
parentimplementation intro (diff)
downloadmalign-583dc7b3f903b1bf05780981508c7e9b24eb9c5a.tar.gz
malign-583dc7b3f903b1bf05780981508c7e9b24eb9c5a.tar.xz
malign-583dc7b3f903b1bf05780981508c7e9b24eb9c5a.zip
Implementation
-rw-r--r--vorlagen/thesis/maindoc.pdfbin17094529 -> 17094853 bytes
-rw-r--r--vorlagen/thesis/src/kapitel_x.tex99
2 files changed, 52 insertions, 47 deletions
diff --git a/vorlagen/thesis/maindoc.pdf b/vorlagen/thesis/maindoc.pdf
index e103055..4b64198 100644
--- a/vorlagen/thesis/maindoc.pdf
+++ b/vorlagen/thesis/maindoc.pdf
Binary files differ
diff --git a/vorlagen/thesis/src/kapitel_x.tex b/vorlagen/thesis/src/kapitel_x.tex
index dad2025..b9c7ac3 100644
--- a/vorlagen/thesis/src/kapitel_x.tex
+++ b/vorlagen/thesis/src/kapitel_x.tex
@@ -2594,15 +2594,16 @@ B6 1....... FixType = 1 :threeDFix
\chapter{Implementation}
\label{Implementation}
The aim of this chapter is to give the reader a review of the employed hardware and the software implementation.
-The main idea of authors algorithm and authors approach to the problem is discussed in this chapter.
-This chapter can be divided into two stages. The first stage being the inital phase of
+The main idea of author's approach to the problem is discussed in this chapter.
+The implementation can be divided into two stages. The first stage being the inital phase of
the thesis where the initial system has been set up to perform RRLP tests.
The second stage can be divided into two implemantation parts. The
first part of the second stage consists of the development of the application
-that generated RRLP assistance data. The second part of the second stage
-consists of modifying existing open source GSM network software implementation
-for creating a data channel between the BTS and MS. This channel was utilised for the
-transmission of assistance data to the MS and obtaining the response from the MS back.
+that generates RRLP assistance data. The second part of the second stage
+consists of modifying the existing open source GSM software and implementing the
+procedures for creating a data channel between the BTS and MS. This channel
+was deployed for the transmission of assistance data to the MS and for obtaining
+the response from the MS.
\section{Initial phase of trying out RRLP}
Traditionally all radio communication systems are hard wired and
@@ -2614,62 +2615,66 @@ at the start of the thesis, the author had no access to the nanoBTS.
On the other hand, instead of the nanoBTS a software defined radio
(SDR) platform was available and used to emulate the GSM network.
SDR is a hardware platfrom that enables the development and test
-of different radio communication systems using software that modifies the
+of different radio communication systems and protocols using software that modifies the
function of the hardware. In other words, the hardware may perform
-other functions in the range of its specified limits. Those limits
-can be the frequency on which it can transmit and receive radio waves
-or the speed of sampling a radio wave signal.
+different functions in the range of its specified limitations. Those limitations
+can be the frequency on which the SDR can transmit and receive radio waves,
+the speed of sampling a radio wave signal and other properties.
The basic idea is to use the fast performace of a CPU from the
computer to do the software signal processing while the
-SDR hardware itself does only the physical radio communication like
-emitting and receiving on defined frequencies. Alternatively to the
-dedicated hardware, USRP can be programmed to perform various
+SDR hardware itself performs only the physical radio communication like
+emitting and receiving radio waves. Alternatively to the
+dedicated hardware, SDRs can be programmed to perform various
functions e.q. an FM radio, a GPS receiver, GSM and etc.,
-all of them working on different standards and frequency spectrums
+all of them employing different modulation/demodulation standards and frequency spectrums
\citep{fmRadio} \citep{openBTS}. Theoretically ``anything'' can be
built using an SDR platform that is within the domain of the SDR hardware.
The exploited SDR platform in this thesis was the Universal Software
Radio Peripheral (USRP) that already had an GSM and RRLP implementation.
-The GSM implementation used on USRP was OpenBTS, a Linux application written in C++
-that uses software radio to provide a GSM air interface
-and uses a software switch to interconnect calls \citep{openBTS}. After the
-system has been successfully set up and set in operation. Initially the system was
-tested with 2G cell phones (Nokia 3310 and Siemens M50). While the system was
-tested with smart phones, a strange behaviour could be noticed. Sometimes
-the smart phones ($iPhones$ $3GS$ and $4$) could not detect the GSM network
-existance at all in the network search menu where all GSM networks in range are shown.
-The reason for this strange phenomenon may be found in the unstable
-operation of the cheap clock oscillator. Although the clock unstability issue can not be
-confirmed by the author due to the missing frequency counter to measure the actual frequency.
-Nevertheless these results, network undetectability behaviour, are consistent with those
-of the developers of OpenBTS with the same clock oscillator\footnote{GSM not detecting station, USRP1, FA-SY1, WBX, DBS
+The GSM network software used on USRP was OpenBTS, a Linux application written in C++
+employing the SDR platform to provide a GSM air interface \citep{openBTS}. Once the
+system has been successfully configured and set in operation it was followed by tests
+to verify if it was operating correctly. Initially, the system was
+tested with 2G cell phones (Nokia 3310 and Siemens M50) and its correctness was verified.
+While the system was tested with smart phones, a strange behaviour could be noticed.
+Sometimes the smart phones ($iPhones$ $3GS$ and $4$) could not detect existance of the
+GSM network at all, i.e. the network could not be found in the search menu where
+all GSM networks in range are shown. The reason for this strange phenomenon may be found
+in the unstable operation of the cheap clock oscillator. Although the clock unstability
+issue can not be confirmed by the author due to the missing hardware equipment to measure
+the actual frequency and its deviation. Nevertheless, these results
+were consistent with the results of the OpenBTS developers
+with similar clock issues\footnote{GSM not detecting station, USRP1, FA-SY1, WBX, DBS
\url{http://www.ruby-forum.com/topic/1876696}}. As previously stated in the GSM chapter,
the clock oscillator for the BTS is not allowed to deviate more than $\pm$5 ppm
-(parts per million). This finding that older cell phones (the tested 2G phones)
-have rather less problems than the newer ones suggest that newer generation
-cell phones are not robust to the timing deviation issues. Meanwhile the RRLP
-module was downloaded and installed. The module was written by Kurtis Heimerl in two
-different programming languages, Erlang and Common Gateway Interface (CGI)\footnote{Kurtis
-Heimerl's code can be found on \url{https://github.com/ttsou/RRLP}}. Once the
-RRLP module was configured the new system configuration was tested with RRLP.
-The first observation and finding was that not a single smart phone could
+(parts per million). This finding, that older cell phones like Nokia 3310 and Siemens M50
+have rather less problems connecting to the GSM network than the newer cell phones suggest
+that newer generation cell phones are not robust and resistant to the timing deviation issues.
+Meanwhile the RRLP module was downloaded and installed. The module was written by Kurtis
+Heimerl in two different programming languages, Erlang and Common Gateway Interface
+(CGI)\footnote{Kurtis Heimerl's code can be found on \url{https://github.com/ttsou/RRLP}}.
+Once the RRLP module was configured and installed, the new GMS system configuration
+was examined. The first observation and finding was that not a single smart phone could
connect to the GSM network. In the log files it could be seen a time out was triggered
-by OpenBTS while the smart phones tried to get a position fix after the RRLP request
-was received by the MS. This result may be explained by the fact that the RRLP
-request was immediatelly sent after the paging request has been sent by the BTS. Once
-the option was found to disable the RRLP request sending each time the cell phones are
-being paged. Next step was manually so send the RRLP requests from the OpenBTS terminal
+by OpenBTS. This timeout was triggered while the smart phones tried to get a
+position fix after the RRLP request was delivered to the MS. This result may be
+explained by analysing at what stage in the protocol the RRLP request was sent.
+The RRLP request was immediatelly sent after the paging request has been obtained by the MS.
+This evidence justifies the time out behaviour. Once the option for sending RRLP requests
+while the paging is in progress was disabled, this problem was solved!
+Next step was to manually send the RRLP requests from the OpenBTS terminal
to smart phones. Contrary to expectations, the smart phones sometimes received the
-RRLP request as an SMS message. In the case where the smart phone did not receive the
-RRLP request as an SMS message, it would still not respond its position back.
+RRLP request as an SMS message and did not provide any response.
+In the case where the smart phones did not receive the
+RRLP request as an SMS message, still no response was produced.
One of the consequences of such behaviour was that the RRLP could not be tested
inside of this set up because the system itself was unstable and had an unpredictive
-behaviour. The conducted tests with OpenBTS lead to the decision to employ dedicated
-hardware BTS with a tested and calibrated clock oscillator only for GSM. On the other
-hand, the Erlang RRLP module was a starting point to understand the RRLP protocol.
-The generated assistance data packets by the module were used as a template and
-comparison to build author's RRLP assistance data generator.
+behaviour. The conducted tests with OpenBTS thus lead to a logical decision to
+employ dedicated BTS hardware with a tested and calibrated clock oscillator only
+for GSM. On the other hand, the Erlang RRLP module was a starting point to understand
+the RRLP protocol. The generated assistance data packets by the module were used as
+a template and comparison to build author's RRLP assistance data generator.
\section{OpenBSC}
OpenBSC is an open source implementation of a GSM network by Osmocom. It was developed