summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRefik Hadzialic2012-09-05 13:50:13 +0200
committerRefik Hadzialic2012-09-05 13:50:13 +0200
commit15c1aa9a6104b80e35602ee8f8d8ec9ff62c3d72 (patch)
tree207a1c410db77ee7eeb73e3563cb0c4d2026761c
parentchanges (diff)
downloadmalign-15c1aa9a6104b80e35602ee8f8d8ec9ff62c3d72.tar.gz
malign-15c1aa9a6104b80e35602ee8f8d8ec9ff62c3d72.tar.xz
malign-15c1aa9a6104b80e35602ee8f8d8ec9ff62c3d72.zip
RRLP corrections
-rw-r--r--vorlagen/thesis/maindoc.pdfbin15868709 -> 15870751 bytes
-rw-r--r--vorlagen/thesis/src/kapitel_x.tex228
2 files changed, 116 insertions, 112 deletions
diff --git a/vorlagen/thesis/maindoc.pdf b/vorlagen/thesis/maindoc.pdf
index 5b75733..d41ca63 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 1ae0bcc..765d946 100644
--- a/vorlagen/thesis/src/kapitel_x.tex
+++ b/vorlagen/thesis/src/kapitel_x.tex
@@ -1647,31 +1647,27 @@ be present in the assistance data \citep{998892}.
\chapter{Radio Resource Location Protocol}
\label{rrlpChapt}
-This chapter shall focus on the Radio Resource Location Protocol (RRLP) and a description
-how it works inside of the GSM network shall be given. RRLP is a protocol from the family of Location Services (LCS)
+This chapter examines the Radio Resource Location Protocol (RRLP) and provides a description
+how it works inside of the GSM network. RRLP is a protocol from the family of Location Services (LCS)
which were not part of the initial GSM standard. It is a widely used protocol in other cellular
networks like UMTS, it was later introduced to the GSM system as well \citep{3GPPTS03.71}. It was
developed by the request of government and rescue organizations to fulfill the wireless enhanced 911
standard in the US, each mobile user had to be located within a range of 300 m in 95\% of cases and
-within 100 m in 67\% of cases \citep{E911Accuracy}.
-
-The standard supports three positioning mechanisms: E-OTD, UL-TDOA and AGPS \citep{3GPPTS03.71}.
+within 100 m in 67\% of cases \citep{E911Accuracy}. The RRLP protocol supports three positioning
+techniques: E-OTD, UL-TDOA and AGPS \citep{3GPPTS03.71}.
The LCS process can be divided into two seperate stages, signal measurements and
-position estimation from the derived data in the previous stage. In this chapter
-the description shall be given on how to make an RRLP request, how to send assistance
-data and then more information shall be given on its response.
+position estimation from the derived data in the previous stage.
\section{RRLP Request}
-In this section the RRLP protocol and its request shall be reviewed in more detail.
RRLP represents the connection/protocol between the Serving Mobile Location Center (SMLC)
and the standalone handset, in this case the MS \citep[Chapter 5]{harper2010server-side}.
-The SMLC node contains the functionaly to support
-location services for the GSM network \citep{3GPPTS03.71}. SMLCs primary function is to manage
-the overall coordination and scheduling of resources required to perform the localization of the MS
-and it is located on the Base Station Controller (BSC) \citep{3GPPTS03.71}.
+The SMLC node contains the functionality to support
+location services for the GSM network \citep{3GPPTS03.71}. SMLC is located on the Base
+Station Controller (BSC) \citep{3GPPTS03.71}. SMLC' primary function is to manage
+the overall coordination and scheduling of resources required to perform the localization of the MS.
SMLC controls the LMU's as well but since in this work no LMU were available this part
-shall be skipped as well as the description of E-OTD and UL-TDOA localization.
+can be skipped as well as the description of E-OTD and UL-TDOA localization.
Before an attempt is made, of requesting the SMLC to initialize an RRLP request, an SDCCH connection
channel has to be initialized to the MS, this connection can not be seen by the MS user\footnote{However,
@@ -1689,29 +1685,32 @@ connected to the GSM network.}.
\end{figure}
Data sent inside of a protocol are called Protocol Data Unit (PDU). On different
-layer levels PDU's may take a different shape and size because of the encapsulation or splitting \citep{kozierok2005the} \citep{stevens1994tcp/ip}.
-In RRLP, the PDU's sent from the SMLC ought to be not greater than 244 bytes\footnote{Bytes of 8 bits!},
-although the standard defines that larger packets shall be split in lower layers, in this work the
-rule of 244 bytes has been obeyed and each PDU packet is not greater
-than 211 bytes \citep{04.31V8.18.0}. In the RRLP standard terms, the messages are entitled
+layer levels PDU's may take a different shape and size because of the encapsulation
+or splitting \citep{kozierok2005the} \citep{stevens1994tcp/ip}.
+In RRLP the PDU's sent from the SMLC are not allowed be greater than 244 bytes\footnote{Bytes of 8 bits!} \citep{04.31V8.18.0}.
+Although the standard defines that larger packets ought to be split into smaller pieces in lower layers, in this work the
+rule of 244 bytes has been obeyed due to crashing of the GSM operating software (OpenBSC), thus each PDU packet was not greater
+than 211 bytes. In the RRLP standard terms, the messages are entitled
as \textit{components} and fields in the messages (components) are labelled as \textit{information elements} (IE) \citep{04.31V8.18.0}.
The SMLC may send only the request for the position of the MS or it may assist the MS with assistance data
-required to estimate the position (in case of an AGPS request, these data may be ephemeris, almanac,
-accurate timing data and similar data that help to estimate the position in a shorter period of time).
+required to estimate its position. In case of an AGPS request, assistance data may be ephemeris, almanac,
+accurate timing data or other assistance data that may help the receiver to estimate its position in a shorter period of time.
The RRLP protocol is shown in figure \ref{img:RRLPReqProt}. Dashed lines represent optionally transmitted data
-like assistance data according to which an acknowledgement or error shall be produced. Once the MS obtains the RRLP request,
-after a period of processing time it shall respond to the SMLC with the position of the MS or with an error IE indicating what
-assistance data are missing or why it can not return the position \citep{04.31V8.18.0} \citep{49.031V8.1.0}. In the response component IE it is exactly indicated
-what type of data ought to be sent to the MS so it can complete the RRLP request and give back its
-position. To save bandwidth space in the communication between the SMLC and MS, it can be proceeded in such a manner that
-first the RRLP request is sent out for the position estimation and then if the MS requires some of the assistance data,
-it shall send a request for those data back to the SMLC and then the SMLC can send the required data and expect an
-successful response from the MS. However, in this work the author had a different approach in that sense, that first
-all the RRLP assistance data were sent and then the RRLP position request. This way, sending all assistance data,
-was choosen over the other idea of waiting for the MS response because in OpenBSC it was not possible to access
-directly the response data without querying the database directly. 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 the complete network!
+like the assistance data. If assistance data are present, an acknowledgement or error will be produced by the MS after
+every RRLP assistance packet has arrived. Once the MS obtains the RRLP request,
+after a period of processing time, the MS will send its response back to the SMLC. The response may contain the position of the MS,
+an error IE indicating what assistance data are missing or a reason why the MS could not return its position \citep{04.31V8.18.0} \citep{49.031V8.1.0}.
+In the response IE, it is exactly indicated
+what type of data ought to be sent back to the MS so that it can complete the RRLP request and deliver its position.
+To save bandwidth space in the communication between the SMLC and MS, it can be proceeded in such a manner that
+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
+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
+the complete network!
The structure of the RRLP messages (requests, assistance data and response) is well defined using
Abstract Syntax Notation One (ASN.1) in the technical specifications 3GPP 04.31
@@ -1721,13 +1720,17 @@ structures \citep[Chapter 8]{sharp2008principles} \citep{ITU-TX.680}. In other w
to describe data in an indepedent representation of programming languages in which a protocol is implemented.
In this section, only some of the mostly important and used parts of the RRLP protocol
inside of the thesis shall be presented, more details can be found in the
-technical specifications \citep{49.031V8.1.0} \citep{ETSITS144031}. Structure
-of the RRLP message encoding for transmission can be seen in listing \ref{lst:RRLP}.
-Further details on some of the unknown terms are given in listings
-\ref{lst:RRLPReq} and \ref{lst:RRLPReqData}. An example how to build an RRLP request packet shall be given,
-then it shall be encoded using Packed Encoding Rules (PER). PER is one of the telecommunication
-standards used for encoding and decoding messages inside of protocols specified in the ASN.1
-notation \citep{ITU-TX.691}.
+technical specifications \citep{49.031V8.1.0} \citep{ETSITS144031}. It is important to understand the meaning
+of ASN.1 types before proceeding with an RRLP example. A short summary for the used ASN.1
+types elements will be provided parallely to the RRLP message structure. Structure of the
+RRLP message encoding for transmission can be seen in listing \ref{lst:RRLP}.
+The IE from listing \ref{lst:RRLP} are variables that can take certain values. The domain of these values
+is shown in listings \ref{lst:RRLPReq} and \ref{lst:RRLPReqData}.
+The explanation of listings \ref{lst:RRLP}, \ref{lst:RRLPReq} and \ref{lst:RRLPReqData}
+will follow in short after the reader has been introduced to the ASN.1 and RRLP message
+format standard.
+%Without the explanation it is not possible to understand the message structure
+%and build RRLP packets. Then it will be followed by an example of an RRLP request packet.
\newpage
\begin{lstlisting}[label=lst:RRLP,
caption={\textbf{Structure of the RRLP message in ASN.1}},
@@ -1768,82 +1771,83 @@ RRLP-Component ::= CHOICE {
}
END
\end{lstlisting}
-\begin{lstlisting}[label=lst:RRLPReq,
-caption={\textbf{Structure of the RRLP request in ASN.1}},
-backgroundcolor=\color{light-gray},
-basicstyle=\scriptsize\ttfamily]
--- Measurement Position request component
-
-MsrPosition-Req ::= SEQUENCE {
- positionInstruct PositionInstruct,
- referenceAssistData ReferenceAssistData OPTIONAL,
- msrAssistData MsrAssistData OPTIONAL,
- systemInfoAssistData SystemInfoAssistData OPTIONAL,
- gps-AssistData GPS-AssistData OPTIONAL,
- extensionContainer ExtensionContainer OPTIONAL,
- ...,
- -- Release 98 extension element
- rel98-MsrPosition-Req-extension Rel98-MsrPosition-Req-Extension OPTIONAL
-}
-\end{lstlisting}
-PER is intended for use in circumstances where
-minimizing the size of the representation of values is the major concern
-in the choice of encoding rules \citep{ITU-TX.691}. In other words, it compresses the data
-in the PDU packets by limiting the bit field length to the minimal amount of
-bits required to define the minimal and maximal variable values defined in the standard.
-There are two variations of PER,
-aligned and nonaligned \citep{ITU-TX.691}. In the RRLP protocol the nonaligned type of PER
-is used. The major difference between aligned and nonaligned PER lies in the fact that some
-data structures are aligned on octet 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.
-
-Before proceeding with an example, summary for the used ASN.1 type
-elements shall be provided otherwise it is not possible to proceed with an example
-RRLP request. A type of \textbf{SEQUENCE} is used to
+A type of \textbf{SEQUENCE} is used to
reference a ``fixed, ordered list of types (some of which may be declared to be
optional); each value of the sequence type is an ordered list of values,
-one from each component type'' \citep{ITU-TX.691} where the
+one from each component type'' \citep{ITU-TX.691} while the
IE (fields) of \textbf{OPTIONAL} type do not need to be included and are not mandatory.
Variables defined by \textbf{CHOICE} are used to reference ``a list of distinct types;
each value of the choice type is derived from the value of one of the
component types'' \citep{ITU-TX.691}, i.e. only one element is selected from the
list and the elements of the list are defined according to their variable type.
Variables of type \textbf{ENUMERATED} are ``simple types whose values are given
-distinct identifiers as part of the type notation'' \citep{ITU-TX.691}, these types
+distinct identifiers as part of the type notation'' \citep{ITU-TX.691}. These simple types
are used to distinguish a choice by identifying it with an incremented number from the previous
-element where the
-first element is of value zero. Variables defined by \textbf{INTEGER} are of the ``simple
+element where the first element is always of value zero. Variables defined by \textbf{INTEGER} are of the ``simple
type with distinguished values which are the positive and negative whole numbers,
including zero (as a single value)'' \citep{ITU-TX.691}.
-At this point the meaning of RRLP data elements marked in red, blue and orange from listing \ref{lst:RRLP} shall be given.
+At this point, the meaning of RRLP data elements marked in red, blue and orange from listing \ref{lst:RRLP} will be explained.
To construct an RRLP PDU sequence (packet) these fields need to be known: \textit{referenceNumber}
-and \textit{RRLP-Component}. \textbf{referenceNumber}
+and \textit{RRLP-Component}. \\\textbf{referenceNumber}
specifies the reference number of the request and is used for the purpose of identifying
-the response from the MS. It can take any value between 0 and 7, in
-PER enocoding this requires at least a three bit representation since with three bits,
-eight different values can be represented ($2^3=8$). \textbf{component} is of the type RRLP-Component,
+the response from the MS. It can take any value between 0 and 7. Since these values will be later
+binary encoded, at least three bits are required to represnt eight different values ($2^3=8$).
+\textbf{component} is of the type RRLP-Component,
which is a CHOICE list. RRLP-Component is used for defining what type of information the
packet shall include (assistance data, request, response, error, etc.). For this particular example
one chooses \textbf{msrPositionReq} that is of type MsrPosition-Req (marked in orange in listing \ref{lst:RRLP}),
-with this information the MS shall know that its position is requested. MsrPosition-Req is a SEQUENCE,
-consisting out of one mandatory and few optional IE elements. One choice shall be only considered,
-\textbf{PositionInstruct}, the rest is used later for the assistance data and what
-type of information is included inside of the PDU message. \textbf{PositionInstruct} consists
+with this information the MS knows that its position is requested. MsrPosition-Req is a SEQUENCE,
+consisting out of one mandatory and few optional IE elements. At this point only the first choice will be
+explained from listing \ref{lst:RRLPReq}, \textbf{PositionInstruct}. The rest of the provided choices
+are used later for the assistance data. The choices are dependent on what type of information is going to be
+included inside of the RRLP packets. \textbf{PositionInstruct} consists
of five elements but four are mandatory: \textit{methodType}, \textit{positionMethod},
-\textit{measureResponseTime} and \textit{useMultipleSets}. These four elements are the most
+\textit{measureResponseTime} and \textit{useMultipleSets}. They can be seen in the listing \ref{lst:RRLPReqData}.
+These four elements are the most
compact representation of an inquiry for the MS to differentiate between all the possible
-position measurements it could perform, how long (time duration) it is allowed to measure
-the position and how many positions it should perform and return in its response.
-\newpage
-\textbf{methodType} defines where the position estimation calculation ought to be executed,
-shall it take place solely on the MS (\textit{msBased}), solely on the server\footnote{With server
-the BTS location is ment!} (\textit{msAssisted}),
-or one is prefered over the other depending if the MS can execute the prefered one
+position measurements it could perform, how long it is allowed to measure
+the position (time duration) and how many position estimations it is allowed to perform.
+If it is allowed to perform more position estimations then all of them will be included in the returned response.
+\begin{lstlisting}[label=lst:RRLPReq,
+caption={\textbf{Structure of the RRLP request in ASN.1}},
+backgroundcolor=\color{light-gray},
+basicstyle=\scriptsize\ttfamily]
+-- Measurement Position request component
+
+MsrPosition-Req ::= SEQUENCE {
+ positionInstruct PositionInstruct,
+ referenceAssistData ReferenceAssistData OPTIONAL,
+ msrAssistData MsrAssistData OPTIONAL,
+ systemInfoAssistData SystemInfoAssistData OPTIONAL,
+ gps-AssistData GPS-AssistData OPTIONAL,
+ extensionContainer ExtensionContainer OPTIONAL,
+ ...,
+ -- Release 98 extension element
+ rel98-MsrPosition-Req-extension Rel98-MsrPosition-Req-Extension OPTIONAL
+}
+\end{lstlisting}
+
+\textbf{methodType} defines where the position estimation calculation will be executed.
+Does it solely take place on the MS (\textit{msBased}), on the server\footnote{With server
+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},
-otherwise it must be included in the message.
+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}.
+\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.
+
\begin{lstlisting}[label=lst:RRLPReqData,
caption={\textbf{Structure of the data types from RRLP request in ASN.1}},
backgroundcolor=\color{light-gray},
@@ -1898,25 +1902,25 @@ r=10((1.1)^{K}-1)
\label{eq:responseTime}
MeasureResponseTimeBitValue=\frac{ln(N)}{ln(2)}
\end{equation}
-\newpage
-This uncertainty of the accuracy, is an integer
-number, that defines how certain the accuracy of the returned position ought 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 ought to report back to SMLC.
-Since in this thesis the author exploits the AGPS method, GPS is choosen for \textbf{PositionMethod}.
-\textbf{MeasureResponseTime} is a three bit integer value that corresponds to the time the MS is allowed
-to perform the position estimation and to send a respose back to SMLC. Otherwise, if it takes longer the MS
-than the specified time period, it shall disconnect the SDCCH channel without responding back.
-It 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.
-In the next step the RRLP request can be constructed and encoded using PER. To construct the RRLP request
-query from the above given ASN.1 specifications is straightforward. The choosen values are only concatenated
+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
+notation \citep{ITU-TX.691}. PER is intended for use in circumstances where
+minimizing the size of the representation of values is the major concern
+in the choice of encoding rules \citep{ITU-TX.691}. In other words, it compresses the data
+in the PDU packets by limiting the bit field length to the minimal amount of bits required
+to define the minimal and maximal variable values defined in the standard.
+There are two variations of PER, aligned and nonaligned \citep{ITU-TX.691}.
+In the RRLP protocol the nonaligned type of PER is used. The major difference between
+aligned and nonaligned PER lies in the fact that some data structures are aligned on octet
+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.
+To construct the RRLP request query from the above given ASN.1 specifications is straightforward.
+The choosen values are only concatenated
into a binary string. A simple
RRLP request in PER encoded form is shown in figure \ref{img:RRLPReqExplained} and the previous conversion
process might become more clear, different variables have been colored with distinguishable colors to its neighbor