summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRefik Hadzialic2012-09-06 14:23:22 +0200
committerRefik Hadzialic2012-09-06 14:23:22 +0200
commitd182d7c634bb553dd247ad26e5219596ff20a5c9 (patch)
treea6b54d1edd192315342326cf94864a9aab64bd38
parentChanges (diff)
downloadmalign-d182d7c634bb553dd247ad26e5219596ff20a5c9.tar.gz
malign-d182d7c634bb553dd247ad26e5219596ff20a5c9.tar.xz
malign-d182d7c634bb553dd247ad26e5219596ff20a5c9.zip
Changes
-rw-r--r--vorlagen/thesis/maindoc.pdfbin8534080 -> 8556086 bytes
-rw-r--r--vorlagen/thesis/src/.kapitel_A.tex.kate-swpbin0 -> 70 bytes
-rw-r--r--vorlagen/thesis/src/bib/.literatur.bib.kate-swpbin0 -> 50 bytes
-rw-r--r--vorlagen/thesis/src/bib/literatur.bib9
-rw-r--r--vorlagen/thesis/src/kapitel_A.tex10
-rw-r--r--vorlagen/thesis/src/kapitel_x.tex439
-rw-r--r--vorlagen/thesis/src/maindoc.lof6
-rw-r--r--vorlagen/thesis/src/maindoc.lot2
8 files changed, 227 insertions, 239 deletions
diff --git a/vorlagen/thesis/maindoc.pdf b/vorlagen/thesis/maindoc.pdf
index a196c45..e0ad759 100644
--- a/vorlagen/thesis/maindoc.pdf
+++ b/vorlagen/thesis/maindoc.pdf
Binary files differ
diff --git a/vorlagen/thesis/src/.kapitel_A.tex.kate-swp b/vorlagen/thesis/src/.kapitel_A.tex.kate-swp
new file mode 100644
index 0000000..208bd82
--- /dev/null
+++ b/vorlagen/thesis/src/.kapitel_A.tex.kate-swp
Binary files differ
diff --git a/vorlagen/thesis/src/bib/.literatur.bib.kate-swp b/vorlagen/thesis/src/bib/.literatur.bib.kate-swp
new file mode 100644
index 0000000..6490c79
--- /dev/null
+++ b/vorlagen/thesis/src/bib/.literatur.bib.kate-swp
Binary files differ
diff --git a/vorlagen/thesis/src/bib/literatur.bib b/vorlagen/thesis/src/bib/literatur.bib
index 6cb8273..ca24e12 100644
--- a/vorlagen/thesis/src/bib/literatur.bib
+++ b/vorlagen/thesis/src/bib/literatur.bib
@@ -191,7 +191,7 @@
author = "Xu, Guochang",
isbn = "3540727140",
publisher = "Springer",
- title = "{GPS: Theory, Algorithms and Applications}",
+ title = "GPS: Theory, Algorithms and Applications",
year = "2007"
}
@@ -784,3 +784,10 @@ ISSN={0018-9251},}
year = "2012"
}
+@misc{silentPolice,
+ author = "European Digital Civil Rights",
+ howpublished = "\url{http://www.edri.org/edrigram/number10.2/silent-sms-tracking-suspects}",
+ note = "[Online; accessed 1-September-2012]",
+ title = "Police Frequently Uses Silent SMS To Locate Suspects",
+ year = "2012"
+} \ No newline at end of file
diff --git a/vorlagen/thesis/src/kapitel_A.tex b/vorlagen/thesis/src/kapitel_A.tex
index 13bb98d..3fbbb2e 100644
--- a/vorlagen/thesis/src/kapitel_A.tex
+++ b/vorlagen/thesis/src/kapitel_A.tex
@@ -465,7 +465,7 @@ developer to troubleshoot and find the bug.
\begin{tabular}{llll}
\toprule
%$D$&&$P_u$&$\sigma_N$\\
-State&Color \& Pattern&When&Precedence\\\toprule
+\textbf{State}&\textbf{Color \& Pattern}&\textbf{When}&\textbf{Precedence}\\\toprule
Self-test failure&Red - Steady &In boot or application code when a power&1 (High) \\
&&on self-test fails\\\midrule
Unspecified failure&Red - Steady &On software fatal errors&2\\\midrule
@@ -504,7 +504,7 @@ are the RRLP assistance data converted in the RRLP packet generator software.
\begin{tabular}{lllcc}
\toprule
%$D$&&$P_u$&$\sigma_N$\\
-Field (IE) & Description\\\toprule
+\textbf{Field (IE)} & \textbf{Description}\\\toprule
$A_{1}$&Drift coefficient of GPS time scale relative\\
&to UTC time scale\\\midrule
$A_{0}$&Bias coefficient of GPS time scale relative\\
@@ -527,7 +527,7 @@ $\Delta t_{LSF}$&Current of future leap second count
\begin{tabular}{llllc}
\toprule
%$D$&&$P_u$&$\sigma_N$\\
-Field (IE) & Description\\\toprule
+\textbf{Field (IE)} & \textbf{Description}\\\toprule
$\alpha_{0}$&Coefficient 0 of vertical delay\\\midrule
$\alpha_{1}$&Coefficient 1 of vertical delay\\\midrule
$\alpha_{2}$&Coefficient 2 of vertical delay\\\midrule
@@ -549,7 +549,7 @@ $\beta_{3}$&Coefficient 3 of period of the model
\begin{tabular}{llll}
\toprule
%$D$&&$P_u$&$\sigma_N$\\
-Field (IE) & Description\\\toprule
+\textbf{Field (IE)} & \textbf{Description}\\\toprule
Satellite ID&This is the satellite ID that is in the range of 0 to 63. PRN=SatelliteID + 1\\\midrule
Satellite status&This is an indicator of whether this is a new or existing satellite and whether\\
&the navigation model is new or the same.\\\midrule
@@ -598,7 +598,7 @@ Idot&Rate of inclination angle (semicircles/second)
\begin{tabular}{lll}
\toprule
%$D$&&$P_u$&$\sigma_N$\\
-Field (IE) & Description\\\toprule
+\textbf{Field (IE)}& \textbf{Description}\\\toprule
SatelliteID&This is the satellite ID that is in the range of 0 to 63. PRN=SatelliteID + 1\\\midrule
SV Health&Satellite health (e.q. 000 means the satellite is fully operational)\\\midrule
$e$&``Eccentricity shows the amount of the orbit deviation from circular (orbit).\\
diff --git a/vorlagen/thesis/src/kapitel_x.tex b/vorlagen/thesis/src/kapitel_x.tex
index fd7947b..445f26e 100644
--- a/vorlagen/thesis/src/kapitel_x.tex
+++ b/vorlagen/thesis/src/kapitel_x.tex
@@ -211,7 +211,7 @@ Although the equivalent ARFCN number is used for uplink and downlink, the freque
\begin{tabular}{lllll}
\toprule
%$D$&&$P_u$&$\sigma_N$\\
-Frequency band&Uplink frequency (MHz)&Downlink frequency (MHz)& Channel number\\\toprule
+\textbf{Frequency band}&\textbf{Uplink frequency (MHz)}&\textbf{Downlink frequency (MHz)}&\textbf{Channel number}\\\toprule
GSM900&880 - 915&925 - 960&0, 1 - 124, 975 - 1023\\\midrule
GSM1800&1710 - 1785&1805 - 1880& 512 - 885\\\bottomrule
\end {tabular}
@@ -293,7 +293,7 @@ Traffic and signalling channels can be split up by their usage, as given in tabl
\begin{tabular}{llll}
\toprule
%$D$&&$P_u$&$\sigma_N$\\
-Channel name & Abbreviation & Function & Direction\\\toprule
+\textbf{Channel name}&\textbf{Abbreviation}&\textbf{Function}&\textbf{Direction}\\\toprule
Traffic channel full rate &TCH/F & Full rate traffic transmission & MS$\leftrightarrow$BSS\\\midrule
Traffic channel half rate&TCH/H& Half rate traffic transmission & MS$\leftrightarrow$BSS
\\\bottomrule
@@ -308,7 +308,7 @@ Traffic channel half rate&TCH/H& Half rate traffic transmission & MS$\leftrighta
\begin{tabular}{llll}
\toprule
%$D$&&$P_u$&$\sigma_N$\\
-Channel name & Abbreviation & Function & Direction\\\toprule
+\textbf{Channel name}&\textbf{Abbreviation}&\textbf{Function}&\textbf{Direction}\\\toprule
Frequency correction channel&FCCH &Frequency correction for oscillator on MS & MS$\leftarrow$BSS\\\midrule
Synchronization channel&SCH&Synchronization information (TDMA frame& MS$\leftarrow$BSS\\
&&number to know current location in hyperframe)\\\midrule
@@ -532,7 +532,7 @@ table \ref{tbl:overviewLoc}.
\begin{tabular}{lllll}
\toprule
%$D$&&$P_u$&$\sigma_N$\\
-Method&Sync.&Advantage\&Disadvantage&Accuracy&Type\\\toprule
+\textbf{Technique}&\textbf{Sync.}&\textbf{Advantage\&Disadvantage}&\textbf{Accuracy}&\textbf{Type}\\\toprule
Cell-ID& No& Works on any cell phone;& Anywhere in cell& Network\\
& &Imprecise&&\\%\midrule
RSS & No& Works on any cell phone;& $\approx 300$ m& Network\\
@@ -674,10 +674,7 @@ used for the clock corrections on the receiver side. More details on these
parameters shall be given in section \ref{sec:SigDemod}. Subframe two and three
are made of \textit{ephemeris data}. Ephemeris
information are precise parameters for predicting the precise orbital
-position of the GPS satellite. Using ephemeris data for the specific
-system time stamp and the equations given in appendix section \ref{sec:gpsConsAndEq}
-the GPS receiver can precisely estimate the position $(x_s,y_s,z_s)$ of
-the satellite. The first three subframes are satellite dependent and do not
+position of the GPS satellite. The first three subframes are satellite dependent and do not
change in the transmitted 25 frames aside from the system time stamp \citep{GPS-Guide}.
\begin{figure}[ht!]
\centering
@@ -1686,58 +1683,62 @@ F8 @\textcolor{red}{\textbf{1}}@.......
\section{RRLP Assistance data}
\label{sec:rrlpassistance}
-Assistance data are of the most important value when it comes to RRLP response time.
+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 frequency and phase shift of
-the visible GPS satellite. In the assistance data packets, same as in the request
-packet, one has to specify what type of assistance information are included in the RRLP assistance packets.
+which allows the AGPS to find ``immediatelly'' 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.
In this thesis, as assistance data, only the almanac, ephemeris, UTC model, ionospheric
model and reference location are transmitted to the MS. There are also other assistance
data like differential GPS corrections (DGPS), real time integrity, acquisition assistance
and reference time but none of these were available to the author, so they were avoided.
The reasons for not including them are of cost and complexity nature.
-DGPS corrections' main task is to give additional accuracy to the GPS measurement reports between $1-3$ m \citep{489522}, however
+DGPS corrections give additional accuracy to the GPS positioning, then the accuracy varies between $1-3$ m \citep{489522}, however
they are rarely used \citep[Chapter 4]{harper2010server-side}. Real
time integrity is a list of satellites the AGPS receiver is not allowed to use in its position estimation because they
have integrity problems \citep[Chapter 4]{harper2010server-side}.
This helps the AGPS receiver to know why assistance data for satellites with errors
-are not included in the ephemeris or almanac as well as to be aware of not using the old
+are not included in the ephemeris or almanac data as well as to be aware of not using the old
ephemeris or almanac cached data instead \citep[Chapter 4]{harper2010server-side}.
Reference time can be considered as the ``most valuable'' data for the MS because it provides ``exact time''
to the AGPS receiver.
This helps the AGPS receiver to better estimate the phase shift required to detect GPS
signals. This phase shift estimation in return allows the AGPS receiver better integration period $\tau$ to detect
-weaker signals in cities or buildings (see section \ref{sec:SigDemod}
-and page \pageref{sec:CAdemod} for better understanding) \citep[Chapter 4]{harper2010server-side}.
+weaker signals in cities or buildings %(see section \ref{sec:SigDemod}
+%and page \pageref{sec:CAdemod} for better understanding)
+\citep[Chapter 4]{harper2010server-side}.
By knowing the reference time, it is straightforward for the AGPS receiver to predict the TLM and
HOW starting words of the transmitted GPS packets from the satellites
-(refer to section \ref{sec:gpsDataAndSignal}) required for synchronization and distance calculation. Reference time data can include the relationship
-between the GSM network and GPS time, as well as the GSM frame number to help the MS to
-synchronize with the BTS (earlier this was described as time synchronized GSM networks which is
+%(refer to section \ref{sec:gpsDataAndSignal})
+required for synchronization and distance calculation. Reference time data can include the relationship
+between the GSM network and GPS time, as well as the GSM frame number to help the MS
+synchronize with the BTS (this was described earlier as time synchronized GSM networks which is
required for methods like E-OTD) \citep[Chapter 4]{harper2010server-side}. Acquisition assistance
-data, as the name itself says provides the AGPS receiver directly with acquisition data. Acquisition data
-are the Doppler frequencies and phase shift precalculated on the BTS for the MS. If this type of data are
-provided to the AGPS receiver, it does not require to compute and search on its on for Doppler frequencies and phase shift
+data, as the name itself indicates provides the AGPS receiver directly with acquisition data. Acquisition data
+are the Doppler frequencies and phase shifts precalculated on the BTS for the MS. If this type of data are
+provided to the AGPS receiver, it does not require to compute and search on its on for Doppler frequencies and phase shifts
from the provided reference time \citep[Chapter 4]{harper2010server-side}. This would speed up the process of getting a
position and would help weak signals to be detected which in return would minimize the reception errors.
As listed above, almanac, ephemeris, UTC model, ionospheric model and reference location are transmitted to the MS. Reference
-location is the location of the BTS and provides the MS with an approximate location which can be used
+location is the location of the BTS and provides the MS with an proximate location which can be used
for the position determination in equations given in appendix \ref{sec:distanceAndPosition}.
Furthermore, this limits the search space in time and frequency domain for satellites
-to lock on, since if the AGPS receiver has access to these data it can not expect to see satellites
+to lock on. For an illustration, if the AGPS receiver has access to these data it can not expect to see satellites
which send signals on the opposite side of the Earth \citep[Chapter 4]{harper2010server-side}.
With the reference location, one sends also the altitude and uncertainty of the included location
-data so that the AGPS receiver inside the MS can determine and limit the time and frequency search space even further.
+data. As a consequence the AGPS receiver can limit the time and frequency search space even further.
The ionospheric model includes data for correcting errors introduced by the radio wave transmission through
-the ionosphere \citep[Chapter 4]{harper2010server-side}. These data are not satellite dependent therefore they
-are not sent for each satellite seperately but once and they are valid for
-all satellites \citep[Chapter 4]{harper2010server-side}. Ephemeris data in RRLP terminology named as navigation data.
+the ionosphere \citep[Chapter 4]{harper2010server-side}. Ionosphere data are not satellite dependent thus they
+are not sent for each satellite seperately but only once since they are valid for
+all satellites \citep[Chapter 4]{harper2010server-side}. Ephemeris data in RRLP terminology are named as navigation data.
+Ephemeris data contain more precise and accurate orbital information of the satellites.
If the reader is interested in the exact description of the transmitted assistance data,
-they can be seen in the following tables \ref{tbl:utcModel}, \ref{tbl:navMessage},
-\ref{tbl:almanacMessage} and \ref{tbl:ionoModel} in the appendix.
+they can be seen in the appendix, in following tables \ref{tbl:utcModel}, \ref{tbl:navMessage},
+\ref{tbl:almanacMessage} and \ref{tbl:ionoModel}.
\begin{lstlisting}[label=lst:GPSAssisData,
caption={\textbf{Structure of data types of GPS assistance data in ASN.1}},
@@ -1758,31 +1759,75 @@ ControlHeader ::= SEQUENCE {
}
\end{lstlisting}
-The packets are constructed in the same manner as RRLP requests with a slight difference of selecting
+The packets are constructed in the same form as RRLP requests however, with a slight difference of selecting
other RRLP components and including assistance data. In this particular example,
only a packet with the reference location shall be presented, a ``complete'' 211 bytes PDU packet constructed by author's
software would require at least four pages to be shown. Instead of RRLP request (\textit{msrPositionReq})
in \textbf{RRLP-Component} one has to choose assistance data (\textit{assistanceData}) (for the purpose
of better understanding in this listening different colors have been used,
this particular difference was bolded in listing \ref{lst:RRLPAssisPER}). Afterwards, one
-needs to specify what type of assistance the packet includes, in this case it is GPS assistance
-data (\textit{gps-AssistData}, marked in red color in listing \ref{lst:RRLPAssisPER}). GPS assistance data were described in the
-two previous paragraphs and therefore shall be omitted here. They shall be only listed in the order as
-specified in the RRLP standard for GPS assistance data, listing \ref{lst:GPSAssisData}: reference time, reference location, DGPS corrections, navigation model,
-ionospheric model, UTC model, almanac, acquisition assistance and real time integrity (all marked with blue color in
-listing \ref{lst:RRLPAssisPER}). The assistance data one
-wants to include in the RRLP packet have to be selected previously.
-Selecting is straightforward and one only is required to set
-the appropriate bit to one (1=included in the packet, 0=not included in the packet). Since in this example only the reference
-location is transmitted inside the RRLP PDU packet, the \textit{refLocation}
+needs to specify for what positioning technique assistance data will be included, in this case it is GPS assistance
+data (\textit{gps-AssistData}, marked in red color in listing \ref{lst:RRLPAssisPER}).
+The assistance data will be listed in the order specified by the RRLP standard, listing \ref{lst:GPSAssisData}: reference time,
+reference location, DGPS corrections, navigation model, ionospheric model, UTC model, almanac,
+acquisition assistance and real time integrity (all marked with blue color in
+listing \ref{lst:RRLPAssisPER}).
+\begin{lstlisting}[label=lst:RRLPAssisPER,
+caption={\textbf{Encoding reference location from ASN.1 to PER}},
+backgroundcolor=\color{light-gray},
+basicstyle=\scriptsize\ttfamily,
+escapechar=@,
+emph={gps-AssistData},
+emphstyle=\color{red},
+emph={[2]referenceTime,refLocation,dgpsCorrections,
+navigationModel,ionosphericModel,utcModel,almanac,acquisAssist,realTimeIntegrity},
+emphstyle={[2]\color{blue}}]
+ RRLP Message:
+44 010..... referenceNumber = 2
+ component(RRLP-Component):
+ ...0.... Extension of RRLP-Component = 0 :Absent
+ @\textbf{....010.}@ @\textbf{RRLP-Component}@ @\textbf{=}@ @\textbf{2}@ @\textbf{:assistanceData}@
+ AssistanceData:
+ .......0 Extension of AssistanceData = 0 :Absent
+11 0....... referenceAssistData = 0 :Absent
+ .0...... msrAssistData = 0 :Absent
+ ..0..... systemInfoAssistData = 0 :Absent
+ ...1.... @\textcolor{red}{gps-AssistData}@ = 1 :Present
+ ....0... moreAssDataToBeSent = 0 :Absent
+ .....0.. extensionContainer = 0 :Absent
+ GPS-AssistData:
+ ControlHeader:
+ ......0. referenceTime = 0 :Absent
+ .......1 refLocation = 1 :Present
+00 0....... dgpsCorrections = 0 :Absent
+ .0...... navigationModel = 0 :Absent
+ ..0..... ionosphericModel = 0 :Absent
+ ...0.... utcModel = 0 :Absent
+ ....0... almanac = 0 :Absent
+ .....0.. acquisAssist = 0 :Absent
+ ......0. realTimeIntegrity = 0 :Absent
+ RefLocation:
+ threeDLocation(Ext-GeographicalInformation):
+ .......0 @\textcolor{narandzasta}{Ext-GeographicalInformation length(octet)}@ = 13 :13 + 1 = 14
+D9 1101....
+ ....1001 @\textcolor{narandzasta}{Ext-GeographicalInformation = 904445940594B200000707000700h}@
+04 00000100
+ . (binary data were removed because of length)
+00 0000....
+ ....0000 Spare Bits = 0000b
+\end{lstlisting}
+The assistance data one wants to include in the RRLP packet have to be selected previously.
+Selecting is straightforward and one simply requires to set the appropriate
+bit to one (1=included in the packet, 0=not included in the packet). Since in this example
+only the reference location is included inside the RRLP PDU packet, the \textit{refLocation}
bit is set to one. Once the variables have been set, the assistance data
have to follow the given order as in listing \ref{lst:GPSAssisData}.
-The top variable data (\textit{referenceTime}) would follow as first and
-bottom variable (\textit{realTimeIntegrity}) would be the last to be included
+The first selected variable (\textit{referenceTime}) would follow as the first and
+the last selected variable (\textit{realTimeIntegrity}) would be the last one included
in the RRLP assistance PDU packet. The reference location has to be converted
into an ellipsoid point with altitude and uncertainty ellipsoid as described
-in the standard \citep{3gppequations} under section \textit{7.3.6}, as shown
-in figure \ref{img:refLocStandard}, described in the following text.
+in the standard \citep{3gppequations} under section \textit{7.3.6}. This is shown
+in figure \ref{img:refLocStandard} and described in the following paragraphs.
\begin{figure}[ht!]
\centering
\includegraphics[scale=0.5]{img/ElipsoidPoint.pdf}
@@ -1794,7 +1839,8 @@ The reference location consists of longitude, latitude, altitude, uncertainty se
uncertainty semi-minor, orientation of major axis, uncertainty of altitude and confidence
level. \textbf{S} is sign of the latitude, it is set to zero if it is North and one if
it is South. \textbf{D} is the altitude direction, it is set to zero if the altitude that
-follows is height and to one if it is depth. Uncertainty semi-major and uncertainty semi-minor
+follows is height (above mean sea level) and to one if it is depth (below mean sea level).
+Uncertainty semi-major and uncertainty semi-minor
are uncertainties for longitude and latitude. Orientation of major axis is the orientation angle
of the BTS between the major axis and North pole in degrees. These terms are depicted in figure
\ref{img:earthElipsoid} by showing the World Geodetic System 1984 (WGS84).
@@ -1806,34 +1852,34 @@ of the BTS between the major axis and North pole in degrees. These terms are dep
\end{figure}
The latitude,
longitude and altitude need to be encoded into a format recognized by the RRLP standard. This is
-straightforward and can be proceeded using the equations shown in \eqref{eq:latLong}, where $\varphi$
+straightforward and can be computed using the equations shown in \eqref{eq:latLong}, where $\varphi$
is the latitude and $\lambda$ is the longitude value in decimal degrees.
-Longitude is encoded as second compliment binary number \citep{3gppequations}.
-The altitude is encoded as it is where one bit increments represent one meter increments.
-The uncertainties for latitude, longitude and altitude were not used since it did not affect
-the position estimation process. Orientation of major axis is not used in this work so it
-was set to zero. Confidence describes the level by which the sent BTS reference position is
+The longitude is encoded as second compliment binary number \citep{3gppequations}.
+The altitude is encoded as it is, where one bit increments represent one meter increments.
+The uncertainties for latitude, longitude and altitude were not used since changing these variables
+did not affect the position estimation process. Orientation of major axis is not used in this work so it
+was set to zero, its modification did not affect the position estimation.
+Confidence describes the level by which the sent BTS reference location is
known to be correct. The confidence is a 7 bit number but ought to take values
-between 0 and 100 since it represents the percentage. In this work it was set
+between 0 and 100 since it represents a percentage. In this work it was set
to zero, i.e. no information is available about the confidence for our reference
-location. It did not change the output behaviour from the MS.
-
-If the reference location is included in the RRLP assistance packet, it is
+location. It did not change the output behaviour from the MS. If the reference
+location is included in the RRLP assistance packet, it is
important to specify the octet length of the reference location. The length of the reference
-location of an ellipsoid point with altitude and uncertainty ellipsoid is of length 14 octets,
-as it can be seen in figure \ref{img:refLocStandard} (amount of rows), it is written as 13 octets
-in the RRLP PDU packet.
-It is always specified as one number less since at least one octet has to be included in the
+location of an ellipsoid point with altitude and uncertainty ellipsoid is of 14 octets,
+as it can be seen from figure \ref{img:refLocStandard} (total number of rows). However, it is written as 13 octets
+in the RRLP PDU packet. Generally as a rule, it is always specified one number less since at least one octet has to be included in the
reference location. There are other reference location standards inside of the RRLP protocol.
-This way the RRLP protocol knows where the data end and where new data may start if they are included.
-What type of reference location is include is defined by the first four bits of the reference location,
-in this case it is $1001$, as it can be seen in figure \ref{img:refLocStandard}. This is an additional
+Using this mechanism, the RRLP protocol knows where the data ends and where new data may start in case other assistance data follow.
+Which standard for defining the reference location was used, is included as well. It is defined by the first four bits of the reference location,
+in this case it is $1001$, as it can be seen from figure \ref{img:refLocStandard} in first row. This is an additional
mechanism for error control, if the numbers do not match when the transmitted binary data have been decoded
then the MS can return an error and ask for retransmission of the data. Information related to the reference
location in the example listing \ref{lst:RRLPAssisPER} are marked with orange color. Once the assistance data
-have been transmitted to the MS, it shall respond back with an acknowledgement or error depending if the
-data were correctly received and parsed by the MS. The acknowledgement is going to have the same reference number
-as the assistance packet. In the next section more details shall be given on the RRLP response from the MS.
+have been transmitted to the MS, it will respond back with an acknowledgement or error. This response depends on
+the MS, if the data were correctly received and parsed. The acknowledgement is going to have the same reference number
+as the assistance packet which is not always the case for the error.
+In the next section, an RRLP response from the MS will be described and analysed.
\begin{equation}
\label{eq:latLong}
\begin{array}{l}
@@ -1843,8 +1889,7 @@ as the assistance packet. In the next section more details shall be given on the
\quad\Longleftarrow\quad
\begin{split}
\mbox{Latitude}
- \end{split}\\
- \\
+ \end{split} \; \; \; \;
\begin{split}
Long = \frac{2^{24}}{360}\cdot\lambda
\end{split}
@@ -1855,67 +1900,18 @@ as the assistance packet. In the next section more details shall be given on the
\end{array}
\end{equation}
-
-\begin{lstlisting}[label=lst:RRLPAssisPER,
-caption={\textbf{Encoding reference location from ASN.1 to PER}},
-backgroundcolor=\color{light-gray},
-basicstyle=\scriptsize\ttfamily,
-escapechar=@,
-emph={gps-AssistData},
-emphstyle=\color{red},
-emph={[2]referenceTime,refLocation,dgpsCorrections,
-navigationModel,ionosphericModel,utcModel,almanac,acquisAssist,realTimeIntegrity},
-emphstyle={[2]\color{blue}}]
- RRLP Message:
-44 010..... referenceNumber = 2
- component(RRLP-Component):
- ...0.... Extension of RRLP-Component = 0 :Absent
- @\textbf{....010.}@ @\textbf{RRLP-Component}@ @\textbf{=}@ @\textbf{2}@ @\textbf{:assistanceData}@
- AssistanceData:
- .......0 Extension of AssistanceData = 0 :Absent
-11 0....... referenceAssistData = 0 :Absent
- .0...... msrAssistData = 0 :Absent
- ..0..... systemInfoAssistData = 0 :Absent
- ...1.... @\textcolor{red}{gps-AssistData}@ = 1 :Present
- ....0... moreAssDataToBeSent = 0 :Absent
- .....0.. extensionContainer = 0 :Absent
- GPS-AssistData:
- ControlHeader:
- ......0. referenceTime = 0 :Absent
- .......1 refLocation = 1 :Present
-00 0....... dgpsCorrections = 0 :Absent
- .0...... navigationModel = 0 :Absent
- ..0..... ionosphericModel = 0 :Absent
- ...0.... utcModel = 0 :Absent
- ....0... almanac = 0 :Absent
- .....0.. acquisAssist = 0 :Absent
- ......0. realTimeIntegrity = 0 :Absent
- RefLocation:
- threeDLocation(Ext-GeographicalInformation):
- .......0 @\textcolor{narandzasta}{Ext-GeographicalInformation length(octet)}@ = 13 :13 + 1 = 14
-D9 1101....
- ....1001 @\textcolor{narandzasta}{Ext-GeographicalInformation = 904445940594B200000707000700h}@
-04 00000100
- .
- . (binary data were removed because of length)
- .
-00 0000....
- ....0000 Spare Bits = 0000b
-\end{lstlisting}
-\clearpage
\section{RRLP Response}
-In this section the RRLP response from the MS shall be analysed. The RRLP response is
-constructed in the same manner as the RRLP request and assistance data by following
-ASN.1 rules precisely specified in the RRLP standard. RRLP response is produced by the MS itself.
-It may include the estimated position, data for estimating the position on the BTS (if MS assisted was
-choosen as the prefered method) or errors indicating that some of the
-previously stated assistance data are missing. Missing data and errors are
-specified inside of the RRLP response. The response data shall be PER encoded and require
-to be decoded into the ASN.1 notation. In listing \ref{lst:RRLPRespError} an example of an
-RRLP response with an error can be seen. The location error bit is set if the location
-of the MS is not present within the message (marked in red). The MS may sometimes supply more
-information on the error if the MS knows this information (newer models support this).
-In case it does support more information, it shall set an optional IE \textit{additionalAssistanceData} bit
+The RRLP response is constructed by the MS in the same manner as the RRLP request and assistance data by following
+ASN.1 rules precisely specified in the RRLP standard.
+The response may include the estimated position, data for estimating the position on the BTS (if MS-assisted method was
+chosen) or errors indicating that some of the assistance data are missing. Missing data and errors are
+specified inside of the RRLP response. The response data is PER encoded and requires
+to be decoded into the ASN.1 notation. For illustration, in listing \ref{lst:RRLPRespError}, an erroneous
+RRLP response is shown. To distinguish successful from erroneous responses, two different bits
+are used in the response message, \textit{locationInfo} and \textit{locationError}. The location error
+bit is set if the location of the MS is not present within the message (marked in red).
+The MS may include more information on the error if it can identify the error (newer models support this).
+In case the MS does support more information, an optional IE \textit{additionalAssistanceData} bit will be set
(marked in cyan).
\begin{lstlisting}[label=lst:RRLPRespError,
caption={\textbf{Decoding an error RRLP response from Samsung Galaxy S3}},
@@ -1954,22 +1950,19 @@ emphstyle={[2]\color{blue}}]
GPSAssistanceData:
.000101. @\textcolor{narandzasta}{GPSAssistanceData length(octet)}@ = 5 :5 + 1 = 6
.......1 @\textcolor{narandzasta}{GPSAssistanceData = E80000000000h}@
-D0 11010000
-00 00000000
-00 00000000
-00 00000000
-00 00000000
+ . (binary data were removed because of length)
00 0000000.
.......0 Spare Bits = 0b
-\end{lstlisting}
-This is followed with a more detailed explanation of the error that not sufficient
-assistance data were present, \textit{LocErrorReason} (marked with blue color). There
-are other possible location error reasons as well and they are listed in listing
-\ref{lst:RRLPPosError}. Depending on the MS model, it can even further specify
-what kind of GPS assistance data are missing. This shall be well specified by setting
-the IE \textit{gpsAssistanceData} bit, this is shown in listing \ref{lst:RRLPRespError}
-(marked with magenta color). If this bit is set, the length of the IE for requested missing assistance
-data shall be exactly specified as well as what assistance data are missing (marked in orange color).
+\end{lstlisting}\newpage
+In the case that more information of the error is known, it will be followed with a more detailed explanation
+of the error. For this particular example, not sufficient assistance data were present,
+\textit{LocErrorReason} (marked with blue color). There
+are other possible location error reasons as well. All location errors are listed in listing
+\ref{lst:RRLPPosError} (self-explanatory). Depending on the MS model, it can be even further specified
+what kind of GPS assistance data were missing. This is well specified by setting
+the IE \textit{gpsAssistanceData} bit, as shown in listing \ref{lst:RRLPRespError}
+(marked with magenta color). If this bit was set, the length of the IE for requested missing assistance
+data will be exactly specified as well as what assistance data are missing (marked in orange color).
\begin{lstlisting}[label=lst:RRLPPosError,
caption={\textbf{Possible location error reasons}},
backgroundcolor=\color{light-gray},
@@ -1998,78 +1991,17 @@ LocErrorReason ::= ENUMERATED {
\label{img:RequestedGPSAss}
\end{figure}
The first two bytes of the IE \textit{GPSAssistanceData} contain the information for requested
-assistance AGPS data (marked in orange color). They can be seen
+assistance data (marked in orange color). Information of missing assistance data can be seen
in figure \ref{img:RequestedGPSAss} \citep{49.031V8.1.0}. If one of these bits from A to K is set,
the MS requires more assistance data. The meaning of the bits in figure \ref{img:RequestedGPSAss}
-is given in table \ref{tbl:RRLPReqAss}. In this particular example, the first two bytes are: \textbf{E800},
+are explained in table \ref{tbl:RRLPReqAss}. In this particular example, the first two bytes are: \textbf{E800},
indicating acquisition assistance, reference time, reference location and the navigation model are requsted
-by the MS as assistance data. The next RRLP response example, shown in listing \ref{lst:RRLPRespSucc}, is
-a response with a successfully estimated position! A successful or erroneous position response
-is of RRLP measurement responses type, this can be seein in listing \ref{lst:RRLPRespSucc}
-(bolded, in listing \ref{lst:RRLPRespError} it is bolded as well). It can not be
-distinguished by analysing the first byte of the response stream! In the second byte, two mutually exclusive IE
-contain the information if the response contains the location information or not, \textit{locationInfo} bit must
-be set and \textit{locationError} must be unset (both marked in red color in listing \ref{lst:RRLPRespSucc}).
-If the IE \textit{locationInfo} bit is one and \textit{locationError} bit zero, then the position of the MS is
-included in the response. Aside from the position information, the time when the position measurement
-was performed is included as well however, only the least significant bits in the range of miliseconds. The
-most significant bits shall be derived by the SMLC using the GSM frame number, included in the IE \textit{refFrame}.
-\textit{refFrame} contains the GSM frame number as observed by the MS \citep{49.031V8.1.0}!
-The time of miliseconds can be found in the IE \textit{gpsTOW}. The included time is
-not in UTC format and would require additional conversions.
-The elements of \textit{locationInfo} can be seen in listing \ref{lst:RRLPLocInfo}. The IE \textit{fixType} contains
-the information if the performed measurement was 2D or 3D.
-\begin {table}[ht]
-\caption{Requested AGPS assistance data bit meaning. Table courtesy of \citep{49.031V8.1.0}.}
-\label{tbl:RRLPReqAss}\centering
-%\rowcolor{2}{light-gray}{}
-\scriptsize\fontfamily{iwona}\selectfont
-\begin{tabular}{lllcc}
-\toprule
-%$D$&&$P_u$&$\sigma_N$\\
-Bit (IE) & Description\\\toprule
-$A$&Acquisition assistance requested\\\midrule
-$B$&Reference time requested\\\midrule
-$C$&Reference location requested\\\midrule
-$D$&DGPS corrections requested\\\midrule
-$E$&Navigation model requested\\\midrule
-$F$&Ionospheric model requested\\\midrule
-$G$&UTC model requested\\\midrule
-$H$&Almanac data requested\\\midrule
-$I$&Real time integrity requested\\\midrule
-$J$&Ephemeris extension requested\\\midrule
-$K$&Ephemeris extension check requested
-\\\bottomrule
-\end {tabular}
-\end {table}
-\begin{lstlisting}[label=lst:RRLPLocInfo,
-caption={\textbf{Structure of data types of location info data in ASN.1}},
-backgroundcolor=\color{light-gray},
-basicstyle=\scriptsize\ttfamily,
-escapechar=@]
--- Location information IE
-LocationInfo ::= SEQUENCE {
- refFrame INTEGER (0..65535), -- Reference Frame number
- -- If refFrame is within (42432..65535), it shall be ignored by the receiver
- -- in that case the MS should provide GPS TOW if available
- gpsTOW INTEGER (0..14399999) OPTIONAL, -- GPS TOW
- fixType FixType,
- -- Note that applicable range for refFrame is 0 - 42431
- -- Possible shapes carried in posEstimate are
- -- ellipsoid point, ellipsoid point with uncertainty circle,
- -- ellipsoid point with uncertainty ellipse,
- -- ellipsoid point with altitude and uncertainty ellipsoid
- posEstimate Ext-GeographicalInformation
-}
+by the MS as assistance data.
-FixType ::= INTEGER {
- twoDFix (0),
- threeDFix (1)
-} (0..1)
-\end{lstlisting}
-The position information is extracted with the inverse process as it was specified for the reference location.
-Equations to return from the bit format to decimal degrees are given in equation \eqref{eq:latLongBack}. %\clearpage
-In the next chapter, more details shall be given on the implementation of the complete system.
+The next RRLP response example, shown in listing \ref{lst:RRLPRespSucc}, is
+a response with a successfully estimated position! In the second byte, two mutually exclusive IE
+contain the information if the response was successful and contains the location information, \textit{locationInfo} bit must
+be set and \textit{locationError} must be zero (both marked in red color in listing \ref{lst:RRLPRespSucc}).
\begin{lstlisting}[label=lst:RRLPRespSucc,
caption={\textbf{Decoding a successful RRLP response from iPhone 3GS}},
backgroundcolor=\color{light-gray},
@@ -2106,22 +2038,71 @@ B6 1....... FixType = 1 :threeDFix
posEstimate(Ext-GeographicalInformation):
.01101.. @\textcolor{narandzasta}{Ext-GeographicalInformation length(octet)}@ = 13 :13 + 1 = 14
......10 @\textcolor{narandzasta}{Ext-GeographicalInformation = 904445840594A6016316114F1D44h}@
-41 01000001
-11 00010001
-16 00010110
-10 00010000
-16 00010110
-52 01010010
-98 10011000
-05 00000101
-8C 10001100
-58 01011000
-45 01000101
-3C 00111100
-75 01110101
+ . (binary data were removed because of length)
10 000100..
......00 Spare Bits = 00b
\end{lstlisting}
+If the IE \textit{locationInfo} bit is set and \textit{locationError} bit is zero, then the position of the MS is
+included in the response. Aside from the position information, the time when the position measurement
+was performed is included as well however, only the least significant bits in the range of miliseconds. The
+most significant bits ought to be derived by the SMLC using the GSM frame number, included in the IE \textit{refFrame}.
+In this thesis this is not known and used. \textit{refFrame} contains the GSM frame number as observed by
+the MS \citep{49.031V8.1.0}. The time of miliseconds can be found in the IE \textit{gpsTOW}. The included time is
+not in UTC format and would require additional conversions.
+The elements of \textit{locationInfo} can be seen in listing \ref{lst:RRLPLocInfo}. The IE \textit{fixType} contains
+the information if the performed measurement was 2D or 3D GPS fix. An 2D fix is when only 3 GPS satellites are
+used to estimate the position, the GPS receiver assumes it is on the earth surface located with the most recent
+known altitude from cache \citep{understandGPS}. 3D fix is a sign of at least 4 GPS satellites have been used to perform
+the position estimation \citep{understandGPS}. The position information is extracted with the
+inverse process as it was specified for the reference location, the reading is in the same format
+as earlier in figure \ref{img:refLocStandard}. Equations to return from the PER bit format to decimal
+degrees are given in equation \eqref{eq:latLongBack}. %\clearpage
+In the next chapter, more details are revealed how it was implemented.
+
+\begin {table}[ht]
+\caption{Requested AGPS assistance data bit meaning. Table courtesy of \citep{49.031V8.1.0}.}
+\label{tbl:RRLPReqAss}\centering
+%\rowcolor{2}{light-gray}{}
+\scriptsize\fontfamily{iwona}\selectfont
+\begin{tabular}{llll}
+\toprule
+%$D$&&$P_u$&$\sigma_N$\\
+\textbf{Bit (IE)} & \textbf{Description}&\textbf{Bit (IE)} & \textbf{Description}\\\toprule
+$A$&Acquisition assistance requested&$G$&UTC model requested\\\midrule
+$B$&Reference time requested&$H$&Almanac data requested\\\midrule
+$C$&Reference location requested&$I$&Real time integrity requested\\\midrule
+$D$&DGPS corrections requested&$J$&Ephemeris extension requested\\\midrule
+$E$&Navigation model requested&$K$&Ephemeris extension check requested\\\midrule
+$F$&Ionospheric model requested
+\\\bottomrule
+\end {tabular}
+\end {table}
+\begin{lstlisting}[label=lst:RRLPLocInfo,
+caption={\textbf{Structure of data types of location info data in ASN.1}},
+backgroundcolor=\color{light-gray},
+basicstyle=\scriptsize\ttfamily,
+escapechar=@]
+-- Location information IE
+LocationInfo ::= SEQUENCE {
+ refFrame INTEGER (0..65535), -- Reference Frame number
+ -- If refFrame is within (42432..65535), it shall be ignored by the receiver
+ -- in that case the MS should provide GPS TOW if available
+ gpsTOW INTEGER (0..14399999) OPTIONAL, -- GPS TOW
+ fixType FixType,
+ -- Note that applicable range for refFrame is 0 - 42431
+ -- Possible shapes carried in posEstimate are
+ -- ellipsoid point, ellipsoid point with uncertainty circle,
+ -- ellipsoid point with uncertainty ellipse,
+ -- ellipsoid point with altitude and uncertainty ellipsoid
+ posEstimate Ext-GeographicalInformation
+}
+
+FixType ::= INTEGER {
+ twoDFix (0),
+ threeDFix (1)
+} (0..1)
+\end{lstlisting}
+
\begin{equation}
\label{eq:latLongBack}
\begin{array}{l}
@@ -2550,7 +2531,7 @@ table \ref{tbl:smartphones}.
\begin{tabular}{ll}
\toprule
%$D$&&$P_u$&$\sigma_N$\\
-Cell phone & Manufacturer \& Country\\\toprule
+\textbf{Cell phone} & \textbf{Manufacturer \& Country}\\\toprule
$Defy$&Motorola, USA\\\midrule
$iPhone$ $4$&Apple, USA\\\midrule
$iPhone$ $3GS$&Apple, USA\\\midrule
@@ -2716,7 +2697,7 @@ in the left corner of it.
\begin{tabular}{lllll}
\toprule
%$D$&&$P_u$&$\sigma_N$\\
-Cell phone model&RRLP(E)&RRLP(A)&RRLP&Type of error (or missing data)\\\toprule
+\textbf{Cell phone model}&\textbf{RRLP(E)}&\textbf{RRLP(A)}&\textbf{RRLP}&\textbf{Type of error (or missing data)}\\\toprule
$Defy$&No&No&No&No response (time out) \\\midrule
$iPhone$ $4$&No&No&No&Reference time, Navigation Model,\\
&&&&Reference Location\\\midrule
@@ -2876,13 +2857,13 @@ data can be provided by the GSM network operator. The findings of this study ind
of smart phones can be tracked accurately and precisely without their knowledge. One implication of this
evidence is to suggest that it would not be complicated for German law enforcement agencies to employ this precise
surveillance technique to follow suspects. According to the German Interior Minister Hans-Peter Friedrich,
-in 2011 silent SMS were employed with the UL-TDOA technique to track down suspects \citep{silentPolice}
-\citep{silentPolice1}. The law is unclear if silent SMS can be considered communication when taking into
+in 2011 silent SMS were employed with the UL-TDOA technique to track down suspects \citep{silentPolice}.
+The law is unclear if silent SMS can be considered communication when taking into
consideration that no information is sent to the GSM user, and it remains a gray area from the legal point of view
-\citep{silentPolice1}. "The state found that it was not communication, since there is no content. This is useful,
+\citep{silentPolice}. "The state found that it was not communication, since there is no content. This is useful,
because if it is not a communication, it does not fall under the framework of the inviolability of
telecommunications described in Article 10 of the German Constitution." said Mathias Monroy from
-Heise Online \citep{silentPolice1}. The development of a working RRLP application and the obtained
+Heise Online \citep{silentPolice}. The development of a working RRLP application and the obtained
results from this work enhance the understanding of AGPS receivers and may be further used to
better understand how the assistance data influence the obtained results.
Finally, a number of important limitations in the obtained results need to be considered.
diff --git a/vorlagen/thesis/src/maindoc.lof b/vorlagen/thesis/src/maindoc.lof
index 1dfa7da..ea0a550 100644
--- a/vorlagen/thesis/src/maindoc.lof
+++ b/vorlagen/thesis/src/maindoc.lof
@@ -15,7 +15,7 @@
\contentsline {figure}{\numberline {3.1}{\ignorespaces GPS Simple working principle, a) example in 3D space with spheres b) example in 2D space with circles.\relax }}{19}{figure.caption.19}
\contentsline {figure}{\numberline {3.2}{\ignorespaces One frame of 1500 bits on L1 frequency carrier. Image courtesy of \citep {harper2010server-side}.\relax }}{21}{figure.caption.20}
\contentsline {figure}{\numberline {3.3}{\ignorespaces Subframes always start with telemetry and handover words\relax }}{21}{figure.caption.21}
-\contentsline {figure}{\numberline {3.4}{\ignorespaces BPSK Modulation - First signal is the carrier wave, and it is multiplied (mixed) with the second signal, which are the data to be transmitted. The resulting signal at the output of the satellite antenna is the third one.\relax }}{23}{figure.caption.22}
+\contentsline {figure}{\numberline {3.4}{\ignorespaces BPSK Modulation - First signal is the carrier wave, and it is multiplied (mixed) with the second signal, which are the data to be transmitted. The resulting signal at the output of the satellite antenna is the third one.\relax }}{22}{figure.caption.22}
\contentsline {figure}{\numberline {3.5}{\ignorespaces Modulation of the GPS signal L1. Image courtesy of \citep {harper2010server-side}.\relax }}{23}{figure.caption.23}
\contentsline {figure}{\numberline {3.6}{\ignorespaces Two equivalent carrier waves with the same frequency but different phase shift\relax }}{26}{figure.caption.24}
\contentsline {figure}{\numberline {3.7}{\ignorespaces Demodulation of the L1 GPS signal\relax }}{27}{figure.caption.25}
@@ -29,8 +29,8 @@
\addvspace {10\p@ }
\contentsline {figure}{\numberline {4.1}{\ignorespaces RRLP Request protocol. Assistance data can be sent before the request is made. If the assistance data are sent, their reception acknowledgement is sent as a response from the MS. Image courtesy of \citep {harper2010server-side} and \citep {04.31V8.18.0}.\relax }}{38}{figure.caption.33}
\contentsline {figure}{\numberline {4.2}{\ignorespaces An example of constructing an RRLP request. Image courtesy of \citep {harper2010server-side}.\relax }}{43}{figure.caption.34}
-\contentsline {figure}{\numberline {4.3}{\ignorespaces Reference location is a 14 octet stream built according to the given rule as specified in the standard \citep {3gppequations} under section \textit {7.3.6}. Image courtesy of \citep {3gppequations}.\relax }}{46}{figure.caption.35}
-\contentsline {figure}{\numberline {4.4}{\ignorespaces World Geodetic System 1984. Image courtesy of \citep {harper2010server-side}.\relax }}{47}{figure.caption.36}
+\contentsline {figure}{\numberline {4.3}{\ignorespaces Reference location is a 14 octet stream built according to the given rule as specified in the standard \citep {3gppequations} under section \textit {7.3.6}. Image courtesy of \citep {3gppequations}.\relax }}{47}{figure.caption.35}
+\contentsline {figure}{\numberline {4.4}{\ignorespaces World Geodetic System 1984. Image courtesy of \citep {harper2010server-side}.\relax }}{48}{figure.caption.36}
\contentsline {figure}{\numberline {4.5}{\ignorespaces Requested AGPS assistance data to be delivered. Image courtesy of \citep {49.031V8.1.0}.\relax }}{50}{figure.caption.37}
\addvspace {10\p@ }
\contentsline {figure}{\numberline {5.1}{\ignorespaces nanoBTS with two external antennas and five connection ports\relax }}{54}{figure.caption.39}
diff --git a/vorlagen/thesis/src/maindoc.lot b/vorlagen/thesis/src/maindoc.lot
index 62ac1bd..3ebdceb 100644
--- a/vorlagen/thesis/src/maindoc.lot
+++ b/vorlagen/thesis/src/maindoc.lot
@@ -7,7 +7,7 @@
\contentsline {table}{\numberline {2.4}{\ignorespaces Overview of the localization techniques.\relax }}{18}{table.caption.18}
\addvspace {10\p@ }
\addvspace {10\p@ }
-\contentsline {table}{\numberline {4.1}{\ignorespaces Requested AGPS assistance data bit meaning. Table courtesy of \citep {49.031V8.1.0}.\relax }}{51}{table.caption.38}
+\contentsline {table}{\numberline {4.1}{\ignorespaces Requested AGPS assistance data bit meaning. Table courtesy of \citep {49.031V8.1.0}.\relax }}{52}{table.caption.38}
\addvspace {10\p@ }
\addvspace {10\p@ }
\contentsline {table}{\numberline {6.1}{\ignorespaces Smart phone models used for testing in the thesis.\relax }}{64}{table.caption.42}