From d90c4a9addc0c78ef6105e87eb831bb2e2562fbd Mon Sep 17 00:00:00 2001
From: Refik Hadzialic
Date: Sun, 9 Sep 2012 15:45:06 +0200
Subject: Implementation changes and proof reading

---
 vorlagen/thesis/src/kapitel_x.tex | 80 +++++++++++++++++++++++----------------
 1 file changed, 48 insertions(+), 32 deletions(-)

(limited to 'vorlagen/thesis/src/kapitel_x.tex')

diff --git a/vorlagen/thesis/src/kapitel_x.tex b/vorlagen/thesis/src/kapitel_x.tex
index 7c14f43..8e63c43 100644
--- a/vorlagen/thesis/src/kapitel_x.tex
+++ b/vorlagen/thesis/src/kapitel_x.tex
@@ -2207,11 +2207,20 @@ proceed with the cabling of the nanoBTS and the ethernet switch or hub, since wr
 wiring with the power supply unit (PSU) could damage one of the devices. 
 In Figure \ref{img:connectionDiagram}, the junction points are label according 
 to the used configuration setting. The ethernet cables between the switch/hub, 
-PSU and nanoBTS should not be longer than 100 m \citep{installnanoBTS}.
+PSU and nanoBTS should not be longer than 100 m \citep{installnanoBTS}. 
+Author's test system operated on the ARFCN 877 channel. 
+ARFCN 877 corresponds to the uplink frequency of 1,783.2 MHz and a downlink 
+frequency of 1,878.2 MHz, where the uplink direction
+represents the direction from the nanoBTS to the mobile stations and downlink the
+opposite direction. The decision to use the ARFCN 877 channel was derived from
+the fact that the channel was free, measurements were carried out with a
+spectrum analyser built on the USRP hardware. The set up, installation
+and configuration are 
+discussed in appendix \ref{sec:instConf}.
 
 \begin{figure}[ht!]
   \centering
-  \includegraphics[scale=0.5]{img/hardwareConnection}
+  \includegraphics[scale=0.4]{img/hardwareConnection}
   \caption{Cable connections, showing interconnection diagram}
 \label{img:connectionDiagram}
 \end{figure}
@@ -2415,37 +2424,44 @@ and sent to the MS.
 
 \section{Creating a data channel in OpenBSC}
 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. 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 
-well as parsing the RRLP packets, waiting for the response back and 
-disconnecting. This will be explained in an sequential order of 
-execution. 
-
-The GSM network operator can connect to the VTY interface of OpenBSC 
-using Telnet on port 4242 to issue commands and administer the GSM 
-network. In order to send RRLP requests from the VTY command interface,
-RRLP execution command had to be integrated. Function that integrates
+requests have been sent originally, the solution was to create a dedicated data
+channel. The previously implemented approach by OpenBSC developers 
+was to open a data channel with a silent SMS and then to send the 
+RRLP request without any assistance data. However, this triggered always 
+a time out. The new approach, implemented by the author, can be split up 
+into four steps: adding a command in the Virtual Teletype interface to 
+launch an RRLP request; open a dedicated data 
+channel (SDCCH) between the BTS and MS; open the text file generated with 
+the RRLP assistance data generator in the previous step;
+send the RRLP packets; wait for the response from the MS and 
+close the data channel. This will be explained in a sequential order of execution. 
+
+The GSM network operator can connect to the Virtual Teletype (VTY)
+interface of OpenBSC using Telnet on port 4242 to issue commands 
+and administer the GSM 
+network. In order to send an RRLP requests from the VTY command interface,
+RRLP execution command had to be integrated. The function that integrates
 that command is named \textbf{\texttt{subscriber\_silent\_rrlp\_start()}} 
-and is in the file \textit{vty\_interface\_layer3.c}. Once the operator
-executes on of the four implemented commands: RRLP request, RRLP request
-with almanac data, RRLP request with ephemeris and other assistance data
-or to end the execution of the RRLP request. For the first three commands,
-the next executed function is \textbf{\texttt{gsm\_rrlp\_operation\_start()}} in 
-the file \textit{silent\_call.c}. Any of the three commands will iniate 
-the opening of an SDCCH channel (what in \textbf{\texttt{gsm\_rrlp\_operation\_start()}}
-function takes place was already explained in \ref{sec:SDCCHChan}). In the case,
-when the GSM operator can not wait for the RRLP request answer or wants 
-to stop the execution of the RRLP request, he can issue a command in the VTY
-interface to stop it, which will execute \textbf{\texttt{gsm\_rrlp\_operation\_stop()}}
-in the file \textit{silent\_call.c}. If the channel was successfully opened
-the function \textbf{\texttt{send\_rrlp\_req()}} will be executed that is responsible
-for opening the text file with assistance data, copying the assistance data
-into the RRLP data structure and transmitting it to the MS. The data structure
+and is in the file \textit{vty\_interface\_layer3.c}. Four different commands
+can be executed by the operator from the VTY interface: RRLP request (send a 
+position request without any assistance data); RRLP request
+with almanac data (send a position request with almanac as assistance data);
+RRLP request with ephemeris and other assistance data (send a position request with
+all available assistance data); or stop RRLP request (to stop the current
+execution of the RRLP request). Any of the first three commands,
+will call the function \textbf{\texttt{gsm\_rrlp\_operation\_start()}} in 
+the file \textit{silent\_call.c}. Afterwards, the initializing of an SDCCH channel 
+will start. Theoretically what takes place in background of this process, i.e.
+function \textbf{\texttt{gsm\_rrlp\_operation\_start()}}, 
+was already discussed in \ref{sec:SDCCHChan}. For the particular situation,
+when the GSM operator can not wait for the RRLP response or wants 
+to stop the execution of the RRLP request, the GSM operator can issue a command
+in the VTY interface to stop it, which will call the function 
+\textbf{\texttt{gsm\_rrlp\_operation\_stop()}} in the file \textit{silent\_call.c}.
+If the channel was successfully opened, the function \textbf{\texttt{send\_rrlp\_req()}} 
+will be executed which is responsible for opening the text file with parsed 
+assistance data content, copying the content into the RRLP data structure and 
+transmit it to the MS. The data structure
 is shown in \ref{lst:rrlpDatastructure}. The structure contains the length
 of the data packets, \textit{lengthOfPacket} as well as the content
 of the packets, \textit{packetContent} which never exceeds more than 211 bytes.
-- 
cgit v1.2.3-55-g7522

