Inhaltsverzeichnis

Inhaltsverzeichnis
Inhaltsverzeichnis
0. Vorwort ....................................................................................................................... 3
1. Einleitung .................................................................................................................... 4
2. Digitale Modulation und Internet-Protokolle .......................................................... 6
2.1. Schichtenmodelle ................................................................................................. 6
2.2. V.21 Modemstandard zur Datenübertragung im öffentlichen Telefonnetz ......... 9
2.3. Das Point-to-Point-Protokoll (PPP) ..................................................................... 12
2.3.1. Hauptkomponenten des PPP ...................................................................... 12
2.3.2. Rahmenbildung auf Basis des HDLC-Protokolls ....................................... 13
2.3.2.1. Rahmenformat ..................................................................................... 13
2.3.2.2. Transparenz ......................................................................................... 16
2.3.2.3. Ungültige Datenrahmen ...................................................................... 17
2.3.2.4. Inter-frame Fill .................................................................................... 17
2.3.2.5. FCS (Frame Check Sequence) Berechnung ........................................ 17
2.3.3. PPP-Verbindungs-Optionen ....................................................................... 20
2.3.3.1. Überblick ............................................................................................. 20
2.3.3.2. Das PPP-Phasen-Diagramm ................................................................ 21
2.4. Das Link-Control-Protokoll (LCP) ...................................................................... 24
2.4.1. Das LCP-Datenformat ................................................................................ 25
2.4.2. Die LCP-Datenpakete ................................................................................. 26
2.4.3. Die LCP-Konfigurations-Optionen ............................................................ 30
2.5. Das Internet-Protocol-Control-Protokoll (IPCP) ................................................. 34
2.5.1. Das IPCP-Datenformat ............................................................................... 34
2.5.2. Die IPCP-Konfigurations-Optionen ........................................................... 35
2.6. Der Option-Negotiation-Automat ........................................................................ 36
2.6.1. Der Restart-Timer und seine Counter .........................................................36
2.6.2. Zustandübergangs-Tabelle ......................................................................... 39
2.6.3. Zustände, Ereignisse und Aktionen ............................................................ 40
2.7. PPP-Protokoll-Mitschnitt ..................................................................................... 42
2.8. TCP/IP und HTTP ............................................................................................... 44
3. Soft-Modem Baugruppe ............................................................................................ 45
3.1. Vom Hard- zum Softmodem ................................................................................ 45
3.2. Direct Access Arrangement (DAA) ..................................................................... 47
3.3. Die Mikrocontroller-Baugruppe .......................................................................... 48
1
Inhaltsverzeichnis
4. Funktionsblöcke der Software .................................................................................. 54
4.1. Rufsignalerkennung und Steuerung des Rufzustandes ........................................ 54
4.2. Digitale Modulation nach V.21 ............................................................................ 58
4.2.1. V.21 FSK Modulator .................................................................................. 58
4.2.2. V.21 FSK Demodulator .............................................................................. 61
4.3. V.21 Negotiation-Handshake ............................................................................... 67
4.4. PPP im Server-Betrieb ......................................................................................... 70
4.5. Maßnahmen zur Anpassung des TCP/IP-Stacks an das PPP ............................... 76
4.6. Embedded Soft-Modem Applikation..................................................................... 78
5. Ressourcen-Untersuchungen und Ausblick ............................................................. 80
6. Zusammenfassung ...................................................................................................... 83
A
Literatur- und Quellenverzeichnis ..................................................................... 84
B
Schaltplan und Bestückungsliste ......................................................................... 86
2
Vorwort
0. Vorwort
Nach der Absolvierung meines praktischen Studiensemesters im Bereich der Field
Applications MSP430 bei der Firma Texas Instruments entstand, angeregt durch einen
Mitarbeiter von Texas Instruments und Herrn Professor Sturm, die Idee zu der vorliegenden
Diplomarbeit mit dem Thema „Entwicklung einer Embedded Softmodem Applikation auf
Basis des MSP430F149 Mikrocontroller von Texas Instruments“.
Danken möchte ich allen Mitarbeitern des Forschungs- und Transferzentrum Leipzig (FTZLeipzig e.V.), die mir einen Arbeitsplatz zur Verfügung gestellt haben, mir mit Rat und Tat
bei der Entwicklung zur Seite standen und damit nachhaltig einen positiven Eindruck eines
sehr angenehmen Arbeitsklimas hinterlassen haben. Besonderer Dank gilt Herrn Tobias
Wengemuth, ohne dessen Erfahrung im Entwurf und Erstellen von Leiterplatten-Prototypen,
die Entwicklung weitaus mehr Zeit in Anspruch genommen hätte. Weiterhin geht mein Dank
an Herrn Professor Sturm für die unkomplizierte und reibungslose Zusammenarbeit auf dem
organisatorischen Gebiet und die unerschöpfliche Flut an Ideen in Engpässen der
Entwicklung.
3
Einleitung
1. Einleitung
Unter dem Schlagwort „Embedded Internet“ wird meist der Netzzugang Mikrocontrollerbasierter Geräte über Ethernet verstanden. Der Traum vom Zugriff auf entlegene Endgeräte
per Web wird sich jedoch kaum mit Ethernet realisieren lassen. An dieser Stelle gewinnt
einmal mehr die allgegenwärtige Telefonleitung an Bedeutung, die in Kombination mit einem
Modem als Übertragungskanal von Daten dienen kann. Eine besonders elegante, kleine und
Kosten sparende Möglichkeit, den Netzzugang – ohne externes Modem - über die
Telefonleitung zu realisieren, stellt ein sog. Soft-Modem-Ansatz dar, der eine fast direkte
Verbindung zwischen Controller und Telefonnetz erlaubt.
Ausgangspunkt für diese Arbeit war ein Projekt mit dem Namen „easyWeb“, das bereits im
Jahr 2001 ins Leben gerufen wurde und als Komplett-Lösung in [D&E] im Detail beschrieben
und offen gelegt wurde. Die Rede ist dabei von einem Mikrocontroller-basierten
Internetknoten auf der Basis des MSP430F149 Mikrocontroller der Firma Texas Instruments,
der sich per Ethernet an ein IP-Netzwerk anschließen lässt. Im Mikrocontroller ist ein
TCP/IP-Protokollstapel implementiert und als Anwendungs-Beispiel wurde ein Webserver
realisiert, der für die Teilnehmer im IP-Netzwerk eine dynamische Internet-Seite zum Abruf
bereit hält.
Ziel dieser Arbeit war es, die Webserver-Baugruppe vorerst per serieller RS-232 Schnittstelle
und einem externen Modem über die Telefonleitung betreiben zu können und anschließend
möglichst viele Funktionen des externen Modems mit dem MSP430F149 in EmbeddedSoftware zu realisieren, um eine kompakte Soft-Modem-Applikation zu erstellen. Das
Ergebnis und der, im Folgenden beschriebene Entwicklungsweg dieser Arbeit stellt nur einen
möglichen Lösungs-Ansatz auf dem Weg zu einer Soft-Modem-Applikation dar und soll
vielmehr als Machbarkeits-Studie betrachtet werden, in der gezeigt wird, mit welchen
einfachen Mitteln eine Internet-Anbindung über das öffentliche Telefonnetz realisiert werden
kann. Die entwickelte Soft-Modem-Baugruppe stellt demnach auch kein Industrie-reifes
Endprodukt dar, sondern bietet eine Menge Ansatzpunkte zur Weiterentwicklung in Richtung
einer wirtschaftlich sinnvollen Lösung.
Als Herzstück der Entwicklung diente, vorgegeben durch die „easyWeb“-Baugruppe, der
MSP430F149 ultra-low-power Mikrocontroller der Firma Texas Instruments. Es wird sich
später zeigen, dass zur Realisierung der eigentlichen Modem-Funktionen weitaus weniger
Ressourcen benötigt werden, als der MSP430F149 zur Verfügung stellt.
4
Einleitung
Die Reihenfolge der einzelnen Kapitel dieser Arbeit entspricht dem Entwicklungsweg, der
von der Webserver-Baugruppe hin zur Soft-Modem-Applikation beschritten wurde und
gliedert sich wie folgt.
Kapitel 2
Protokoll-Grundlagen für die Internetanbindung über das öffentliche
Telefonnetz. Ersatz von Ethernet durch Point-to-Point-Protokoll und
Digitale Modulation nach V.21 Modemstandard auf physikalischer
Ebene
Kapitel 3
Der Weg vom Hard- zum Soft-Modem und Beschreibung der
entwickelten Soft-Modem-Baugruppe
Kapitel 4
Erläuterung und Dokumentation der, in Funktionsblöcke eingeteilten,
Mikrocontroller-Software
Kapitel 5
Untersuchungen zu den erforderlichen Mikrocontroller-Ressourcen der
Soft-Modem-Applikation und Ideen zur unmittelbaren
Weiterentwicklung
Kapitel 6
Zusammenfassung und Ausblick
5
Digitale Modulation und Internet-Protokolle
2. Digitale Modulation und Internet-Protokolle
2.1. Schichtenmodelle
Bei der Entwicklung von Systemen zur Datenkommunikation ist es allgemein üblich
Kommunikations-Mechanismen in einem Schichtenmodell darzustellen. Dies ermöglicht eine
einfache Einordnung der realisierten Funktionen in ein allgemein verständliches Modell und
liefert Freiraum für Änderungs- und Erweiterungsmöglichkeiten, da das Gesamtproblem der
Entwicklung eine Unterteilung (Schichtung) in mehrere einzelne Problem-Komponenten
erfährt. Die Schnittstellen der Komponenten sind dann genau definiert und es kann eine
getrennte Bearbeitung der Teilprobleme erfolgen. D.h. in einer „Schichtenorientierten
Architektur“ (vertikale Anordnung der Schichten übereinander) stellt jede Schicht der
nächstübergeordneten Schicht einen Satz bestimmter Dienstleistungen zur Verfügung. Die
übergeordnete Schicht übernimmt bedenkenlos die ihr dargebotene Dienstleistung, verlässt
sich somit kritiklos auf die Funktion der untergeordneten Schicht. Die untergeordnete Schicht
hat mit dem Liefern der Dienstleistung ihre Aufgabe erfüllt.
Beim Datenaustausch zweier Rechnersysteme erfolgt die Kommunikation einander
entsprechender Schichten über ein bestimmtes Protokoll. Der Informationsaustausch zwischen
gegenüberliegenden Schichten erfolgt jedoch nicht im Sinne einer direkten Verbindung,
sondern Zuhilfenahme von Dienstleistungen untergeordneter Schichten. Die einzelnen
Schichten
stehen
demnach
stellvertretend
für Protokolle mit
den
dazugehörigen
ISO/OSI Referenzmodell
Dienstleistungen. Man spricht
Application Layer
daher auch von „Protokoll-
Presentation Layer
DoD-Internet-Standard
TCP/IP-Architektur
Application Layer
Session Layer
Stapeln“ (Stacks).
Die für das Internet gültige
Architektur basiert auf einer
Transport Layer
Gliederung in vier Schichten
Internet Layer
und ist als DoD-Standard
Network Layer
(Department of Defence) oder
Transport Layer
Network Layer
Data Link Layer
TCP/IP-Architektur bekannt.
Physical Layer
Der DoD-Standard kann als
Teilmenge
Abb. (2.1): ISO/OSI und Internet-Referenzmodell
des
allgemein
gültigen und standardisierten
ISO/OSI-7-Schicht-Referenzmodells (International Organisation for Standardization, Open
System Interconnection) verstanden werden. Eine weitere Beschreibung der einzelnen
6
Digitale Modulation und Internet-Protokolle
ISO/OSI-Schichten wird an dieser Stellen nicht vorgenommen und auf weitere Quellen
verwiesen [TCP/IP]. Eine Gegenüberstellung der Referenzmodelle DoD-Standard und
ISO/OSI zeigt Abbildung (2.1).
Abbildung (2.2) zeigt das Blockschaltbild der „easyWeb“-Webserver-Baugruppe in
Zusammenhang mit dem TCP/IP-Schichtenmodell und den konkreten Protokoll-Stapeln
(Ethernet, IP, ARP, TCP, ICMP, HTTP), die von der Baugruppe bedient werden.
8 MHz
20 MHz
DoD-Internet-Standard
TCP/IP-Architektur
D[7...0]
JTAG
MSP430F149
RS232
CS8900A
A[3...0]
Application Layer
HTTP
Transport Layer
TCP / ICMP
IOR
Internet Layer
IP / ARP
IOW
LEDs: Power,
Link, LAN
ImpulsTransf.
3,3 V
Power-Supply
RJ45LAN
Network Layer
ETHERNET
Abb. (2.2): Webserver-Baugruppe und Schichtenmodell
Die Kommunikation auf Netzwerk-Schicht, also das Ethernet, wird hierbei komplett von
einem zusätzlichen Ethernetcontroller (CS8900A der Firma Crystal) behandelt, der per
Übertrager (Impuls-Transformator) und RJ-45-Westernsteckerbuchse mit dem EthernetNetzwerk verbunden wird. Ethernetcontroller und MSP430F149 kommunizieren über ein klar
definiertes Bussystem, über das der Datenaustausch erfolgt. Sämtliche höheren ProtokollSchichten von IP über TCP bis zum HTTP sind im MSP430F149 implementiert. Der
Ethernetcontroller implementiert das Kanalzugriffsverfahren und speichert eingehende, sowie
zu sendende Datenpakete im internen RAM zwischen, bevor diese, im Falle eines
empfangenen Datenpakets, an die höheren Protokoll-Schichten im Mikrocontroller
weitergereicht, oder im Sendefall, auf das physikalische Medium zur Übertragung gegeben
werden. Die MSP430F149 Software muss lediglich kontrollieren, ob der Ethernetcontroller
irgendwelche Daten in seinem Empfangspuffer gespeichert hat. Ist dies der Fall, können die
Daten vom Ethernetcontroller an den MSP430F149 übermittelt und von den implementierten
Protokoll-Mechanismen ausgewertet werden. Je nachdem, ob die Daten für die WebserverApplikation relevant oder nicht von Interesse sind, werden die empfangenen Daten verworfen
7
Digitale Modulation und Internet-Protokolle
oder entsprechende Antwort-Datenpakete zusammengestellt, die dann anschließend wieder in
den Ausgangspuffer des Ethernetcontrollers geschrieben werden. Der Ethernetcontroller
kümmert sich dann selbständig darum, wann der richtige Zeitpunkt eintritt, um die Daten in
seinem Ausgangspuffer auf das physikalische Medium zu geben.
Um nun die Webserver-Applikation über das öffentliche Telefonnetz betreiben zu können,
wird auf der Netzwerk-Schicht das Ethernet durch ein weiteres Software-Protokoll ersetzt,
dass es ermöglicht Datenpakete über eine serielle Punkt-zu-Punkt-Verbindung zu übermitteln
und gleichzeitig eine Ethernet-äquivalente Schnittstelle zur höheren IP-Schicht darstellt. Für
reine TCP/IP-Netze steht hierfür seit den achtziger Jahren das Serial-Line-Interface-Protokoll
(SLIP) zur Verfügung. SLIP weist jedoch zu viele Defizite auf, um als allgemeingültiger
Standard akzeptiert zu werden. Das umfangreichere und mit Multiprotokoll-Charakter
ausgestattete Point-to-Point-Protokoll (PPP) bietet
DoD-Internet-Standard
TCP/IP-Architektur
Application Layer
HTTP
Transport Layer
TCP / ICMP
Internet Layer
IP
Network Layer
PPP / MODEM
Abb. (2.3): Soft-Modem Schichtenmodell
weitaus bessere Mechanismen und erfreut sich
dementsprechend großer Popularität. Das PPP wird
mittlerweile standardmäßig von Internet-fähigen
PC-Systemen
zum
Aufbau
einer
Modem-
Wahlverbindung (DFÜ-Verbindung) verwendet und
findet deshalb auch in diesem Projekt seine
Anwendung. Neben dem PPP bildet das Modem den
zweiten Bestandteil der Netzwerk-Schicht. Das
Modem stellt die Schnittstelle zum physikalischen
Medium, der Telefonleitung, dar und kümmert sich mittels digitaler Modulation um die
Anpassung der binären Information an das Übertragungsmedium. Abbildung (2.3) zeigt das,
für die Soft-Modem-Applikation gültige Schichtenmodell.
Die Einschränkung des zugrunde liegenden TCP/IP-Stacks, nur eine aktive TCP-Verbindung
zu ermöglichen, tritt bei der Soft-Modem-Applikation in den Hintergrund, da hierbei Daten
über eine serielle Punkt-zu-Punkt-Verbindung übermittelt werden, an der sowieso nur zwei
Verbindungs-Teilnehmer beteiligt sind.
Weiterhin entfällt ein Protokoll der Internet-Schicht. Das Address-Resolution-Protokoll
(ARP), das die vom IP verwendeten IP-Adressen in Hardware-Adressen (die sog. MACAdressen) auflöst und damit die Grundlage für die Kommunikation über Ethernet darstellt.
Das in diesem Projekt besprochene Point-to-Point-Protokoll erfordert keine Auflösung der IPAdressen in Hardware-Adressen.
8
Digitale Modulation und Internet-Protokolle
In den folgenden zwei Punkten dieses Kapitels wird zuerst, der für dieses Projekt verwendete
Modemstandard besprochen und anschließend im Detail auf die Definition und
Implementierungs-Forderungen des PPP eingegangen.
2.2. V.21 Modemstandard zur Datenübertragung im öffentlichen
Telefonnetz
Zentrale Aufgabe eines Modems ist einerseits die Modulierung von binärer Information in
analoge Signale, die über die Telefonleitung übertragen werden können und andererseits die
Demodulierung von analogen Übertragungs-Signalen zurück in binäre Information. Aus
dieser Aufgabe lässt sich auch der Name Modem herleiten, als Modulator und Demodulator.
Die verschiedenen Arten der Binärmodulation sind in den sog. CCITT-Empfehlungen der VSerie
definiert.
Tabelle
(2.1)
zeigt
einen
kleinen
Ausschnitt
der
empfohlenen
Modemstandards entnommen aus [FHL].
V.21
Datenübertragung bei 300bit/s vollduplex, im Wählnetz. Für jede der beiden
Richtungen wird eine eigene Trägerfrequenz verwendet. Die binären Zustände
werden durch Frequenzen (Frequenzumtastung) codiert.
V.22
Übertragungsnorm mit 1200bit/s, vollduplex. Als Modulation wird
Phasenumtastung verwendet. Die Baudrate beträgt 600Baud. Gleichzeitige
Übertragung von zwei Bits (Dibit) in vier Zuständen bzw. Phasensprüngen. Die
Trägerfrequenzen sind 1200Hz bei Originate bzw. 2400Hz bei Answer.
V.22bis
Übertragungsnorm für Geschwindigkeiten von 2400bit/s. Basiert auf V.22, nur
dass statt zwei Bits vier Bits (Quadbit) gleichzeitig übertragen werden. Arbeitet
mit QAM als Modulation bei den selben Frequenzen wie V.22
Asymmetrische vollduplex Datenübertragung. In der einen Richtung wird mit
1200bit/s übertragen, in der anderen mit 75bit/s (Split-Speed). Modulation ist
Frequenzumtastung.
Vollduplex-Modem mit 2400bit/s und Echobeseitigung zur Benutzung im
öffentlichen Telefonwählnetz und auf Zweidraht-Telefonmietleitungen. Verfahren
ähnlich V.22
ITU-T-Norm zur halbduplex-Datenübertragung mit 9600bit/s. Basiert auf
V.22bis. Dort hat man eine Schrittgeschwindigkeit von 600Baud. Dabei werden
mit QAM vier Bit (Quadbit) gleichzeitig übertragen. Die Schrittgeschwindigkeit
wurde für V.29 auf 2400Baud erhöht. Dafür wird eine Trägerfrequenz von
1700Hz verwendet, die genau in der Mitte des Frequenzbandes (300Hz bis
3400Hz) liegt. Für den Rückkanal bleibt damit kein Platz mehr.
V.23
V.26ter
V.29
V.32
ITU-Norm zur Datenübertragung mit 9600bit/s bidirektional (vollduplex). Basiert
auf V.29. Ebenso wie dort werden für 9600bit/s Quadbit mit QAM übertragen,
9
Digitale Modulation und Internet-Protokolle
allerdings bei einer Trägerfrequenz von 1800Hz. Auch hier ist kein Platz für einen
Rückkanal. Daher senden beide Modems gleichzeitig auf derselben Frequenz. Da
aber jedes Modem weiß, was es gerade gesendet hat, kann es aus dem
Frequenzgemisch sein Signale unterdrücken und so die Daten der Gegenstelle
herausfiltern (Echo-Cancelling). Eine Variante von V.32 ist die TrellisModulation. Hier werden statt der Quadbit Quintbit übertragen. Das zusätzliche
Bit wird nicht für Datenübertragung genutzt, sondern für die Fehlerkorrektur.
Dadurch ist die Übertragung etwa doppelt so fehlersicher, wie ohne Trellis.
Erweiterung von V.32 auf 14400bit/s vollduplex.
Duplexmodem mit Geschwindigkeiten bis 28800bit/s für die Verwendung im
allgemeinen Telefonnetz auf Zweidraht-Telefonmietleitungen und für
festgeschaltete Zweidraht-Telefonmietleitungen (Punkt-zu-Punkt)
Duplexmodem mit Geschwindigkeiten bis 33600bit/s
V.32bis
V.34
V.34bis
V.90
56k-Modems behandeln die Telefonleitung nicht wie ein analoges System,
sondern nutzen die überwiegend digitale Struktur moderner Netze
Tab.(2.1): V-Modemstandards
Für dieses Projekt wurde die Festlegung getroffen, die Kommunikation ausschließlich auf
Basis des V.21-Modemstandards zu realisieren.
Der V.21-Standard definiert eine voll-duplex Verbindung zur gleichzeitigen Übertragung von
Daten in beide Richtungen mit einer Bitgeschwindigkeit von 300 bit/s. Der Standard gilt
sowohl
für
synStartbit
asynchrone
Ver-
bindungen, wobei in
Binärsignal
chrone, als auch für
0
Stoppbit
Datenbits
1
1
0
1
0
0
1
0
dieser Arbeit, die für
bindungen
übliche
t
FSK-Signal
Modem-Wahlver-
1
asynchrone
Datenübertragung
Abb.(2.4): Binär- und FSK-Signal für ASCII „K“
im Betrachtungsfeld steht. Bei asynchroner Datenübertragung werden die Datenbits (z.B. ein
Byte) vor der Übertragung mit einem Start- und Stoppbit umrahmt.
Die Binärmodulation des V.21-Standards erfolgt durch eine Frequenzumtastung (engl.
Frequency Shift Keying, FSK), bei der den Binärzuständen 0 und 1 jeweils genau eine
charakteristische Frequenz zugeordnet wird und entsprechend der zu sendenden Bitfolge in
Bitgeschwindigkeit zwischen den beiden charakteristischen Frequenzen umgetastet wird.
Abbildung (2.4) zeigt schematisch das FSK-Signal für das ASCII-codierte Zeichen „K“.
10
Digitale Modulation und Internet-Protokolle
Zur Realisierung der voll-duplex Verbindung definiert der V.21-Standard zwei getrennte
Frequenzkanäle, die mit Kanal Nr.1 und Kanal Nr. 2 bezeichnet werden. Ein Kanal zum
Empfangen und einer zum Senden. Abbildung (2.5) stellt die beiden Kanäle im
Frequenzbereich dar. Jeder Kanal belegt einen Frequenzbereich von ∆f = ±100Hz. Aus
Tabelle (2.2) lassen sich die nominellen Mittenfrequenzen und die, bei einem
Frequenzbereich von ±100Hz resultierenden, charakteristischen Frequenzen der FSK des
jeweiligen Kanals entnehmen.
Kanal Nr.1
Kanal Nr.2
f1 = 1080Hz
f2 = 1750Hz
binär 1
980Hz
1650Hz
binär 0
1180Hz
1850Hz
nominelle Mittenfrequenz
charakteristische Frequenzen
Tab.(2.2): Frequenzdefinitionen für FSK nach V.21
Die Frequenzen sind so gewählt, dass sich beide Kanäle innerhalb des Sprachbandes
befinden, für das das Telefonnetz ursprünglich ausgelegt wurde.
Weiterhin definiert der V.21-Standard zwei verschiedene Modem-Betriebsarten. Zum einen
den
Kanal Nr.1
Kanal Nr.2
als
Originate-Mode
bezeichneten
Zustand des rufenden Modem, das im Kanal
A
Nr.1 sendet und im Kanal Nr. 2 empfängt.
Und zum anderen den als Answer-Mode
bezeichneten Zustand des gerufenen Modem,
das entsprechend im Kanal Nr.1 empfängt
//
f1-∆f
f1
f1+∆f
f2-∆f
f2
f2+∆f
und
f
im
entwickelte
Abb.(2.5): FSK-Frequenzkanäle nach V.21-Standard
Kanal
Nr.2
sendet.
Da
Soft-Modem-Baugruppe
die
aus-
schließlich für den Server-Betrieb ausgelegt
wurde, lässt sich an dieser Stelle bereits eine Aufgabenverteilung der beiden Kanäle
vornehmen. Aus Sicht der Soft-Modem-Applikation, die sich stets im Answer-Mode befindet,
ist Kanal Nr.1 der Empfangskanal und Kanal Nr.2 der Sendekanal.
Der V.21 Standard lässt eine Frequenz-Abweichung von ±6Hz am Ausgang des FSKModulators zu. Es wird weiterhin eine Frequenzabweichung von ±6Hz angenommen, die
durch den Übertragungsweg entstehen könnte. Der FSK-Demodulator muss demnach
Frequenzabweichungen der charakteristischen Frequenzen von ±12Hz tolerieren.
11
Digitale Modulation und Internet-Protokolle
Der maximale Sendepegel eines Modems sollte –9dBm nicht überschreiten. Im Gegenzug
sollten Frequenzen mit einem minimalen Signalpegel von –43dBm vom Demodulator noch
erkannt werden.
Alle weiteren Definitionen des V.21-Standards beziehen sich auf die Steuerung von ModemSchnittstellensignale zum daten-verarbeitenden Endgerät. Da in diesem Projekt die ModemFunktion nach V.21-Standard per Software in das Endgerät implementiert werden soll,
können sämtliche Hardware-Schnittstellensignale außer Acht gelassen werden.
2.3. Das Point-to-Point-Protokoll (PPP)
Das PPP dient eigentlich nur als Überbegriff für einen sehr komplexen ProtokollMechanismus, der die Datenkommunikation auf seriellen Punkt-zu-Punkt-Verbindungen
ermöglicht. Im folgenden wird deshalb sehr detailliert auf alle Komponenten und deren
Funktions-Mechanismen eingegangen, um der Komplexität des Protokolls und seiner
Hilfsprotokolle gerecht zu werden.
2.3.1 Hauptkomponenten des PPP
a) Data Encapsulation (Datenkapselung)
Die PPP-Datenkapselung ermöglicht die Unterscheidung von Datagrammen unterschiedlicher
Protokolltypen. Die Kapselung erfordert weiterhin eine Rahmenbildung, um die Identifikation
von Anfang und Ende der Kapselung zu gewährleisten.
Das HDLC (High-Level-Data-Link-Control)-Protokoll wurde beim PPP als Basis zum
Übermitteln der Datenpakete auf der ISO/OSI-Schicht 2 (Data-Link-Layer) spezifiziert. Das
HDLC-Protokoll ist seit Mitte der siebziger Jahre weltweit standardisiert und wurde im ISOStandard ISO 3309-1979 und ISO 3309:1984/PDAD1 veröffentlicht.
Die PPP-Datenkapselung ermöglicht das Multiplexen von verschiedenen Network-LayerProtokollen simultan über die selbe Verbindung.
b) Link-Control-Protocol (LCP)
Hierbei handelt es sich um ein Verbindungskontroll-Protokoll, das zum Aufbau, zur
Konfiguration und zum Testen der Datenverbindung dient. Mit Hilfe des LCP werden beim
Aufbau einer Verbindung zwischen zwei Rechnern automatisch die Formatoptionen der
Datenkapselung geklärt, die unterschiedlichen Größenbeschränkungen der Empfangspuffer
12
Digitale Modulation und Internet-Protokolle
beider an der Kommunikation beteiligten Teilnehmer aufeinander abgestimmt, looped-backVerbindungen und allgemein auftretende Konfigurationsfehler erkannt. LCP ist weiterhin
zuständig für die Trennung der Verbindung. Optional kann das LCP ermitteln, ob eine
Verbindung einwandfrei funktioniert oder scheitert.
c) Familie von Network-Control-Protokollen (NCPs)
PPP-Verbindungen tendieren dazu viele Probleme der gegenwärtigen Familie an NetzwerkProtokollen zu verschärfen. Z.B. Die Zuweisung und Verwaltung von IP-Adressen, was sogar
in LAN-Umgebungen ein Problem darstellt, ist besonders schwierig über Punkt-zu-PunktVerbindungen.
Diese Probleme werden von einer Familie von Network-Control-Protokollen (NCPs)
behoben. Jedes NCP ist unmittelbar mit einem Protokoll der Netzwerk-Schicht verbunden.
Das jeweilige NCP stellt Mechanismen zur Verfügung, durch die die Punkt-zu-PunktVerbindung für das zugehörige Netzwerk-Protokoll konfiguriert werden kann. Für das
Internet-Protokoll findet hierfür das Internet-Protocol-Control-Protocol (s. Abschnitt 2.5)
seine Anwendung.
2.3.2. Rahmenbildung auf Basis des HDLC-Protokolls
2.3.2.1. Rahmenformat
Abbildung (2.6) zeigt eine Zusammenfassung der standardmäßigen PPP-Rahmen-Struktur.
Die einzelnen Felder werden von links nach recht gesendet. Die Erläuterungen zur HDLCmäßigen Rahmenbildung beschränken sich auf die Betrachtung von asynchronen
Datenverbindungen.
Flag
0111 1110
Protocol
8/16 Bit
FCS
16/32 Bit
Address
1111 1111
Information
*
Flag
0111 1110
Control
0000 0011
Padding
*
Inter-Frame Fill
or next Address
Abb. (2.6): Standard PPP-Rahmen-Struktur auf HDLC-Basis
Die Abbildung beinhaltet weder Start/Stopp-Bits (im Falle von asynchronen Verbindungen),
noch irgendwelche zur Transparenz zusätzlich eingefügte Oktette. Auf asynchronen
Verbindungen werden die Oktette jeweils mit einem Start- und einem Stopp-Bit gesendet.
13
Digitale Modulation und Internet-Protokolle
Alle Binärwerte, die im Folgenden aufgeführt werden lesen sich von links nach rechts,
beginnend mit dem Most-Significant-Bit (MSB) und endend mit dem Least-Significant-Bit
(LSB).
Flag-Sequenz
Jeder Rahmen beginnt und endet mit einer Flag-Sequenz, die der binären Sequenz 01111110
(hexadezimal 0x7E) entspricht. Zwischen zwei Rahmen wird nur eine einzige Flag-Sequenz
benötigt. Zwei aufeinander folgende Flag-Sequenzen werden als ein leerer Rahmen gedeutet
und nicht weiter von der Implementierung verarbeitet, d.h. es wird kein FCS-(Frame-CheckSequence)-Fehler (s. Abschnitt 2.3.2.5) registriert.
Address
Das Address-Feld hat die Länge von einem Byte und beinhaltet den binären Wert 11111111
(hexadezimal 0xFF). Das Address-Feld entspricht der All-Stations Adresse, da PPP keine
individuellen Stationsadressen zuweist. Die All-Stations Adresse sollte immer erkannt und
empfangen werden. Datenrahmen mit ungültiger Adresse werden nicht weiter bearbeitet.
Control
Das Control-Feld hat die Länge von einem Byte und beinhaltet den binären Wert 00000011
(hexadezimal 0x03). Hierbei handelt es sich um das Unnumbered-Information-Kommando
bei dem das Poll/Final (P/F) Bit auf NULL gesetzt ist. Rahmen mit ungültigem Control-Feld
werden nicht weiter bearbeitet.
Protocol
Das Protocol-Feld umfasst ein oder zwei Byte und sein Wert identifiziert das Datagramm,
welches im Informationsfeld des Datenpakets gekapselt vorliegt. Das höherwertige Byte des
Protokoll-Feldes wird zuerst gesendet.
Die Struktur des Protocol-Feldes entspricht dem ISO 3309 Erweiterungsmechanismus für
Adressfelder. Alle Protokollwerte müssen ungerade sein, das bedeutet, dass das
niederwertigste Bit des niederwertigen Bytes eine „1“ sein muss. Gleichzeitig soll das
niederwertigste Bit des höherwertigen Bytes einer „0“ entsprechen. Wird ein Rahmen
empfangen, der nicht diesen Regeln entspricht, gilt das Protokoll als unerkannt.
14
Digitale Modulation und Internet-Protokolle
Die aktuellen Protokollwerte finden sich im „Assigned Numbers“-RFC [RFC1700]. Die
Werte sind in Abschnitte eingeteilt.
„0***“ bis „3***“
Netzwerkprotokolle (z.B. IP)
„4***“ bis „7***“
Protokolle, die wenig Datenaufkommen verursachen und
kein eigenes NCP besitzen
„8***“ bis „b***“
mit den Netzwerkprotokollen verbundene NCPs
„c***“ bis „f***“
Werte für Datenpakete der LCPs
Wichtige Protokollwerte für dieses Projekt:
c021
Link-Control-Protocol (LCP)
8021
Internet-Protocol-Control-Protocol (IPCP)
0021
Internet-Protocol (IP)
Information
Das Information-Feld umfasst eine beliebige Anzahl von Bytes größer oder gleich NULL. Die
maximale Anzahl der beinhalteten Bytes, einschließlich des Paddings, wird als MaximumReceive-Unit (MRU) bezeichnet und ist standardmäßig auf den Wert 1500 festgelegt.
Padding
Bei der Übertragung kann das Informationsfeld mit einer beliebigen Anzahl an
informationslosen Bytes, bis zum Erreichen der MRU, aufgefüllt werden. Es obliegt dann
weiterhin in der Verantwortung der einzelnen Protokolle die wirkliche Information vom
Padding zu unterscheiden.
Frame-Check-Sequence (FCS)
Das 16 oder 32 Bit lange Frame-Check-Sequence-Feld ermöglicht eine Fehlerkontrolle des
übermittelten Datenrahmens. Eine Tabellengestützte Berechnungsmethode hierfür wird im
Rahmen dieser Arbeit im Abschnitt 2.3.2.5 vorgestellt und wurde auch in dieser Form in die
Lösung implementiert.
Der oben beschriebene Basis-Rahmen kann durch Konfigurationen im Rahmen des LCP noch
ein paar Modifikationen erfahren. Die modifizierten Rahmen lassen sich jedoch klar von den
Standard-Rahmen unterscheiden. Im Detail wird hierauf im Abschnitt 2.4.3 eingegangen, bei
der Beschreibung der einzelnen Konfigurations-Optionen des LCP.
15
Digitale Modulation und Internet-Protokolle
2.3.2.2. Transparenz
HDLC verwendet, um dem Datenstrom Transparenz zu verleihen und ASCII-KontrollZeichen, die nicht als solche erkannt werden sollen, zu Maskieren, einen sog. Octet-StuffingProcess. Hierfür findet das Control-Escape-Byte Anwendung. Das Control-Escape-Byte
entspricht dem binären Wert 01111101 (hexadezimal 0x7d).
Nach der FCS Berechnung, analysiert die Implementierung auf dem sendenden Rechner den
kompletten Datenrahmen zwischen zwei Flag-Sequenzen.
Alle Flag-Sequenzen, Control-Escape-Bytes und sämtliche weiteren Bytes, deren Wert kleiner
als hexadezimal 0x20 entspricht, werden dabei durch eine zwei Byte lange Sequenz ersetzt
(nach [RFC1662] erfolgt dies nur, wenn das Byte zusätzlich noch in der ACCM des
sendenden Rechners aufgeführt ist). Diese Sequenz besteht aus dem Control-Escape-Byte,
gefolgt von dem ursprünglichen Byte, welches mit dem hexadezimal-Wert 0x20 exklusivODER verknüpft wurde. Ein paar Beispiele sollen dieses Prinzip anschaulich verdeutlichen.
Die Implementierung findet vor dem Senden zwischen zwei Flag-Sequenzen, sprich innerhalb
eines Datenrahmens die Bytes
0x7E (Flag-Sequenz),
0x7D (Control-Escape-Byte) und
0x01.
Diese Bytes werden nun mit dem Wert 0x20 exklusiv-ODER verknüpft und es wird ihnen ein
Control-Escape-Byte vorangestellt. Übertragen werden dann also:
0x7D 0x5E
0x7D 0x5D
0x7D 0x21
Durch die Berücksichtigung aller Bytes, deren Wert kleiner als hexadezimal 0x20 ist, können
alle
ASCII-Kontroll-Zeichen
(exklusive
DEL)
transparent
durch
alle
bekannten
Datenkommunikationsgeräte übermittelt werden.
Die Implementierung des empfangenden Rechners, beschreitet den oben beschriebenen Weg
rückwärts. Vor der FCS Berechnung werden die Daten zwischen zwei Flag Sequenzen
analysiert. Jedes Byte, dessen Wert kleiner als hexadezimal 0x20 ist, wird überprüft. Wenn
16
Digitale Modulation und Internet-Protokolle
das Byte in der Async-Control-Character-Map (ACCM, siehe Abschnitt 2.4.3) des
empfangenden Rechners aufgeführt ist, wird es einfach entfernt [RFC1662], da das Zeichen in
diesem Fall als ASCII-Kontroll-Zeichen gilt. Weiterhin werden sämtliche Control-EscapeBytes aus dem Datenstrom entfernt, wobei das jeweils folgende Byte mit 0x20 exklusivODER verknüpft wird.
2.3.2.3. Ungültige Rahmen
Rahmen, die als ungültig erkannt wurden, sollten nicht weiter von der Implementierung
bearbeitet werden und sollten keinen FCS-Fehler verursachen. Hierzu zählen Rahmen, deren
Länge weniger als vier Byte, bei Verwendung einer standardmäßigen 16Bit-FCS, umfasst.
Rahmen, bei denen auf ein Control-Escape-Byte unmittelbar eine abschließende FlagSequenz folgt.
2.3.2.4. Inter-frame Fill
Wie bereits weiter oben beschrieben, kann eine Flag-Sequenz das Ende eines Datenrahmens
und gleichzeitig den Anfang eines neuen Datenrahmens kennzeichnen. Es ist also nicht
zwingend notwendig eine weitere Flag-Sequenz zum Einleiten eines neuen Datenrahmens zu
senden. Es wird aber häufig der Fall auftreten, dass zwei Datenrahmen nicht direkt
aufeinander folgend gesendet werden und demnach eine zeitliche Pause auftritt. Innerhalb
dieser Pause muss der Sendepegel kontinuierlich auf HIGH-Level gehalten werden. Der
Empfänger befindet sich dabei in einem Zustand, der einen neuen Datenrahmen empfangen
kann. Da es innerhalb dieser Pause zu Verbindungsbedingten Störungen kommen kann, ist es
jedoch trotzdem ratsam eine weitere Flag Sequenz dem neuen Datenrahmen voran zu stellen,
da ansonsten mit großer Sicherheit ein FCS-Fehler auftreten kann.
Es wird demnach empfohlen immer eine weitere Start-Flag-Sequenz zu senden, wenn bereits
eine gewisse Zeit seit der letzten Flag-Sequenz vergangen ist. Als Richtlinie dient hierfür der
Wert von einer Sekunde.
2.3.2.5. FCS (Frame-Check-Sequence) Berechnung – 16Bit mit Tabellenunterstützung
Um überhaupt Daten über eine PPP-Verbindung versenden zu können, die vom Gegenüber
auch als korrekt anerkannt werden, muss die Implementierung einen FCS-BerechnungsMechanismus unterstützen. Die FCS-Berechnung erfolgt über Address-, Control-, Protocol-,
Information- und Padding-Feld des Datenrahmens. Bei vereinbarter Address- und ControlFeld-Kompression und Protocol-Feld-Kompression (siehe Abschnitt 2.4.3) wird die FCS17
Digitale Modulation und Internet-Protokolle
Berechnung über den komprimierten Datenrahmen und nicht über den Unkomprimierten
ausgeführt.
Ursprünglich wurde die FCS-Berechnung für eine hardwaremäßige Implementierung
entworfen. Während des Versendens wird die FCS berechnet und anschließend im
Einerkomplement an den Datenstrom angehangen, um daraufhin den Datenstrom mit einer
Flag-Sequenz zu beenden.
Da die empfangende Implementierung keine Möglichkeit hat festzustellen, wann sie mit der
FCS-Berechnung enden kann bevor nicht eine abschließende Flag-Sequenz auftritt, wurde die
FCS-Berechnung so konzipiert, dass sich beim Durchlaufen der Sender-FCS-Sequenz durch
die FCS-Berechnung im Empfänger ein bestimmter Wert ergibt. Anhand diesem Wert wird
entschieden, ob der empfangene Datenrahmen als gültig anerkannt wird.
[RFC1662] und [RFC1171] bieten eine softwaremäßige Lösung zur Berechnung und
Behandlung der
FCS.
Hierzu
findet
ein
Tabellengestützter Software-Algorithmus
Verwendung. Der folgende C-Code generiert die benötigten Tabellenwerte.
#define P 0x8408
static unsigned int fcstab[256];
void TableGenerator(void) {
unsigned int b, v;
int i;
for (b = 0;b<256;b++ ) {
v = b;
for (i = 0; i<8;i++ )
v = v & 1 ? (v >> 1) ^ P : v >> 1;
fcstab[b] = v;
}
}
Der Code füllt bei seiner Abarbeitung den Datenvektor fcstab mit 256 Werten. Auf der
nächsten Seite sind die berechneten Werte aufgelistet.
18
Digitale Modulation und Internet-Protokolle
fcstab[256] = {
0x0000, 0x1189,
0x8c48, 0x9dc1,
0x1081, 0x0108,
0x9cc9, 0x8d40,
0x2102, 0x308b,
0xad4a, 0xbcc3,
0x3183, 0x200a,
0xbdcb, 0xac42,
0x4204, 0x538d,
0xce4c, 0xdfc5,
0x5285, 0x430c,
0xdecd, 0xcf44,
0x6306, 0x728f,
0xef4e, 0xfec7,
0x7387, 0x620e,
0xffcf, 0xee46,
0x8408, 0x9581,
0x0840, 0x19c9,
0x9489, 0x8500,
0x18c1, 0x0948,
0xa50a, 0xb483,
0x2942, 0x38cb,
0xb58b, 0xa402,
0x39c3, 0x284a,
0xc60c, 0xd785,
0x4a44, 0x5bcd,
0xd68d, 0xc704,
0x5ac5, 0x4b4c,
0xe70e, 0xf687,
0x6b46, 0x7acf,
0xf78f, 0xe606,
0x7bc7, 0x6a4e,
};
0x2312,
0xaf5a,
0x3393,
0xbfdb,
0x0210,
0x8e58,
0x1291,
0x9ed9,
0x6116,
0xed5e,
0x7197,
0xfddf,
0x4014,
0xcc5c,
0x5095,
0xdcdd,
0xa71a,
0x2b52,
0xb79b,
0x3bd3,
0x8618,
0x0a50,
0x9699,
0x1ad1,
0xe51e,
0x6956,
0xf59f,
0x79d7,
0xc41c,
0x4854,
0xd49d,
0x58d5,
0x329b,
0xbed3,
0x221a,
0xae52,
0x1399,
0x9fd1,
0x0318,
0x8f50,
0x709f,
0xfcd7,
0x601e,
0xec56,
0x519d,
0xddd5,
0x411c,
0xcd54,
0xb693,
0x3adb,
0xa612,
0x2a5a,
0x9791,
0x1bd9,
0x8710,
0x0b58,
0xf497,
0x78df,
0xe416,
0x685e,
0xd595,
0x59dd,
0xc514,
0x495c,
0x4624,
0xca6c,
0x56a5,
0xdaed,
0x6726,
0xeb6e,
0x77a7,
0xfbef,
0x0420,
0x8868,
0x14a1,
0x98e9,
0x2522,
0xa96a,
0x35a3,
0xb9eb,
0xc22c,
0x4e64,
0xd2ad,
0x5ee5,
0xe32e,
0x6f66,
0xf3af,
0x7fe7,
0x8028,
0x0c60,
0x90a9,
0x1ce1,
0xa12a,
0x2d62,
0xb1ab,
0x3de3,
0x57ad,
0xdbe5,
0x472c,
0xcb64,
0x76af,
0xfae7,
0x662e,
0xea66,
0x15a9,
0x99e1,
0x0528,
0x8960,
0x34ab,
0xb8e3,
0x242a,
0xa862,
0xd3a5,
0x5fed,
0xc324,
0x4f6c,
0xf2a7,
0x7eef,
0xe226,
0x6e6e,
0x91a1,
0x1de9,
0x8120,
0x0d68,
0xb0a3,
0x3ceb,
0xa022,
0x2c6a,
0x6536,
0xe97e,
0x75b7,
0xf9ff,
0x4434,
0xc87c,
0x54b5,
0xd8fd,
0x2732,
0xab7a,
0x37b3,
0xbbfb,
0x0630,
0x8a78,
0x16b1,
0x9af9,
0xe13e,
0x6d76,
0xf1bf,
0x7df7,
0xc03c,
0x4c74,
0xd0bd,
0x5cf5,
0xa33a,
0x2f72,
0xb3bb,
0x3ff3,
0x8238,
0x0e70,
0x92b9,
0x1ef1,
0x74bf,
0xf8f7,
0x643e,
0xe876,
0x55bd,
0xd9f5,
0x453c,
0xc974,
0x36bb,
0xbaf3,
0x263a,
0xaa72,
0x17b9,
0x9bf1,
0x0738,
0x8b70,
0xf0b7,
0x7cff,
0xe036,
0x6c7e,
0xd1b5,
0x5dfd,
0xc134,
0x4d7c,
0xb2b3,
0x3efb,
0xa232,
0x2e7a,
0x93b1,
0x1ff9,
0x8330,
0x0f78
Die folgende Funktion berechnet auf Grundlage eines Datensatzes, der Länge des Datensatzes
und einer Initialisierungs-FCS einen FCS-Wert für den gegebenen Datensatz.
#include
<assert.h>
///////////////////////////////////////////////////////////////
// Calculate a new fcs given the current fcs and the new data.
// arguments: fcs, initialization FCS
//
cp, pointer to the serial data stream
//
len, length of the data buffer in bytes
// returns:
unsigned int fcs
unsigned int pppfcs16(unsigned int fcs,char* cp,int len) {
assert(sizeof (fcs) == 2);
assert(((fcs) -1) > 0);
while (len--)
fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff];
return (fcs);
}
19
Digitale Modulation und Internet-Protokolle
Das folgende Anwendungsbeispiel soll die praktische Verwendung der Funktion pppfcs16
veranschaulichen.
#define PPPINITFCS16 0xffff // Initial FCS value
#define PPPGOODFCS16 0xf0b8 // Good final FCS value
unsigned char* pFrame
unsigned int
FrameLen
// pointer to the data-stream
// length of the data-stream
Testfcs16() {
unsigned int trialfcs;
// add FCS on output
trialfcs = pppfcs16(PPPINITFCS16,pFrame,FrameLen);
trialfcs ^= 0xffff;
// complement
pFrame[FrameLen] = (trialfcs & 0x00ff);
// least significant byte first
pFrame[FrameLen+1] = ((trialfcs >> 8) & 0x00ff);
// check FCS on input
trialfcs = pppfcs16(PPPINITFCS16,pFrame,FrameLen+2);
// if(trialfcs==PPPGOODFCS16) Æ FCS is correct
}
Die berechnete FCS wird im Einerkomplement, mit dem niederwertigen Byte zuerst, an den
Datenstrom angehängt.
2.3.3. PPP Verbindungs-Optionen
2.3.3.1. Überblick
Um eine Datenübertragung über einer Punkt-zu-Punkt-Verbindung zu ermöglichen, muss
jedes
Ende
der
PPP-Verbindung
zuerst
LCP-Pakete
senden,
um
die
Datenübertragungsverbindung zu konfigurieren und zu testen. Nach dem Aufbau der
Verbindung kann optional ein Authentifizierungs-Mechanismus gestartet werden.
Anschließend muss PPP NCP-Pakete senden, um ein oder mehrere Network-Layer-Protokolle
auszuwählen und die Verbindung entsprechend zu konfigurieren. Sobald jedes der
ausgewählten Network-Layer-Protokolle konfiguriert wurde, können Datagramme der
jeweiligen Network-Layer-Protokolle über die Verbindung gesendet werden.
Die Verbindung bleibt solange für die Datenübertragung konfiguriert, bis durch LCP- oder
NCP-Pakete die Verbindung explizit getrennt wird oder bis ein externes Ereignis auftritt, dass
eine Trennung der Verbindung veranlasst
20
Digitale Modulation und Internet-Protokolle
2.3.3.2. Das PPP-Phasen-Diagramm
Während der Prozesse der Konfiguration, der Aufrechterhaltung und der Trennung der Punktzu-Punkt-Verbindung, durchläuft die PPP-Verbindung klar voneinander getrennte Phasen.
Diese Phasen und deren Zusammenhänge sind in dem folgenden vereinfachten
Zustandsgraphen dargestellt.
UP
Dead
OPENED
Establish
Authenticate
FAIL
SUCCESS/
NONE
FAIL
CLOSING
DOWN
Terminate
Network
Abb. (2.7): PPP-Phasen-Diagramm
In der Abbildung (2.7) sind nicht alle Zustands-Übergänge spezifiziert. Die ergänzenden
Erläuterungen zu den einzelnen Phasen sind für die Implementierung bindend.
a) Dead-Phase (die physikalische Schicht ist nicht bereit)
Die Verbindung startet und endet in dieser Phase. Sobald ein externes Ereignis auftritt und
anzeigt, dass die physikalische Schicht einsatzbereit ist, geht das PPP-Protokoll in die
Establish-Phase über. Während der Dead-Phase befindet sich der LCP-Automat (siehe
Abschnitt 2.6) im Initial oder Starting-Zustand. Der Übergang von dieser Phase in die
Establish-Phase signalisiert dem LCP-Automat ein sog. Up-Ereignis.
Die in Kapitel 4 vorgestellte Implementierungs-Lösung definiert keine explizite Dead-Phase,
sondern befindet sich als Server-Anwendung stets in der Establish-Phase, um auf eingehende
LCP-Datenpakete zu warten, sobald die physikalische Verbindung hergestellt wurde.
b) Establish-Phase
Das LCP übernimmt die Aufgabe des Aufbaus der Verbindung durch den Austausch von
Konfigurations-Datenpaketen. Sobald beiderseits ein Configure-Ack (s. Abschnitt 2.4.2)
21
Digitale Modulation und Internet-Protokolle
gesendet und empfangen wurde, ist der Konfigurations-Mechanismus beendet und das LCP
befindet sich im Opened-Zustand.
Es wird angenommen, dass alle Konfigurations-Optionen mit Standardwerten belegt sind, es
sei denn, dass eine Änderung während der Konfigurations-Phase vereinbart wurde.
In dieser Phase werden von LCP nur Konfigurations-Optionen verhandelt, die unabhängig
von spezifischen Network-Layer-Protokollen sind. Die Konfiguration von einzelnen NetworkLayer-Protokollen wird erst später innerhalb der Network-Layer-Phase von separaten NCPs
ausgeführt.
Alle Datenpakete, bei denen es sich nicht um ein LCP-Paket handelt, werden in dieser Phase
nicht weiter verarbeitet.
Das Empfangen eines LCP-Configure-Request innerhalb der Authentication- oder NetworkLayer-Phase verursacht eine Rückkehr des PPP in die Establish-Phase.
c) Authentication-Phase
Auf manchen Verbindungen wird von einem Rechner verlangt, dass er seine Identität bestätigt
und sich beim Kommunikationspartner anmeldet, bevor ihm erlaubt wird Network-LayerProtokoll-Daten über die Verbindung auszutauschen.
Standardmäßig
ist
diese
Authentifizierungs-Phase
nicht
erforderlich.
Wenn
eine
Implementierung es wünscht, dass sich ein Verbindungs-Partner mit einem bestimmten
Authentifizierungs-Protokoll anmeldet, muss die Verwendung dieses AuthentifizierungsProtokolls bereits in der Establish-Phase ausgehandelt und vereinbart werden.
Die Authentifizierung sollte so schnell wie möglich nach dem Aufbau der Verbindung
stattfinden. Obwohl innerhalb dieser Phase auch Link-Quality-Monitoring-Datenpakete
ausgetauscht werden können, darf durch das Link-Quality-Monitoring keine zeitlich
unbestimmte Verzögerung des Anmeldevorgangs verursacht werden.
Der Übergang von Authentication-Phase zur Network-Layer-Phase darf erst nach
erfolgreicher Anmeldung erfolgen. Sollte die Anmeldung fehlschlagen geht das PPP des
Rechners, der die Authentifizierung verlangt hat, über in die Termination-Phase.
In der Authentication-Phase ist nur der Austausch von Link-Controll-Protokoll-,
Authentifizierungs-Protokoll-, und Link-Quality-Monitoring-Datenpaketen erlaubt. Alle
anderen Datenpakete werden nicht weiter verarbeitet.
Das Scheitern der Anmeldung sollte auf der Seite der anmeldenden Implementierung nicht
aufgrund einer einfachen Zeitüberschreitung erfolgen. Es sollte vielmehr ein Mechanismus
unterstützt werden, der es ermöglicht Datenpakete des Authentifizierungs-Protokolls erneut
22
Digitale Modulation und Internet-Protokolle
zu senden und erst nach einigen gescheiterten Versuchen den Übergang in die TerminationPhase veranlasst.
Auf die Implementierung der Authentication-Phase wurde in diesem Projekt verzichtet, da im
Normalfall der Authentifizierungs-Wunsch von der passiven, angewählten ServerImplementierung gestellt wird.
d) Network-Layer-Phase
Sobald PPP die vorangegangenen Phasen durchlaufen hat, muss jedes Network-LayerProtokoll (z.B. IP, IPX oder AppleTalk) durch sein zugehöriges NCP einzeln konfiguriert
werden. Jedes NCP kann zu jedem beliebigen Zeitpunkt in die Zustände Opened oder Closed
gebracht werden. Nachdem ein NCP den Opened-Zustand erreicht hat überträgt PPP die
zugehörigen Network-Layer-Protokoll-Daten. Alle Datenpakete, die zu einem NetworkLayer-Protokoll gehören, dessen NCP sich nicht im Opened-Zustand befindet, dürfen nicht
weiter von der Implementierung verarbeitet werden. Dies gilt aber nur für Protokolle, die von
der Implementierung unterstützt werden. Datenpakete nicht-unterstützter Protokolle führen zu
einem Protocol-Reject (siehe Abschnitt 2.4).
Während der Network-Layer-Phase kann jede mögliche Kombination aus LCP, NCP und
Network-Layer-Protokoll Datenpaketen über die Verbindung ausgetauscht werden.
e) Termination-Phase
PPP ist zu jeder Zeit in der Lage eine bestehende Verbindung zu trennen. Ursachen für eine
Trennung sind:
- Verlust eines Hardware-Schnittstellensignals
- Fehlschlagen der Anmeldeprozedur
- Fehlschlagen der Verbindungs-Qualitäts-Prüfung
- Ablauf eines Leerlauf-Timers
- oder ein administratorischer Eingriff zur Verbindungs-Trennung
Das LCP wird zum Trennen der Verbindung eingesetzt, indem Terminate-Datenpakete
übermittelt werden. PPP informiert die einzelnen NCPs über die stattfindende Trennung, auf
dass diese entsprechend reagieren können.
Nach dem Übermitteln von Terminate-Paketen sollte die Implementierung der physikalischen
Schicht ein Signal geben, welches das physikalische Medium zur Trennung der Verbindung
veranlasst. Dies gilt im besonderen Fall bei einem Fehlschlagen der Anmelde-Prozedur.
23
Digitale Modulation und Internet-Protokolle
Die Implementierung, welche einen Terminate-Request gesendet hat, sollte die Trennung
vollziehen, nachdem sie ein Terminte-Ack empfangen hat oder der Restart-Timer abgelaufen
ist. Der Empfänger eines Terminate-Request sollte warten bis die sendende Implementierung
die Trennung vollzogen hat und darf die Verbindung nicht trennen, solange nicht mindestens
ein Restart-Timer Durchlauf stattgefunden hat. PPP sollte anschließend in die Dead-Phase
übergehen.
In der Terminate-Phase werden nur LCP-Datenpakete verarbeitet.
Das Trennen der Verbindung durch LCP ist vollkommen ausreichend. Es besteht kein Bedarf,
dass jedes NCP einen eigenen Terminate-Prozess durchläuft. Auf der anderen Seite besteht
kein ausreichender Grund eine PPP-Verbindung zu trennen sobald ein NCP in den ClosedZustand übergeht, auch wenn es sich hierbei um das einzig verwendete NCP handelt.
Da die Implementierung in diesem Projekt ohne Restart-Timer auskommt, wurde auch die
Terminate-Phase nicht vollständig implementiert. Das PPP hat keine Möglichkeit die PPPVerbindung aktiv zu beenden. Durch den Empfang eines Terminate-Request in der Establishoder Network-Phase kommt es zum Versenden eines Terminate-Ack und anschließend wird
die Verbindung als getrennt angesehen und damit das Trennen der physikalischen
Modemverbindung veranlasst.
2.4. Das Link-Control-Protokoll (LCP)
Das
Link-Control-Protokoll ermöglicht optional das dynamische Aushandeln von
Konfigurations-Optionen zwischen den PPP-Peers.
Die LCP-Informationen werden in Form von PPP-Datenrahmen verschickt. Dabei signalisiert
das Protocol-Feld mit dem Wert 0xc021 hexadezimal, dass es sich im Datenteil um LCPInformationen handelt. Pro Datenrahmen kann nur eine LCP-Information verschickt werden.
Für das LCP-Protokoll wurden drei Paketgruppen definiert.
a) Link-Configure-Pakete
Werden zum Aufbau und zur Konfiguration einer Verbindung eingesetzt (Configure-Request,
Configure-Ack, Configure-Nak und Configure-Reject).
24
Digitale Modulation und Internet-Protokolle
b) Link-Termination-Pakete
Link-Termination-Pakete signalisieren den geregelten Abbau der Verbindung zwischen zwei
PPP-Peers (Termination-Request, Termination-Ack).
c) Link-Maintenance-Pakete
Um die Verbindung ordnungsgemäß aufrecht halten zu können , werden zwischen den PPPPeers Link-Maintenance-Pakete verschickt (Code-Reject, Protocol-Reject, Echo-Request,
Echo-Reply und Discard-Request)
2.4.1. LCP-Datenformat
Abbildung (2.8) zeigt eine Zusammenfassung des Datenformats der LCP-Pakete.
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 15 ...
Code
Identifier
... 7 6 5 4 3 2 1 0
Length
Options
Abb. (2.8): LCP-Datenformat
Code
Das ein Byte lange Code-Feld definiert die Art der LCP-Information. Folgende Werte sind
hierfür festgelegt:
1
Configure-Request
2
Configure-Ack
3
Configure-Nak
4
Configure-Reject
5
Terminate-Request
6
Terminate-Ack
7
Code-Reject
8
Protocol-Reject
9
Echo-Request
10
Echo-Reply
11
Discard-Request
25
Digitale Modulation und Internet-Protokolle
Identifier
Das ein Byte lange Identifier-Feld ermöglicht die Zuordnung von Anfragen (Requests) zu
Antworten (Replies).
Length
Das zwei Byte lange Length-Feld legt die gesamte Länge des LCP-Paketes inklusive des
Code-, Identifier-, Length- und Options-Feldes fest.
Options
Das Options-Feld enthält die eigentlichen LCP-Konfigurations-Optionen. Das Format des
Options-Feldes wird durch das Code-Feld bestimmt.
2.4.2. LCP-Datenpakete
a) Configure-Request
Zum Öffnen einer Verbindung muss eine Implementierung Configure-Requests senden. Im
Options-Feld werden alle möglichen Konfigurations-Optionen (s. Abschnitt 2.4.3) aufgeführt,
die Änderungen an den Standard-Einstellungen einer Verbindung beabsichtigen. D.h. es
werden nur Konfigurations-Optionen übermittelt, deren Parameter von den Standard-Werten
abweichen.
Der Empfang eines Configure-Request führt zum Versenden einer entsprechenden Antwort.
Das Identifier-Feld muss jedes Mal verändert werden, wenn sich der Inhalt des OptionsFeldes ändert oder eine gültige Antwort auf einen vorangegangenen Request empfangen
wurde. Bei einem wiederholtem Senden des gleichen Configure-Request kann das IdentifierFeld unverändert bleiben.
b) Configure-Ack
Wenn alle Konfigurations-Optionen in einem empfangenen Configure-Request erkannt und
deren Parameter akzeptiert werden können muss die Implementierung ein Configure-Ack
versenden. Das Options-Feld enthält dabei die unveränderten Konfigurations-Optionen des zu
bestätigenden Configure-Request. Gleiches gilt für das Identifier-Feld.
Beim Empfang eines Configure-Ack ist ausschlaggebend, ob der Inhalt des Options-Feldes
mit den Konfigurations-Optionen des zuletzt versendeten Configure-Request übereinstimmen.
Ist dies nicht der Fall, wird das Configure-Ack nicht weiterverarbeitet und gilt als nicht
26
Digitale Modulation und Internet-Protokolle
empfangen. Gleiches gilt, wenn keine Übereinstimmung des Identifier-Feld mit dem des
zuletzt versendeten Configure-Request besteht.
c) Configure-Nak
Wenn alle Konfigurations-Optionen in einem empfangenen Configure-Request erkannt, aber
einige Parameter nicht akzeptiert werden können, muss die Implementierung einen ConfigureNak senden. Das Options-Feld enthält dabei alle Konfigurations-Optionen des ConfigureRequest, die nicht akzeptiert werden können. Die Parameter der Konfigurations-Optionen sind
jedoch so verändert, dass sie den Konfigurierungs-Wünschen der Configure-Nak sendenden
Implementierung entsprechen. In einem Configure-Nak können die Konfigurations-Optionen
auch Standardwerte annehmen, insofern die Konfigurations-Optionen des abzulehnenden
Configure-Request von diesen abgewichen sind.
Für Konfigurations-Optionen, die keine speziellen Parameter besitzen (z.B. ProtokollCompression, Address-and-Control-Field-Compression (siehe Abschnitt 2.4.3) muss anstelle
eines Configure-Nak ein Configure-Reject versendet werden.
Kann die sendende Implementierung für eine Option mehrere unterschiedliche ParameterWerte akzeptieren, so muss der Configure-Nak eine Liste mit sämtlichen akzeptablen Werten
enthalten. Die Liste enthält auch die Werte, die unter Umständen bereits von einem früheren
Configure-Request des Peers vorgeschlagen und für gut befunden wurden.
Beim Empfang eines Configure-Nak muss darauf geachtet werden, ob das Identifier-Feld mit
dem des zuletzt versendeten Configure-Request übereinstimmt. Ist dies nicht der Fall, wird
das Configure-Nak nicht weiter verarbeitet und gilt als nicht empfangen.
Das Configure-Nak gibt der empfangenden Implementierung Vorschläge zur Gestaltung eines
neuen Configure-Request. Entweder erfolgt eine Anpassung der Parameter-Werte an die
Spezifikationen im empfangenen Configure-Nak, oder einzelne Konfigurations-Optionen
entfallen einfach im nächsten Configure-Request. Enthält das Configure-Nak eine Liste mit
mehreren Instanzen einer Konfigurations-Option (sprich, oben angesprochene Liste mit
mehreren unterschiedlichen Parameter-Werten), so sollte die empfangende Implementierung
einen einzelnen Wert daraus auswählen und in ihren nächsten Configure-Request mit
einbinden.
d) Configure-Reject
Wenn einige Konfigurations-Optionen in einem empfangenen Configure-Request nicht
erkannt oder für die Konfiguration nicht akzeptiert werden konnten, muss die
27
Digitale Modulation und Internet-Protokolle
Implementierung einen Configure-Reject senden. Das Options-Feld enthält dabei sämtliche
unerkannten und inakzeptablen Konfigurations-Optionen. Alle erkannten und akzeptierbaren
Optionen werden herausgefiltert und nicht mit dem Configure-Reject gesendet. Der
Configure-Reject
entspricht
demnach
einem
konkreten
Ablehnen
von
einzelnen
Konfigurations-Optionen. Der Empfänger eines Configure-Reject sollte in seinen folgenden
Configure-Requests keine Konfigurations-Optionen einbinden, die bereits in einem
Configure-Reject vom Peer abgelehnt wurden.
Das Identifier-Feld muss beim Empfänger mit dem des zuletzt versendeten Configure-Request
übereinstimmen, ansonsten wird der Configure-Reject nicht weiter verarbeitet und gilt als
nicht empfangen.
e) Terminate-Request und Terminate-Ack
Zur Trennung einer Verbindung verwendet das LCP die Terminate-Request und TerminateAck Codes. Eine Implementierung, welche die Verbindung trennen möchte, sollte TerminateRequests versenden. Das Versenden eines Terminate-Request wird so oft wiederholt bis ein
entsprechendes Terminate-Ack empfangen wurde, die physikalische Schicht anzeigt, dass sie
nicht mehr funktionstüchtig ist oder eine genügend große Anzahl an Terminate-Requests
versendet wurde, sodass mit großer Wahrscheinlichkeit sichergestellt ist, dass der Peer nicht
mehr zur Verfügung steht und von seiner Seite aus die Verbindung als getrennt betrachtet
wird.
Der Empfang eines Terminate-Request verpflichtet zum Versenden eines Terminate-Ack.
Wird ein Terminate-Ack ohne vorangegangenes Versenden eines Terminate-Request
empfangen, bedeutet das, dass sich der Peer im Closed- oder Stopped-Zustand befindet oder
eine Situation eingetreten ist, die nach einer neuen Konfiguration der Verbindung verlangt.
Das Identifier-Feld muss jedes Mal geändert werden, wenn sich der Inhalt des Options-Feldes
ändert. Bei einem wiederholten Senden des gleichen Terminate-Request kann das IdentifierFeld unverändert bleiben.
f) Code-Reject
Der Empfang eines LCP-Paketes mit einem unbekannten Wert im Code-Feld deutet darauf
hin, dass die beiden kommunizierenden Implementierungen verschiedene ProtokollVersionen verwenden oder Implementierungsfehler vorliegen. Dieser Fehler muss dem
Sender des unbekannten Code-Feld-Wertes durch übermitteln eines Code-Reject mitgeteilt
28
Digitale Modulation und Internet-Protokolle
werden. Das Options-Feld enthält das zurückgewiesene LCP-Paket, exklusive des ProtocolFeldes und sämtlicher PPP- Header und Trailer.
Der Empfang eines Code-Rejects veranlasst das LCP zum unmittelbaren Übergang in den
Closed-Zustand. Es sollte ein Fehler-Report erfolgen, da es sehr unwahrscheinlich ist, dass
sich die Fehler-Situation automatisch korrigieren lässt.
Das Identifier-Feld muss bei jedem neuen Code-Reject geändert werden.
g) Protocol-Reject
Der Empfang eines PPP-Pakets, welches im Protocol-Feld einen unbekannten Protokollwert
enthält deutet darauf hin, dass der Peer versucht ein von der Implementierung nicht
unterstütztes Protokoll zu verwenden. Üblicherweise tritt diese Situation ein, wenn der Peer
versucht ein neues Protokoll zu konfigurieren. Nur wenn sich das LCP im Opened-Zustand
befindet wird daraufhin ein Protocol-Reject gesendet. Andernfalls wird das PPP-Paket mit
dem nicht unterstützten Protokoll nicht weiter verarbeitet und ignoriert.
Das Options-Feld eines Protocol-Reject enthält das komplette empfangene Datenpaket
beginnend mit dem zurückgewiesenen Protokoll-Wert.
Der Empfang eines Protocol-Reject muss dazu führen, dass die Implementierung zum
nächstmöglichen Zeitpunkt das Senden von Datenpakten des unzulässigen Protokolls
unterbindet.
Das Identifier-Feld muss bei jedem neuen Protocol-Reject geändert werden.
h) Echo-Request und Echo-Reply
Mit den Echo-Request und Echo-Reply Codes unterstützt LCP einen Data-Link-LayerLoopback-Mechanismus zur Verwendung in beide Richtungen der Verbindung. Dieser
Mechanismus bietet Hilfe beim Debuggen, Feststellen der Verbindungsqualität, Leistungstest
und bei vielen anderen Funktionen. Echo-Request und Echo-Reply dürfen nur gesendet
werden, wenn sich LCP im Opened-Zustand befindet. In allen anderen Zuständen werden
Echo-Request und Echo-Reply nicht weiter verarbeitet.
Der Empfang eines Echo-Request muss zum Senden eines Echo-Reply führen.
Das Identifier-Feld wird jedes Mal geändert, wenn sich der Inhalt des Options-Feldes ändert
oder ein gültiges Echo-Reply einem Echo-Request folgte. Für ein erneutes Senden des
gleichen Echo-Request kann das Identifier-Feld unverändert bleiben. Das Identifier-Feld eines
Echo-Reply stellt die Kopie des Identifier-Feldes des zu beantwortenden Echo-Requests dar.
Dem Options-Feld wird, die später erwähnte, Magic Number (s. Abschnitt 2.4.3)
29
Digitale Modulation und Internet-Protokolle
vorangestellt. Die Daten im Options-Feld können beliebig sein und bleiben uninterpretiert.
Sollte die Magic Number Konfigurations-Option nicht verhandelt worden sein, muss die
Magic Number den Wert 0 annehmen.
Echo-Request und Echo-Reply wurden in diesem Projekt nicht implementiert.
i) Discard-Request
Der Discard-Request wird nur in eine Richtung der Verbindung gesendet. Der Empfang eines
Discard-Request führt zu keiner weiteren Reaktion der empfangenden Implementierung.
Discard-Requests dürfen nur im Opened-Zustand des LCP versendet werden. Auch hier wird
dem Options-Feld (welches beliebige Daten enthalten darf) die Magic Number vorangestellt.
Auch beim Discard-Request wird der Wert der Magic Number als 0 übertragen, wenn diese
Konfigurations-Option nicht ausgehandelt wurde.
Das Identifier-Feld nimmt mit jedem gesendeten Discard-Request einen neuen Wert an.
Discard-Request Datenpakete wurden in diesem Projekt nicht implementiert.
2.4.3. LCP-Konfigurations-Optionen
Eine Zusammenfassung des Formats der LCP-Konfigurations-Optionen zeigt Abbildung
(2.9).
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Code
Length
Data ...
Abb. (2.9): LCP-Konfigurations-Optionen-Datenformat
Code
Das ein Byte lange Code-Feld definiert die Art der LCP-Konfiguration. Folgende Werte
wurden hierfür festgelegt:
1
Maximum-Receive-Unit
2
Async-Control-Character-Map (ACCM)
3
Authentication-Protocol
4
Quality-Protocol
5
Magic Number
6
Link-Quality-Monitoring
7
Protocol-Field-Compression
8
Address-and-Control-Field-Compression
30
Digitale Modulation und Internet-Protokolle
Length
Das ein Byte lange Length-Feld legt die gesamt Länge der LCP-Konfigurations-Option
inklusive Code-, Length- und Data-Feld fest.
Data
Das Data-Feld enthält die Parameter der jeweiligen LCP-Konfigurations-Option.
Tabelle (2.3) zeigt eine Zusammenfassung der unterschiedlichen Datenformate der einzelnen
LCP-Konfigurations-Optionen. Eine ausführliche Erklärung der Konfigurations-Optionen des
Data-Feldes findet sich im Anschluss.
Name
Maximum-Receive-Unit
Async-Control-Character-Map
Authentication-Protocol
Quality-Protocol
Magic Number
Link-Quality-Monitoring
Protocol-Field-Compression
Address-and-Control-Field-Comp.
Code
1
2
3
4
5
6
7
8
Length/Byte
4
6
>=4
>=4
6
6
2
2
Data-Length/Byte
2
4
>=2
>=2
4
4
0
0
Default-Wert
1500
0xffffffff
0
-
Tab. (2.3): Datenformat-Längen der LCP-Konfigurations-Optionen
a) Maximum-Receive-Unit
Diese Konfigurations-Option bietet die Möglichkeit die maximale Paketgröße auszuhandeln,
die eine Implementierung empfangen kann. Als Standard sollte jeder der PPP-Peers in der
Lage sein 1500 Bytes an Information empfangen zu können. Diese 1500 Bytes beziehen sich
auf das Information-Feld des PPP-Datenrahmens, exklusive sämtlicher Header, Trailer und
Bytes, die zur Transparenz eingefügt wurden. Ein Implementierung kann also entweder ihrem
Gegenüber mitteilen, dass sie größere Pakete empfangen kann, oder darum bitten, dass ihr
kleinere Pakete geschickt werden.
Das Maximum-Receive-Unit-Feld umfasst zwei (2) Byte und enthält den zu verhandelnden
neuen Wert der Maximum-Receive-Unit. In diesem Projekt ist die MRU der Soft-ModemApplikation
aufgrund
Ressourcenknappheit
auf
256Byte
beschränkt.
Sollte
die
Implementierung des Peers nicht auf die Bitte, keine größeren Datenpakete zu senden,
eingehen, werden diese Pakete schlicht von der Soft-Modem-Applikation ignoriert.
31
Digitale Modulation und Internet-Protokolle
b) Async-Control-Character-Map (ACCM)
Wie bereits weiter oben beschrieben ersetzt PPP beim Senden alle ASCII-Kontroll-Zeichen
(exklusive DEL) mit einer zwei Byte langen Sequenz. Es ist jedoch selten, dass wirklich alle
Kontroll-Zeichen diesem Mechanismus unterzogen werden müssen. Oft liegt sogar der Fall
vor, dass sämtliche Kontroll-Zeichen im Klartext über die Verbindung gesendet werden
können. Mit dieser Konfigurations-Option kann eine Implementierung mitteilen, welche
Kontroll-Zeichen weiterhin ersetzt werden müssen und welche nicht. Das ACCM-Feld
umfasst vier (4) Byte und liegt im big-endian-Format vor. Jedes Bit entspricht einem
Kontroll-Zeichen in der ASCII-Tabelle. Jedes gesetzte Bit zeigt an, dass das entsprechende
Kontroll-Zeichen weiterhin durch eine zwei-Byte-Sequenz ersetzt werden muss. Die Folgende
Tabelle zeigt eine Übersicht der ACCM-Bits und ihrer Entsprechung als ASCII-KontrollZeichen.
31
30
29
28
27
26
25
24
23
US
RS
GS
FS
Esc
SUB EM
CAN ETB SYN NAK DC4 DC3 DC2 DC1 DLE
15
14
13
12
11
10
9
8
SI
SO
CR
FF
VT
LF
TAB BS
7
22
6
21
5
20
4
19
3
18
2
17
1
16
0
BEL ACK ENQ EOT ETX STX SOH NUL
Tab. (2.4): ACCM-Bits mit ASCII-Kontroll-Zeichen
Als Standardwert gilt für das ACCM-Feld hexadezimal 0xffffffff.
Würde z.B. eine Implementierung verlangen, dass nur das ASCII-Kontroll-Zeichen DC3 beim
Senden ersetzt werden soll, wäre im ACCM-Feld nur das Bit19 gesetzt (0x00080000).
c) Authentication-Protocol
Das Authentication-Protocol-Feld hat die Länge von zwei (2) Byte und enthält den Wert eines
zur Anmeldung gewünschten Authentifizierungs-Protokolls. Standardmäßig ist keine
Anmeldung erforderlich, wird dies jedoch von einer Implementierung gewünscht, erweitert
sich das PPP-Phasen-Diagramm, wie oben beschrieben, um die optionale Authenticate-Phase.
Eine Implementierung hat auch die Möglichkeit ihrem Peer mehrere Anmelde-Protokolle
innerhalb eines Configure-Request zur Auswahl anzubieten. Der Peer darf dann mit Hilfe von
Configure-Reject und Configure-Ack höchstens eines dieser Protokolle auswählen.
d) Quality-Protocol
Standardmäßig nicht implementiert. An dieser Stelle folgt nur der Verweis auf [RFC1661].
32
Digitale Modulation und Internet-Protokolle
e) Magic Number
Diese Option wird standardmäßig nicht verwendet. Mit dieser Konfigurations-Option ist es
möglich looped-back-Verbindungen zu erkennen. Die Magic Number wird teilweise von
anderen Konfigurations-Optionen, wie dem Link-Quality-Monitoring benötigt. Das Magic
Number-Feld hat eine Länge von vier (4) Byte dessen Wert möglichst einzigartig und Peerspezifisch sein sollte. Teilt eine Implementierung ihre Magic Number ihrem Peer mit, so ist
diese Magic Number für Aktionen, die auf die Magic Number zurückgreifen, verpflichtend.
Für eine ausführliche Beschreibung der Magic Number Konfigurations-Option sei an dieser
Stelle auf [RFC1172] verwiesen.
f) Link-Quality-Monitoring
Standardmäßig nicht implementiert. An dieser Stelle folgt nur der Verweis auf [RFC1172].
g) Protocol-Field-Compression
Diese Konfigurations-Option ermöglicht einer Implementierung ihrem Peer mitzuteilen, dass
sie komprimierte Protocol-Felder empfangen kann. Der standardmäßige PPP-Rahmen
beinhaltet ein zwei Byte langes Protocol-Feld. Viele Protokoll-Werte sind jedoch so
festgelegt, dass deren Wert nicht 256 überschreitet und damit ein Byte zu ihrer
Kennzeichnung ausreicht. Die oben beschriebenen Konventionen für die Protokoll-Werte
nach ISO (s. Abschnitt 2.3.2.1) ermöglichen eine Komprimierung des Protocol-Feldes auf ein
Byte, so dass der Protokoll-Wert immer noch eindeutig vom Empfänger erkannt werden kann.
Eine Implementierung, die den Komprimierungs-Mechanismus unterstützt sollte jedoch
weiterhin in der Lage sein unkomprimierte Protocol-Felder richtig zu erkennen. Beim
Versenden von LCP-Paketen darf keine Protocol-Field-Compression verwendet werden.
Die in diesem Projekt vorgestellte Implementierung erlaubt das Komprimieren des ProtocolFeldes, sendet aber stets ein zwei Byte langes Protocol-Feld.
h) Address-and-Control-Field-Compression
Diese Konfigurations-Option ermöglicht die Komprimierung der Address- und ControlFelder. Standardmäßig versendet jede Implementierung Address- und Control-Felder. Da
dieser Felder konstante Werte enthalten gestaltet sich eine Komprimierung relativ
unkompliziert. Address- und Control-Feld werden beim Senden einfach vernachlässigt, wenn
die empfangende Implementierung mitgeteilt hat, dass sie die Address-and-Control-Field-
33
Digitale Modulation und Internet-Protokolle
Compression unterstützt. Beim Versenden von LCP-Paketen darf keine Address-and-ControlField-Compression verwendet werden.
Ähnlich wie im Fall der Protocol-Field-Compression erlaubt die Implementierung dieses
Projekts die Komprimierung von Address- und Control-Feld beim Empfang, sendet jedoch
stets Datenrahmen mit Address- und Control-Feld.
2.5. Das Internet-Protocol-Control-Protokoll (IPCP)
Das IPCP ist verantwortlich für die Konfiguration, Aktivierung und Deaktivierung der IPModule auf beiden Seiten der PPP-Verbindung. IPCP verwendet den gleichen Mechanismus
zum Austausch von Datenpaketen wie das LCP. IPCP-Datenpakte sollten von den
Implementierungen erst übermittelt werden, wenn PPP die Network- Phase erreicht hat. Alle
IPCP-Pakete, die vor dieser Phase empfangen werden, erfahren keine weitere Verarbeitung
durch die Implementierung und gelten als nicht empfangen.
Die maximale Länge der IP-Datagramme, welche über eine PPP-Verbindung übertragen
werden, entspricht der Länge des Information-Feldes. Größere IP-Datagramme müssen
dementsprechend zerlegt werden. [RFC879] und [RFC1191] beschreiben Methoden, die das
Zerlegen und Wiederzusammensetzen von IP-Datagrammen umgehen. Dies soll jedoch nicht
Gegenstand dieser Arbeit werden.
2.5.1. Das IPCP-Datenformat
IPCP ist aufgebaut wie das LCP, mit den folgenden Ausnahmen.
Protocol-Feld
Wie beim LCP werden die IPCP-Informationen in Form von PPP-Datenrahmen verschickt,
wobei pro Datenrahmen nur ein IPCP-Pakettyp verschickt werden kann. Der Unterschied zum
LCP besteht darin, dass das Protocol-Feld den Wert hexadezimal 0x8021 hat und damit
signalisiert, dass es sich im Datenteil um IPCP-Informationen handelt.
Code
Für IPCP werden nur die Pakettypen 1 bis 7 (Configure-Request, Configure-Ack, ConfigureNak, Configure-Reject, Terminate-Request, Terminate-Ack, Code-Reject) verwendet. Alle
34
Digitale Modulation und Internet-Protokolle
anderen Werte für das Code-Feld sollten nicht erkannt werden und einen Code-Reject (siehe
Abschnitt 2.4.2) zur Folge haben.
IPCP-Konfigurations-Optionen
Folgende Werte wurden hierfür festgelegt:
1
IP-Addresses
2
Compression-Type
3
IP-Address
2.5.2. Die IPCP-Konfigurations-Optionen
a) IP-Addresses
Wird als Option für frühere PPP-Versionen unterstützt und hat bei neueren Versionen keine
Bedeutung mehr. Eine Beschreibung dieser Option befindet sich in [RFC1172].
b) Compression-Type
Diese Konfigurations-Option ermöglicht die Verwendung eines speziellen KomprimierungsProtokolls für TCP/IP-Datagramme. Eine Komprimierung ist standardmäßig nicht aktiviert
und findet in dieser Arbeit auch keine weitere Berücksichtigung. Als Beispiel soll an dieser
Stelle das “Van Jacobson Compressed TCP/IP“-Protokoll erwähnt werden, das Methoden zur
TCP/IP-Header-Komprimierung bietet und in [RFC1144] spezifiziert ist.
c) IP-Address
Diese Konfigurations-Option ermöglicht das aushandeln und zuweisen von IP-Adressen.
Damit wird dem Sender eines Configure-Request erlaubt, seinem Peer mitzuteilen, welche IPAdresse für die Implementierung gewünscht wird, oder darum zu bitten, vom Peer eine
dynamische IP-Adresse zugewiesen zu bekommen. Die Zuweisung einer dynamischen IPAdresse erfolgt durch ein Configure-Nak mit der Übermittlung einer gültigen IP-Adresse.
Dieser Mechanismus sollte am Beispiel des Protokoll-Mitschnitts in Abschnitt 2.7 klar
werden.
Das Datenformat entspricht dem Konfigurations-Optionen-Datenformat des LCP aus
Abschnitt 2.4.3 wobei das Data-Feld vier Byte lang ist und die gewünschte IP-Adresse der
Configure-Request sendenden Implementierung enthält. Das Nullsetzen aller vier Bytes im
Data-Feld signalisiert die Bitte der Zuweisung einer dynamischen IP-Adresse.
35
Digitale Modulation und Internet-Protokolle
2.6. Der Option-Negotiation-Automat
[RFC1661] beschreibt einen geschlossenen Zustands-Automaten, der den AushandlungsMechanismus der Konfigurations-Optionen sowohl für LCP, als auch für die NCPs behandelt.
Der Automat wird definiert durch Ereignisse, Aktionen und Zustandsübergänge. In den
Ereignissen spiegeln sich externe Kommandos (Open oder Close), Ablaufen des RestartTimers und der Empfang von Datenpaketen wider. Die Aktionen veranlassen den Neustart des
Restart-Timers und das Versenden von Datenpaketen zum Peer.
Die Zusammenhänge von Zustandsübergängen, Ereignissen und Aktionen werden im
Folgenden dargestellt. Zunächst erfolgt jedoch eine Beschreibung des soeben erwähnten,
jedoch nicht in der Lösung implementierten Restart-Timers.
2.6.1. Der Restart-Timer und seine Counter
Der Zustands-Automat verwendet genau einen speziellen Timer. Der Restart-Timer wird dazu
verwendet die Übertragung von Configure-Requests und Terminate-Requests zu regeln. Der
Ablauf
des
Restart-Timers
verursacht
ein
Timeout-Ereignis
und
veranlasst
die
Implementierung zum erneuten Senden des zugehörigen Configure-Request oder TerminateRequest. Der Restart-Timer muss frei konfigurierbar sein, sollte aber standardmäßig auf drei
(3) Sekunden festgelegt werden.
In Zusammenhang mit dem Restart-Timer stehen drei Restart-Counter.
a) Max-Terminate
Dieser Restart-Counter zeigt die Anzahl von Terminate-Requests an, die gesendet werden
ohne ein entsprechendes Terminate-Ack zu empfangen, vor der Annahme, dass der Peer nicht
in der Lage ist zu antworten. Standardmäßig ist der Wert auf zwei (2) Übertragungen
festgelegt.
b) Max-Configure
Hierbei handelt es sich um den Restart-Counter für das wiederholte Versenden von
Configure-Requests. Max-Configure entspricht der Anzahl an Configure-Requests, die
gesendet werden ohne ein entsprechendes Configure-Ack, Configure-Nak oder ConfigureReject zu empfangen, bevor angenommen wird, dass der Peer nicht in der Lage ist zu
antworten. Standardmäßig ist dieser Counter auf zehn (10) Übertragungen eingestellt.
36
Digitale Modulation und Internet-Protokolle
c) Max-Failure
Dieser Counter behandelt die Anzahl der Configure-Naks, die empfangen werden dürfen bis
angenommen wird, dass die entsprechende Konfigurations-Option nicht erfolgreich
ausgehandelt werden kann, d.h. kein entsprechendes Configure-Ack zustande kommt. MaxFailure ist standardmäßig auf fünf (5) Übertragungen festgelegt. Sobald dieser Counter
ausgelaufen ist müssen alle Configure-Nak-Pakete in Configure-Reject-Pakete umgewandelt
werden.
.
37
Digitale Modulation und Internet-Protokolle
2.6.2. Zustandübergangs-Tabelle
Die Beschreibung des Zustands-Automaten erfolgt in einer Zustandübergangs-Tabelle. Die Zustände sind
horizontal, die Ereignisse vertikal aufgelistet. Zustandsübergänge und Aktionen sind in der Form
„Aktion/Neuer Zustand“ angegeben. Mehrere Aktionen werden durch ein Komma voneinander getrennt.
Für das Ausführen von mehreren Aktionen besteht bei der Implementierung keine festgeschriebene
Reihenfolge. Der vertikale Strich (-) steht für einen unzulässigen Übergang.
Ereignisse
Up
Down
Open
Close
Zustände
0
Initial
2
tls/1
0
1
Starting
irc,scr/6
1
tlf/0
2
Closed
0
irc,scr/6
2
3
Stopped
tls/1
3r
2
4
Closing
0
5r
4
5
Stopping
1
5r
4
6
ReqReq-Sent
1
6
irc,str/4
7
AckAck-Rcvd
1
7
irc,str/4
8
AckAck-Sent
1
8
irc,str/4
9
Opened
tld/1
9r
tld,irc,str/4
TO+
TOTO-
-
-
-
-
Str/4
Tlf/2
Str/5
Tlf/3
scr/6
tlf/3p
scr/6
tlf/3p
scr/8
tlf/3p
-
RCR+
RCRRCRRCA
RCN
-
-
sta/2
sta/2
sta/2
sta/2
irc,scr,sca/8
irc,scr,scn/6
sta/3
sta/3
4
4
4
4
5
5
5
5
sca/8
scn/6
irc/7
irc,scr/6
sca,tlu/9
scn/7
scr/6x
scr/6x
sca/8
scn/6
irc,tlu/9
irc,scr/8
tld,src,sca/8
tld,src,scn/6
tld,scr/6x
tld,scr/6x
RTR
RTA
-
-
sta/2
2
sta/3
3
sta/4
tlf/2
sta/5
tlf/3
sta/6
6
sta/6
6
sta/6
8
tld,zrc,sta/5
tld,scr/6
RUC
RXJ+
RXJRXJ-
-
-
scj/2
2
tlf/2
scj/3
3
tlf/3
scj/4
4
tlf/2
scj/5
5
tlf/3
scj/6
6
tlf/3
scj/7
7
tlf/3
scj/8
8
tlf/3
scj/9
9
tld,irc,str/5
RXR
-
-
2
3
4
5
6
7
8
ser/9
Tabelle (2.5): Zustandübergangs-Tabelle des Option-Negotiation-Automaten
[p] ... Passiv Option
[r] ... Restart-Option
[x] ... Crossed Connection
39
Aktionen:
tlu = This-Layer-Up
tld = This-Layer-Down
tls = This-Layer-Started
tlf = This-Layer-Finished
irc = Initialize-Restart-Count
zrc = Zero-Restart-Count
scr = Send-Configure-Request
sca = Send-Configure-Ack
scn = Send-Configure-Nak/Rej
str = Send-Terminate-Request
sta = Send-Terminate-Ack
scj = Send-Code-Reject
ser = Send-Echo-Reply
Ereignisse:
Up = lower layer is Up
Down = lower layer is Down
Open = administrative Open
Close= administrative Close
TO+ = Timeout with counter > 0
TO- = Timeout with counter expired
RCR+ = Receive-Configure-Request (Good)
RCR- = Receive-Configure-Request (Bad)
RCA = Receive-Configure-Ack
RCN = Receive-Configure-Nak/Rej
RTR = Receive-Terminate-Request
RTA = Receive-Terminate-Ack
RUC = Receive-Unknown-Code
RXJ+ = Receive-Code-Reject (permitted)
or Receive-Protocol-Reject
RXJ- = Receive-Code-Reject
or Receive-Protocol-Reject (catastrophic)
RXR = Receive-Echo-Request
or Receive-Echo-Reply
or Receive-Discard-Request
Digitale Modulation und Internet-Protokolle
Eine detaillierte allgemeine Beschreibung der einzelnen Zustände, Ereignisse und Aktionen
findet sich in [RFC1661] und wird an dieser Stelle nicht weiter ausgeführt. Zum
grundlegenden Verständnis erfolgt jedoch eine kurzer Umriss des prinzipiellen Mechanismus
des Automaten
2.6.3. Zustände, Ereignisse und Aktionen
Der Option-Negotiation-Automat gilt sowohl für LCP, als auch für das Network-ControlProtokoll IPCP. Der Initial-Zustand ist dabei jeweils Ausgangspunkt für die Aushandlung der
Konfigurations-Optionen. Stark vereinfacht kann man sich vorstellen, dass LCP die
Zustandübergangs-Tabelle vom Initial- bis zum Opened-Zustand durchläuft und danach dem
IPCP mit Hilfe eines Up-Ereignisses signalisiert, dass nun der Aushandlungs-Mechanismus
des IPCP gestartet werden kann. IPCP durchläuft anschließend gleichermaßen die
Zustandübergangs-Tabelle vom Initial- zum Opened-Zustand. Hat IPCP den Opened-Zustand
eingenommen, kann wiederum durch ein Up-Ereignis dem Internet-Protokoll signalisiert
werden, dass die Verbindung konfiguriert ist, um IP-Datagramme zu übermitteln. Zum
Trennen der Verbindung wird die Zustandübergangs-Tabelle entgegengesetzt durchlaufen, bis
sich der Automat wieder im Initial-Zustand befindet.
Die Ereignisse Up und Down, sowie die Aktionen This-Layer-Up, This-Layer-Down, ThisLayer-Started, This-Layer-Finished dienen somit der Kommunikation zwischen den einzelnen
Protokoll-Schichten. Die Aktion This-Layer-Up verursacht ein Up-Ereignis, wodurch der
höheren Protokoll-Schicht angezeigt wird, dass die darunterliegende Schicht aktiviert wurde
und ihre Dienste zur Verfügung stellen kann. Umgekehrt löst die Aktion This-Layer-Down ein
Down-Ereignis aus, welches den höheren Schichten anzeigt, dass keine Dienste mehr von der
unteren Schicht zur Verfügung gestellt werden können. Die Aktionen This-Layer-Started und
This-Layer-Finished signalisieren den unteren Schichten, dass deren Dienste von den höheren
Schichten gebraucht bzw. nicht mehr gebraucht werden.
Bei den Ereignissen Open und Close handelt es sich um administrative Eingriffe, die von
Außen (z.B. durch eine User-Anforderung: Verbindung aufbauen bzw. trennen) auf die
Implementierung einwirken.
Timeout-Ereignisse werden durch den Restart-Timer und dessen Counter ausgelöst. Hierbei
erfolgt die Unterscheidung, ob es nur zum Ablaufen des Restart-Timers kam, oder ob
zusätzlich einer der Counter (Max-Terminate, Max-Configure, Max-Failure) abgelaufen ist.
40
Digitale Modulation und Internet-Protokolle
Die restlichen Ereignisse (RCR, RCA, RCN, RTR, RTA usw.) können als Konsequenz
empfangener Datenpakte angesehen werden. Der Automat reagiert auf das jeweilige Ereignis
mit der entsprechenden Aktion und einem Zustandsübergang.
Die beschriebenen Zusammenhänge sollen an einem kurzen Beispiel verdeutlicht werden.
Abbildung (2.10) beschreibt einen möglichen Ablauf des Aushandlungs-Mechanismus
zwischen zwei Protokoll-Schichten unter Berücksichtigung der jeweiligen inneren Zustände
der Implementierungen. Zum Ende nehmen beide den Opened-Zustand ein.
MSP430F149
Embedded
Soft-Modem
Ereignis-Prozessor
Initial
Open
Aktionen
Starting
Up
scr
Req-Sent
RCR+
scr
RCA
Req-Sent
RCR+
Ack-Rcvd
RCN
scr
Ack-Sent
Stopped
scn
sca
Ack-Sent
RCR-
RCA
sca
Opened
Opened
Zustandsspeicher
Abb.(2.10): Beispiel für Ablauf des Aushandlungs-Mechanismus
41
Digitale Modulation und Internet-Protokolle
2.7. PPP-Protokoll-Mitschnitt
Um der relativ trockenen Theorie, der bereits behandelten Abschnitte, mehr Anschaulichkeit
zu verleihen, erfolgt nun die Auswertung eines erfolgreichen PPP-Verbindungs-Aufbaus. Der
Protokoll-Mitschnitt wurde mit der Windows-Freeware PORTMON erstellt. Mit Hilfe von
PORTMON können alle Aktivitäten der seriellen Schnittstelle protokolliert werden. Zum
Kenntlichmachen der Sende-Richtung werden die beiden Kommunikationspartner mit A und
B bezeichnet.
Auswertung des Protokoll-Mitschnitts
Teilnehmer A hat per Modem-Einwahl eine physikalische Verbindung zu Teilnehmer B
hergestellt und beginnt mit dem Senden eines LCP-Pakets.
A
B
A
B
A
B
A
7E
7D
7D
7D
7D
7D
34
FF
22
25
27
28
2D
F7
7D
7D
7D
7D
7D
7D
7E
23
26
26
22
22
23
C0 21 7D 21 7D 21 7D 20 7D 37
7D 20 7D 2A 7D 20 7D 20
7D 20 7D 3B 7D 3B 36
7E
7D
7D
7D
7D
7D
7D
9C
FF
21
22
27
28
31
33
7D
7D
7D
7D
7D
7D
7D
7D
27
23
24
26
22
22
24
29
7E
C0 21 7D 21 7D 21 7D 20 23
7D 25 F4
7D 20 7D 2A 7D 20 7D 20
7E
7D
7D
AA
7E
7D
FB
7E
7D
7D
7D
7D
7D
7E
7D
7D
7D
7D
88
FF
31
33
66
FF
2D
3E
FF
22
25
27
28
29
FF
21
22
27
28
75
7D
7D
7D
7E
7D
7D
7E
7D
7D
7D
7D
7D
5A
7D
7D
7D
7D
7D
7E
23 C0 21 7D 24 7D 21 7D 20 7D 31
24 7D 25 F4
29 7D 23 7D 20 C0 7B 7D 5E 80 E2
7E
7D
7D
7D
7D
E2
7E
7D
7D
7D
7D
7D
FF
22
25
27
28
33
FF
21
22
27
28
5E
7D
7D
7D
7D
7D
7E
7D
7D
7D
7D
7D
86
23 C0 21 7D 22 7D 23 7D 20 7D 34
26 7D 20 7D 2A 7D 20 7D 20
26 7D 20 7D 3B 7D 3B 36
22
22
7D 26
LCP Configure-Request ID:01 Length: 19
Maximum-Receive-Unit: 1524 Bytes (0x5F4)
Async-Control-Character-Map: 00 0A 00 00
Protocol-Field-Compression
Address-and-Control-Field-Compression
unbekannte Konfig-Option 17
unbekannte Konfig-Option 19
FCS Flag-Sequenz
LCP Configure-Reject ID:01 Length: 17
Die unbekannten Konfig-Optionen (17, 19)
werden abgelehnt.
FCS Flag-Sequenz
LCP Configure-Reject ID:02 Length: 7
Ablehnen der unbekannten Konfig-Option (13)
FCS Flag-Sequenz
LCP Configure-Request ID:03 Length: 20
Async-Control-Character-Map: 00 0A 00 00
MagicNumber: 00 1B 1B 16
Protocol-Field-Compression
Address-and-Control-Field-Compression
FCS Flag-Sequenz
LCP Configure-Request ID:02 Length: 22
Maximum-Receive-Unit: 1524 Bytes
Async-Control-Character-Map: 00 0A 00 00
Protocol-Field-Compression
Address-and-Control-Field-Compression
FCS Flag-Sequenz
7D 25 F4
7D 23 7D 20 C0 7B 7D 5E 80 E2
23 C0 21 7D 24 7D 22 7D 20 7D 27
23 7D 26
23
26
26
22
22
7E
23
24
26
22
22
LCP Configure-Request ID:01 Length:23
Async-Control-Character-Map: 00 0A 00 00
Magic-Number: 00 1B 1B 16
Protocol-Field-Compression
Address-and-Control-Field-Compression
unbekannte Konfig-Option 13
FCS Flag-Sequenz
C0 21 7D 21 7D 23 7D 20 7D 34
7D 20 7D 2A 7D 20 7D 20
7D 20 7D 3B 7D 3B 36
C0 21 7D 21 7D 22 7D 20 7D 36
7D 25 F4
7D 20 7D 2A 7D 20 7D 20
LCP Configure-Ack ID:03 Length: 20
Die Konfig-Optionen des Configure-Request
mit der ID:03 werden vom Peer mit diesem
Configure-Ack angenommen.
FCS Flag-Sequenz
LCP Configure-Ack ID:02 Length: 22
Annehmen der Konfig-Optionen des ConfigureRequest mit der ID:02
23 C0 21 7D 22 7D 22 7D 20 7D 36
24 7D 25 F4
26 7D 20 7D 2A 7D 20 7D 20
22
22
7E
FCS Flag-Sequenz
42
Digitale Modulation und Internet-Protokolle
Die Verbindung wurde von LCP konfiguriert, damit ist die Establish-Phase beendet und PPP
geht in die Network-Phase über. Das IPCP konfiguriert die Einstellungen für das IP, d.h. es
wird eine dynamische IP-Adresse angefordert.
Auffällig ist, das kaum noch Control-Escape-Bytes gesendet und empfangen werden. Der
Grund dafür findet sich in den ausgehandelten ACCMs, bei denen jeweils nur Bit19 (DC3)
und Bit17 (DC1) gesetzt wurden. Hierbei handelt es sich um die ASCII-Kontroll-Zeichen für
das Modem-Xon/Xoff-Flow-Control-Protokoll.
B
A
B
A
A
B
7E
02
03
27
80
06
06
63
21 01 01 00 10
00 2D 0F 01
8D 39 01 0E
7E
IPCP Configure-Request ID:01 Length: 16
Compression-Type: Van Jacobson Comp. TCP/IP
IP-Address: 141.57.1.14
FCS Flag-Sequenz
7E
7D
B0
7E
03
BC
80
31
31
80
06
B0
FD
06
7E
21
00
7E
01 01 00 0A
00 01 01 03
Compression Control Protocol (CCP)
01 01 00 22
00 00 00
IPCP Configure-Request ID:01 Length: 34
IP-Address: Anforderung einer IP vom Peer
FCS Flag-Sequenz
7E 80 21 04 01 00 0A
02 06 00 2D 0F 01
F8 30 7E
IPCP Configure-Reject ID:01 Length: 10
Ablehnen der TCP/IP-Header-Komprimierung
FCS Flag-Sequenz
7E
80
7D
AE
7E
03
9D
FF
FD
31
A0
80
06
5C
03
01
06
7E
21
8D
7E
C0 21 08 04 00 10
01 00 0A
00 01 01 03
LCP Protocol-Reject ID:04 Length: 16
Das Compression Control Protocol wird von
der Implementierung nicht unterstützt und
angelehnt.
IPCP Configure-Request ID:02 Length:10
IP-Address: 141.57.1.14
FCS Flag-Sequenz
7E
03
33
7E
03
F4
7E
03
F4
7E
03
02
80
06
65
80
06
28
80
06
08
80
06
FB
21
8D
7E
21
8D
7E
21
8D
7E
21
8D
7E
03 02 00 16
39 E6 3C
01 02 00 0A
39 01 0E
IPCP Configure-Nak ID:02 Length:22
IP-Address: 141.57.230.60
FCS Flag-Sequenz
IPCP Configure-Ack ID:02 Length:10
Configure-Request mit der ID:02 wird
bestätigt
IPCP Configure-Request ID:03 Length:22
Enthält die im vorangegangenen Configure-Nak
vorgeschlagene IP-Adresse.
IPCP Configure-Ack ID:03 Length:22
Der Configure-Request mit der ID :03 wird
bestätigt. Damit wurde der Implementierung
die IP 141.57.230.60 zugewiesen
02 02 00 0A
39 01 0E
01 03 00 16
39 E6 3C
02 03 00 16
39 E6 3C
Das IPCP befindet sich nun im Opened-Zustand und es können IP-Datagramme über die
Verbindung ausgetauscht werden.
7E 21 45 00 00
8D 39 E6 3C 8D
55 00 3A 29 10
4F 45 50 46 45
………………… 7E
………………………………..
60
39
00
45
02
FF
01
46
AE
FF
00
45
00
00
00
43
00
89
00
45
80
00
00
50
7D
89
00
45
31
00
01
50
37
4C
20
45
30
87
45
4C
IP
Das PPP-Protocol-Feld ist nur noch ein Byte
lang, da in der Establish-Phase die LCPKonfigurations-Option Protocol-Compression
vereinbart wurde.
43
Digitale Modulation und Internet-Protokolle
Teilnehmer A möchte die Verbindung trennen. Ein Close-Ereignis kam hierdurch zustande
und PPP tritt in die Terminate-Phase ein. Die Verbindung wird von LCP durch Versenden
von Terminate-Paketen getrennt.
A
B
7E
5C
7E
91
FF
A4
FF
81
7D 23 C0 21 7D 25 7D 25 7D 20 7D 24
7E
7D 23 C0 21 7D 26 7D 25 7D 20 7D 24
7E
LCP
FCS
LCP
FCS
Terminate Request ID:05 Length: 04
Flags
Terminat-Ack ID:05 Length: 04
Flags
2.8. TCP/IP und HTTP
Die Protokoll-Struktur des Transmission-Control-Protokoll (TCP) und des Internet-Protokoll
(IP), sowie deren Implementierung in Mikrocontroller-Software ist ausführlich in [D&E]
beschrieben und dokumentiert und wird daher in dieser Arbeit nicht noch einmal erläutert.
Gleiches gilt für das HTTP-Protokoll.
Das nächste Kapitel beschäftigt sich mit den Überlegungen zum Hardware-Aufbau einer
Embedded Soft-Modem-Baugruppe und der daraus entstandenen Mikrocontroller-Baugruppe.
44
Soft-Modem-Baugruppe
3. Soft-Modem-Baugruppe
3.1. Vom Hard- zum Softmodem
Beim Entwurf einer Soft-Modem-Baugruppe macht es Sinn zuerst einen Blick auf eine
komplette Hardware-Modem-Baugruppe zu
werfen, um sich über die einzelnen
Funktionseinheiten eines Modems im Klaren zu werden. Abbildung (3.1) zeigt das
Blockschaltbild einer klassischen Modem-Baugruppe, die auf der linken Seite mit dem
öffentlichen Telefonnetz (Personal Switched Telecomunication Network, PSTN) und auf der
rechten Seite mit einem Daten-verarbeitenden Host Processor verbunden ist.
Host Processor
MSP430F149
PSTN
Datenpumpe
DAA
Rx, Tx
Codec
DSP
Mikrocontroller
Kontrollsignale: CID,RING, OH
Abb.(3.1): Blockschaltbild einer klassischen Modem-Baugruppe
Der Host Processor soll dabei der MSP430F149 sein. Typischerweise findet man in der
Modem-Baugruppe einen Hardware-Mikrocontroller, der sich um den reibungslosen
Datentransfer bzw. die Kommunikation mittels AT-Kommandos zwischen Modem und Host
Processor kümmert und eventuell vom Modemstandard geforderte FehlerkorrekturMechanismen und Kompressionsverfahren implementiert. Der Mikrocontroller steuert
weiterhin den Rufzustand der Modem-Baugruppe.
Zentraler Bestandteil der Modem-Baugruppe ist die sog. Datenpumpe, bestehend aus
Digitalem Signalprozessor (DSP) und Codec. Der DSP implementiert die Algorithmen zur
Modulation bzw. Demodulation der binären Information entsprechend des verwendeten
Standards. Der Codec realisiert ausschließlich die analog-digital- bzw. digital-analogWandlung.
Der dritte Bestandteil der Modem-Baugruppe wird als Direct Access Arrangement (DAA)
bezeichnet und stellt die tatsächliche physikalische Schnittstelle zum Übertragungsmedium,
der Telefonleitung, dar. Hierbei handelt es sich um einen Übertrageraufbau, der die
Signalpegel auf der Telefonleitung in einen Signalpegelbereich überträgt, der von der
Mikroelektronik-Seite ausgewertet werden kann. An dieser Stelle gibt es keine andere
45
Soft-Modem-Baugruppe
Möglichkeit, als mit Analogtechnik die spezielle Datenübertragung und Zustandssignalisierung zu realisieren. Mehr dazu im Abschnitt 3.2.
Der Ansatz zum Soft-Modem äußert sich darin, möglichst viele Funktionen der ModemBaugruppe als Embedded-Software in den Host Processor zu implementieren, um damit
Hardware-Bausteine zu ersetzen. In diesem Projekt war es möglich, bis auf den DAAÜbertrageraufbau,
sämtliche
Funktionseinheiten
der
Modem-Baugruppe
mit
dem
MSP430F149 zu ersetzen. Die Fachwelt spricht bereits von einem Soft-Modem, wenn nur
DAA und Codec als Hardware-Elemente zu finden sind. Um der Begrifflichkeit treu zu
bleiben, handelt es sich bei der entwickelten Applikation wohl um ein Soft-Modem ohne
Codec. Abbildung (3.2) zeigt das reduzierte Blockschaltbild.
Host Processor
MSP430F149
Kontrollsignale: CID,RING, OH
PSTN
Rx, Tx
Datenpumpe
DAA
Codec
DSP
Mikrocontroller
Embedded Software
Mikrocontroller
Funktionen
DSP
Funktionen
AD/DA
Funktionen
Abb.(3.2): Blockschaltbild der reduzierten Modem-Baugruppe
46
Soft-Modem-Baugruppe
3.2. Direct Access Arrangement (DAA)
[ELECD] und [ATI] geben einen umfassenden Überblick über die verschiedenen
Möglichkeiten eine DAA aufzubauen. Auch hierbei geht der Trend ganz klar in Richtung
Platz sparender, integrierter Schaltkreise. Für dieses Projekt viel die Wahl auf eine Ein-ChipLösung der Firma CLARE mit dem Namen LITELINK III. Durch Einsatz des LITELINK III
Entwicklungs-Boards war es möglich, ohne zusätzlichen Entwicklungsaufwand in der
Einhaltung von Vorschriften für Endgeräte am öffentlichen Telefonnetz, unmittelbar die
Verbindung zur Telefonleitung herzustellen. Die Schaltung des Entwicklungs-Boards
entspricht den Vorgaben des LITELINK III Datenblatts und erfüllt damit die europäischen
Zulassungsvorschriften
nach TBR-21. Abbildung
(3.3) zeigt das Blockschaltbild des LITELINK
III. Klar zu erkennen ist
dabei
die
Isolations-
barriere zwischen Modem
und Leitungsseite. Auf der
rechten Seite findet man
die Anschlusse für TIP
und RING der TelefonAbb.(3.3): LITELINK III CPC5621 Blockschaltbild
Zweidrahtleitung
und
links, jenseits der Isolationsbarriere, die Sende- und Empfangssignalwege (Tx+, Tx-, Rx+, Rx-) für die
Mikroelektronik sowie einige Steuer- und Kontrollsignal-Leitungen (MODE, OH, RING,
CID).
Das LITELINK III Entwicklungs-Board realisiert folgende Funktionen:
•
galvanische NF-Signal-Trennung von Leitungsseite und Modemseite mittels
integrierter Optokoppler
•
DC-Schleifencharakteristik: Elektronische Drossel (Gyrator), Leistungstransistor
CPC5602
•
DC-Leitungsstrombegrenzung (einstellbar durch einen Widerstand)
•
AC-Leitungsimpedanzanpassung (komplexe-Leitungs-Referenzimpedanz nach TBR21)
47
Soft-Modem-Baugruppe
•
Leitungsschalter inklusive galvanisch getrennter Ansteuerung
•
2-Draht/4-Draht Hybrid mit Sprecherecho-Unterdrückung, Einstellung der TIP/RINGAusgangsspannung
•
Ruferkenner, galvanisch entkoppeltes Rechteckausgangssignal für Mikrocontroller
•
Leitungssignalwege im on-hook Zustand für z.B. Caller-ID Erkennung
•
Schleifenstromerkennung durch statischen Spannungspegel an Rx+/Rx-
Der 2-Draht/4-Draht Hybrid-Schaltkreis ermöglicht das Einspeisen und Empfangen von
differentiellen Signalen, d.h. das Sendesignal kann an Pin Tx+ positiv und gleichzeitig an Pin
Tx- negativ eingespeist werden. Diese Vorgehensweise hat eine maximale SprecherechoUnterdrückung zur Folge, das Sendesignal wird im Empfangssignal um mindestens 40dB
gedämpft. Bei differentieller Einspeisung ist laut Datenblatt eine maximale Signalamplitude
von 2,2Vpp zulässig, die dann auf der Telefonleitung einem Signalpegel von 0dBm an 600Ω
entspricht. Ebenso liegt auch das Empfangssignal an Rx+ und Rx- differentiell vor und kann
eine maximale Signalamplitude von 2,2Vpp erreichen.
3.3. Die Mikrocontroller-Baugruppe
Abbildung (3.4) zeigt das komplette Blockschaltbild der Soft-Modem-Baugruppe und
Abbildung (3.5) die MSP430F149 Entwicklungs-Platine. Das LITELINK III EntwicklungsBoard wird über zwei Steckverbinderleisten auf die MSP430F149 Entwicklungs-Platine
aufgesteckt.
7,3728 MHz
JTAG
RING
OH
LITELINK III
Eval-Board
RJ45LAN
MSP430F149
analogue
Signal
Processing
LEDs: Power,
Link, Traffic
32 kHz
3,3 V
Power-Supply
Abb.(3.4): Blockschaltbild der Soft-Modem-Baugruppe
48
Abb.(3.5): MSP430F149 Entwicklungs-Platine
Soft-Modem-Baugruppe
Auf der MSP430F149 Entwicklungs-Platine befinden sich,
•
der MSP430F149 Mikrocontroller mit zwei externen Quarzen (32kHz und
7,3728MHz)
•
der Schaltkreis für die Spannungsversorgung der gesamten Baugruppe mit 3,3V
•
die JTAG-Schnittstelle zum Programmieren des MSP430F149 und Echtzeit-Debuggen
der Mikrocontroller-Software
•
eine standardmäßige RJ11-Steckerbuchse für den Anschluss der Telefonleitung
•
drei LEDs zum Anzeigen des Betriebszustandes der Baugruppe
•
analoge Schaltungen zur Signalaufbereitung der Sende- bzw. Empfangssignale
zwischen MSP430F149 und dem LITELINK III Entwicklungs-Board
Bei dem verwendeten Mikrocontroller handelt es sich um einen Vertreter der MSP430
Familie von Texas Instruments, einer sehr leistungsfähigen
Reihe von 16-Bit-
Mikrocontrollern mit RISC-Architektur, die speziell für eine extrem niedrige Stromaufnahme
entwickelt wurde. In diesem Projekt kommt der Typ MSP430F149 zum Einsatz, welcher über
einen Flash-Programmspeicher von 60Kbyte und einem Arbeitsspeicher von 2Kbyte Größe
verfügt. Abbildung (3.6) zeigt das Block-Diagramm der MSP430x14x Serie, daraus lassen
sich die integrierten Module, die in diesem Projekt zum Einsatz kommen erkennen.
Abb.(3.6): Block-Diagramm der Low-Power-Controllerfamilie MSPx14x
Vier Pins des LITELINK III Entwicklungs-Boards sind entweder direkt oder indirekt mit dem
MSP430F149 verbunden. Direkt verbunden ist der Kontroll-Eingangspin OH mit dem der
Rufzustand der DAA gesteuert werden kann. Bei einem logischen 0 Pegel an OH befindet
49
Soft-Modem-Baugruppe
sich die DAA im sog. off-hook Zustand, der, bildlich beschrieben, einem abgehobenen
Telefonhörer entspricht. Bei einem logischen 1 Pegel an OH befindet sich die DAA im sog.
on-hook Zustand, in dem ein eingehender Ruf auf der Leitung erkannt werden kann, oder
wieder bildlich beschrieben, der Telefonhörer aufgelegt ist.
Weiterhin ist der RING-Ausgangspin des LITELINK III Entwicklungs-Boards direkt mit dem
MSP430F149 verbunden. Das RING-Signal entspricht dem Ausgang des LITELINK III
Ruferkenner-Schalkreises, der bei einem eingehenden Ruf, das von der Vermittlung auf die
Leitung gegebene Rufsignal in ein, für den Mikrocontroller auswertbares Rechtecksignal
umwandelt und am RING-Pin zur Verfügung stellt.
Indirekt mit dem MSP430F149 verbunden sind die Sende- und Empfangssignalwege, die
entgegen der oben beschriebenen Vorgehensweise nicht differentiell, sondern einseitig
betrieben werden. Es hat sich während der Entwicklung gezeigt, dass die SprecherechoUnterdrückung bei einseitiger Betriebsweise dennoch ausreichend für die Realisierung der
Soft-Modem-Applikation ist. Es folgt nun eine getrennte Beschreibung der analogen
Schaltungen, die sich im Sende- bzw. Empfangssignalweg befinden.
Sendesignal
Die im MSP430F149 implementierten Modulator-Algorithmen erzeugen am ModulatorAusgangspin (P1.7) ein Wechselsignal mit einer Signalamplitude von 3,3Vpp. Bei einseitiger
Signaleinspeisung darf aber am Pin Tx+ ein Signal mit nur maximal 1,1Vpp anliegen, was
einem Signalpegel von
  1,1V  2 
 
 
  2⋅ 2  
P = 10 ⋅ log
 = −5,985dBm
Ω
⋅
600
1
mW






Gl. (3.1)
entsprechen würde. Ein Modem darf jedoch, wie
bereits oben erwähnt, nur einen maximalen Pegel
von –9dBm auf die
P1.7
Leitung geben. Das
9.1k
TX+
560
10n
Modulator-Ausgangssignal wird daher über einen
Spannungsteiler mit RC-Tiefpass-Charakteristik
Ufsk
Utx
(s. Abbildung(3.7)) in den Sendepin Tx+ des
LITELINK III Entwicklungs-Boards eingespeist.
50
Abb.(3.7): Spannungsteiler und RC-Tiefpass
Soft-Modem-Baugruppe
Der Spannungsteiler reduziert die Amplitude auf
Utx _ max =
560 Ω
⋅ 3,3Vpp = 0,191Vpp
9,1kΩ
Gl. (3.2)
Dies entspricht einem Sendepegel von –21,2dBm.
Durch die zusätzliche Tiefpass-Charakteristik werden die modulierten Sendefrequenzen von
1650Hz und 1850Hz, sowie störende Oberwellen noch weiter gedämpft. Die Eckfrequenz des
RC-Gliedes ergibt sich zu:
fc =
1
= 1749 Hz
2 ⋅ π ⋅ 9,1kΩ ⋅ 10 nF
Gl. (3.3)
Aus der Frequenzabhängigkeit der Ausgangsspannung Utx des RC-Gliedes lässt sich die
Signalamplitude und die zusätzliche Dämpfung der charakteristischen Signalfrequenzen
berechnen.
Utx ( f ) =
1
1 + j ⋅ 2 ⋅ π ⋅ 9,1kΩ ⋅ 10 nF ⋅ f
Gl. (3.4)
Tabelle (3.1) gibt die berechneten Werte wieder.
f
Utx_max(f)
20⋅log|Utx(f)|
resultierender Pegel
1650Hz
0,139Vpp
-2,8dB
-24,0dBm
1850Hz
0,131Vpp
-3,3dB
-24,5dBm
Tab.(3.1): Signalpegel und maximale Amplituden des Sendesignals
Die relativ geringen Signalpegel des Sendesignals sind vollkommen ausreichend für die
Kommunikation, da davon ausgegangen wird, dass das empfangende Modem Signale mit
Pegeln bis zu –43dBm sicher erkennen kann.
Empfangssignal
Am Empfangspin Rx+ des LITELINK III Entwicklungs-Boards steht ein DC-entkoppeltes
reines Wechselsignal zur Verfügung, dessen Signalamplitude maximal 340mVpp (bei
maximalem Empfangspegel von –9dBm) annehmen kann. Messungen haben ergeben, dass
sich die reale Amplitude des Empfangssignals im Bereich von 200mVpp bewegt. Zusätzlich
ist das Signal von einer Menge Störungen überlagert, die einerseits vom Übertragungskanal
und andererseits vom, ebenfalls sich auf der Leitung befindenden, Sendesignal stammen. Das
Diagramm in Abbildung (3.8) soll so ein typisches 980Hz Empfangssignal veranschaulichen.
51
Soft-Modem-Baugruppe
0.1
U/V
0.05
0
-0.05
-0.1
0
0.5
1
1.5
2
t/s
2.5
3
3.5
4
x 10
-3
Abb.(3.8): LITELINK III Eval-Board Rx+ Ausgangssignal
Bevor das Signal nun auf den Demodulator-Eingangspin des MSP430F149 gegeben wird,
erfolgt eine geringfügige Signalaufbereitung mittels zweier aufeinander folgender OPVSchaltungen, die in Abbildung (3.9) dargestellt sind.
Vcc
Vcc
100n
180k
51k
-
10k
47p
2k
+
51k
+
-
22k
4,7n
100n
Abb.(3.9): OPV-Schaltung zur Signalaufbereitung
Mit Hilfe der ersten OPV-Stufe wird das Empfangssignal um den Faktor 18 verstärkt und mit
einem Gleichspannungs-Offset der halben Betriebsspannung (1,65V) überlagert. Abbildung
(3.10) zeigt das Empfangssignal am Ausgang der ersten OPV-Schaltung.
U/V
3
2
1
0
0
0.5
1
1.5
2
t/s
2.5
3
3.5
4
x 10
-3
Abb.(3.10): Signal am Ausgang der Verstärkerstufe
Durch unsymmetrische Spannungsversorgung der Operations-Verstärker mit 3,3V und 0V als
Betriebsspannung und Überlagerung des Gleichspannungs-Offsets befindet sich das
Empfangssignal jetzt im Bereich zwischen 0 und 3,3V und demnach im Spannungsbereich,
der vom MSP430F149 ausgewertet werden kann.
52
Soft-Modem-Baugruppe
Die zweite OPV-Stufe entspricht einem Chebychef-Tiefpass-Filter 2.Ordnung mit einer Cutoff-Frequenz von 1300Hz und einer Verstärkung von 1. Damit werden störende Frequenzen,
die oberhalb der zu empfangenden charakteristischen Frequenzen im Kanal Nr.1 liegen, aus
dem Signal herausgefiltert. Das Tiefpass-Filter wurde mit der Software „FilterPro“ der Firma
Texas Instruments dimensioniert. Das Programm steht kostenlos auf der Internet-Seite von
Texas Instruments zum Download zur Verfügung und liefert unter Eingabe verschiedener
Filter-Parameter eine fertig dimensionierte OPV-Schaltung mit den vorgegebenen
Eigenschaften. Wie Abbildung (3.11) zeigt, steht dann am Ausgang der OPV-Schaltungen ein
fast reines Sinussignal zur Demodulation mit dem MSP430F149 bereit.
U/V
3
2
1
0
0
0.5
1
1.5
2
t/s
2.5
3
3.5
4
x 10
-3
Abb.(3.11): Signal am Ausgang der TP-Schaltung
Abschließend noch ein paar Worte zu den Kontroll-LEDs auf der MSP430F149
Entwicklungs-Platine. Die blaue LED (D1) liegt direkt an Betriebsspannung und zeigt
demnach an, ob die Baugruppe mit Spannung versorgt ist, oder nicht.
Die gelbe LED (D2) wird per Software gesteuert und signalisiert den Rufzustand der
Baugruppe. Im on-hook Zustand leuchtet die LED nicht. Ein eingehendes und als gültig
erkanntes Rufsignal wird dann durch einmaliges Aufleuchten der LED dem Anwender
visualisiert. Beim Wechsel in den off-hook Zustand, d.h. beim entgegennehmen eines Anrufs
blinkt die LED kurz um anschließend wieder zu erlöschen, bis der Verbindungsaufbau
komplett abgeschlossen ist. Sobald die Soft-Modem-Baugruppe bereit ist, Daten zu
Empfangen und zu Senden, leuchtet die LED permanent.
Die rote LED (D3) visualisiert den Datentransfer in Echtzeit, durch software-gesteuertes Einbzw. Ausschalten der LED entsprechend der im Moment empfangenen bzw. gesendeten
Bitfolge.
Im Folgenden wird nun konkret auf die Mikrocontroller-Software eingegangen, die den obern
beschriebenen Hardware-Aufbau eigentlich erst zur Soft-Modem-Applikation macht.
53
Funktionsblöcke der Software
4. Funktionsblöcke der Software
Abbildung (4.1) zeigt eine Zusammenfassung der Funktionsblöcke der KommunikationsProtokolle, die als Software im MSP430F149 Mikrocontroller implementiert wurden, in
Zusammenhang mit der dazugehörigen Netzwerkschicht, entsprechend des DoD-Standards
der TCP/IP-Protokollstapel-Architektur.
Application
Transport
Internet
Network
send
Header
Header
Header
Data
HTTP
Header
Header
Header
Data
TCP
Header
Header
Header
Data
IP
Header
Header
Header
Data
receive
PPP
FCS
Modulation bzw. Demodulation der V.21 Signale
asynchrones Senden & Empfangen von Bytes
(Start/Stopp-Betrieb)
V.21
Ring-Detektion
Steuerung des Rufzustands
LITELINK DAA
MSP430F149
Abb.(4.1): Protokollschichten und Datenkapselung
Es ist weiterhin zu erkennen, dass nur zwei Funktionsblöcke (Ring-Detektion und V.21) in
direkter Verbindung zu der physikalischen DAA-Schnittstelle stehen.
In den folgenden Abschnitten wird bis ins Detail erklärt, wie die Realisierung der geforderten
Aufgaben in einzelnen Blöcken umgesetzt wurde. Die Betrachtung erfolgt von „unten nach
oben“ bis zur fertigen Applikation.
4.1. Rufsignalerkennung und Steuerung des Rufzustandes
In Abbildung (4.2) ist der Ruferkenner-Schaltkreis des LITELINK III dargestellt. Abbildung
(4.3) zeigt im oberen Diagramm ein typisches Rufsignal
auf der Telefonleitung (typisch für Deutschland
60V@25Hz, bei Nebenstellenanlagen 48V@50Hz), im
unteren Diagramm der Abbildung (4.3) ist das
Ausgangssignal
Abb.(4.2): Ring Signal Detection Circuit
(RING)
des
LITELINK
III
Vollwellenruferkenners abgebildet. Es handelt sich
hierbei um einen Vollwellenruferkenner, der für jede
Halbwelle der Rufton-Wechselspannung einen Impuls am RING-Ausgang erzeugt. Das
Rechtecksignal muss vom Mikrocontroller, entsprechend des in Abbildung (4.4) dargestellte
54
Funktionsblöcke der Software
Zeitschemata, ausgewertet werden. Das
Rufsignal auf Tip und Ring @25Hz
20
Rufsignal wird jeweils für eine Sekunde
gegeben,
zwischen
zwei
-40
U/V
von der Vermittlung auf die Leitung
0
-20
-60
Rufsignalen
-80
-100
herrscht für vier Sekunden Sendepause.
International
unterschieden
sich
0
0.02
0
0.02
die
3
und befinden sich in einem Bereich
2
U/V
Frequenzen der Rufsignal-Töne erheblich
zwischen 16⅔Hz und 64Hz, was, bei einer
1
Signaldauer von einer Sekunde und dem
0
LITELINK Vollwellenruferkenner, 33 bis
0.04
0.06
0.08
0.1
0.12
t/s
Vollw ellenerkennung RING Ausgangssignal
0.04
0.06
0.08
t/s
0.1
0.12
0.14
0.16
0.14
0.16
Abb.(4.3): Rufsignale
128 Impulsen am RING Ausgangspin
entspricht. Der Software-Algorithmus zur Rufsignalerkennung sollte so angelegt sein, dass er
in diesem Frequenzbereich gültige
1s
4s
Rufsignale erkennt.
1s
Weiterhin kann es bei der Rufsignalisierung zu zwei Arten von
Störungen kommen, die in Abbildung
RING
(4.4) mit den kleinen Gewitterwolken
visualisiert sind. Es kann z.B. vorkommen, dass während der Sendepause
durch Störeinflüsse auf der Leitung ein
Abb.(4.4): Rufsignale im Zeitkontext mit Störungen
RING-Impuls durch den RuferkennerSchaltkreis erzeugt wird, dem eigentlich gar kein Rufsignal zugrunde liegt. Oder der zweite
Fall wäre, dass sich tatsächlich ein Rufsignal auf der Leitung befindet, aber einzelne
Rufimpulse ausbleiben. Der auswertende Software-Algorithmus muss, robust gegenüber diese
Arten von Störungen, sicher ein Rufsignal als gültig bewerten können.
Für den verwendeten Algorithmus wird lediglich ein interruptfähiger Port-Einganspin (P2.5)
am MSP430F149 benötigt, an den der RING-Ausgangspin angeschlossen ist und ein interner
Intervall-Timer, mit dessen Hilfe der Zeitkontext für die Validierung des Rufsignals
hergestellt wird. Hierfür kommt der Watchdog-Timer (WDT) des MSP430F149 zum Einsatz,
da sich dieser mit Hilfe des 32kHz-Quarzes für eine Intervallzeit von 250ms Sekunden
konfigurieren lässt, sodass, nach dem Starten des Timers, alle 250ms die WDT-Interrupt55
Funktionsblöcke der Software
Routine aufgerufen wird. Die Interrupt-Routinen
für den Eingangspin P2.5 und den WDT finden sich
im Software-Modul ring_detection.c. Abbildung
(4.5) zeigt das Blockschaltbild des WDT.
In Abbildung (4.6) ist der Programmablaufplan für
die Rufsignalerkennung abgebildet. Darin wird das
Zusammenspiel von Port-Interrupt und IntervallTimer-Interrupt veranschaulicht.
Abb.(4.5): Watchdog Timer Blockschaltbild
Abb.(4.6): Ring-Detektion Software-Algorithmus
Die Aufgabe des Port-Interrupts besteht hauptsächlich darin RING-Impulse mit Hilfe der
Variablen ring_puls_cntr zu zählen. Die Variable wird beim Programmstart mit 0
initialisiert. Beim Auftreten des ersten RING-Impulses wird, innerhalb des Port-Interrupts, der
WDT durch Aufruf der Funktion StartWDT_IntervalTimer() als Intervall-Timer
gestartet. Nach 15 erkannten RING-Impulsen erfolgt die Deaktivierung des Port-Interrupts
und gleichzeitig wird das Statusflag ValidRingFG im Statusregister ModemStatusReg
gesetzt. Bei einer minimalen Rufsignal-Frequenz von 16⅔Hz ist nach 15 RING-Impulsen
mindestens eine Zeit von 0,45s vergangen.
Der WDT-Interrupt wird 250ms nachdem der erste RING-Impuls registriert wurde zum ersten
Mal generiert. Die Interrupt-Routine kontrolliert, ob in dem Zeitintervall von 250ms noch
weitere RING-Impulse registriert wurden (ring_puls_cntr > 1). Bei minimaler Frequenz
56
Funktionsblöcke der Software
von 16⅔Hz sollten das bis zu 8 Impulse sein. Für den Fall, dass es sich nur um einen
einzelnen Störimpuls gehandelt hat, wird der Ruferkennungs-Algorithmus neu initialisiert,
d.h. der Intervall-Timer durch Aufruf der Funktion StopWDT() angehalten und, durch
Aufruf der Funktion Init_RingDetection() der Port-Interrupt aktiviert und die
Variable ring_puls_cntr auf 0 zurückgesetzt.
Nach 750ms kontrolliert die WDT-Interrupt-Routine, ob das Flag ValidRingFG gesetzt
wurde. Ausgehend von der minimalen Rufsignal-Frequenz und einem gültigen Rufsignal auf
der Leitung sollten bereits mehr als 15 RING-Impulse registriert sein. Sollte dies nicht der
Fall sein, kam es wohl zu mehreren durch Störung verursachten RING-Impulsen und die
Ruferkennung wird neu initialisiert. Bei gesetztem ValidRingFG Flag läuft der IntervallTimer weiter, das Flag wird zurückgesetzt und die gelbe LED wird zur Visualisierung des
eingehenden Rufsignals angeschaltet.
Nach zwei Sekunden wird dann die Zählvariable ValidRing_cntr für gültig erkannte
Rufsignale um eins erhöht und die gelbe LED wieder ausgeschaltet. Danach erfolgt eine
Fallunterscheidung bzgl. der Anzahl bereits gültig erkannter Rufsignale. Mit der Konstanten
MAX_RINGS wird in der Software festgelegt, nach wie viel erkannten Rufsignalen der
eingehende Ruf angenommen werden soll. Wenn ValidRing_cntr den Wert
MAX_RINGS angenommen hat, erfolgt durch Aufruf der Funktion go_off_hook() die
Änderung des Rufzustands der Soft-Modem-Baugruppe und der Ruf wird entgegen
genommen. Andernfalls wird die Ruferkennung neu initialisiert und das nächste Rufsignal
ausgewertet.
Im Weiteren können nun zwei Fälle unterschieden werden. Der Ruf wurde noch nicht
angenommen. Im Normalfall würde das bedeuten, dass mit Auftreten eines RING-Impulses,
der oben beschriebene Algorithmus erneut durchlaufen wird. Sollte jedoch nach 10 Sekunden
kein weiterer RING-Impuls auftreten, hat es sich wohl um ein einzelnes Rufsignal gehandelt
und der vermeintliche Gesprächspartner hat den Verbindungsaufbau zu der Soft-ModemBaugruppe aufgegeben. Die Ruferkennung wird neu initialisiert, sowie der Ruftonzähler
ValidRing_cntr auf 0 zurückgesetzt.
Im Fall der Rufannahme wartet die Software zwei Sekunden (s. auch Abschnitt 4.3) , bevor
mit Hilfe das Flags OFF_HOOK im Statusregister ModemStatusReg dem Hauptprogramm
mitgeteilt wird, dass sich die Baugruppe im off-hook Zustand befindet.
57
Funktionsblöcke der Software
4.2. Digitale Modulation nach V.21
Dieser Abschnitt beschreibt die eigentliche Grundlage zur Übertragung binärer Information
über das öffentliche analoge Telefonnetz, die Modulation von digitalen Daten in analoge
Signale und die Demodulation von analogen Signalen in digitale Information. Wie bereits
beschrieben soll dabei nach dem V.21-Modemstandard vorgegangen werden. Die
beschriebenen Software Funktionen und Interrupt-Routinen sind im Modul v_21.c zu finden.
Es erfolgt zunächst eine nähere Betrachtung des implementierten FSK-Modulators.
4.2.1. V.21 FSK-Modulator
Entgegen der gängigen Meinung, eine Frequenzumtastung müsse auf reinen Sinussignalen
beruhen, hat die Entwicklung gezeigt, dass die geforderte Frequenzumtastung auch durch
Umtastung von Rechtecksignalen realisiert werden kann. Dabei wird davon ausgegangen,
dass das empfangende Modem tolerant gegenüber im Signal auftretende Oberwellen ist und
die richtigen Frequenzanteile herausfiltern und erkennen kann. Die in Kapitel 3 Abschnitt 3
beschriebene Tiefpass-Charakteristik der Koppelschaltung zwischen Modulator-Ausgangspin
und Sendepin Tx+ des LITELINK III Entwicklungs-Boards hat nur geringe dämpfende
Wirkung auf die Oberwellen der erzeugten Modulator-Frequenzen.
Der V.21-Modulator-Algorithmus muss also eine FSK mit den definierten charakteristischen
Frequenzen des Kanal Nr.2 (1650Hz und 1850Hz) realisieren. Die Erzeugung eines
Rechtecksignals einer bestimmten Frequenz gestaltet sich mit dem MSP430F149 relativ
einfach. Hierzu wird das Timer_A Modul verwendet (s. Abbildung (4.7)).
Abb.(4.7): MSP430F149 Timer_A Blockschaltbild
58
Funktionsblöcke der Software
Hierbei handelt es sich um ein 16-Bit breites Zählregister, dass mit drei Capture/CompareBlöcken verbunden ist. Für die Realisierung des FSK-Modulators wird konkret der CCR2Block im Compare-Modus betrieben. Durch Übereinstimmung des Timer_A Zählerwertes
und des Wertes im Compare-Register (CCR2) erfolgt die Generierung eines Interrupt. Jeder
Capture/Compare-Block des Timer_A ist weiterhin mit einer separaten Ausgabeeinheit
verbunden, die acht verschiedene Betriebsarten beherrschen. Die Ausgabeeinheit kann so
konfiguriert werden, dass bei Übereinstimmung des Timer_A Zählerwertes mit dem
Compare-Register Inhalt hardwaremäßig, ohne weiteres Eingreifen per Software, der Pegel
eines Ausgangspins geändert wird. Die Erzeugung einer definierten Signalfrequenz ergibt sich
aus dem Zusammenspiel zwischen Compare-Interrupt und entsprechender Konfiguration der
Ausgabeeinheit, unter Zuhilfenahme einer Speichervariablen (BitFreq), deren Inhalt dem
Zählerwert der halben zu erzeugenden Signalperiode entspricht. Die Werte für die Variable
BitFreq berechnen sich aus der Frequenz, mit der der Timer_A getaktet wird und der zu
erzeugenden Signalfrequenz nach der Formel:
BitFreq =
Timer _ A Zählfreque nz
2 ⋅ Signalfreq uenz
Gl. (4.1)
Timer_A wird mit vollem Systemtakt von 7,3728MHz getaktet. Hieraus ergeben sich die in
Tabelle (4.1) aufgelisteten BitFreq-Werte für die FSK-Frequenzen im Kanal Nr.2.
charakteristische Frequenz
BitFreq
binär 0
1850Hz
1993
binär 1
1650Hz
2235
Tab.(4.1): Werte für BitFreq
In Abbildung (4.8) ist der Programmablaufplan der CCR2-Interrupt-Routine abgebildet. In
der Routine wird lediglich der Inhalt der Variablen BitFreq auf
CCR2 Interrupt
Service Routine
den aktuellen CCR2-Register Inhalt aufaddiert. Damit wird stets
nach BitFreq Zählschritten des Timer_A ein weiterer Interrupt
CCR2 = CCR2 + BitFreq
generiert. Durch Konfiguration der CCR2-Ausgabeeinheit im
„Toggle“-Modus wird am Modulator-Ausgangspin
Return from Interrupt
Abb.(4.8): CCR2 Interrupt
(P1.7) ein
Rechtecksignal mit der gewünschten Frequenz erzeugt.
Um zu erreichen, dass die Frequenz des Ausgangssignals
entsprechend der zu sendenden Bitfolge umgetastet wird, kommt an
59
Funktionsblöcke der Software
dieser Stelle das UART-Modul zum Einsatz. Die Bitgeschwindigkeit wird mit 300bit/s
initialisiert und das UART-Ausgangssignal wird wiederum hardwaremäßig auf einen
interrupt-fähigen MSP430F149 Eingangspin (P1.3) geschaltet. Das UART-Modul arbeitet
CPU-unabhängig, d.h. die Software muss lediglich ein Datenbyte in das UART-Senderegister
schreiben und anschließend generiert das UART-Modul ein asynchrones Ausgangssignal mit
StartP1.3 Interrupt
Service Routine
und
Stoppbit
und
einer
Bit-
geschwindigkeit von 300bit/s. Abbildung
(4.9) zeigt den Programmablaufplan für den
nein
Eingangspin-Interrupt
ja
von
P1.3.
Der
high-low-Flanke?
Interrupt wird jeweils durch eine steigende
BitFreq den Wert für
1650Hz zuweisen
oder fallende Flanke des UART-Signals
BitFreq den Wert für
1850Hz zuweisen
generiert. Bei einer fallenden Flanke wird die
Variable BitFreq mit dem Wert für die
Flankensensibilität für P1.3
Interrupt andern
Frequenz 1850Hz (logisch 0) und bei einer
steigenden Flanke mit dem Wert für die
Frequenz 1650Hz (logisch 1) initialisiert.
Return from Interrupt
Abbildung (4.10) zeigt eine Zusammen-
Abb.(4.9): P1.3 Interrupt
fassung der Realisierung des Modulations-
Mechanismus und Abbildung (4.11) soll das Zusammenspiel der einzelnen Interrupt-Routinen
MSP430F149
noch einmal veranschaulichen. Die Software
UART
Transmit Logic
verwendet zum Starten des Modulators zwei
UART Tx
Output
Funktionen. SetupFSKModem() initialisiert
sämtliche Hardware-Module des MSP430F149,
P1.3
Interrupt Routine
die für die Modulation und Demodulation verwendet
werden.
startet
den
schließend
StartFSKModulator()
Modulator-Mechanismus,
kann
dann
mit
der
an-
Funktion
BitFreq
P1.7
Output
Timer_A CCR2
Compare Logic
putchr() das UART-Senderegister mit Bytes
beschrieben werden, die dann eine entsprechende Modulierung erfahren..
60
Abb.(4.10): FSK-Modulator
P1.3
Input
Funktionsblöcke der Software
UART-Signal
P1.3 Interrupt
1
0
1
1
0
P1.7 Output
t
CCR2 Compare-Interrupt
Abb.(4.11): UART- und P1.7-Modulator-Ausgangssignal
4.2.2. V.21 FSK-Demodulator
Abbildung (4.12) eine kleine Auswahl an Möglichkeiten zur Demodulation eines FSKSignals.
analoge
Filterung
AD-Wandlung
Software zur
Ampl.auswertung
AD-Wandlung
digitale
Filterung
Software zur
Ampl.auswertung
AD-Wandlung
FFT
2 x Goertzel
Comparator
PeriodendauerMessung
0...1
Abb.(4.12): Demodulationsarten
Der Weg über analoge Filterung und anschließende Amplitudenbewertung mittels ADWandlung wurde verworfen, da der Hardware-Aufwand zu umfangreich erschien und zudem
in diesem Projekt die Aufgabe bestand, mit möglichst wenig Hardware auszukommen.
Simulationen mit der Software Matlab/Simulink haben ergeben, dass die Realisierung von
DSP-typischen digitalen Filter-Algorithmen zu viel Rechenzeit beanspruchen würden, sodass
61
Funktionsblöcke der Software
es möglicherweise zu Problemen bei der Implementierung der höheren Protokoll-Schichten
kommen würde. Deshalb wurde in diesem Projekt ein etwas unkonventioneller Lösungsweg
bei
der
Realisierung
der
Demodulation des FSK-Signals
gegangen.
Mit
integrierten
Hilfe
des
MSP430F149
Comparator_A-Moduls
(s.
Abbildung 4.13)) werden die
Nulldurchgänge
der
FSK-
Schwingung erkannt und anschließend
aus
den
Zeit-
punkten der Nulldurch-gänge
die Periodendauer des Signals
bestimmt. Das in Kapitel 3
Abschnitt 3 beschriebene auf-
Abb.(4.13): Comparator_A Blockschaltbild
bereitete Empfangssignal wird
über den Eingangspin P2.3 auf den nicht-invertierenden Eingang des Comparator_A
geschaltet. An den invertierenden Comparator_A Eingang wird per Software-Initialisierung
eine interne Referenzspannung gelegt, die der halben Betriebsspannung entspricht. Da das
Empfangssignal durch die in Kapitel 3 Abschnitt 3 beschriebene OPV-Schaltung mit einem
Gleichspannungs-Offset der
halben
Comparator Eingangs- & A usgangssignal @980Hz
Betriebsspannung
3
chen die Flankenwechsel am
U/V
überlagert wurde, entspre-
1
Ausgang des Comparator_A
0
genau den Nulldurchgängen
des
empfangenen
Signals.
Abbildung
0
FSK-Signal
zu-
sammensetzt, zusammen mit
der Referenzspannung und
dem
Comparator_A
1
2
2.5
3
x 10
-3
3
2
1
0
0
0.5
Aus-
gangssignal, dargestellt in-
1.5
t/s
Comparator Eingangs- & A usgangssignal @1180Hz
(4.14)
U/V
das
0.5
FSK-
zeigt die Signale aus denen
sich
2
1
1.5
t/s
2
2.5
3
x 10
Abb.(4.14): Comparator_A Eingans- und Ausgangssignale
62
-3
Funktionsblöcke der Software
nerhalb der Bitzeit. Dabei handelt es sich im oberen Diagramm um ein Wechselsignal mit der
Frequenz 980Hz (binär 1) und im unteren Diagramm um ein Signal mit der Frequenz 1180Hz
(binär 0).
Das Comparator_A Ausgangssignal kann intern auf den Eingang des CCR1 Capture-Moduls
geschaltet werden (s. Abbildung (4.7) und Abbildung (4.13)). Dadurch kann mit jeder Flanke
des Comparator_A Ausgangssignals der CCR1 Capture-Interrupt generiert werden.
Abbildung (4.15) zeigt den Programmablaufplan der CCR1 Capture-Interrupt-Routine. Die
Routine berechnet
Comparator_A
aus zwei korrespondierenden
Ausgangssignals
und
entscheidet
Flanken
die
anschließend,
Periodendauer des
ob
die
berechnete
Periodendauer mit einer
der erwarteten Perioden-
CCR1
Capture-Interrupt
Service Routine
Zeitdifferenz zur
vorangegangenen
low-high-Flanke
berechnen
nein
Zeitdifferenz zur
vorangegangenen
high-low-Flanke
berechnen
ja
high-low-Flanke?
dauern
(Perioden
für
980Hz
oder
1180Hz)
übereinstimmt.
Entspre-
chend wird dann entweder
die Variable zeros, für
Entspricht
Zeitdifferenz
Periodendauer von
1180Hz?
ja
Zähler zeros
inkrementieren
eine erkannte 0-Signalperiode, oder die Variable
nein
ones, für eine erkannte 1Zähler ones
inkrementieren
ja
Entspricht
Zeitdifferenz
Periodendauer von
980Hz?
nein
Signalperiode,
um
erhöht.
Perioden-
Die
dauern werden durch 16-
Return from Interrupt
Bit Werte repräsentiert,
Abb.(4.15): CCR1 Capture-Interrupt-Routine
die
einem
Zählerwert
Timer_A
entsprechen
und sich aus der Taktfrequenz des Timer_A nach folgender Formel berechnen lassen.
Zählerwert =
eins
Timer _ A Zählfreque nz
Signalfreq uenz
63
Gl. (4.2)
Funktionsblöcke der Software
Tabelle (4.2) enthält die Zählerwerte für die erwarteten charakteristischen Frequenzen im
Kanal Nr.1 bei einer Timer_A Zählfrequenz von 7,3728MHz.
Signalfrequenz
Zählerwert
980Hz
7523
1180Hz
6248
Tab.(4.2): Signalfrequenzen und korrespondierende Zählerwerte
Da die real berechneten Werte wohl kaum exakt mit den theoretischen Werten in Tabelle (4.2)
übereinstimmen werden und zusätzlich vom V.21-Standard eine Demodulator-Toleranz von
±12Hz gefordert wird, ist in der CCR1 Interrupt-Routine bei der Periodendauer-Bewertung
ein Toleranzfenster eingebaut. Der Toleranz-Rahmen lässt sich mittels der Konstanten
CHN1_MARGIN einstellen und ist in der Software auf 500 Zählerwerte festgelegt. Damit
ergeben sich die in Tabelle (4.3) zusammengestellten Toleranzbereiche für die FrequenzDetektion innerhalb der CCR1 Capture-Interrupt-Routine.
charakteristische Frequenzen
Toleranzbereich
binär 0
1180Hz
1093Hz - 1283Hz
binär 1
980Hz
919Hz – 1050Hz
Tab.(4.3): Toleranzbereich für charakteristische Frequenzen bei der Detektion
Aus Abbildung (4.14) ist zu erkennen, dass für ein Signal mit 980Hz innerhalb der Bitzeit
fünf Signalperioden erkannt werden können und für ein Signal mit 1180Hz sechs
Signalperioden. Um nun aus den erkannten Signalperioden wieder ein Datenbyte zu erhalten,
wird mit dem noch zur Verfügung stehenden CCR0 Compare-Interrupt ein Bitzähler
realisiert. Nach sechs erkannten 0-Signalperioden, es wird davon ausgegangen, dass es sich
dabei um ein Startbit handelt, wird der Bitzähler gestartet. Nach sechs 0-Signalperioden ist
mittlerweile auch die Bitzeit für das vermeintliche Startbit vergangen. Der Bitzähler generiert
dann neun mal hintereinander im Bitzeittakt den CCR0 Compare-Interrupt. Abbildung (4.16)
zeigt den Programmablaufplan der Interrupt-Routine. Die Routine entscheidet dann darüber,
ob in der vergangenen Bitzeit mehr 0 oder 1 Signalperioden erkannt wurden, durch Vergleich
der Zählerstände von zeros und ones. Entsprechend wird der Pegel am Ausgangspin P1.2
auf logisch 0 oder 1 gesetzt. Anschließend werden die Variablen ones und zeros auf 0
64
Funktionsblöcke der Software
zurückgesetzt. Dadurch entsteht am Ausgangspin P1.2 ein zeitdiskretes Ausgangssignal im
Bittakt, das hardwaremäßig auf den Eingangspin des UART-Moduls geschaltet ist.
CCR0
Compare-Interrupt
Service Routine
BitCounter
inkrementieren
ja
CCR0 Compare-Interrupt
deaktivieren
BitCounter = 9?
nein
P1.2 Output auf
Low-Pegel
zurücksetzen
nein
ones > zeros?
ja
P1.2 Output auf
High-Pegel
setzen
Return from Interrupt
Abb.(4.16): CCR0 Compare-Interrupt-Routine
Abbildung (4.17) stellt das Zusammenspiel der an der Demodulation beteiligten HardwareModule dar.
MSP430F149
UART
Receive Logic
UART Rx
Input
Timer_A CCR0
Compare Interrupt
Timer_A CCR1
Capture Logic
P2.3
Input
Comparator_A
Abb.(4.17): FSK-Demodulator
65
P1.2
Output
Funktionsblöcke der Software
Abbildung (4.18) zeigt den realisierten MSP430F149 Modulator und Demodulator noch
einmal im Zusammenhang.
MSP430F149
UART Tx
Output
P1.3
Input
P1.7
Output
Transmit Buffer
Receive Buffer
FSK-Modulator
FSK-Demodulator
UART
Transmit Logic
UART
Receive Logic
P1.3
Interrupt Routine
Timer_A CCR0
Compare Interrupt
BitFreq
Timer_A CCR1
Capture Logic
UART Rx
Input
P1.2
Output
P2.3
Input
Timer_A CCR2
Compare Logic
Comparator_A
Abb.(4.18): Modulator und Demodulator
Es wird ersichtlich, dass das UART-Modul die Schnittstelle zur höher liegenden
Kommunikations-Protokoll-Schicht darstellt. Dieses Konzept lässt sich damit begründen, dass
das PPP-Software-Modul ursprünglich so konzipiert wurde, dass es die serielle RS232Schnittstelle zur Kommunikation mit einem externen Modem nutzt und die RS232Schnittstelle mit dem UART-Modul realisiert wurde. Damit kann das PPP-Modul, ohne
Veränderung, mit einem externe oder integriertem Soft-Modem eingesetzt werden.
Mit der Funktion SetupFSKModem() wird der Demodulator initialisiert und mit
StartFSKDemodulator() gestartet.
66
Funktionsblöcke der Software
4.3. V.21 Negotiation-Handshake
Zwischen Rufannahme und dem eigentlichen Datentransfer nach V.21-Standard müssen sich
beide Modems der Kommunikationspartner auf einen gemeinsamen Modulations-Standard
einigen. Dies erfolgt im sog. Negotiation-Handshake. Die Soft-Modem-Applikation
implementiert ausschließlich den V.21-Standard. Das Modem am anderen Ende der
Telefonleitung wird aber sicherlich mehrere Standards beherrschen und dementsprechend
muss dem Modem mitgeteilt werden, dass von der Soft-Modem-Applikation eine
Kommunikation nach V.21-Standard gewünscht wird. Der V.21-Standard definiert keinen
eigenen Negotiation-Handshake. Man behilft sich deshalb durch einen Blick in den V.22oder V.25-Standard. Abbildung (4.20) zeigt die zeitliche Abfolge des HandshakeMechanismus aus Sicht der Soft-Modem-Applikation.
Rufannahme
Antwort-Ton
2100Hz
Ring-Detektion
2150ms
3300ms
Senden binärer 1en
1650Hz
75ms
155ms
Daten
600ms
Abb.(4.20): V.21 Negotiation-Handshake
Nach der Rufannahme herrscht zuerst für 2150ms Ruhe auf der Leitung, davon stammen noch
2 Sekunden vom Ruferkennungs-Algorithmus, die restlichen 150ms, sowie alle weiteren
Zeitabschnitte werden vom CCR0 Compare-Interrupt gesteuert, der zu gegebenem Zeitpunkt
eine Zustands-Änderung der Variablen HandshakeStateMachine, innerhalb des
Handshake-Algorithmus veranlasst. Die Ruhepause ist dafür gedacht, dass den DAAs in
beiden Modems genügend Zeit zur Verfügung steht, den Übergang in den Rufszustand
vollkommen abzuschließen. Nach der Ruhepause sendet die Soft-Modem-Baugruppe für
3300ms einen 2100Hz Antwort-Ton an das rufende Modem. Die Erzeugung des 2100Hz
Antwort-Ton erfolgt durch Aufruf der Funktion StartAnswerSequence(), indem der
Modulator gestartet und die Variable BitFreq mit dem entsprechenden Wert für 2100Hz
initialisiert wird. Nach 3300ms erfolgt der Aufruf der Funktion StopAnswerSequence()
und es herrscht für weitere 75ms wieder Ruhe auf der Leitung. Anschließend wird wieder der
Modulator, diesmal mit der Funktion StartFSKModulator() gestartet und die SoftModem-Applikation sendet binäre 1en, im Kanal Nr.2 in Form eines Signals mit der
konstanten Frequenz von 1650Hz, an das rufende Modem. Ebenfalls zu diesem Zeitpunkt
erfolgt das Starten des Demodulators mit der Funktion StartFSKDemodulator(). Der
67
t
Funktionsblöcke der Software
folgende Zeitabschnitt ist mit keiner konkreten Zeitdauer beziffert. Das rufende Modem hat
nun Zeit zu erkennen, dass ihm der V.21-Standard als Kommunikations-Protokoll angeboten
wird. Sobald das rufende Modem den V.21-Standard erkannt hat, beginnt es ebenfalls binäre
1en, im Kanal Nr.1 in Form eines Signals mit der konstanten Frequenz von 980Hz, an die
Soft-Modem-Baugruppe zu senden. Die Soft-Modem-Applikation muss nun für 155ms die
binären 1en im Kanal Nr.1 erkennen. Die Erkennung erfolgt im Rahmen der CCR1 CaptureInterrupt-Routine durch Zählen von 1-Signalperioden. In die Zeit von 155ms passen knapp
152 Signalperioden bei einer Frequenz von 980Hz. Da die Capture-Routine aber auf jeden
Nulldurchgang des Empfangsignals reagiert, werden innerhalb von 155ms doppelt so viele
Signalperioden erkannt. Es werden also mit der Variablen EdgeCounter 300
Signalperioden gezählt, bis der Negotiation-Handshake in die nächste Phase übergeht. Die
Anzahl der zu zählenden Signalperioden lässt sich mit der Konstanten DetectTime_Chn1
variieren. In der nächsten Phase wartet die Soft-Modem-Applikation noch weitere 600ms bis
dann anschließend der Transfer von Daten beginnen kann.
Die Einbindung des V.21-Moduls in ein Anwender-Programm erfolgt über die beiden
Funktionen ModemInit() und modem(). Abbildung (4.21) zeigt schematisch die
Einbindung des V.21-Moduls in ein Anwender-Programm. Dabei steuert die Routine
modem() den Zustand der Modembaugruppe und
muss zyklisch vom Hauptprogramm aufgerufen
ModemInit()
werden. Der aktuelle Modem-Zustand wird in der
globalen
modem()
Variablen
ModemStateMachine
gespeichert. Bei Programmstart befindet sich das
Modem im Zustand RingDetection. Sobald ein Ruf
sonstiges
Anwenderprogramm
entgegen genommen und das Flag OFF_HOOK
gesetzt
sonstiges
Anwenderprogramm
Abb.(4.21): Verwendung des V.21-Moduls
wurde,
beschriebenen
erfolgt
die
Modulator-
Initialisierung
und
der
Demodulator-
Mechanismen. Anschließend wechselt das Modem
in den Zustand AnsweringHandshake. In diesem
Zustand findet der Negotiation-Handshake statt.
Nachdem der Handshake-Mechanismus abgeschlossen ist, nimmt das Modem den DataModeZustand ein. Im diesem Zustand wird fortwährend kontrolliert, ob ein Empfangssignal
vorhanden ist. Dies geschieht mit Hilfe des OFF_HOOK-Flags. Mit jeder erkannten
Signalperiode durch die CCR1 Capture-Interrupt-Routine wird gleichzeitig das OFF_HOOKFlag gesetzt. Im DataMode-Zustand wird bei jedem Aufruf der Routine modem() das Flag
68
Funktionsblöcke der Software
zurückgesetzt. Beim Ausbleiben des Empfangsignals erfolgt kein erneutes Setzen des Flags
und
jeder
Aufruf
der
Routine
modem()
hat
eine
Erhöhung
des
Zählers
Off_Hook_TimeOut_cntr zur Folge. Nachdem der Zähler einen bestimmten Wert
erreicht hat, ist sichergestellt, dass kein Empfangssignal mehr verfügbar ist und
dementsprechend wird die Modem-Verbindung getrennt und die Software neu initialisiert.
Abbildung (4.22) zeigt die Zustände des Modem in Form eines Phasen-Diagramms.
ja
RingDetection
OFF_HOOK?
nein
AnsweringHandshake
nein
OnesDetected?
ja
ja
nein
OFF_HOOK?
DataMode
Abb.(4.22): Modem-Zustände und Übergangsbedingungen
69
Funktionsblöcke der Software
4.4 PPP im Server-Betrieb
Die Implementierung des PPP erfolgt durch das Software-Modul ppp.c und dessen HeaderDatei ppp.h. Der Empfangs-Interrupt des UART-Empfangsregisters und das UARTSenderegister stellen die unmittelbare Schnittstelle zwischen dem Senden und Empfangen von
Bytes nach V.21-Modulations-Standard und der PPP-Schicht dar.
Es soll nun zuerst ein Blick auf den Empfangspfad gerichtet werden. Innerhalb des UARTEmpfangsinterrupts wird die Funktion ppp_RXroutine() aufgerufen. Die Funktion
ppp_RXroutine()
realisiert
das
organisierte
Speichern
von
Datenpaketen
im
Empfangspuffer RXBuffer, mit Hilfe der Struktur-Variablen BufferTable. Die Variable
BufferTable entspricht einer Tabelle mit MaxDataPackets Zeilen, bei der jede Zeile aus
zwei Zellen besteht. Die erste Zelle ist vom Typ unsigned char* und die zweite Zelle vom
Typ unsigned int. Damit lassen sich MaxDataPackets Datenpakete im Empfangspuffer für
die spätere Auswertung adressieren. Eine Zeile der Variable BufferTable wird
dementsprechend mit Startadresse und Byte-Anzahl eines empfangenen Datenpakets
beschrieben. Abbildung (4.23) soll diesen Sachverhalt an einem kleinen Beispiel
veranschaulichen.
RXBuffer[ ]
address
BufferTable[3]
unsigned char*
unsigned int
1
36
37
42
79
33
content
1
0x03
2
0xFF
... ...
36
0x56
37
0x21
... ...
78
0x5A
79
0xC0
... ...
111
0xB9
112
0xAB
... ...
Abb.(4.23): Organisation des Empfangspuffers
Zum zyklischen Beschreiben der einzelnen Tabellenzeilen dient die Index-Variable
TableIndex.
Abbildung
(4.24)
zeigt
den
Programmablaufplan
der
Funktion
ppp_RXroutine(). Der Zeiger pRXBuffer dient zum Adressieren der Speicherzellen
des Empfangspuffer. Die Routine unterscheidet, ob eine Flag-Sequenz, ein Control-EscapeByte oder ein beliebiges Datenbyte empfangen wurde. Flag-Sequenzen und Control-Escape70
Funktionsblöcke der Software
Bytes werden nicht im Empfangspuffer gespeichert, sodass ausschließlich Nutzdaten und FCS
im Empfangspuffer vorliegen. Sollte es während des Empfangs eines Datenpakets zum
Puffer-Überlauf kommen, werden die bereits empfangenen Datenbytes an den Anfang des
Empfangspuffers kopiert und anschließend mit der Beschreibung des Puffers fort gefahren.
„Start Flag Sequenz“
aktuelle Adresse auf die pRXBuffer
zeigt in BufferTable[TableIndex]
speichern
empfangenes Byte
nein
ja
Flag Sequenz?
mit TableIndex nächste Tabellenzeile
indizieren
RXBufferSize = 0
RXpackets inkrementieren
RXBufferSize = 0?
ja
nein
„End Flag Sequenz“
Anzahl empfangener Datenbytes
(RXBufferSize) in
BufferTable[TableIndex] speichern
ja
Control-Escape?
FRX_CE Flag setzen
nein
ja
Empfangenes Byte mit 0x20
exklusiv-oder Verknüpfen und
FRX_CE zurücksetzen
FRX_CE gesetzt?
nein
empfangenes Byte auf die Adresse auf
die pRXBuffer zeigt speichern und
Zeiger pRXBuffer inkementieren
nein
ja
Pufferüberlauf?
pRXBuffer und
BufferTable[TableIndex] mit
Startadresse des Puffers
beschreiben
nein
RXBufferSize > 120
bereits empfangene Bytes des
Datenpakets an den Anfang des
Puffers kopieren
ja
RXBufferSize = 0
Return from Subroutine
Abb.(4.24): Programmablaufplan von ppp_RXroutine()
71
Funktionsblöcke der Software
Diese Vorgehensweise kommt nicht zum Einsatz, wenn bei einem Überlauf bereits mehr als
120Bytes eines einzigen Datenpakets empfangen wurden. Die Implementierung erwartet
Datenpaket mit einer maximalen Gesamtlänge von ca. 100Bytes, bei einem Datenpaket, dass
bereits die Anzahl von 120Bytes überschritten hat, kann es sich sicher nicht um ein Paket
handeln, dass für die Applikation von Interesse ist. Die Software wechselt also unbeirrt zum
Anfang des Empfangspuffer und setzt dort mit dem Beschreiben fort. Bei der Berechnung der
FSC wird daraufhin ein Fehler auftreten und das „zu große“ Datenpaket verworfen. Nachdem
ein komplettes Datenpaket empfangen wurde, wird die Variable RXpackets um eins erhöht.
Damit wird der Routine ppp_sdu(), die vom Hauptprogramm zyklisch aufgerufen werden
muss, mitgeteilt, dass mindestens ein Datenpaket im Empfangspuffer zur Auswertung bereit
liegt.
Die Funktion ppp_sdu() implementiert die Establish-, Network- und Terminate-Phase des
PPP und muss vom übergeordneten Hauptprogramm zyklisch aufgerufen werden. Die aktuelle
Phase des PPP, sowie die Zustände des LCP und IPCP stehen über die globalen Variablen
PPPphase, LCPAutomaton und IPCPAutomaton jederzeit für die Anwendung zur
Verfügung. Abbildung (4.25) stellt den Programmablaufplan für die Funktion dar. Die
Terminate-Phase dient lediglich zur Neuinitialisierung des PPP-Stacks. Das PPP befindet sich
nach dem Programmstart oder einer Neuinitialisierung in der Establish-Phase. Solange sich
das LCP nicht im Opened-Zustand befindet bleibt PPP in der Establish-Phase und es wird die
Funktion ProcessLCP() aufgerufen. ProcessLCP() implementiert den OptionNegotiation-Automat für das LCP. Anschließend wird kontrolliert, ob Datenpakete im
Empfangspuffer zur Auswertung bereit liegen. Sollte dies der Fall sein (RXpackets > 0),
wird die Funktion EvalRXpacket() aufgerufen, die dann das zuletzt empfangene
Datenpaket auswertet. Auf EvalRXpacket() wird weiter unten noch detaillierter
eingegangen. Das Auswerten eines Datenpakets sollte jedoch zum Auftreten eines Ereignisses
führen, das dann in der Variablen Event genauer spezifiziert ist. Beim nächsten Durchlauf
von ppp_sdu() führt das aufgetretene Ereignis dann eventuell zu Zustandsübergängen und
zum Versenden von Datenpaketen innerhalb der Routine ProcessLCP(). Die Routine
EvalRXpacket() liefert zudem in der globalen Variablen ProtocolType den
Protokoll-Typ, der im zuletzt ausgewerteten PPP-Datenpaket transportiert wurde. In der
Establish-Phase sind nur LCP-Datenpakete erlaubt. Sollte es sich im letzten Datenpaket um
einen anderen Protokoll-Typ gehandelt haben, wird kein Ereignis generiert. Sobald LCP den
Opened-Zustand eingenommen hat, wird der IPCP Option-Negotiation-Automat entsprechend
initialisiert und es erfolgt der Übergang in die Network-Phase.
72
Funktionsblöcke der Software
IPCPAutomaton = Starting
PPPphase = Network
Event = Up
PPPphase
ja
ja
Establish?
LCPAutomaton =
Opened?
nein
ProcessLCP()
nein
nein
RXpackets > 0?
ja
EvalRXpacket()
ProtocolType =
LCP?
nein
Event = NONE
ja
ja
Network?
nein
ProcessIPCP()
RXpackets > 0?
ja
nein
EvalRXpacket()
ProtocolType =
LCP?
nein
ja
ja
Event = RCR?
PPPphase = Establish
IPCPAutomaton = Initial
nein
ja
Event = RTR?
PPPphase = Terminate
nein
Event = NONE
ProcessLCP()
ja
Terminate?
ppp_Init()
nein
Return from Subroutine
Abb.(4.25): Programmablaufplan von ppp_sdu()
73
Funktionsblöcke der Software
Die Behandlung der Network-Phase gestaltet sich ähnlich wie die der Establish-Phase. Der
Aufruf von ProcessIPCP() implementiert den Option-Negotiation-Automat für IPCP.
Anschließend wird wieder kontrolliert, ob Datenpakete zur Auswertung bereit stehen. In der
Network-Phase wird jedoch zusätzlich die Verarbeitung von LCP-Datenpaketen erlaubt.
Dementsprechend wird beim Empfang eines LCP-Pakets die Routine ProcessLCP()
aufgerufen. Der Empfang eines LCP-Configure-Request führt zum Übergang in die EstablishPhase. Ein Terminate-Request zum Übergang in die Terminate-Phase. Im Gegensatz zu
ProcessLCP() verwendet ProcessIPCP() die Funktionen This_Layer_Up() und
This_Layer_Down(). Wenn IPCP den Opened-Zustand einnimmt, wird entsprechend
dem Option-Negotiation-Mechanismus, die Funktion This_Layer_Up() aufgerufen.
Darin wird das Flag PPP_Up im Statusregister PPPstatus gesetzt. Damit wird den höheren
Protokoll-Schichten angezeigt, dass die PPP-Schicht für die Kommunikation zur Verfügung
steht. Die Funktion This_Layer_Down() setzt das Flag PPP_Up wieder zurück. Die
PPP-Schicht steht dann nicht mehr
für die höheren Protokoll-Schichten
zur Verfügung.
FCS berechnen
Wie bereits oben beschrieben dient
ja
die Routine EvalRXpacket()
nein
FCS korrekt?
zum Auswerten und ProtokollProtokoll-Typ bestimmen
Multiplexen
Datenpaketen.
ProtocolType =
LCP?
ja
von
empfangenen
Abbildung
(4.26)
soll den Programmablaufplan der
EvalLCPpacket()
Routine
veranschaulichen.
Die
Routine
liest
der
nein
ProtocolType =
IPCP?
ja
mit
Hilfe
Variablen ReadTableIndex den
EvalIPCPpacket()
letzten
nein
Tabellen-Eintrag
aus
BufferTable und beginnt die
ja
ProtocolType = IP?
Service-Access-Point für IP initialisieren
ppp_RXpacket, ppp_RXpacketSize
FCS des Datenpakets zu berechnen.
Eine
nein
falsche
FCS
führt
zum
Verwerfen des Datenpakets. Sollte
RXpackets
dekrementieren
die FCS des Datenpakets korrekt
sein wird zuerst der Protokoll-Typ
Return from Subroutine
des
Abb.(4.26): Programmablaufplan von EvalRXpacket()
74
Pakets
anschließend
ermittelt,
zur
um
weiteren
Funktionsblöcke der Software
Auswertung
die
entsprechenden
Routinen
EvalLCPpacket()
oder
EvalIPCPpacket() aufzurufen, die dann ein entsprechendes Ereignis erzeugen. Handelt
es sich bei dem empfangenen Datenpaket um ein IP-Datagramm, wird, für den Fall, dass sich
sowohl LCP als auch IPCP im Opened-Zustand befinden, der Zeiger ppp_RXpacket auf
den Anfang des IP-Pakets initialisiert und in der Variablen ppp_RXpacketSize die
Anzahl der Bytes, die das IP-Datagramm umfasst, gespeichert. Zusätzlich wird das Flag
RXData_Available im Statusregister PPPstatus gesetzt, um dem TCP/IP-Stack
anzuzeigen, dass IP-Daten empfangen wurden und bereit stehen. ppp_RXpacket und
ppp_RXpacketSize stellen damit den Service-Access-Point (SAP) der PPP-Schicht für
den TCP/IP-Stack dar.
Sämtliche Funktionen, die das Versenden eines Datenpakets zur Folge haben, entsprechen den
bereits oben beschriebenen Aktion des Option-Negotiation-Automat und werden aufgrund
eines aufgetretenen Ereignisses von den Routinen ProcessLCP() und ProcessIPCP()
aufgerufen. Alle diese Funktionen beschreiben zuerst den Sendepuffer (TXBuffer) mit
einem
entsprechenden
Datenpaket
und
greifen
dann
auf
die
Funktion
TransmitTXBuffer() zurück. Der Routine TransmitTXBuffer() wird jeweils ein
Zeiger auf den Anfang des Datenpakets und die Länge des Datenpakets in Byte übergeben.
Anschließend berechnet die Routine die zugehörige FCS und speichert diese im Sendepuffer,
am Ende des Datenpakets ab. Danach erfolgt das Byteweise Versenden des Datenpakets mit
Hilfe der Funktion putchr(). Dabei wird jedes einzelne Byte entsprechend der ACCM des
Kommunikations-Partners überprüft und gegebenenfalls eine Maskierung mittels ControlEscape-Byte vorgenommen.
Sämtliche Option-Negotiation-Mechnismen die zum erneuten Senden von Datenpaketen
führen oder Timout-Ereignisse verursachen wurden in dieser Lösung nicht implementiert. Der
PPP-Stack verlässt sich auf die PPP-Implementierung des Kommunikations-Partners, die bei
Bedarf ein nicht-beantwortetes Datenpaket erneut sendet oder die Verbindung vorzeitig
beendet.
Zum Versenden von IP-Datagrammen stellt das PPP-Modul dem TCP/IP-Stack die beiden
Funktionen ppp_TransmitFrame1() und ppp_TransmitFrame2() zur Verfügung.
Die beiden Routinen sind von ihrer Funktion her identisch. Der TCP/IP-Stack arbeitet jedoch
mit zwei getrennten Sendpuffern (TxFrame1 und TxFrame2) und deshalb wird für jeden
Puffer eine eigene Sendefunktion bereit gestellt. Die Funktionen bestücken das, im jeweiligen
Sendepuffer liegende, IP-Datagramm mit den notwendigen PPP-Header-Informationen und
75
Funktionsblöcke der Software
greifen dann wiederum auf die Funktion TransmitTXBuffer() zurück. Abbildung (4.27)
zeigt das Pufferkonzept für PPP und TCP/IP-Stack.
TxFrame1 = TXBuffer
(Pufferung kompletter PPP-Datenrahmen inklusive
gekapselter LCP-, IPCP- und TCP/IP-Datenrahmen)
TxFrame2 = TXBuffer_2
(Pufferung kompletter PPP-Datenrahmen die TCP/IPNICHT-Datenrahmen sowie ICMP-Daten kapseln)
RXBuffer
(Ablage kompletter empfangener PPP-Datenrahmen, wird
ähnlich einem Ringspeicher verwendet)
Abb.(4.27): Pufferkonzept
4.5. Maßnahmen zur Anpassung des TCP/IP-Stacks an das PPP
Der „easyWeb“-TCP/IP-Stack wurde an folgenden Punkten verändert und an die neuen
Protokoll-Strukturen auf der Netzwerk-Schicht angepasst:
•
Verzicht auf das Ethernet-Modul cs8900.c und cs8900.h und Ersatz sämtlicher
Funktionen, die das TCP/IP-Modul ursprünglich genutzt hat durch Funktionen, die
von der PPP-Schnittstelle bereit gestellt werden
•
Entfernen sämtlicher Algorithmen und Funktionen des Address-Resolution-Protokolls
(ARP), sowie aller Code-Zeilen die Ethernet-Header-Informationen und MACAdressen behandeln
•
Realisierung des Taktgenerators für die „Initiale Sequenznummer“, sowie die
Inkrementierung des Registers TCPTimer mittels Watchdog-Timer IntervallInterrupt.
Anpassung
(Verlängerung)
Übertragungsrate
76
der
Timeout-Zeiten
an
die
geringe
Funktionsblöcke der Software
Die
ausschlaggebenden
Veränderungen
wurden
hauptsächlich
an
der
Funktion
DoNetworkStuff() vorgenommen. Die beiden Routinen SendFrame1() und
SendFrame2() werden komplett von den PPP-Routinen ppp_TransmitFrame1() und
ppp_TransmitFrame2()
ersetzt.
Es
muss
weiterhin
kein
Speicherplatz
im
Ethernetcontroller angefordert werden. Durch Aufruf der Funktion ppp_Available()
wird lediglich kontrolliert, ob die PPP-Verbindung für die Datenübermittlung zur Verfügung
steht.
Da bei einer PPP-Verbindung
keine
Broadcast-Adressierung
verwendet
wird,
entfällt
das
Demultiplexing von empfange-
Frame empfangen?
ppp_DataAvailable()
ja
ProcessEthIAFrame()
nen Datenpaketen. Im Falle eines
nein
empfangenen
IP-Datagramms
wird stets die EreignisbehandTimer-Event
aufgetreten?
lungs-Funktion
ProcessEthIAFrame()
aufgerufen.
Abbildung
ja
Retransmission oder Timeout-Fehler
handhaben, Verbindung beenden
nein
(4.28)
zeigt den überarbeiteten Pro-
Zustand der TCPStateMachine
entsprechend globaler Flags ändern
grammablaufplan der Routine
angelehnt an die Darstellung in
[D&E].
Die
Routinen
TxFrame2-Puffer
senden?
ja
ppp_TransmitFrame2(TxFrame2Size)
ProcessEthIAFrame(),
nein
ProcessICMPFrame()
und
ProcessTCPFrame() wurden
so angepasst, dass anstelle der
TxFrame1-Puffer
senden?
Auslese-Funktionen des Ethernet-Moduls
nun
ppp_RXpacket
der
und
ja
ppp_TransmitFrame1(TxFrame1Size)
nein
Zeiger
die
Variable ppp_RXpacketSize
Abb.(4.28): Routine DoNetworkStuff()
zum Auswerten eines empfangenen IP-Datagramms verwendet werden.
Mit den beschriebenen Veränderungen ist der TCP/IP-Stack einsatzbereit zur Anwendung auf
einer seriellen Punkt-zu-Punkt-Verbindung.
77
Funktionsblöcke der Software
4.6. Embedded Soft-Modem Applikation
Das Aufsetzen der Webserver-Applikation
erfolgt
nach dem gleichen Schema
Systemtaktgeber initialisieren
HardwareInit()
wie in [D&E] ausführlich
beschrieben. Es müssen nur
Modemfunktionen initialisieren
ModemInit()
noch zusätzlich die unteren
Protokoll-Schichten
PPP-Schicht initialisieren
ppp_Init()
und
V.21)
mit
(PPP
in
Hauptprogramm
TCPLowLevelInit()
HTTP-Server Flag-Register initialisieren
TCPLocalPort = TCP_PORT_HTTP
bunden
das
einge-
werden.
Dies
geschieht durch zyklisches
modem()
Aufrufen
der
Funktionen
und
modem()
ppp_sdu()
ppp_sdu() in der Hauptprogrammschleife.
nein
bildung (4.29) zeigt den
ppp_Available()?
Programmablaufplan
ja
des
Webserver-
nein
SOCK_ACTIVE?
Ab-
TCPPassiveOpen()
Hauptprogramms.
Nach
Initialisierung der Hardware
ja
und sämtlicher Protokoll-
DoNetworkStuff()
Module implementiert die
HTTPServer()
Abb.(4.29): Webserver-Hauptprogramm
Hauptschleife
alle
be-
schriebenen
Protokoll-
Schichten vom V.21 bis hin
zum HTTP-Server.
Nach der Programmierung des MSP430F149 kann die Baugruppe an eine Telefondose
angeschlossen werden. Ein internet-fähiger PC mit Modem hat nun die Möglichkeit zur SoftModem-Baugruppe eine DFÜ-Verbindung herzustellen. Sobald die Verbindung aufgebaut
wurde, kann der PC-Anwender mit einem Standard-Internet-Browser die dynamische
Webseite (s. Abbildung (4.30)) des integrierten Webservers abrufen.
78
Funktionsblöcke der Software
Abb(4.30): Beispiel-Webseite
Die verwendete Beispiel-Webseite stellt dynamische Inhalte bereit. Das Einfügen der
dynamischen Inhalte in die Webseite wird in [D&E] ausführlich beschrieben. Im konkreten
Fall handelt es sich hierbei um das Ergebnis der Temperaturmessung mittels AD-Wandlung
und Chip-interner Referenzdiode, sowie dem Pegelzustand des Einganspins P6.6.
Die DFÜ-Verbindung zur Soft-Modem-Baugruppe muss von PC-Seite aus getrennt werden.
79
Ressourcen-Untersuchungen und Ausblick
5. Ressourcen-Untersuchungen und Ausblick
Die vorgestellte Embedded Soft-Modem Applikation benötigt bei Compilierung für einen
MSP430F149 folgende Speicherressourcen:
•
ca. 14 KByte Flash EEPROM für den Programmspeicher
•
ca. 1 KByte Flash EEPROM als Konstantenspeicher
•
Ca. 740 Byte RAM, inklusive zweier jeweils 300Byte fassender Sende- und
Empfangspuffer für PPP-Datenrahmen
Bei den vom Controller zur Verfügung stehenden Speicherressourcen von 60 KByte Flash
EEPROM
und
2
KByte
RAM
bleibt
also
noch
viel
Raum
für
zusätzliche
Anwendungsmöglichkeiten. Da die Modem-Funktionalität im Wesentlichen durch InterruptProzesse realisiert wurde, ist der Prozessor nicht komplett ausgelastet und bietet noch Luft für
weitere Anwendungen im Hauptprogramm. Dadurch würde es unter Umständen nur zu einer
zeitlichen Verzögerung bei der Übertragung der Webseite kommen.
Den Hauptanteil der Speicherressourcen benötigt das PPP-Modul. Bei alleiniger Betrachtung
des V.21- und Ruferkenner-Moduls, durch welche die Modem-Funktionalität realisiert wird,
würden bereits ca. 1,7 KByte Flash EEPROM und ca. 30 Byte RAM den Anforderungen
genügen. Wenn es also darum geht nur eine geringe Menge an Daten zu verarbeiten und zu
übertragen, in Form eines benutzerdefinierten Übertragungs-Protokolls, würde bereits ein
wesentlich „kleinerer“ Mikrocontroller die Aufgaben erfüllen können.
Die Diskussion bzgl. der Leistungsaufnahme beim Betrieb der Soft-Modem-Baugruppe stand
in diesem Projekt im Hintergrund, da die Baugruppe problemlos, bei entsprechender
Beschaltung und Einhaltung von Isolations-Vorschriften, aus der Telefonleitung mit
Spannung gespeist werden könnte. Bei einer Betriebsspannung der Baugruppe von 3,3V
benötigt der LITLINK III im off-hook-Zustand 8mA und der MSP430F149 maximal 1mA.
Die Summe der Ströme liegt weit unter dem zugelassenen Wert, der von einem Endgerät an
der Telefonleitung eingehalten werden muss. Wobei es sich hierbei um Maximalwerte
handelt. Die Messung der Leistungsaufnahme des MSP430F149 müsste gemittelt werden, da
der Controller, entsprechend dem Betriebszustand der kompletten Baugruppe, über die meiste
Zeit hinweg wesentlich weniger Strom benötigt. Nur beim gleichzeitigen Empfangen,
Verarbeiten und Senden von Daten steigt die Leistungsaufnahme auf ihren Maximal-Wert.
80
Ressourcen-Untersuchungen und Ausblick
An dieser Stelle sollen nun noch ein paar Ideen für die Weiterentwicklung und Verbesserung
der Applikation angesprochen werden.
Timer
Die vorgestellte Software-Lösung verwendet zum leichteren Verständnis zwei
unterschiedliche Timer-Module des MSP430F149 (Timer_A und Watchdog Timer). Es wäre
jedoch durchaus denkbar, sämtliche Timer-Funktionen allein mit dem Timer_A-Modul des
MSP430F149 zu realisieren.
Externe Quarze
Es wäre zu Überlegen, ob der MSP430F149 nicht gänzlich auf den externen HF-Quarz mit
7,3728MHz verzichten könnte und für die Realisierung der zeitkritischen Funktionen
(Modulation, Demodulation und Ruferkennung) der 32kHz-Quarz ausreichen würde.
UART-Modul
Die Funktionen des UART könnten komplett in Software realisiert werden. Gerade im
Empfangsweg stellt die Generierung eines zeitdiskreten UART-Empfangssignals mittels
CCR0 Compare-Interrupt einen zusätzlichen Mehraufwand dar. Diese Vorgehensweise wurde
nur aus Symmetriegründen zum leichteren Verständnis der Schnittstelle zur PPP-Schicht
gewählt.
Analoge Filterung
Durch geschickte Programmierung der Periodendauer-Messung mittels CCR1 CaptureInterrupt könnte auf das Tiefpass-Filter im Empfangssignalweg verzichtet werden und eine
Art softwaremäßige Filterung realisiert werden, die das gleiche Ergebnis liefert.
Direct Acces Arrangement
Gerade in Betracht der geringen realisierten Übertragungsrate von 300bit/s, würde es
wirtschaftlich Sinn machen eine andere DAA als den vorgestellten LITLINK III Chip zu
verwenden, die z.B. auf Datenraten bis 2400bit/s beschränkt ist.
81
Ressourcen-Untersuchungen und Ausblick
Kombination mit Ethernet (Gateway)
Durch Erweiterung des TCP/IP-Stacks und Kombination der Modem-Funktionalität mit
Ethernet könnte die Soft-Modem-Baugruppe als Schnittstelle zu einem auf Ethernet
basierenden IP-Netzwerk dienen.
V.22 Modemstandard
Es wäre zu Überlegen und zu Testen, ob sich die vom V.22-Standard geforderte 4Phasenumtastung ebenfalls durch die Umtastung von Rechtecksignalen realisieren lassen und
umgekehrt die Phasenlage des Empfangssignals mit Hilfe des Comparator erkannt und
demoduliert werden könnte. Weiterhin steht noch der AD-Wandler des MSP430F149
unbenutzt zur Verfügung, mit Hilfe dessen zusätzlich eine Amplitudenauswertung des
Empfangsignal stattfinden könnte und Überlegungen zur Demodulation eines QuadraturAmplituden modulierten Signals ins Leben ruft.
Soft-Modem als Internet-Client
Der Betrieb der Soft-Modem-Baugruppe in die „andere Richtung“. Die Applikation könnte
sich selbständig mit einem Internet-Service-Provider verbinden und dann Dienste wie FTP
und EMAIL nutzen. Die Generierung von DTMF-Tönen für den Wahlvorgang ließe sich
durch eine Pulsweiten-Modulation realisieren. Hierzu wurden bereits Untersuchungen im
Rahmen diese Projekts unternommen. Zusätzlich müsste die analoge Signalaufbereitung im
Empfangsweg eine Änderung erfahren, da die Filter-Stufe für den Empfang von Frequenzen
im Kanal Nr.1 dimensioniert wurde. Als Internet-Client würde die Soft-Modem-Baugruppe
aber im Kanal Nr.1 senden und entsprechend im Kanal Nr.2 empfangen.
82
Zusammenfassung
6. Zusammenfassung
Diese Arbeit hat gezeigt, dass sich grundlegende Funktionen einer klassischen ModemBaugruppe durch Programmierung geeigneter Embedded Software mit dem MSP430F149
Mikrocontroller ersetzen lassen und darauf aufbauend eine komplette Embedded Internet
Applikation mit minimalem Hardware-Aufwand entwickelt werden kann.
Im Bereich der digitalen Modulation bzw. Demodulation wurden dabei relativ
unkonventionelle Wege beschritten, die sicherlich nicht ganz unproblematisch erscheinen
mögen, in Bezug auf Zulassungsvorschriften im öffentlichen Telefonnetz und Schutz vor
Fehlern bei der Übertragung von Daten. Jedoch eröffnen sich dadurch ganz neue
Ansatzpunkte bei der Realisierung einer Modem-Funktionalität auf Soft-Modem-Basis.
Der „easyWeb“-TCP/IP-Stack wurde erfolgreich an die Kommunikation über eine serielle
Punkt-zu-Punkt-Verbindung angepasst und ermöglicht damit die Realisierung einer
Webserver-Anwendung, die im Rahmen der Soft-Modem-Applikation oder gegebenenfalls
auch mit einem externen Modem über das öffentliche Telefonnetz betrieben werden kann.
Damit können Informationen Mikrocontroller-basierter Geräte über das Telefonnetz zur
Verfügung gestellt und per Standard-Verbindung und Standard-Software abgerufen werden.
Die Machbarkeitsstudie, als welche diese Diplomarbeit betrachtet werden darf, konnte also
mit einem positiven Ergebnis abgeschlossen werden und bietet zugleich ein ganzes Paket an
Ideen zur sinnvollen Weiterentwicklung.
83
Literatur- und Quellenverzeichnis
A
Literatur- und Quellenverzeichnis
[CCITT]
G. Schenck
CCITT-Empfehlungen der V-Serie und der X-Serie 6., erweiterte
Auflage, Band 1.1 Datenübertragung über das Telefonnetz V.1-V.33,
Heidelberg 1990, ISBN 3-7685-1190-1
[FHL]
Dipl.-Ing. F. Schubert
Technologien der Text- und Datendienste, Basiskenntnisse für das
5.Semester, Vorlesungsbegleitende Arbeitsblätter, Deutsche Telekom
AG Fachhochschule Leipzig 2003
[TCP/IP]
Hein, Mathias:
TCP/IP Internet-Protokolle im professionellen Einsatz;
4. Aufl. – Bonn [u.a.] : Internat. Thomson Publishing., 1998
Design&Elektronik: Embedded Internet Extraheft
Design&Elektronik, September 2001
[D&E]
[RFC791]
Postel, Jon: Internet Protocol (IP). RFC-791,
September 1981
[RFC793]
Postel, Jon: Transmission Control Protocol. RFC-793,
September 1981
[RFC1171]
Perkins, D.: PPP for the Transmission of Multi-Protocol Datagramms
Over Point-to-Point Links. RFC-1171
Juli 1990
[RFC1172]
Perkins, D.; Hobby, R.: PPP Initial Configuration Options. RFC-1172
Juli 1990
[RFC1661]
Simpson, W.: Point-to-Point Protocol. RFC-1661
Juli 1994
[RFC1662]
Simpson, W.: PPP in HDLC-like Framing. RFC-1662
Juli 1994
[RFC1332]
McGregor, G.: PPP Internet Protocol Control Protocol. RFC-1332
Mai 1992
[RFC1334]
Lloyd, B.; Simpson, W.: PPP Authentication Protocols. RFC-1334
Oktober 1992
Texas Instruments: MSP430x13x, MSP430x14x Mixed Signal
Microcontroller Datasheet. Texas Instruments Inc. Juli 2000
[MSP430DS]
[MSP430UG]
Texas Instruments: MSP430x1xx Family User’s Guide. Texas
Instruments Inc. August 2000
[LITELINK]
Clare/Ixys, CPC5620/CPC5621 LITELINK III Phone Line Interface IC
(DAA) Datasheet, Clare Inc. 2002
[LLEVAL]
Clare/Ixys, CPC5621-EVAL-RDL/CPC5621-EVAL-CDL LITELINK III
Evaluation-Board User’s Guide, Clare Inc. 2002
84
Literatur- und Quellenverzeichnis
[ATI]
Klaus Wiedorn, Analoges Telefon-Interface, Embedded Internet 2003
Handout Juni 2003
[ELECD]
Jeff Sorensen (TDK Semiconductor), Direct-Access Arrangements Are
Crucial To Successful Embedded-Modem Designs, Electronic Design
20.August 2001
Reynolds, J.; Postel, J.: Assigned Numbers. RFC-1700
Oktober 1994
[RFC1700]
85
Schaltplan und Bestückungsliste
B
Schaltplan und Bestückungsliste
86
Schaltplan und Bestückungsliste
87