01-einleitung.tex

\utsection{Einleitung}{Stefan Giggenbach}

Im Rahmen des Moduls Mobile Netze im Masterstudiengang Informatik wird mit der Durchführung einer Projektarbeit, das in der Vorlesung vermittelte Wissen praxisnah vertieft und  ergänzt. In der vorliegenden Projektarbeit wird die Handover-Funktionalität in einem GSM-Netzwerk näher untersucht. Im Folgenden wird nach einer theoretischen Einführung das Projektziel und die entsprechende Vorgehensweise beschrieben.

\subsection{Handover}\label{sec:handover}

Der Handover stellt in einem GSM-Netzwerk eine wichtige Aufgabe des Mobility Management dar. Ändert ein Teilnehmer bei aktiver Verbindung seinen Standort, ist es möglich, dass er den von einer Funkzelle abgedeckten Bereich verlässt. In einem solchen Fall wird die Verbindung durch den Wechsel zu einer benachbarten Funkzelle (Handover) aufrecht erhalten. Grundsätzlich unterscheidet man in einem GSM-Netzwerk folgende Handoverszenarien:

\begin{itemize}
 \item Intra BSC Handover
 \item Inter BSC Handover
 \item Inter MSC Handover
 \item Subsequent Inter MSC Handover
\end{itemize}

Die einzelnen Szenarien werden in \cite{bib:grundkursmks} ausführlich beschrieben. Im folgenden wird nur der Ablauf des Intra BSC Handover näher betrachtet, der für das Verständnis dieser Arbeit entscheidend ist. Aus Sicht der Mobile Station unterscheiden sich die genannten Handoverszenarien nicht.

\begin{figure}[h!]
  \centering
  \includegraphics[width=\textwidth]{img/ablauf_handover}
  \caption{Ablaufdiagramm eines Intra BSC Handover}
  \label{fig:adhandover}
\end{figure}

Abbildung \ref{fig:adhandover} zeigt das Ablaufdiagramm eines Intra BSC Handover. Während einer aktiven Verbindung wird der BSC in regelmäßigen Zeitäbständen über die Signalqualität im Up- und Downstream informiert. Zu diesem Zweck sendet die Mobile Station über den SACCH sogenannte Measurement Reports, die anschließend im BSC zur Bestimmung der Downstream-Signalqualität ausgewertet werden. In den Measurement Reports sind neben den Messergebnissen zur aktuell verwendeten BTS auch Messergebnisse zu benachbarten BTS, die auf Anweisung des BSC während der Sendepausen von der Mobile Station ermittelt werden. Die Signalqualität des Upstreams wird durch Messergebnisse aus der entsprechenden BTS ebenfalls im BSC berechnet. Der BSC kann aufgrund der eingehenden Measurement Reports zu dem Ergebnis kommen, dass ein Handover zwischen zwei benachbarten BTS notwendig ist, um einen Abbruch der Verbindung zu verhindern. Nach der Entscheidung des BSC einen Handover durchzuführen, wird im ersten Schritt ein TCH in der neuen BTS aufgebaut. Ist dieser Vorgang erfolgreich, wird der Mobile Station über den FACCH der bestehenden Verbindung ein Handover-Command übermittelt. Das Handover-Command enthält als Parameter die Frequenz und den Timeslot des TCH der neuen BTS. Nach der Synchronisation der Mobile Station mit der neuen BTS, sendet diese in vier aufeinanderfolgenden Bursts eine Handover Access Message und anschließend eine SABM Message. Die neue BTS quittiert den erfolgreichen Handover mit einem Established Indicator gegenüber dem BSC und einer UA Message gegenüber der Mobile Station. Nachdem der BSC die Verbindung auf den neuen TCH umschaltet, wird der TCH in der alten BTS abgebaut. Der Handover-Vorgang ist damit abgeschlossen.

Die wichtigesten Punkte des Ablaufs für die Analyse und Implementierung einer Handover-Funktionalität sind damit:

\begin{itemize}
 \item Erfassung und Auswertung der Measurement Reports
 \item Logik für die Entscheidungsfindung eines Handover
 \item Inter BTS Kommunikation zum Aufbau eines neuen TCH
 \item Erzeugen und Senden eines Handover Command
 \item Umschalten der bestehenden Verbindung und Abbau des alten TCH
\end{itemize}

\subsection{Projektziel und -durchführung}

Ziel der Projektarbeit ist die Integration der in Abschnitt \ref{sec:handover} eingeführten Handover-Funktionalität in die Open Source Software OpenBTS. Das OpenBTS Projekt ermöglicht zusammen mit einer entsprechenden Radio-Hardware und zusätzlichen Software-Komponenten (GNURadio und Asterisk), den Betrieb eines GSM-Netzwerks. Mit der kommerziell vertriebenen Version der Software ist ein Handover zwischen zwei BTS bereits möglich. Die Vorraussetzungen für eine erfolgreiche Integration eines Handover-Moduls sind somit gegeben. Architektur, Installation und Konfiguration des im Anschluss für die Implementierung verwendeten OpenBTS-Systems werden in Kapitel \ref{sec:openbts} ausführlich beschrieben.

Noch vor der Integrations- und Implementierungsphase wird der Ablauf eines Handover genauer analysiert. Zu diesem Zweck wird ein OpenBSC-System verwendet, mit dem das in Abschnitt \ref{sec:handover} eingeführte Handoverszenario reproduziert werden kann. Der Aufbau, sowie die Installation und Konfiguration des OpenBSC-Systems für die Durchführung eines Intra BSC Handover werden in Kapitel \ref{sec:openbsc} behandelt.

Da brauchbare Dokumentationen zur Implementierung von OpenBTS nicht vorhanden sind, enthält Kapitel \ref{sec:swarch} einen Überblick zur Software-Architektur und detaillierte Beschreibungen zu verwendeten Klassen des OpenBTS-Quellcodes. Dieses Kapitel fasst die Ergebnisse der sehr aufwändigen Code-Analyse zusammen und soll zukünftigen Projektgruppen einen einfacheren Einstieg in die Weiterentwicklung der OpenBTS-Software ermöglichen.

Der Architekturentwurf für die Integration und die durchgeführten Implementierungsarbeiten des Handover-Moduls werden in Kapitel \ref{sec:erweiterung} behandelt. Die Arbeiten konnten in dem zur Verfügung stehenden zeitlichen Rahmen nicht vollständig abgeschlossen werden. Der aktuelle Entwicklungsstand wird in sich abgeschlossen festgehalten und es werden Lösungsansätze für weitere Arbeiten aufgezeigt.

Die Analyse der durchgeführten Handover (sowohl mit OpenBSC als auch mit OpenBTS) wird am Ende der Arbeit in Kapitel \ref{sec:analyse} beschrieben. Dabei werden zum einen die vorbereitenden Arbeiten und eingesetzten Werkzeuge zur Erzeugung von Traces auf der Um- und Abis-Schnittstelle behandelt. Zum anderen werden die daraus gewonnen Erkenntnisse, die während der gesamten Entwicklungsarbeiten immer wieder zur Verifikation verwendet wurden, beschrieben.