From d46e81d6e0b57b2c518c1501157f5e313b43dfd0 Mon Sep 17 00:00:00 2001 From: Refik Hadzialic Date: Sat, 8 Sep 2012 17:07:46 +0200 Subject: Implementation corrections --- vorlagen/thesis/maindoc.pdf | Bin 8589336 -> 8589828 bytes vorlagen/thesis/src/kapitel_x.tex | 89 ++++++++++++++++++++------------------ vorlagen/thesis/src/maindoc.lof | 2 +- 3 files changed, 49 insertions(+), 42 deletions(-) diff --git a/vorlagen/thesis/maindoc.pdf b/vorlagen/thesis/maindoc.pdf index 827780d..0ca38bf 100644 Binary files a/vorlagen/thesis/maindoc.pdf and b/vorlagen/thesis/maindoc.pdf 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} -- cgit v1.2.3-55-g7522