 Der nächste Vortrag ist für mich persönlich interessant und ich freue mich darauf. Wir werden uns über unsere neuen Vortrag zeigen, wie man das GSM-Protokoll auf Software Defined Radio und eine GSM-Basestation auf Software Defined Radio laufen lassen kann. Vielen Dank für die Vorstellung. Vielen Dank, dass ihr uns hier eingeladen habt. Mein Name ist Wadim Yanitski. Ich bin aus der Kommunikationsabteilung. Jetzt bin ich in Telekom. Ich war vorher ein Web-Entwickler. Und hier ist Piotr Krusik. Er ist bei der Warschau-Universität für Technologie. Er sagt, diese Software zu benutzen ist eine gute Idee und zu schreiben ist sogar noch eine bessere. Es gibt noch zwei andere Pakete, die ich mitentwickelt habe, Multi-RTL. Das ist ein RTL Software Defined Radio basierter Kanal-Empfänger. Worum geht es hier? Wir werden euch zeigen, wie man ein GSM-Mobiltelefon betreibt. Wie ihr das wahrscheinlich schon wisst, basieren wir auf OsmoCom. Und wir werden euch erklären, was mit der aktuell unterstützten Hardware falsch ist. Und dann zeigen wir euch, wie man das mit dem Software Defined Radio machen kann und das auch mal vorführen. Jetzt würde ich gerne mal wissen, wie viele Leute hier schon mal mit OsmoCom.BB gespielt haben. Wenn Sie von dieser Software reden, dann stellen sich normalerweise die Benutzung eines Motorroller-Telefons vor. Es ist ja kein Geheimnis, dass das Telefon getrennte CPUs hat, um die Basement-Software zu fahren und das Userinterface. Und momentan fragt das Betriebssystem auf dem Telefon den zweiten Basement-Prozessor, diese Arbeit der Kommunikation zu machen. Und darin steckt eine Firmware und wie auch viele andere Leute vertrauen mich auf dieses Software. Und wir hätten gerne eine Open-Source-Implementierung davon. Und die höheren Ebenen dieses Stacks sind auf dem PC. Und der Layer 1 ist die Firmware und die ist für Kalypso-Telefone. Und jetzt kann man Sprach-Calls machen und SMS im Moment. Es ist momentan kein benutzerorientiertes Projekt. Wofür brauche ich so ein Projekt, werdet ihr mich jetzt fragen. Das hängt davon ab, wer du bist. Wenn du ein Student oder ein GSM-Enthusiast, dann wird es dein bester Freund darin, die Software zu verstehen. Wenn du ein Sicherheitsforscher bist, wirst du dich vielleicht für das Protokoll interessieren. Und als letztes haben wir hier noch das Debang von dem OsmoCom-Projekt. Vor ein paar Jahren gab es ein League von Kalypso-Source-Codes. Und das hat den OsmoCom-Forschein erlaubt auf einem alten Motorola-Telefon selber Software zu schreiben. Und diese Kalypso basierten Telefone, insbesondere das Motorola C1. Das hat also diese Firmware, für die wir jetzt ins House Code hatten, mit der man diese privatewirtschaftlich geheim gehaltenen Signalprozession betrieben hat. Wo ist das Problem? Ja, das Problem ist, dass diese Hardware nicht mehr gibt, die wird aber nicht mehr hergestellt. Und dieser Signalverarbeitungsprozessor, der ist auch nicht vollkommen verstanden. Und das heißt also, wir müssen uns darauf verlassen, dass diese Software funktioniert. Das ist nicht 100% Open Source und außerdem lässt sich das auch nicht in GPS-Modus betreiben. Was passiert denn nun, wenn wir versuchen, die Kalypso basierte Firmware durch etwas anderes zu ersetzen? Zum Beispiel durch dein eigenes STR. Und was ist so ein STR überhaupt? Ein Software-Send-Find-Radio ist ein generelles Funkgerät, mit dem man hier das nicht auf einen speziellen Software-Stack limitiert ist. Es kann also für verschiedene Protokolle verwendet werden, zum Beispiel Alte, Bluetooth, GSM. Und ja, GSM-Halt, das für uns interessant ist. Die gute Neuigkeit ist, dass dies sehr Open Source-freundlich ist. Viele Open Source-Projekte unterstützen STRs und viele STR-Hersteller unterstützen Open Source-Programme, um darauf zugezogen zuzugreifen. Software-Design-Radios sind sehr populär, wenn es um mobile Kommunikation geht. Man kann sein eigenes Alte-Netzwerk oder GSM-Netzwerk aufbauen und kann auch ein spezielles Stack von dem Alte ausprobieren usw. Aber können wir jetzt auch das auf einem Mobile-Telefon? Ja, das ist da, wo unsere Arbeit angefangen hat. Also, denk daran, dies ist allgemein Hardware. Es hat nicht irgendwie ein Audio-System oder ein Keyboard oder ein einiges. Wir machen etwas nach Open Source, was etwas von Open Source vorgesehen ist. Und im Fakt ist, wofür ist das denn? Das Osmachon-BB-Projekt ist vor allem für Forschung und Entwicklung gedacht. Und damit könnt ihr jetzt absolut Open Source-Implementationen von Layer 1 erstellen. Es erlaubt euch eine andere Hardware-Plattform zu nehmen für Osmachon-BB. Jetzt drehen wir eine Zeit etwas zurück und stehen uns vor, dass wir mit einer SDR-Plattform von vorne von Grund auf beginnen würden. Was würden wir denn jetzt da tun? Auf diesem Bild seid ihr die Osmachon-Anwendung, welche zuvor benutzt wurde, um die hochhöhrläblichen Applikationen zu den Firmware zu verbinden. Und die höheren Applikationen haben mit einem seriellen Link kommuniziert. Aber in unserem Fall haben wir keine Firmware. Wir haben, ja, wir müssen mit dem Asterien wie kommunizieren. Nach einer, ja, nachdem wir kurz in den Source-Kopf nochmal geshaut haben, haben wir gesehen, dass es da 2 Layer 1 Protokolle gibt. Die sind sehr spezifisch, aber sehr einfach. Und das Gute daran ist, dass das aber halt bereits implementiert ist und auch voneinander unterstützt wird. Das Problem ist, die Osmachon-BB-House-Applikation hat Layer 2, aber nicht Layer 1 Burst. Das heißt, wir müssen eine Art Burst-Encoding selber machen. Ein anderes Problem ist, dass die Host-Applikationen nicht über das Time-Division Multiple Access-TDMA sich kümmern. Das ist aber eine sehr wichtige Technologie im GSM. Das heißt, wir müssen das TDMA selber implementieren. Und Osmachon-BB wurde unsere Coilader-Inspiration und was wir nun gemacht haben. Wir haben die allgemeinen Teile von Osmabitias, von der Base Station, halt separiert. Und wir haben eine Library daraus gemacht, weil die Library quasi aufgeräumt, verschneller optimiert. Wir haben auch ein paar GSM-Strukturen genommen, welche aus dem Osmabitias. Jetzt haben wir TRX-Con, eine Applikation. Das ist die karmitörligen Applikation kümmerizieren, aber noch nicht mit der Master R. Wir können etwas empfangen, aber die können noch nicht direkt mit der Master R kümmerizieren. Da gibt es das TRX-Protokoll, das zuerst im OpenBitias-Projekt implementiert wurde. Das wird also mit dem Transceiver zu kommunizieren. Der Transceiver hat mehr Resokats, einen für Ressourcenmanagement, einen für Clock-Frame-Indikationen und eine Hardware für Burst. Was wir jetzt implementiert haben, was wir kümmerizieren, was wir BITAS unterstützen, ist dieses Interface. Warum können wir nicht zusammen verbinden, um das aktuelle Hardware auf Hardware auszuprobieren? Wir nehmen das Fact-Therics-Toolkit, das ist ein Python-Toolkit, was man nutzen kann. Das kann z.B. TRX feiken. Es erlaubt euch, um im Interface direkt zur Osmo-Comm eine Applikation zu verbinden. Dann braucht ihr keine Hardware, um mit dem OpenSource-Netzwerk und dem OpenSource-Tag zu kommunizieren. Was ist denn das der Anmenu von diesen Tools? Man kann eine Simulation und einen Massentest damit durchführen. Hier ist der letzte Teil. Wir können direkt mit dem Übertragungsteil kommunizieren. Unsere Anwendung muss Downlink Burst Detection und die Demodulatisierung durchführen. Es muss dem TDMA-Time-Zeitcode folgen. Das wird von der TRX-Con unterstützt, aber wir müssen das Interface implementieren. Es gibt zwei Programme, die diese Anforderungen erfüllen. Das ist das Osmo-TX, und das ist dazu entworfen. Das ist, ob ein BTS funktioniert. Das ist in C++ geschrieben. Wir haben das mit wenigen Änderungen übernehmen können. Das Zweite ist GRJSM. Das ist ein Modul, und das ist ein Modular, und das lässt es leicht erweitern. Das, was ich gemacht habe, ist, den Burst-Sender umzusetzen. Das ist, wie er im Vorgang geflogen wird, und das ist ein Modul. Das ist das Modul, und das ist ein Modul, und das ist ein Modul. Das wollen wir. Das braucht viel لل. Es ist, Blöckchen, sondern es macht auch das Multiplexing. Es markiert die unterschiedlichen logischen Kanäle. Es gibt auch Anwendungen dabei, die demonstrieren, wie man das benutzt und wie dieser Datenstrom reinkommt. Wie die einzelnen Kanäle dekodiert werden. Es ist eine Dekodierung, die man auch in Weiherschark einbinden kann. Und jetzt, dass ich euch über den Anfangsstatus des Projektes. Wir hatten einen Empfänger und das, was uns gefehlt hat, war der Sender. Wir haben also den GSM-Modulator für die Einzelstückchen implementiert, für die Bursts. Wir haben herausfinden müssen, wie man das Signal von der Base Station da reinsteckt und wie man diese Sende- und Empfangs-Signale richtig synchronisiert. Und wir mussten sicherstellen, dass wir in der richtigen Art und Weise senden, dass wir mit niemandem in Konflikt kommen. Hier eine kleine Übersicht über GSM, dass das Luftinterface, das Welleninterface, das Radiointerface, schickt Datensätze, die acht Zeitblöcke überinhalten und diese Pakete, die modulieren mit Gauss-Minimumverschiebungs-Einzuordnung. So, dann haben wir den Modulator der von den GSM-Signalen zum Baseband-Signal übersetzt und da haben wir die richtigen Komponenten aus GNU Radio verwendet. Es gibt bereits einen Key-Modulator, GSM-K Modulator, der das in GSM-Signale übersetzt und dann hätte es eigentlich funktionieren müssen. Die zweite Aufgabe war die Synchronisation. Wir mussten die Burst-Übertragungen zur richtigen Zeit schicken. Es war nicht ganz einfach, aber letztendlich war es nicht sehr groß. Wir haben eine Frame-Nummer und eine Time-Stamp-Nummer und man muss zu einem sehr genau definierten Zeitpunkt die Sendung absetzen. Dafür ist die Hardware-Uhr sehr nutzlich, die wir in dem Software definierten Radio-Trend verwenden, die uns hilft, zu einem genau definierten Moment zu übersenden. Und das Empfangs-Signal ist auch mit der aktuellen Zeit markiert, was wir da gerade reinbekommen haben. Und der Empfänger kann über diese Metadaten die aktuelle Zeit verfolgen. Und anhand des Signals von der Base-Station können wir dieses Signal zuordnen, der Empfangs-Time zuordnen. Dieses Paar von Informationsstücken wird genutzt, um die Frame-Nummer und die Zeit-Nummer zuordnen und zu synchronisieren und zur richtigen Zeit zu übertragen. Also der Modulator, der gibt uns die Teile und die werden dann von USRP zum wohl definierten Zeitpunkt übertragen. Wir hatten danach noch immer paar Verzögerungen, die uns nicht ganz klar waren. Und die waren entweder Teil von unserem Algorithmus oder von der Software Divan Radio Hardware. Das Diagramm ist hier. Wir haben ein Signal von der Base-Station, das in USRP reinkommt. Die Ausgabe von der Empfänger Kette ist der Burst. Da fügen wir eine bekannte Verzögerung von D-Frames hinzu und schicken wir es dann wieder raus. So und dann haben wir das dem richtigen Kanal zugeordnet und dann haben wir angefangen, eine bekannte Anzahl von Frames von dem verzögerten Signal abzuziehen und dann versuchen wir die Blöcke einander zuzuordnen, um die notwendige Korrektur zu finden. Wir messen also, wie die Inputz und die Outputz miteinander verwandt sind. Und so können wir den Delay bestimmen, mit welchem wir dann weiterarbeiten müssen. Dann mussten wir verifizieren, dass die Amplitude des gesendeten Signals und was normale Programme wie Osmo-BTS, Osmo-Therics, die machen einen Konstanten-Stream von Samples, aber für eine mobile Station wäre das etwas langweilig, wenn wir einfach einen Konstanten-Stream von Samples senden würden. So eine Mobile Station muss nur ab und zu mal etwas senden. Jetzt haben wir das Burst Interface benutzt, um die GSM Burst zu senden. Und wir senden nur, wenn wir das brauchen. So ist es einfacher, die Übertragung zu synchronisieren. Aber das hat auch Nachteile. Hier seht ihr, wie die Signalamplitude aussehen sollte für die GSM. Es gibt ein paar Perioden, wo man nichts sendet. Und das ist, was wir erhalten haben. Und wo sind denn jetzt diese 300 Mikrosekunden von unseren Bursts? Wenn wir das genau untersucht haben, haben wir gesehen, dass nur auf einem bestimmten USRP dies auftritt. Auch nur, wenn wir senden und empfangen auf dem selben Gerät. Also nur unter bestimmten Umständen ist das aufgetreten. Und wenn wir diese Umstände quasi aus dem Weg gehen, dann haben wir ein viel besseres Signal. Aber dann, was ist denn das Ding da vor meinem Burst? Was ist das genau? Es scheint, als ob dies das Ende des vorherigen Bursts wäre, der am Anfang des nächsten Bursts quasi auftaucht. Das ist das Resultat von Verzögerungen beim FPGA im USRP im SDR. Und das können wir umgehen, wenn wir am Schluss noch 0 hinzufügen. Und was wir am Schluss noch machen mussten, ist, das Spektrum verifizieren mit einem Spektrum-Analysator. Wir haben die Antenne vom SDR damit verbunden und uns das angeschaut. Man sieht, dass es halt auch nicht ein ideales Signal produziert, was eigentlich immer der Fall ist. Und das hier ist das Signal, das wir gesehen haben. Man sieht auch die rechts, die harmonischen, welche es quasi immer gibt, von der Grundfrequenz dann an der VC Megahertz. Und jetzt kann man ein Filter darüber anwenden und dann wird das schon mal viel besser. Da war mein Teil nun mal funktioniert. Und jetzt müssen wir noch für den Demo warten, welcher Fladi geschrieben hatte. Wenn wir mit dem Sander fertig waren, hatten wir etwas in dem Stil. Wir können nur kommunizieren mit einem SDR, mit dieser Chiasamar TAX-Applikation. Und das über unseren Open Source Stack und mit verschiedenen Basisstationen. Jetzt möchten wir eine kleine Demo zeigen, aber wir haben nicht mehr so viel Zeit. Und ich muss da kurz umschalten. So, das erste, was wir ausführen müssen, ist unser Sender Empfänger-Programm. So, das startet es. Jetzt müssen wir das Terrascom starten, was quasi ein Brück herstellt zwischen Osmo-Com und der anderen Applikation. Und am Schluss die Osmo-Com BB-Applikation, zum Beispiel eine Mobile-Applikation. Und was jetzt passiert ist, es startet sich mit der Basisstation zu synchronisieren. Und jetzt können wir mal versuchen, uns da zu registrieren. Das ist klassisch. Wir müssen unsere virtuelle SIM-Karte einsetzen, weil wir im Moment kein direktes SIM-Karten-Interface haben. Probieren wir das noch mal. Und was jetzt passiert ist, wir machen einen Ortsupdate-Request im GSM-Netzwerk. Schauen wir mal. So, ja, wir haben so eben in diesem Netzwerk registriert. Was wir jetzt hier machen können, ist einfache Operationen ausführen, zum Beispiel unsere Nummer ansehen. Das ist dieses Signal. So, die Implementation ist nicht so stabil. Also, wenn ihr mitarbeiten möchtet, seid ihr gerne willkommen. Und jetzt versuchen wir auch eine Erweiterung dafür. Wir versuchen jetzt seine Osmos-Meteilen zu senden. Und wir sollten diese zurück erhalten. Zum Beispiel so. Wir haben einen Kanal. Und hoppla. Versuchen wir jetzt noch mal. Okay, ja, wir haben die erst einmal zurückgehalten. Jetzt versuchen wir noch mal irgendwohin anzurufen, weil wir ein bisschen Soundanbindung haben. Wir rufen mal eine Testnummer an. Na, endlich. Wir müssen zurück zu unserer Präsentation hier. Also, der Status ist hier auf dieser Seite. Ist noch nicht so, wie ich den gerne hätte. Was haben wir geschafft? Wir haben eine volle Open Source GSM Layer 1-Implementierung. Und man braucht keine Calypso vor uns mehr suchen, sondern man kann es auf der Defiant radio benutzen. Man kann beliebiges Band verwenden. Zum Beispiel könnte man das Netzwerk im Wi-Fi-Band laufen lassen. Wir sind näher an einer GPRS Edge-Implementierung dran. Und wir können versuchen, non-GSM-Audiocodex einbinden wie Speaks oder Opus. Das ist eine neue Hardware-Plattform. Und das öffnet uns neue Möglichkeiten. Vielen Dank für Ihre Zeit. Und gerne nehmen wir Ihre Fragen an. Vielen Dank, Vadim und Piotr. Wir haben leider keine Zeit für eine Frage und Antwort. Aber die Leute sollen noch gerne nachher zu euch kommen und fragen. Damit verabschieden wir uns aus der Übersetzungskabine. Es waren Pharma-Firma.