DE69732751T2

DE69732751T2 - DECT/GSM-externes Weiterreicher

Info

Publication number: DE69732751T2
Application number: DE69732751T
Authority: DE
Inventors: Tuomo Sipila; Markus Tapani Hakaste
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 1996-10-11
Filing date: 1997-10-10
Publication date: 2006-01-12
Anticipated expiration: 2017-10-11
Also published as: GB2318258B; EP0836338B1; JP3438001B2; US6134439A; JPH10191425A; GB9621247D0; US6278880B1; DE69732751D1; EP0836338A3; GB9721569D0; GB2318258A; ES2239347T3; EP0836338A2

Description

Diese Erfindung betrifft das externe Handover während des DECT/GSM-Interworkings und das Verhindern von Datenverlust während des externen Handovers.
1 veranschaulicht das Interworking zweier DECT-Kommunikationssysteme (DECT = Digital European Cordless Telephone) mit einem GSM-Kommunikationssystem (GSM = Global System for Mobiles). Die DECT-Systeme umfassen je eine Feststation 1, 2. Jede Feststation umfasst eine Clustersteuerungs-Feststation (Cluster Control Fixed Part, CCFP) 3, 4 und Funkfeststationen (RFP) 5, 6, 7, 8, von denen jede mit der jeweiligen CCFP verbunden ist. Die CCFPs sind über eine A-Schnittstelle 9 mit einer GSM-Mobildienstzentrale (MSC) 10 verbunden. DECT-Endgerät-(PP, Portable Part) -Handapparate 11, 12 können drahtlos mit den RFPs kommunizieren, wenn sie sich in Reichweite befinden. Wenn sich ein Endgerät aus dem Bereich einer RFP (der „alten" RFP) in den Bereich einer anderen RFP (der „neuen" RFP) bewegt, besteht die Notwendigkeit des Handovers der drahtlosen Kommunikation mit dem Endgerät. Geschieht das Handover zwischen zwei RFPs, die der Steuerung durch dieselbe CCFP unterliegen (Handover 13 in 1), kann dies vom DECT-System anhand einer Prozedur vorgenommen werden, die als internes Handover bezeichnet wird, wobei Daten vor Verlust geschützt sind. Geschieht das Handover zwischen zwei RFPs, die der Steuerung durch unterschiedliche CCFP unterliegen, die durch die MSC verankert sind (Handover 14 in 1), ist die Prozedur als externes Handover bekannt.
Das weiter unten aufgeführte Dokument [14] definiert die Implementierung von Trägerdiensten. Dies nimmt als Grundlage, dass in der DECT/GSM-Schnittstelle das GSM-Fehlerkorrekturprotokoll REP in der Interworking Unit (IWU) der DECT-Feststation endet und die DECT- Luftschnittstelle (basierend auf dem C-Datenprofil) ihre eigene Fehlerkorrektur über die DECT-Luftschnittstelle bereitstellt, indem das Protokoll der MAC-Schicht (MAC = Medium Access Control, Medienzugangssteuerung) neu gesendet wird und indem die DLC (Data Link Control, Datenverbindungssteuerung) das LAPU-Protokoll neu sendet. Dieses Protokollmodell ist in 2 veranschaulicht, wobei Block 15 das DECT-Endgerät repräsentiert, Block 16 die DECT-Feststation repräsentiert und Block 17 die GSM-Mobilvermittlungsstellen-Interworking Unit repräsentiert. Somit funktionieren in dieser Standard-Implementierung die RLP- und LAPU-Protokolle unabhängig; das RLP-Protokoll arbeitet über die A-Schnittstelle (18 in 2) zwischen GSM und DECT, und das LAPU-Protokoll arbeitet über die DECT-Luftschnittstelle (19 in 2). Das LAPU-Protokoll läuft über die gesamte Strecke von der CCFP zum PP, weshalb sowohl die DECT-MAC-Schicht-Fehlerkorrektur als auch das LAPU sich um Situationen kümmern kann, in denen Daten beim internen DECT-Handover möglicherweise verloren gegangen sind. Die Fehlerkorrektur im Falle eines externen Handovers ist jedoch unklar.
In diesem Dokument wird das Protokoll, das für die Bereitstellung nicht transparenten GSM-Dienstes benutzt wird, als das GSM-A-Schnittstellen-LAP-Protokoll bezeichnet. Ein aktuelles Beispiel dieses Protokolls ist RLP, zukünftig konnten aber andere Protokolle (wie z.B. V.120) benutzt werden. In einigen Situationen in diesem Dokument ist RLP als ein Beispiel benutzt worden.
In der Vergangenheit haben Spezifikationen für DECT/GSM-Interworking externes Handover nicht berücksichtigt. Es besteht jedoch die Möglichkeit, dass Daten verloren gehen könnten, wenn externes Handover stattfindet, während Daten übertragen werden. Dies ist so, weil die RLP- und LAPU-Systeme unabhängig funktionieren. Die MSC empfängt eine (von der DECT-Feststation gesendete) Bestätigung eines gesendeten Datenrahmens, bevor der Rahmen sein endgültiges Ziel (das Endgerät) erreicht hat. Ist externes Handover erfolgt und der Rahmen an die falsche CCFP gesendet worden, kann er nicht an das Endgerät gesendet werden.
3 veranschaulicht die Situation, in der in einem Datendienst – in dem das System Signale transportiert, die Daten repräsentieren, die dem System in einer digitalen Form von einem Benutzer des DECT-Endgerätes bereitgestellt worden sind oder die vom System jenem Benutzer in einer digitalen Form bereitzustellen sind – Datenrahmen (I-Rahmen) in die mobil beendete Richtung übertragen werden (d.h., in der Richtung von der MSC zur FP) und anschließend, unter Benutzung des DECT-LAPU, über die DECT-Luftschnittstelle. Der erste I-Rahmen wird bei 20 von der Interworkingfunktion der MSC 21 an die erste Feststation (FP 1) 22 übergeben. FP 1 bestätigt den empfangenen Rahmen bei 23 und leitet die Daten anschließend bei 24 mithilfe von DECT-LAPU an das Endgerät 25 weiter. Das PP bestätigt die Daten bei 26. Wenn dann ein externes Handover des PP von FP 1 an FP 2 (bei 27) erfolgt, bestätigt die FP 1 (bei 28) der MSC den nächsten Rahmen, kann diesen aber nicht an das PP senden. Und FP 2 kann die Daten nicht neu an das PP senden, weil sie nicht über den Rahmen verfügt. Darüber hinaus ist in der IWF das GSM-LAP-Sendefenster nach der erfolgreichen I-Rahmen-Bestätigung inkrementiert worden, und die Daten sind in den RLP-Puffern verloren gegangen.
4 veranschaulicht die Situation bei vom Mobilbereich ausgehender Übertragung. In diesem Fall kann kein Datenverlust auftreten, weil das PP die Daten (bei 29) neu an die FP 2 senden kann. Jedoch muss das PP in der Lage sein, dieselbe LAPU-Verbindung über die neue U-Ebenen-Verbindung fortzusetzen, weshalb die Interworking Unit von FP 2 in der Lage sein muss, den Status der Statusvariablen (der Sende- und Empfangszähler) der alten Verbindung zu kennen.
Somit stößt man auf das größere Problem, wenn während externen Handovers Daten in Richtung des Endgerätes (PP) gesendet werden.
Ein Ziel dieser Erfindung ist es, dieses Problem anzugehen.
Gemäß der vorliegenden Erfindung wird unter einem Aspekt ein Verfahren zum Steuern des Handovers eines DECT-Endgerätes von einer ersten DECT-Feststation an eine zweite DECT-Feststation während der Bereitstellung eines Datendienstes bereitgestellt, wobei beide Feststationen mit einer GSM-Mobilvermittlungsstelle kommunizieren, wobei das Verfahren umfasst, dass die erste Feststation erkennt, dass das Handover angefordert worden ist, und in Reaktion darauf die Verbindung zwischen sich und der Mobilvermittlungsstelle so steuert, dass die Bestätigung von Daten an die Mobilvermittlungsstelle verhindert wird, die nicht vom Endgerät von der ersten Feststation empfangen werden.
Vorzugsweise kann die erste Feststation erkennen, dass Handover angefordert wurde, indem sie eine Anforderung vom Endgerät (z.B. ein (MM-INFO-REQUEST)) oder einen Befehl von der Mobilvermittlungsstelle erkennt (z.B. ein (HANDOVER COMMAND)).
Beim Handover des Endgerätes an die zweite Feststation führt die zweite Feststation vorzugsweise ein Zurücksetzen der Verbindung mit der Mobilvermittlungsstelle durch. Dieses Zurücksetzen setzt vorzugsweise die RLP-Entität über die Verbindung zurück. Die Verbindung wird in geeigneter Weise mittels einer SABM-Meldung zurückgesetzt.
In Reaktion auf das Erkennen, dass das Handover angefordert worden ist, kontrolliert die erste Feststation vorzugsweise den Datenfluss der Verbindung zwischen sich und der Mobilvermittlungsstelle. Die erste Feststation kann den Fluss der U-Ebene bzw. des RLP bzw. des Datenflusses kontrollieren. Die Datenflusskontrolle kann mithilfe von Bit X ausgeübt werden. Beim Handover des Endgerätes an die zweite Feststation gibt die zweite Feststation vorzugsweise die Datenflusskontrolle über die Verbindung mit der Mobilvermittlungsstelle frei.
Vorzugsweise nimmt eine Interworking Unit der Feststation die Modifikation der Kontrolle vor.
Wie weiter unten ausführlicher beschrieben, benutzt ein bevorzugtes Verfahren einen oder mehrere der folgenden Schritte:

– Beim Erkennen der Prozedur „Externes Handover" kontrolliert die Interworking Unit der „alten" Feststation den Fluss des RLP bzw. den Datenfluss mithilfe von Bit X und sendet die übrigen Daten in ihren Puffern über die LAPU-Verbindung an das Endgerät;
– anschließend können die Daten in Richtung der MSC gesendet werden, solang die U-Ebenen-Verbindung vorhanden ist, um die FP 1-IWU-Puffer zu leeren;
– in der „neuen" Feststations-IWU wird eine neue RLP-Entität erstellt, wenn die Verbindung zwischen ihr und der MSC eingerichtet ist, nachdem die DECT-U-Ebenen-LAPU-Verbindung initiiert worden ist;
– bei Einrichtung der Verbindung zwischen der „neuen" Feststations-IWU und der MSC-IWF setzt die „neue" FP-IWU die RLP-Verbindung durch Ausgeben eines SABM-Befehls zurück und gibt die Datenflusskontrolle frei, wenn diese noch nicht freigegeben worden ist;
– anschließend läuft der Datenverkehr über die „neue" Feststations-IWU normal weiter.

Gemäß der vorliegenden Erfindung wird unter einem zweiten Aspekt ein Verfahren zum Steuern des Handovers eines DECT-Endgerätes von einer ersten DECT-Feststation an eine zweite DECT-Feststation während der Bereitstellung eines Datendienstes bereitgestellt, wobei beide Feststationen mit einer GSM-Mobilvermittlungsstelle kommunizieren, wobei das Verfahren umfasst, dass die erste Feststation Protokollmeldungen zwischen ihrer Verbindung mit dem Endgerät und ihrer Verbindung mit der Mobilvermittlungsstelle gemäß einer vorher festgelegten Abbildung überträgt, um die Bestätigung von Daten an die Mobilvermittlungsstelle zu verhindern, die nicht vom Endgerät von der ersten Feststation empfangen werden.
Vorzugsweise handelt es sich bei der Abbildung um eine Eins-zu-eins-Abbildung zwischen Protokollmeldungen der zwei Verbindungen. Die Abbildung beinhaltet in geeigneter Weise mindestens eine der folgenden Abbildungen:
RECEIVE READY wird abgebildet auf RECEIVE READY;
RECEIVE NOT READY wird abgebildet auf RECEIVE NOT READY;
Datenrahmen (zum Beispiel DECT-I-Rahmen) wird abgebildet auf Datenrahmen (zum Beispiel RLP-I+S-Rahmen).
Bei den Protokollmeldungen der Verbindung zwischen der ersten Feststation und dem Endgerät handelt es sich vorzugsweise um DECT-LAPU-Protokollmeldungen. Bei den Protokollmeldungen der Verbindung zwischen der ersten Feststation und der Mobilvermittlungsstelle handelt es sich vorzugsweise um GSM-LAP-Protokollmeldungen, zum Beispiel RLP-Meldungen.
Bei dem Protokoll kann es sich um das GSM-LAP-Protokoll handeln, in welchem Fall das Endgerät vorzugsweise Mittel zum Codieren und Decodieren von Signalen gemäß dem Protokoll beinhaltet. Das Protokoll kann in geeigneter Weise die Unterteilung von Daten in Rahmen bereitstellen, und jeder dieser Rahmen wird zwischen dem Endgerät und der Feststation in einem einzigen DECT-Datenverbindungs-Steuerrahmen übermittelt.
Bei dem Protokoll kann es sich um das DECT-LAPU-Protokoll handeln, in welchem Fall die Mobilvermittlungsstelle vorzugsweise Mittel zum Codieren und Decodieren von Signalen gemäß dem Protokoll beinhaltet.
Gemäß der vorliegenden Erfindung wird unter einem dritten Aspekt eine erste DECT-Feststation für die Kommunikation mit einem DECT-Endgerät und mit einer GSM-Mobilvermittlungsstelle bereitgestellt, die zum Übergeben beim Durchführen eines Handovers an eine zweite DECT-Feststation in der Lage ist, dadurch gekennzeichnet, dass die erste Feststation in der Lage ist zu erkennen, dass das Handover angefordert worden ist, und in Reaktion darauf die Verbindung zwischen sich und der Mobilvermittlungsstelle so zu steuern, dass die Bestätigung von Daten an die Mobilvermittlungsstelle verhindert wird, die nicht vom Endgerät von der ersten Feststation empfangen werden.
Vorzugsweise beinhaltet die Feststation eine Interworking Unit, die Signale nicht gemäß dem Protokoll codiert oder decodiert. Vorzugsweise durchlaufen die Signale in der Schicht des Protokolls die Feststation unverändert.
Vorzugsweise dienen die Verfahren und das System gemäß der vorliegenden Erfindung dem Vermeiden, Vermindern oder mindestens Hemmen des Verlustes von Daten, wenn externes Handover während der Bereitstellung von Datendiensten für das DECT-Endgerät erfolgt – wenn das Endgerät Signale sendet oder empfängt, die digitale Informationen repräsentieren.
Die vorliegende Erfindung wird jetzt anhand eines Beispiels unter Bezug auf die zugehörigen Zeichnungen beschrieben, wobei
1 das Interworking zweier DECT-Feststationen mit einem GSM-System zeigt,
2 den Protokollstapel für das standardmäßige Interworking von DECT/GSM mit nicht transparenten Trägerdiensten zeigt,
3 die Möglichkeit von Datenverlust veranschaulicht, wenn Rahmen an ein DECT-Endgerät übermittelt werden,
4 die Möglichkeit von Datenverlust veranschaulicht, wenn Rahmen von einem DECT-Endgerät übermittelt werden,
5 einen Protokollstapel für die Situation zeigt, in der das GSM-LAP-Protokoll zum DECT-Endgerät läuft,
6 das Einpassen eines RLP-Rahmens in den FU1-Rahmen des LU1-Dienstes zeigt,
7 das Einpassen eines RLP-Rahmens in den FU6-Rahmen des B-Dienstes unter Auslassen des LU2-CRC-Feldes zeigt,
8 einen Protokollstapel für die Situation einer aktiven Feststations-Interworking Unit zeigt,
9 Datenfluss und Signalisierung für die Situation einer aktiven Feststations-Interworking Unit zeigt,
10 einen Protokollstapel für die Situation einer DECT-GSM-LAP-Protokoll-Abbildung zeigt,
11 Datenfluss und Signalisierung für die Situation des DECT-LAPU/GSM-LAP-Halbinterworkings zeigt,
12 Datenfluss und Signalisierung für die Situation des DECT-LAPU/GSM-LAP-Vollinterworkings zeigt und
13 einen Protokollstapel für die Benutzung der LAPU-Protokolldaten zwischen der GSM-Mobilvermittlungsstelle und dem DECT-Endgerät zeigt.
Das weiter oben beschriebene Problem kann in drei Unterbereiche unterteilt werden:

1. Wie wird das GSM-A-Schnittstellen-LAP- und RLP-Interworking gehandhabt?
2. Wie sollte das LAPU während externen Handovers funktionieren? Sollte es seinen Betrieb über die neue DECT-Luftschnittstellenverbindung fortsetzen, und wie sollte in diesem Fall der LAPU-Status an die neue FP übermittelt werden? Sollte als Alternative ein neues LAPU initialisiert werden?
3. Wie sollte das RLP in der neuen FP (der FP, die das PP empfängt) nach einem externen Handover funktionieren? Sollte das RLP zurückgesetzt werden, oder sollte es versuchen, von der alten Situation aus fortzufahren?

Die Spezifikation in Dokument [5] schränkt das Auftreten externen Handovers nicht ein. Während eines Sprachanruf steht externes Handover in enger Beziehung zur U-Ebenen-Verbindung: Ist die U-Ebene noch nicht verbunden worden, ist das Auftreten externen Handovers nicht wahrscheinlich. Externes Handover kann in unterschiedlichen Phasen eines Anrufs oder Anrufaufbaus auftreten. Es ist spezifiziert worden, dass eine Verbindung zur neuen FP parallel zur alten Verbindung aufgebaut werden muss. Im besten Fall wird die alte Verbindung normal dadurch freigegeben, dass die FP {CC-RELEASE) mit einem Hinweis auf „Extern-Handover-Freigabe" sendet. Es ist jedoch möglich, dass die Verbindung zur alten FP mitten in der Prozedur des externen Handovers unterbrochen wird (z.B. wegen einer schlechten Verbindung), was zu Datenverlust führt. In dieser Situation hat das PP bis zu 5 Sekunden Zeit, ein externes Handover in eine neue FP zu versuchen. Der Aufbau einer Verbindung kann gemäß den Parametern erfolgen, die bereits in der Anrufaufbauphase des ursprünglichen Anrufs empfangen wurden, oder anhand der MM-Prozeduren.
Für externes Handover in einem DECT/GSM-Hybridsystem werden jetzt vier Ansätze beschrieben, wobei das Ziel darin besteht, Datenverluste während eines nicht transparenten Trägerdiensttransfers zu reduzieren.

1. Der Mechanismus des externen Handovers ist transparent unter DECT/GSM ohne FP-Intervention implementiert, und das LAP-Protokoll wird über die A-Schnittstelle benutzt (beispielsweise wird RLP über die gesamte Strecke zum DECT-PP übermittelt). Wenn dann externes Handover erfolgt, kann das A-Schnittstellen-LAP-(RLP)-Neusendeschema automatisch Ende-zu-Ende benutzt werden.
2. Die FP-IWU erkennt eine externe Handoversituation und verhält sich während des Prozesses des externen Handovers insofern anders als normal, als sie der MSC-IWF keine Bestätigung der Sendung des A-Schnittstellen-LAP-Rahmens bereitstellt. Dies kann zu einer Neusendung der Meldungen (Datenrahmen) an die neue FP führen.
3. Die C-Datenprofil-LAPU-Schicht wird von der DECT-Luftschnittstelle benutzt, um die Bestätigungen der A-Schnittstellen-LAP-Schicht abzubilden. Dies führt zu Bestätigungssendungen über die gesamte Strecke zum DECT-PP. Erfolgt externes Handover, kann das RLP-Neusendeschema automatisch genutzt werden.
4. LAPU kann über die gesamte Strecke zur MSC laufen. Dies würde Änderungen in der MSC-IWF und eine Repräsentation einer offenen A-Schnittstelle erfordern.

Der erste Ansatz basiert auf der Idee, dass das GSM-A-Schnittstellen-LAP (zum Beispiel das RLP-Neusendeschema) Ende-zu-Ende zwischen dem PP und der IWF läuft. Dies setzt vollständige Unterstützung des GSM-LAP-(RLP-)-Protokolls im PP voraus. Bei der zweiten und der dritten Lösung verwenden sowohl der DECT- als auch der GSM-Teil der Datenübertragung eigene LAP-Protokolle. In der zweiten Lösung ist eine genaue Abbildung zwischen diesen Protokollen erforderlich. Die vierte Lösung benutzt das DECT-spezifische LAP-Protokoll Ende-zu-Ende, und vollständige Unterstützung des LAPU in der GSM-IWF ist erforderlich.
Die Ansätze werden nun ausführlicher beschrieben.
Ansatz 1: GSM-LAP-Protokoll läuft über die gesamte Strecke zum PP
In diesem Ansatz wird das GSM-LAP-Protokoll, das über die A-Schnittstelle benutzt wird, über die DECT-Luftschnittstelle übermittelt, und die Wiederherstellung fehlerhafter Daten erfolgt Ende-zu-Ende zwischen dem PP und der GSM-IWF. Die allgemeine Anordnung ist in 5 gezeigt. Für die Bereitstellung von (beispielsweise) RLP über die DECT-Luftschnittstelle muss ein Luftschnittstellenprotokoll definiert werden. Ein Beispiel eines derartigen Protokolls wird weiter unten diskutiert. Vorzuziehen ist, dass der zu benutzende Datenrahmen (beispielsweise der RLP-Datenrahmen) exakt in den DLC-Schicht-Rahmen passt, um so das DECT-Luftschnittstellenprotokoll effizienter zu nutzen.
Für das Implementieren dieses Ansatzes gibt es drei Optionen: mithilfe des DLC-LU-Dienstes, mithilfe von DECT-Datenprofilen und mithilfe des DLC-LU7-Dienstes.
DLC-LU1-Dienst
Der DLC-LU1-Dienst mit dem FU1-Rahmen wird für normale Sprachübertragungen benutzt. Er kann jedoch auch für Datenübertragungen benutzt werden. Eine Option ist es, den DLC-LU1-Dienst mit dem nicht geschützten oder ungeschützten Dienst der MAC-Schicht zu benutzen. So werden GSM-Daten ohne Modifikationen durch die DECT-Luftschnittstelle hindurch übertragen.
Werden nicht transparente Daten übertragen, muss der RLP-Rahmen mit einer Länge von 240 bit (30 Byte) in den FU1-Rahmen eingepasst werden. Muss die nicht transparente Natur erhalten bleiben, kann kein Teil des Rahmens abgeschnitten werden: zum Beispiel wird das FCS-Feld zur Fehlererkennung benötigt. Die Netto-Datenrate, die erreicht werden kann, ist in der gleichen Weise wir unter GSM berechnet worden, d.h., bei der Rate handelt es sich um die konkrete Nutzdatenrate, wie in der nachstehenden Tabelle gezeigt. Da der RLP-Rahmen nicht exakt in den FU1-Rahmen passt, müssen am Ende des Rahmens einige Fülloktetts hinzugefügt werden. Ein 240-bit-RLP ist ein Beispiel für RLP-Rahmengröße. Andere Rahmengrößen wie z.B. 476- oder 576-bit-Rahmen dürfen benutzt werden.
6 veranschaulicht den Fall „Vollzeitschlitz/geschützt", in dem ein RLP-Rahmen von 240 bit in einen FU1-Rahmen mit 16 Füllbits eingepasst wird.
Wie die obige Tabelle zeigt, kann das DECT-System mit einem einzigen Zeitschlitz die geforderte minimale GSM-Rate von gegenwärtig 9,6 kbit/s (9,6 Kilobit pro Sekunde) problemlos bereitstellen. es kann sogar für höhere Raten wie z.B. 14,4 kbit/s benutzt werden, weshalb dieser DECT-Interworking-Ansatz für zukünftige GSM-Dienste verwendet werden kann, beispielsweise für GSM-HSCSD- und verbesserte DECT/GSM-Trägerdienste.
Die Datenraten hängen von den Rahmengrößen ab. Der Durchsatz kann durch Zuweisen von mehr Zeitschlitzen gesteigert werden. Werden zusätzliche Zeitschlitze benutzt, ist die Datenrate ein Vielfaches derjenigen, die mit einem Zeitschlitz bereitgestellt wird.
Diese Option weist die folgenden Vorteile auf:

– Einfache Implementierung, insbesondere wenn nicht geschützte einzelne Zeitschlitze benutzt werden und die Luftschnittstellen-Lösung auf der standardmäßigen DECT-Sprachimplementierung mit geringfügigen Änderungen basieren kann.
– Das System basiert grundlegend auf dem GSM-System, während DECT lediglich ein Träger von GSM-Daten ist. Dies ist besonders attraktiv für DECT/GSM-Zweifachmodus-Endgeräte, die die GSM-RLP-Protokollentität benutzen können.

DECT-Datenprofile
Diese Option verwendet die A/B-Datenprofile (siehe Dokumente [19] und [22]) oder das C-Datenprofil (siehe Dokument [20]) mit dem RLP. A/B- und C-Profile benutzen FU6-Rahmen mit Längen- und Sequenzfeldern und dem MAC-Ip-Fehlerkorrekturdienst. Der Dienst fügt am Ende des Pakets ein CRC-Prüffeld von 16 bit hinzu. Beim C-Profil werden zusätzliche zwei Oktetts für Headerinformationen benutzt. Die Größe des FU6-Rahmens beträgt 32 Byte mit 2 Byte Steuerinformationen, es bleiben 20 Byte für die Daten.
Wenn das LU2-Prüfsummenfeld im A/B-Profil nicht am Ende des RLP-Pakets hinzugefügt wird, passt der Rahmen exakt in den FU6-Rahmen. Das Prüfsummenfeld ist nicht notwendig, weil RLP bereits eine Fehlerprüfsequenz enthält. In diesem Fall würde RLP sich um Neusendungen usw. kümmern. Die Situation ist in 7 veranschaulicht. Allerdings ist zu beachten, dass die Nichtbenutzung des DECT-Prüfsummenfeldes die DECT-Standards verletzt.
Die folgende Tabelle gibt Datenraten unter Ausschluss der Modemsignalübertragung (L2RBOP/L2RCOP) und der Header- und FCS-Felder an, also die konkrete Nutzrate.
Wird die FU6-Prüfsumme im Rahmen benutzt, wird der RLP-Rahmen von LU2 in zwei Zeitschlitze segmentiert. Somit werden die ersten 224 bit des RLP-Rahmens im ersten Zeitschlitz gesendet, und die übrigen 16 bit werden im nächsten Zeitschlitz transportiert, wobei der Rest des Rahmens mit Fülldaten gefüllt ist. So werden zum Senden eines einzigen RLP-Rahmens (d.h. von 192 bit Nutzdaten) 20 ms benötigt, was zu einer Datenrate von 9,6 kbit/s führt. Obgleich dies dieselbe wie die GSM-Datenrate ist, nutzt sie die DECT-Luftschnittstelle nicht sehr effizient, da dem Benutzer nur 9,6 kbit/s von einer DECT-Rate von 24 kbit/s zur Verfügung gestellt werden. Dieses Problem kann angegangen werden, indem mehr als ein RLP-Rahmen in den LU2-Dienst abgebildet und auf diese Weise die DECT-Luftschnittstelle besser ausgenutzt wird. Da jedoch die RLP-Rahmen nicht kontinuierlich ankommen, kann die Rate abfallen, und es muss irgendeine Art von Algorithmus definiert werden, um zu verhindern, dass die FP-IWU zu lange auf die ankommenden RLU-Rahmen wartet. Man stößt auf dasselbe Problem, wenn die Rahmentypen FU3, FU4 oder FU5 (siehe Dokument [4]) benutzt werden.
Diese Option weist die folgenden Vorteile auf:

– Die Funkschnittstelle wäre mit anderen DECT-Dateneinrichtungen kompatibel. Dies würde es gestatten, mit der Infrastruktur DECT-Dateneinrichtungen unterschiedlicher Hersteller zu benutzen.
– Das Zweifachmodus-Endgerät könnte als Zugangseinrichtung in andere DECT-Datennetzwerke benutzt werden.

DLC-LU7-Dienst
Bei dieser Option wird der LU7-Dienst (siehe Dokument [4]) für Übertragungen benutzt.
In dem Fall könnten drei 240-bit-RLP-Rahmen exakt in die 72-kbit/s-Rahmenstruktur passen. Dies würde das Maximum von 57,6 kbit/s Nutzrate bieten. Jedoch ist der LU7-Dienst ziemlich kompliziert zu implementieren, er verwendet Doppelzeitschlitze, und seine Effizienz ist nicht nachgewiesen.
Diese Option weist den Vorteil auf, dass das Endgerät ISDN-Kompatibilität zumindest auf U-Ebenen-DLC-Level bereitstellen könnte.
Im Allgemeinen weist der oben beschriebene Ansatz den Vorteil auf, dass RLP- und LAPU-Status in der FP direkt eingehalten werden können. Auch muss das LAPU nicht über die neue DECT-Luftschnittstellen-U-Ebenen-Verbindung laufen. Dieser Ansatz könnte auch nahtloses Handover zwischen DECT- und GSM-Verbindungen unterstützen. Der Nachteil ist, dass das PP voraussetzt, dass ein GSM-spezifisches Protokoll (z.B. RLP) ausgeführt wird, und dass es lediglich für GSM-Zugangs-Trägerdienste benutzt werden kann und für nichts anderes. Wenn jedoch zum Beispiel das V.120-Protokoll über die A-Schnittstelle und außerdem über die DECT-Luftschnittstelle benutzt würde, wäre die Lösung allgemeiner.
Die folgende Tabelle führt die Vor- und Nachteile der unterschiedlichen Optionen kurz auf.
Ansatz 2: Aktive FP-IWU
In diesem Ansatz endet die GSM-LAP-Schicht in der FP-IWU, wie in der aktuellen Spezifikation definiert (siehe Dokument [14]). Die FP-IWU-Funktionalität kümmert sich um eine externe Handover-Situation gemäß einiger spezifischer Regeln, anders ausgedrückt: die FP verhält sich anders als normal, wenn sie bemerkt, dass ein externes Handover im Begriff ist zu geschehen.
Die DECT-LAPU- und GSM-LAP-Protokolle funktionieren weitestmöglich unabhängig; zum Beispiel werden die Bestätigungen des LAPU der DECT-Luftschnittstelle nicht auf das GSM-LAP abgebildet, und die Verbindungsparameter von LAPU und GSM-LAP werden nicht einander entsprechend gesetzt. Somit werden die unabhängigen Verbindungen auf die für die Anforderungen der separaten Datenverbindungen bestmögliche Weise konfiguriert. Dies ist in 8 veranschaulicht.
Eingehende Daten von GSM-LAP werden in den DECT-LAPU-Puffern gepuffert und in Paketen in der Größe von LAPU-Rahmen gesendet. Das gleiche Puffern und Neu-Rahmen erfolgt für Verkehr in der entgegengesetzten Richtung. Wie in den Protokollen (RLP und LAPU) definiert, wird, wenn keine I-Rahmen in den Protokollpuffern auf Sendung warten, ein empfangener I-Rahmen mit dem Rahmen „Receive Ready" (RR) bestätigt. Als Folge davon müssen die Zeitgeber der Protokolle nicht nennenswert justiert werden, weil die Entitäten nicht auf Ende-zu-Ende-Bestätigungen warten müssen.
9 zeigt ein Beispiel für Datenfluss und Signalisierung.
Einige Transferregeln müssen aufgestellt werden. Die FP kann die Einleitung externen Handovers erkennen, wenn sie (MM-INFO-REQUEST} (bei 30 in 9) vom PP empfängt oder beim Empfang des (HANDOVER COMMAND) (bei 31) von der MSC. Spätestens muss die alte FP die Datenübertragungen an die MSC stoppen, wenn die alte Verbindung freigegeben ist.
Wenn die FP bemerkt, dass externes Handover im Begriff ist zu geschehen, stoppt sie die Datenübertragung an die MSC sowie an das PP. Das PP leitet das externe Handover ein und kontrolliert den Datenfluss der U-Ebene. Als Folge davon sendet LAPU Receive Not Ready (RNR) an die andere Peer-Entität, und die FP-IWU leitet das RNR an die MSC-IWF und an die Anwendung am anderen Ende weiter. Somit werden keine weiteren Daten über jene Luftschnittstelle zum PP transportiert.
Tritt eine Verbindungsunterbrechung auf (wenn z.B. das PP aus dem Bereich verschwindet), darf die FP-IWU keine GSM-LAP-Bestätigungen der gesendeten Daten an die MSC senden. Dies führt zu einer Neusendung des/der Datenrahmen durch die GSM-LAP-Schicht-Entität in der GSM-IWF an die mögliche neue FP, wenn der LAP-Zeitgeber abläuft.
Da die RLP-Verbindung nur zwischen der FP und der MSC läuft, muss in einer externen Handover-Situation die RLP-Verbindung neu zwischen der neuen FP und der MSC aufgebaut werden. Da die neue FP-IWU den Status der RLP-Entität in der alten Verbindung nicht kennt, ruft bei einem externen Handover die FP in der alten Verbindung durch Ausgeben der SABM-Meldung ein Zurücksetzen der RLP-Entität auf. (Dies führt zum Zurücksetzen beider RLP-Entitäten). Jedoch gehen einige der RLP-Rahmen in der MSC wegen des Zurücksetzens der RLP-Verbindung verloren. EINE Alternative ist es für die neue FP, zu warten, bis die MSC durch Ausgeben von RR an die neue FP-RLP-Entität eine Prüfpunkt-Wiederherstellung zu dem Zweck aufruft, die Statusinformationen zu empfangen (dies ist, wie in Unterabsatz 5.3.3.2 von GSM 04.22, Dokument [21], beschrieben). Das neue RLP kann dann die RR-Informationen durch Ausgeben eines RR mit einer beliebigen Nummer N(R) beantworten. Dies gibt die Datenflusskontrolle frei, und die Datenübertragung wird fortgesetzt. Jedoch können einige Datenrahmen verloren gegangen oder einige zweimal gesendet worden sein.
Dieser Ansatz erfordert wenig Änderungen am etablierten Ansatz. Allerdings sind die Regeln nicht streng, und es kann noch zum Verlust von Daten kommen, insbesondere im Falle eines RLP-Resets in der RLP-Entität. Somit ist die Datenflusskontrolle der Verbindung vor dem Handover wichtig.
Ansatz 3: Interworking zwischen dem DECT-LAPU- und dem GSM-A-Schnittstellen-LAP-Protokoll
Gemäß diesem Ansatz werden die DECT-LAPU-Schicht-Bestätigungen in die GSM-LAP-Bestätigungen abgebildet. Dadurch laufen diese Bestätigungen Ende-zu-Ende. Mögliche Datenfehler werden als Folge davon durch einen kombinierten Fehlerkorrekturmechanismus von GSM-LAP und DECT-LAPU-Schicht korrigiert. Für dieses Interworking gibt es die zwei Optionen LAP-Voll- und -Halbinterworking, wie weiter unten diskutiert. Der Protokollstapel ist in 10 veranschaulicht.
LAPU/GSM-LAP-Vollinterworking
In dieser Option besteht ein vollständiges Interworking der GSM-LAP-Schicht-Meldungen zur DECT-LAPU-Schicht. Im überwiegenden Teil folgen die LAPU-Entitäten-Funktionen den Prozeduren und Status der GSM-LAP-Schicht, wie in Dokument [21] definiert. Das heißt, dass sich die LAPU-Schicht im PP so weit wie möglich wie die GSM-LAP-Schicht verhält. Der Vorteil dabei ist, dass die LAPU-Entität im PP wie eine Peer-Entität für die RLP-Engine in der GSM-IWF funktioniert und dadurch eine vollständige Ende-zu-Ende-Funktionalität bereitstellt. Jedoch ist es wegen der unterschiedlichen Naturen und Merkmale der LAPU- und GSM-LAP-(RLP-)-Protokolle schwierig, diese Art von System aufzubauen.
11 zeigt ein Beispiel für Datenfluss und Signalisierung.
In diesem System besteht ein vollständiges Interworking von LAPU und RLP und der FP-IWU. In der Anrufeinrichtungsphase werden in der Meldung {CC-SETUP} (bei 32 in 11) die LAPU-Fenstergrößen-, PDU-Längen- und LAPU-Neusendungszeitgeber-Parameter ausgehandelt. Diese Parameter werden mit dem RLP-Interworking ausgerichtet, sodass die PDU-Länge den Wert aufweist, den das LAPU als RLP-Nutzdaten in einem einzelnen LAPU-Rahmen transportieren kann. Die Fenstergröße kann jeden Wert zwischen 1 und 7 annehmen, da das RLP diese Längen unterstützen kann. Der LAPU-Neusendungszeitgeber sollte einen Wert aufweisen, der mindestens gleich dem zur RLP-Verbindungs-Umlaufverzögerung addierten LAPU-Standardwert ist. RLP-XID wird benutzt, um die RLP-Parameter auszuhandeln, damit sie den DECT-Anforderungen entsprechen. Die RLP-Fenstergröße (Parameter k) ist in beiden Richtungen dieselbe wie im LAPU, aber nicht größer als 7, dem Grenzwert des LAPU. Der Werte der Zeitgeber T1 (Bestätigungszeitgeber) und T2 (Wiedergabeverzögerung) werden entsprechend ausgehandelt, um die doppelte Verbindungslänge (LAPU und RLP) zu berücksichtigen.
Die FP-IWU bildet die LAPU- und RLP-Meldungen und -Parameter eins zu eins ab, wie in der nachstehenden Tabelle aufgeführt. Somit transportiert jeder DECT-LAPU-I-Rahmen die Inhalte eines GSM-RLP-I-Rahmens (I+S-Rahmens). Die S- und U-Rahmen werden zwischen dem LAPU und dem RLP abgebildet.
Als eine Folge dieser Funktionalität sind die RLP- und LAPU-Funktionen synchronisiert und in hohem Maße miteinander konsistent, um optimiertes Wiederaufsetzen nach Fehler Ende-zu-Ende bereitzustellen. Wenn ein externes Handover auftritt, setzt die DECT-LLME die alte LAPU-Verbindung über die neue Funkverbindung fort. Das LAPU kann im Verbindungsinitialisisierungsprozess die Werte der alten Verbindung benutzen und die Datenübertragung unverzüglich beginnen. Wenn die Übertragungsverbindung in der neuen FP eingerichtet ist, werden die momentanen Werte der LAPU-Parameter im Parameter «Fenstergröße» der {CC-SETUP)-Meldung (bei 33 in 11) zur neuen FP transportiert. Die neue RLP-Entität in der neuen FP wird mithilfe dieser Werte initialisiert. Die neue RLP kann auch die Parameter durch Ausgeben von XID an die MSC-RLP-Entität neu aushandeln. Wenn die neue RLP-Verbindung eingerichtet worden ist, kann die Datenübertragung fortgesetzt werden, und die RLP-Entität in der neuen FP aktualisiert die RLP-Statusparameters gemäß den empfangenen/gesendeten Rahmen.
LAPU/GSM-LAP-Halbinterworking
In dieser Option werden nur jene GSM-LAP-Schicht-Meldungen abgebildet, die für Bestätigungen benötigt werden, und die Haupt-Funktionalität der LAP-Schicht liegt in der FP. Der Vorteil dabei ist, dass die Implementierung der PP-LAPU relativ einfach bleibt, ohne dass dem Endgerät zu viel Komplexität hinzugefügt wird. In dieser Situation unterhält die FP eine Tabelle, die Informationen über die übertragenen und empfangenen Rahmen in beiden Richtungen enthält und darüber, welcher RLP-Informationsrahmen in welchem LAPU-Rahmen transportiert wurde.
12 gibt ein Beispiel für Datenfluss und Signalisierung.
Es gibt zwei mögliche Modi des Betriebs.
Modus 1
In diesem Fall muss die FP-IWU eine Tabelle unterhalten, die Informationen darüber enthält, welcher RLP-Rahmen bestimmte LAPU-Rahmen-Informationen zur GSM-Seite transportierte, und auf die Bestätigung dessen von der MSC-IWF warten. Nach Empfang der Bestätigung für den Rahmen kann die FP-IWU aus der Tabelle die Bestätigung herleiten, die zum PP zu senden ist. Die Tabelle enthält daher Abbildungen zwischen LAPU-N(R)- und GSM-LAP-N(R)-Variablen und LAPU-N(S)- und GSM-LAP-N(S)-Variablen. Die Abbildung muss nicht eins zu eins sein: Wenn das LAPU gleichzeitig die Dateninhalte mehr als eines RLP-Rahmens transportieren kann, kann eine LAPU-Antwort mehr als einen RLP-Rahmen bestätigen.
Wenn das PP externes Handover initiiert, unterliegt die alte LAPU-Verbindung der Datenflusskontrolle. Danach richtet die LLME im PP die neue LAPU-Verbindung gemäß der alten Verbindungsvariablen (N(R) und N(S)) ein, oder die Verbindung wird zurückgesetzt. Eine der DECT-Meldungen kann benutzt werden, um die RLP-Statusinformationen über die DECT-Luftschnittstelle an die neue FP zu transportieren. Der Status kann auch durch die alte FP und über die MSC an die („neue") Ziel-FP übertragen werden, direkt bevor die alte Verbindung der Datenflusskontrolle unterliegt. Beispielsweise können entweder die DECT-Anrufsteuerungs-Meldungen oder die DECT-LAPU-SAPI 3-Verbindung benutzt werden, um die Informationen zu transportieren. Die LAPU-SAPI 3-Verbindung kann kodiert werden, um die RLP/LAPU-Statusinformationen anzugeben. Eine weitere Option ist es, die RLP-Entität zurückzusetzen, zum Beispiel durch Ausgeben einer SABM-Meldung (die zum Zurücksetzen der beiden RLP-Entitäten führt) oder dadurch, dass die alte RLP in FP 1 in den ADM-Modus übergeht (Zurücksetzen) oder die neue FP eine Prüfpunkt-Wiederherstellung in der neuen FP-RLP-Entität zu dem Zweck aufruft, die Statusinformationen von der MSC zu empfangen, wie im Unterabsatz 5.3.3.2 von GSM 04.22 (Dokument [21]) beschrieben.
Danach wird die Datenflusskontrolle freigegeben, und die Datenübertragung wird fortgesetzt, und die RLP/LAPU-Referenztabelle wird wieder aufgebaut.
Modus 2
In diesem Fall werden die RLP- und LAPU-Verbindungsmodi ausgewählt, sodass die Sende- und Empfangsrahmenzählung einfach zwischen den RLP- und LAPU-Variablen berechnet werden kann. Die Fenstergröße des RLP sollte dieselbe wie im LAPU sein, und das LAPU sollte einen Satz von RLP-Dateninhalten in einem einzelnen LAPU-Rahmen senden. Durch diese Vorschrift kann die FP-IWU die RLP-Rahmen-Empfangs- und Sendenummern vom entsprechenden LAPU herleiten. Diese Berechnungsvorschriften können danach im externen Handover benutzt werden, wenn die neue FP nicht wissen kann, welche Rahmen gegenüber der MSC zu bestätigen sind. Somit kann nach externem Handover der DECT-LAPU-Protokollstatus als eine Grundlage für die Berechnungen zum Herleiten benutzt werden, welche RLP-Rahmen Bestätigungen benötigen. In dieser Situation wird keine Datenflusskontrolle benötigt, weil die neue FP die bereits empfangenen Rahmen berechnen und sie bestätigen oder eine Neusendung anfordern kann.
In allen Fällen wird die XID-Meldung des RLP benutzt, um die RLP-Parameter auszuhandeln (Fenstergröße, Bestätigungszeitgeber, Neusendungsversuche und Wiedergabeverzögerung), die für die LAPU-Anforderungen zu optimieren sind.
Von den zwei oben diskutierten Optionen ist die Vollinterworking-Lösung die beste zur Vermeidung von Datenverlust, ihre LAPU-Implementierung kann jedoch besonderen Aufwand erfordern, der möglicherweise nicht immer den DECT-Standards genügt. Die Abbildung der Protokollrahmenzähler ist keine elegante Lösung, weil die LAP-Protokolle gewöhnlich unabhängig funktionieren und die Rahmenzählung eine protokollinterne Angelegenheit ist. Die „Halbinterworking"-Option nimmt dies nicht vollständig vor, aber die FP-IWU muss eine Tabelle unterhalten, wobei die entsprechenden Bestätigungen über dieselben Verbindungen erhalten werden.
Ansatz 4: Zwischen der MSC und den DECT-Endgeräten wird LAPU benutzt
In dieser Lösung läuft das DECT-LAPU-Protokoll über die gesamte Strecke zur GSM-MSC-IWF. Dies würde größere Änderungen im GSM-Standard erfordern. Weil das LAPU-Protokoll DECT-spezifisch ist, sind V.120 oder HDLC geeignetere Kandidaten für ein generisches DECT/GSM-Protokoll.
Der Protokollstapel für diesen Ansatz ist in 13 veranschaulicht.
Referenzliste
Die nachstehende Liste enthält Einzelheiten zu den Dokumenten, auf die weiter oben verwiesen wird, sowie weitere relevante Dokumente. Die Dokumente ETS 300 175 1 bis 8 [1] bis [8] und die ETRs [9] bis [11] enthalten weitere Informationen zum DECT-System. Die Dokumente [12] bis [18] enthalten weitere Informationen zum DECT/GSM-Interworking. Die Dokumente [19] bis [22] enthalten weitere Informationen zu den DECT-Datenprofilen.

[1] ETS 300 175-1 Edition 2: „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications (DECT) Common Interface Part 1: Overview".
[2] ETS 300 175-2 Edition 2: „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications (DECT) Common Interface Part 2: Physical layer".
[3] ETS 300 175-3 Edition 2: „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications (DECT) Common Interface Part 3: Medium access control layer".
[4] ETS 300 175-4 Edition 2: „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications (DECT) Common Interface Part 4: Data link control layer".
[5] ETS 300 175-5 Edition 2: „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications (DECT) Common Interface Part 5: Network layer".
[6] ETS 300 175-6 Edition 2: „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications (DECT) Common Interface Part 6: Identities and addressing".
[7] ETS 300 175-7 Edition 2: „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications (DECT) Common Interface Part 7: Security features".
[8] ETS 300 175-8 Edition 2: „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications (DECT) Common Interface Part 8: Speech coding and transmission".
[9] ETR 015: Digital European Cordless Telecommunications Reference document".
[10] ETR 043: „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications (DECT) Common Interface Services and Facilities requirements specification".
[11] ETR 056: Digital European Cordless Telecommunications System description document".
[12] ETS 300 370 Edition 2: „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications/Global System for Mobile Communications (DECT/GSM) Interworking profile, Access and mapping (Protocol/procedure description for 3.1 KHz speech service.
[13] prETS 300 499: „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications/Global System for Mobile Communications (DECT/GSM) Interworking profile GSM MSC – DECT FP Fixed interconnection".
[14] DE/RES-03071 (September 1995): „Radio Equipment and Systems; Digital European Cordless Telecommunications (DECT)/Global System for Mobile Communications (DECT/GSM) inter-working profile, Implementation of bearer services".
[15] (DE/RES-03049) prETS 300 499 (August 1995): „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications/Global System for Mobile Communications (DECT/GSM) interworking profile, GSM MSC – DECT-FP Fixed Interconnection".
[16] (DE/RES-03050) (June 1995): „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications/Global System for Mobile Communications (DECT/GSM) interworking profile, GSM Phase 2 supplementary services implementation".
[17] (DE/RES-03057): „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications/Global System for Mobile Communications (DECT/GSM) Interworking profile, Implementation of Short message services, point to point and Cell broadcast".
[18] (DE/RES-03058): „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications/Global System for Mobile Communications (DECT/GSM) Interworking profile, Implementation of facsimile group 3".
[19] prETS 300 651: „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications (DECT) Data services profile, Generic data link service, Service Type C, Class 2".
[20] prETS 300 435: „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications (DECT) Data Services Profile Base Standard including inter-working to connectionless networks (service types A and B, Class 1)".
GSM 04.22: „Radio Link Protocol (RLP) for data and telematic services on the Mobile Station – Base- Station System (MS – BSS) interface and the Base Station System – Mobile services Switching Centre (BSS – MSC) interface".
[22] prETS 300 701: „Radio Equipment and Systems (RES); Digital European Cordless Telecommunications (DECT) Data Services Profile Generic Frame relay service with mobility (service types A and B, Class 2)".

All diese Dokumente sind durch Verweis in ihrer Gesamtheit hierin einbezogen.
Die vorliegende Erfindung schließt jedwede neuartigen Merkmale oder Kombinationen von Merkmalen, die hierin entweder explizit oder implizit beschrieben sind, oder jedwede Verallgemeinerungen derselben ungeachtet dessen mit ein, ob es die beanspruchte Erfindung betrifft oder nicht oder eines oder alle der angesprochenen Probleme mildert oder nicht. In Anbetracht der voranstehenden Beschreibung ist es für einen Fachmann offensichtlich, dass innerhalb des Umfangs der Erfindung mannigfaltige Modifikationen vorgenommen werden können.

Claims

Verfahren zum Steuern des Handovers eines DECT-Endgerätes (11; PP) von einer ersten DECT-Feststation (1; FP 1) an eine zweite DECT-Feststation (2; FP 2) während der Bereitstellung eines Datendienstes, wobei beide Feststationen mit einer GSM-Mobilvermittlungsstelle (10) kommunizieren, dadurch gekennzeichnet, dass die erste Feststation (1; FP 1) erkennt, dass das Handover angefordert worden ist, und in Reaktion darauf die Verbindung zwischen sich und der Mobilvermittlungsstelle (10) so steuert, dass die Bestätigung von Daten an die Mobilvermittlungsstelle (10) verhindert wird, die nicht vom Endgerät (11; PP) von der ersten Feststation (1; FP 1) empfangen werden.
Verfahren nach Anspruch 1, gekennzeichnet durch das Bereitstellen einer Datendienst-Kommunikation zwischen der Mobilvermittlungsstelle (10) und dem Endgerät (11; PP) über die gesamte Strecke mit einem gemeinsamen Protokoll derart, dass die Mobilvermittlungsstelle (10) eine Bestätigung nur von Datenpaketen erhält, die vom Endgerät (11; PP) empfangen werden.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass es sich bei dem Protokoll um das GSM-LAP-Protokoll oder das DECT-LAPU-Protokoll handelt.
Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass das Protokoll die Unterteilung von Daten in Rahmen bereitstellt und jeder dieser Rahmen zwischen dem Endgerät (11; PP) und der Feststation in einem einzigen DECT-Datenverbindungs-Steuerrahmen übermittelt wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Steuern der Verbindung zwischen der ersten Feststation (1; FP 1) und der Mobilvermittlungsstelle (10) daraus besteht, dass die erste Feststation (1; FP 1) ihre Steuerung der Verbindung so modifiziert, dass die Bestätigung von Daten an die Mobilvermittlungsstelle (10) verhindert wird, die nicht vom Endgerät (11; PP) von der ersten Feststation (1; FP 1) empfangen werden.
Verfahren nach Anspruch 1 oder 5, dadurch gekennzeichnet, dass beim Handover des Endgerätes (11; PP) an die zweite Feststation (2; FP 2) die zweite Feststation (2; FP 2) ein Zurücksetzen der Verbindung mit der Mobilvermittlungsstelle (10) durchführt.
Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass in Reaktion auf das Erkennen, dass das Handover angefordert worden ist, die erste Feststation (1: FP 1) Datenflusskontrolle über die Verbindung zwischen sich und der Mobilvermittlungsstelle (10) ausübt.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass beim Handover des Endgerätes (11; PP) an die zweite Feststation (2; FP 2) die zweite Feststation (2; FP 2) die Datenflusskontrolle über die Verbindung mit der Mobilvermittlungsstelle (10) freigibt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Daten mindestens einen Rahmen umfassen.
Verfahren nach Anspruch 1, 5 oder 6, dadurch gekennzeichnet, dass das Steuern der Verbindung daraus besteht, dass die erste Feststation (1; FP 1) Protokollmeldungen zwischen ihrer Verbindung mit dem Endgerät (11; PP) und ihrer Verbindung mit der Mobilvermittlungsstelle (10) gemäß einer vorher festgelegten Abbildung überträgt, um die Bestätigung von Daten an die Mobilvermittlungsstelle (10) zu verhindern, die nicht vom Endgerät (11; PP) von der ersten Feststation (1; FP 1) empfangen werden.
Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass es sich bei der Abbildung um eine Eins-zu-eins-Abbildung zwischen Protokollmeldungen der zwei Verbindungen handelt.
Verfahren nach Anspruch 10 oder 11, dadurch gekennzeichnet, dass es sich bei den Protokollmeldungen der Verbindung zwischen der ersten Feststation (1; FP 1) und dem Endgerät (11; PP) um DECT-LAPU-Protokollmeldungen handelt.
Verfahren nach Anspruch 10 bis 12, dadurch gekennzeichnet, dass es sich bei den Protokollmeldungen der Verbindung zwischen der ersten Feststation (1; FP 1) und der Mobilvermittlungsstelle (10) um GSM-LAP-Protokollmeldungen handelt.
Erste DECT-Feststation (1; FP 1) für die Kommunikation mit einem DECT-Endgerät (11: PP) und mit einer GSM-Mobilvermittlungsstelle (10), die in der Lage ist, ein Handover zu einer zweiten DECT-Feststation durchzuführen, dadurch gekennzeichnet, dass die erste Feststation (1; FP 1) in der Lage ist zu erkennen, dass das Handover angefordert worden ist, und in Reaktion darauf die Verbindung zwischen sich und der Mobilvermittlungsstelle (10) so zu steuern, dass die Bestätigung von Daten an die Mobilvermittlungsstelle (10) verhindert wird, die nicht vom Endgerät (11; PP) von der ersten Feststation (1; FP 1) empfangen werden.