summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRefik Hadzialic2012-09-08 17:07:46 +0200
committerRefik Hadzialic2012-09-08 17:07:46 +0200
commitd46e81d6e0b57b2c518c1501157f5e313b43dfd0 (patch)
treea03d9fc53952398b07db7e97bb174789271be252
parentImplementation corrections (diff)
downloadmalign-d46e81d6e0b57b2c518c1501157f5e313b43dfd0.tar.gz
malign-d46e81d6e0b57b2c518c1501157f5e313b43dfd0.tar.xz
malign-d46e81d6e0b57b2c518c1501157f5e313b43dfd0.zip
Implementation corrections
-rw-r--r--vorlagen/thesis/maindoc.pdfbin8589336 -> 8589828 bytes
-rw-r--r--vorlagen/thesis/src/kapitel_x.tex89
-rw-r--r--vorlagen/thesis/src/maindoc.lof2
3 files changed, 49 insertions, 42 deletions
diff --git a/vorlagen/thesis/maindoc.pdf b/vorlagen/thesis/maindoc.pdf
index 827780d..0ca38bf 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 0fdb66f..7c14f43 100644
--- a/vorlagen/thesis/src/kapitel_x.tex
+++ b/vorlagen/thesis/src/kapitel_x.tex
@@ -1410,7 +1410,7 @@ To save bandwidth space in the communication between the SMLC and MS, it can be
first the RRLP request is sent out for the position estimation. If the MS requires some of the assistance data,
it will send back a request for the required assistance data. In the next step the SMLC could send the required assistance data
back to the MS and expect an successful response from the MS. However, in this work the author had a different approach, first
-all the RRLP assistance data were sent and then the RRLP position request. This approach was choosen over the other
+all the RRLP assistance data were sent and then the RRLP position request. This approach was chosen over the other
because in the GSM network operating software (OpenBSC), it was required to access the database and fetch the response.
For the simple reason, since this system is a real time system, waiting for the database to respond may have
corrupted the state machine of the GSM network and this would led to the malfunction and eventually failure of
@@ -1536,21 +1536,21 @@ Does it solely take place on the MS (\textit{msBased}), on the server\footnote{W
the BTS location is ment!} only (\textit{msAssisted}),
or one method is prefered over the other depending if the MS can execute the prefered one method
(\textit{msBasedPref} or \textit{msAssistedPref}). The uncertainty of the accuracy
-of the estimated position is only optional if the choosen method is \textit{msAssisted},
+of the estimated position is only optional if the chosen method is \textit{msAssisted},
otherwise it must be included in the request message. This uncertainty of the accuracy, is an integer
number and defines how certain the accuracy of the returned position has to be. It can be calculated
using the equation \eqref{eq:uncerAccuracy}, where $K$ is the seven bit integer number
and $r$ is the accuracy uncertainty in meters \citep{3gppequations}. The next three parameters
to be defined are the position estimation technique (GPS, E-OTD or one of the two prefered by the MS),
the position measurement time and how many measurements the MS has to report back to the SMLC.
-Since in this thesis the author exploits the AGPS method, GPS is choosen for \textbf{PositionMethod}.
+Since in this thesis the author exploits the AGPS method, GPS is chosen for \textbf{PositionMethod}.
\textbf{MeasureResponseTime} is a three bit integer value that corresponds to the time period the MS is allowed
to perform the position estimation. Otherwise, if it takes longer the MS
to report back than the specified time period, the MS is allowed to disconnect (close the SDCCH channel) without responding back.
This time period can be calculated using the equation
given in \eqref{eq:responseTime}, where $N$ is the number of seconds the MS is allowed to perform the
position estimation. After the ASN.1 parameters of an RRLP request have been understood, they can be
-choosen and set according to the position measurement request which the network operator wants to perform.
+chosen and set according to the position measurement request which the network operator wants to perform.
In the next step the RRLP packet shall be encoded from ASN.1 notation to the Packed Encoding
Rules (PER) notation. PER is one of the telecommunication
standards used for encoding and decoding messages inside of protocols specified in the ASN.1
@@ -1622,7 +1622,7 @@ aligned and nonaligned PER lies in the fact that some data structures are aligne
boundaries in aligned PER, i.e. there are some wasted padding bits which are set to zero if
not used according to the size of the packets.
Construction of the RRLP request query is straightforward.
-The choosen values are simply concatenated
+The chosen values are simply concatenated
into a binary string. A simple RRLP request in PER encoded form is shown in figure \ref{img:RRLPReqExplained}.
As an illustration, in figure \ref{img:RRLPReqExplained} the bits have been colored with distinguishable
colors with the intention to recognize easier the different variables in ASN.1 notation.
@@ -2250,7 +2250,7 @@ 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 was noticed.
-Occasionally the smart phones ($iPhones$ $3GS$ and $4$) could not detect existance of the
+Occasionally the smart phones ($iPhones$ $3GS$ and $4$) could not detect existence 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. However, the clock's unstability
@@ -2329,25 +2329,31 @@ detail in the following sections.
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
+The next step in the attempt to obtain GPS positions from the MS was to
gain better understanding of the RRLP protocol and RRLP assistance data.
-The RRLP assistance data generated by Heimerl's application
+The RRLP data generated by Heimerl's application
did not produce valid assistance data. In order to publish the RRLP assistance
-data generator as open source to be wider extended or ported to another
+data generator as open source to be extended further or ported to another
programming language, it was required to be written in a programming language
-understandale by wider audience. It was sound to write the RRLP assistance
-data generator in C++ because OpenBSC was written in C and OpenBTS in C++.
-The main tasks here can be split up down to: verify the existance and age of
-assistance data download of the assistance data, conversion of the data,
-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.
+understandale to a wider audience. Since the RRLP data generator application
+is independent of the GSM operating software, it was sound to write the
+RRLP assistance data generator in C++. Another reason why C++ was
+taken is due to the fact that OpenBSC was written in C and OpenBTS in C++.
+The main tasks here can be split up down to: verification of assistance data
+existence in the download folder and its age, download of the assistance data,
+conversion of the data, verification of assistance data correctness,
+construction of RRLP packets according to the ASN.1 standard,
+its conversion to PER and lastly saving in the hexadecimal form in a text file.
+The hexadecimal form was chosen because immediately the generated assistance
+data could be compared and verified online\footnote{RRLP message
+parser http://www.3gpp-message-analyser.com/decoder/misc.htm.}.
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
-RRLP packets have been analysed, Heimerl's code produced RRLP assistance
-data packets with only valid data for one satellite but duplicated 32 times.
+and ephemeris files, downloaded from the Navigation Center of the US Coast Guard
+and Trimble, assistance data for 32 different GPS satellites are present.
+Contrary to expectations, Heimerl's code produced RRLP assistance
+data valid for only one satellite. The rest of the assistance
+data were duplicats of the assistance data for one satellite.
At this stage, it was important to have a fully working RRLP assistance data
generator. This generator would be subsequently used to examine the RRLP
protocol once OpenBSC was modified to open a data channel for transmitting
@@ -2357,17 +2363,18 @@ assistance data generator. It was used as a template with the specified RRLP
conversion standard itself. The downloaded assistance data were
in formats known as Receiver Independent Exchange format (RINEX) for ephemeris
data and Yuma for almanac data. RINEX is a format to exchange raw satellite
-navigation data from GPS receivers that have an ability to output them.
+navigation data from GPS receivers with an ability to output the same raw data.
Although almanac data can be in RINEX form as well, the almanac data
-found online were in the Yuma format. The read files with assistance
+found online were in the Yuma format. The files with assistance
data had to be first properly parsed and then converted into the format
specified in the standard by ETSI TS 144 031 \citep{ETSITS144031}.
-The data included in the ephemeris file contained also UTC model,
+The data included in the ephemeris file also contained the UTC model,
and the ionospheric model. Other operational data were included in the
-configuration file like the reference location data, more details
-can be found in the software appendix configuration section \ref{sec:appendSoft}.
+configuration file like the reference location data. More details
+on the operational data can be found in the software appendix
+configuration section \ref{sec:appendSoft}.
Once all data have been successfully parsed and converted, they had to be verified
-to be in the specified range as in the standard. Afterwards the converted
+to be in the specified range (domain) as in the standard. Afterwards, the converted
and verified assistance data were combined into binary series of data
according to the RRLP standard as described in chapter \ref{rrlpChapt}.
If the assistance data packet size in binary format was not divisible by eight
@@ -2378,24 +2385,24 @@ by looking at the flowchart in figure \ref{img:RRLPAlgFlowchart}.
\begin{figure}[ht]
\centering
\includegraphics[scale=0.39]{img/algorithmRRLP.pdf}
- \caption{Flowchart for the RRLP assistance data generators}
+ \caption{Flowchart for the RRLP assistance data generator.}
\label{img:RRLPAlgFlowchart}
\end{figure}
-
-Since the ephemeris data refresh every two hours, the latest generated data
-are appended at the end of the file for the current reading\footnote{This
+\newpage
+Since the ephemeris data refresh every two hours, the most recent generated data
+are appended at the end of the ephemeris file for one day\footnote{This
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
+had to be detected in the data range verification step. To avoid disruption
+in operation of the developed application, once data out of range were detected
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
by different studies \citep{Stanford-Ephem-Errors} \citep{NASA-Ephem-Errors}.
-A solution to this problem is proposed in the future work section \ref{sec:futWork}. Once the
-assistance data have been generated, converted to hexadecimal notation and
-saved to a text file they can be used by OpenBSC to be transmitted to the MS.
+A solution to this problem is proposed in the future work section \ref{sec:futWork}.
+Once the assistance data have been generated, converted to hexadecimal notation and
+saved to a text file, they can be used by OpenBSC to be sent to the MS.
The decision to save the data to a text file, instead of storing to the database,
was made because OpenBSC is a real-time system. If the database does not
respond OpenBSC' real-time functionality might be lost and the system will
@@ -2403,15 +2410,15 @@ 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 point, the assistance data are ready to be opened by OpenBSC
+and sent to the MS.
\section{Creating a data channel in OpenBSC}
-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
+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
-(SDCCH) and what is on going in OpenBSC can be split up into 4
+SMS and then to send the RRLP request. What takes place in OpenBSC when
+the data channel (SDCCH) is opened can be split up into 4
stages: adding a Virtual Teletype (VTY) interface to execute an
RRLP request, open a physical data channel between the BTS and MS,
opening the text file with assistance data and sending the data as
diff --git a/vorlagen/thesis/src/maindoc.lof b/vorlagen/thesis/src/maindoc.lof
index a55a96b..1cfc5de 100644
--- a/vorlagen/thesis/src/maindoc.lof
+++ b/vorlagen/thesis/src/maindoc.lof
@@ -35,7 +35,7 @@
\addvspace {10\p@ }
\contentsline {figure}{\numberline {5.1}{\ignorespaces nanoBTS with two external antennas and five connection ports\relax }}{54}{figure.caption.39}
\contentsline {figure}{\numberline {5.2}{\ignorespaces Cable connections, showing interconnection diagram\relax }}{55}{figure.caption.40}
-\contentsline {figure}{\numberline {5.3}{\ignorespaces Flowchart for the RRLP assistance data generators\relax }}{60}{figure.caption.41}
+\contentsline {figure}{\numberline {5.3}{\ignorespaces Flowchart for the RRLP assistance data generator.\relax }}{60}{figure.caption.41}
\addvspace {10\p@ }
\contentsline {figure}{\numberline {6.1}{\ignorespaces Test rooms as well as the results delivered by the smart phones. Image courtesy of Google Maps.\relax }}{65}{figure.caption.43}
\contentsline {figure}{\numberline {6.2}{\ignorespaces Test room 2 with the positions of the smart phones.\relax }}{66}{figure.caption.44}