summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRefik Hadzialic2012-09-08 15:55:02 +0200
committerRefik Hadzialic2012-09-08 15:55:02 +0200
commit9a0ace7cf63c6b154ed77a7b69c5532db9d667b9 (patch)
tree2642284c638f29470bf40e679cac683d876396cb
parentResults changes (diff)
downloadmalign-9a0ace7cf63c6b154ed77a7b69c5532db9d667b9.tar.gz
malign-9a0ace7cf63c6b154ed77a7b69c5532db9d667b9.tar.xz
malign-9a0ace7cf63c6b154ed77a7b69c5532db9d667b9.zip
Implementation corrections
-rw-r--r--vorlagen/thesis/maindoc.pdfbin8589254 -> 8589336 bytes
-rw-r--r--vorlagen/thesis/src/kapitel_x.tex154
2 files changed, 80 insertions, 74 deletions
diff --git a/vorlagen/thesis/maindoc.pdf b/vorlagen/thesis/maindoc.pdf
index 33f580e..827780d 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 638f480..0fdb66f 100644
--- a/vorlagen/thesis/src/kapitel_x.tex
+++ b/vorlagen/thesis/src/kapitel_x.tex
@@ -338,7 +338,7 @@ broadcast a paging request (PCH channel) to the selected MS. After the MS obtain
try to send a random access request (RACH channel) using the Slotted Aloha protocol. Another MS could
transmit a random access request in the same time slot allowing collisions to occur. In case there was no collision,
if the BTS successfully received the random access request and at the moment of reception has a free SDCCH channels,
-it will immediatelly reserve an SDCCH channel and send the MS an assignment request (AGCH channel) back.
+it will immediately reserve an SDCCH channel and send the MS an assignment request (AGCH channel) back.
After the MS obtains the assignment request, the SDCCH channel is initialized and data can be transferred in both
directions. In this particular case, in the thesis, assistance data are sent to the MS (BTS$\rightarrow$MS),
whereas the acknowledgements, errors or the position are delivered to the BTS (BTS$\leftarrow$MS).
@@ -1682,7 +1682,7 @@ F8 @\textcolor{red}{\textbf{1}}@.......
Assistance data are of the most important value when it comes to AGPS response time.
If the assistance data are present, the response time may be shorter since
the AGPS receiver knows the orbital information of the satellites and the exact time
-which allows the AGPS to find ``immediatelly'' the Doppler frequencies and phase shifts of
+which allows the AGPS to find ``immediately'' the Doppler frequencies and phase shifts of
the visible GPS satellites. In the assistance data packets, same as in the request
packet, one has to specify what type of assistance information is included in the RRLP
assistance packets.
@@ -2134,47 +2134,46 @@ FixType ::= INTEGER {
\chapter{Implementation}
\label{Implementation}
The aim of this chapter is to give the reader a review of the employed hardware,
-testbed setup and the implemented software. 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
+testbed setup and the implemented software. The main idea of the 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 further be divided into two
+implementation parts. The first part of the second stage consists of the
development of the application that generates RRLP assistance data. The second
part of the second stage consists of modifying the existing open source GSM
software by implementing the procedures for creating a data channel
-between the BTS and MS. This channel was deployed for the transmission of
+between the BTS and the MS. This channel was deployed for the transmission of
assistance data to the MS and for obtaining the response from the MS.
\section{Hardware and testbed setup}
In the following section the author provides the testbed setup and
-presents the reader to the hardware components used in this thesis.
+presents the hardware components used in this thesis to the reader.
The hardware components will be introduced according to their
-importance of building an operational and functional GSM
+importance in building an operational and functional GSM
network with GPS localization capabilities. Firstly the nanoBTS shall be
introduced since it is the main hardware component used for building a basic
GSM network infrastructure. Then a short insight into the used GPS receiver
-shall be given. Finally, a hardware connection diagram shall be given.
+shall be given followed by the testbed setup configuration with connection scheme.
\subsection{GSM BTS - nanoBTS}
-In recent years, there has been an increasing interest in deployment of
-private cellular networks in remote areas or for research which lead to
+In recent years, there has been an increasing interest in the deployment of
+private cellular networks in remote areas which led to
the devolopment of diverse ``low-cost'' GSM hardware solutions. According to
ip.access\footnote{http://www.ipaccess.com}, the manufacturer of nanoBTS,
-their hardware product is deployed for coverage of ``hard-to-reach places;
-in-buildings; remote areas; marine and aviation; and public spaces''.
+their hardware product is deployed for coverage of ``hard-to-reach places,
+in-buildings, remote areas, marine, aviation and public spaces''.
Our University GSM network consists of three nanoBTS stations. The deployed
nanoBTS in author's thesis works in the 1800 MHz frequency range,
for which the University of Freiburg had obtained a licence from the
Federal Network Agency (German: $Bundesnetzagentur$). The transmission frequencies
-range between 1805-1880 MHz, with 200 kHz channel spacing and maximal output power
-of +23 dBm ($\approx$200 mW), whereas the receiving frequencies
-lie in the range between 1710-1785 MHz and same channel spacing as for transmission
-of 200 kHz \citep{nanoGSM2007brochure}. At the bottom of the nanoBTS there are 5 ports,
+range between 1805-1880 MHz, with 200 kHz channel spacing and the maximum
+output power of +23 dBm ($\approx$200 mW), whereas the receiving frequencies
+lie in the range between 1710-1785 MHz \citep{nanoGSM2007brochure}. At the bottom of the nanoBTS there are 5 ports,
as seen in Figure \ref{img:nanoBTSPorts}. The ports from left to right are: voltage supply,
ethernet cable with power supply, USB port, TIB-IN and TIB-OUT. The ethernet cable with power supply
is required to power the BTS and to connect its operating software (OpenBSC). The other ports are
-used to extend the GSM network performance operation but are not relevant to this work.
+used to extend the GSM network performance operation but are not relevant to the work presented in this thesis.
\begin{figure}[ht!]
\centering
@@ -2184,11 +2183,11 @@ used to extend the GSM network performance operation but are not relevant to thi
\end{figure}
To determine the working state of the nanoBTS, an indicator status LED is located on the
-left side of the five ports region. After the nanoBTS is connected to the power supply
+left side of the five ports area. After the nanoBTS is connected to the power supply
with the ethernet cable, it changes its color and blink speed according to the state
it is in. The states are given in appendix and can be seen in the table given in
\ref{tbl:LEDStatus} \citep{installnanoBTS}. One of the key limitations of gathering more
-technical data and the critical aspect of this description lies in the fact,
+technical data and the critical aspect of this description lies in the fact
that nanoBTS is not an open source hardware platform and ip.access does not offer more
details on their product. The lack of systematic hardware analysis can be seen as
a major drawback of working with the nanoBTS hardware. However, the given technical data
@@ -2198,14 +2197,14 @@ are sufficient for reproducing and conducting the RRLP tests described in this t
\label{sec:gpsDevice}
The Navilock NL-402U GPS receiver is based on the u-blox UBX-G5000 single chipset and is a one
chip solution \citep{ubxDatasheet}. Receiver tracking sensitivity is -160 dBm ($10^{-16}$ mW).
-The GPS receiver was used as an indicator if there is any GPS signal in the tested room.
+The GPS receiver was used as an indicator of whether there is any GPS signal in the tested room.
\subsection{Testbed setup configuration}
\label{sec:hardwareConfig}
-At least 4 ethernet cables with RJ45 connectors, on both sides, were required
-and one switch or hub connected to the internet. One ought to take notice
-of the cabling between the nanoBTS and the ethernet switch or hub, since wrong
-cabling with the power supply unit (PSU) could damage one of the devices.
+At least 4 network cables with RJ45 connectors were required
+and one switch or hub connected to the internet. It is important to carefully
+proceed with the cabling of the nanoBTS and the ethernet switch or hub, since wrong
+wiring with the power supply unit (PSU) could damage one of the devices.
In Figure \ref{img:connectionDiagram}, the junction points are label according
to the used configuration setting. The ethernet cables between the switch/hub,
PSU and nanoBTS should not be longer than 100 m \citep{installnanoBTS}.
@@ -2221,87 +2220,94 @@ PSU and nanoBTS should not be longer than 100 m \citep{installnanoBTS}.
Traditionally all radio communication systems are hard wired and
the hardware is developed to do only one fixed function as the
nanoBTS, to serve as a BTS. nanoBTS is a dedicated BTS hardware,
-used to set up the GSM network with OpenBSC (more details on
-the nanoBTS can be found in the hardware description). However,
+used to set up a test GSM network. However,
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
+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 and protocols using software that modifies the
-function of the hardware. In other words, the hardware may perform
+SDR is a hardware platform that enables the development and testing
+of different radio communication systems as well as protocols
+using software that modifies the function of the hardware.
+In other words, the hardware may perform
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
+can be the frequency range in which the SDR can transmit and receive radio waves,
+the speed of sampling a radio wave signal and some other properties.
+The basic idea is to use the fast performance of the CPU inside the
+computer to do the signal processing while the
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 employing different modulation/demodulation procedures and frequency spectrums
+dedicated hardware, SDR's can be programmed to perform various
+functions e.g. an FM radio, a GPS receiver, GSM and etc.
+All of the stated ``emulated devices'' employ different modulation/demodulation
+procedures 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) by Ettus Research. USRP had already a GSM and RRLP software
+Radio Peripheral (USRP) by Ettus Research. USRP already had a GSM and RRLP software
implementation. 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
+application written in C++ employing the SDR platform to provide a GSM air interface \citep{openBTS}.
+Once the system has been successfully configured and put in operation, tests
+had been run to verify that it was operating properly. 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.
+While the system was tested with smart phones, a strange behaviour was noticed.
Occasionally 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
+in the unstable operation of the cheap clock oscillator. However, the clock's 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
+the actual frequency and its deviation. Nevertheless, these findings
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 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.
+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
+connect to the GSM network. In the log files it could be seen that a time out was triggered
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!
+The RRLP request was immediately sent after the paging request has been obtained by the MS.
+The 2G phones continued their normal operation
+after the RRLP request contrary to smart phones. This was due to the fact that 2G phones
+did not understand the RRLP request and therefore they skipped it.
+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 occasionally received the
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.
+RRLP request as an SMS message, there was still no response 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
+inside of this set up because the system itself was unstable and had an unpredictable
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
-for comparison and a template to build author's RRLP assistance data generator. The nanoBTS
-is operated by OpenBSC which is explained in the following section.
-
+the RRLP protocol. The generated assistance data packets by the RRLP module
+were used for comparison and as a template to build the author's RRLP assistance
+data generator. The nanoBTS is operated by OpenBSC (not the same as OpenBTS) which
+will be explained in the following section.
+\newpage
\section{OpenBSC and its original RRLP implementation}
OpenBSC is an open source implementation of a GSM network software by Osmocom.
-It was developed for experimentation and security research of the GSM networks \citep{obsc1}.
+It was developed for experimentation and security research of the GSM networks
+\citep{obsc1}.
OpenBSC is ``implementing the minimal necessary parts to build a small,
self-contained GSM network'' \citep{obsc}. This self-contained GSM network
-consists of following functional components: Base Station Controller (BSC),
-Mobile Switching Center (MSC), Home Location Register (HLR),Authentication
+consists of the following functional components: Base Station Controller (BSC),
+Mobile Switching Center (MSC), Home Location Register (HLR), Authentication
Center (AUC), Visitor Location Register (VLR) and Equipment Identity
-Register (EIR). OpenBSC was written in C and operates on Linux. OpenBSC binds
+Register (EIR). OpenBSC was developed in C and operates on Linux. OpenBSC binds
to the BTS using the Abis or Abis/IP interface. At the moment OpenBSC
supports Voice calls, SMS, handovers, support for multiple BTS and other features
-not of the interest for this work. OpenBSC has an implemented module for
-transmitting RRLP requests however without assistance data. This module was
+not of interest to this work. OpenBSC has an implemented module for
+transmitting RRLP requests, however without assistance data. This module was
tested but without successfully obtaining a position from the MS.
While the tests have been performed, no results were obtained due to a
watchdog time out produced by OpenBSC. In order to send an RRLP request in
@@ -2309,18 +2315,18 @@ OpenBSC, a silent SMS would be sent to the cell phone followed by the RRLP
request. Silent SMS is the equivalent of a normal SMS but without notifying
the user of its reception \citep{silentSMS}. When the silent SMS is received
on the cell phone, the message content is not displayed to the user
-neither is it stored in the SMS inbox. In other words, its arrival
+nor is it stored in the SMS inbox. In other words, its arrival
remains completely unknown to the user to whom it was sent \citep{silentSMS}.
An acknowledgement is sent back to the GSM network operator that the MS
received the silent SMS. The watchdog timer in OpenBSC has been triggered
because the acknowledgement was not received within a certain time limit
while the MS was attempting to obtain a GPS position. To overcome this problem
another approach had to be taken by the author to send RRLP assistance data
-with position requests. This shall be further analysed and explained in more
-details in the following sections.
+with position requests. This shall be further analysed and explained in
+detail in the following sections.
\section{RRLP assistance data generator}
-At the point of working on this thesis,
+At this point of the thesis,
two different RRLP implementations on two different hardware platforms
have been examined without successfully obtaining a GPS localization.
The next step in the attempt to obtain GPS positions from MS was to
@@ -2337,7 +2343,6 @@ verification of their correctness, construction of RRLP packets according to
the ASN.1 standard, conversion of it to PER and at last saving in the
hexadecimal form in a text file.
-\newpage
In the almanac
and ephemeris files, downloaded from Navigation Center of the US Coast Guard and Trimble, assistance data were stored
for 32 different GPS satellites. Contrary to expectations after the generated
@@ -2383,7 +2388,7 @@ is performed by Trimble, whose ephemeris data were used.}.
It was common that the ephemeris assistance data contained errors which
were detected in the data range verification step. To avoid disruption
in operation of the written software, once data out of range were detected
-they are immediatelly substituted with data for the same satellite
+they are immediately substituted with data for the same satellite
but with two hours older ephemeris data. If the AGPS receiver in the MS uses
the ephemeris data from that particular satellite then the distance estimation
is affected and may contain errors! This problem is well known and confirmed
@@ -2397,11 +2402,12 @@ respond OpenBSC' real-time functionality might be lost and the system will
malfunction. Since the text file is small and accessed only when an RRLP
request is queued, it is faster than initializing the database driver,
opening a socket connection to the database, making request queries to the
-database, obtaining the result and closing the socket connection. At this step
-the assistance data are ready to be opened by OpenBSC and sent to the MS.
+database, obtaining the result and closing the socket connection.
\section{Creating a data channel in OpenBSC}
-To avoid the watchdog time out triggered by OpenBSC when the RRLP
+At this step the assistance data are ready to be opened by OpenBSC
+and sent to the MS. To avoid the watchdog time out triggered by
+OpenBSC when the RRLP
requests have been sent originally the solution was to open a data
channel. The original idea was to open a data channel with a silent
SMS and then to send the RRLP request. The opening of a data channel
@@ -2723,7 +2729,7 @@ acquisition assistance data (phase shift and Doppler effect frequency required b
explained in section \ref{sec:rrlpassistance}) were not delivered to the MS. It is important
to mention the strange behaviour by $Galaxy$ $Nexus$ $i9250$, the smart phone responded only with
acknowledgements while the assistance data have been sent but after the reception it
-immediatelly closed the SDCCH channel. The $Blade$ closed the SDCCH channel after 4 transmitted
+immediately closed the SDCCH channel. The $Blade$ closed the SDCCH channel after 4 transmitted
assistance packets for the RRLP(E) test. The $Defy$ by Motorola did not produce any output at
all and its behaviour was exact like of an 2G cell phone without a GPS receiver.
To eliminate doubts and suspicion if the SDCCH channel was properly working and the