-
Die
Erfindung bezieht sich auf ein Radiokommunikationssystem und hierbei
insbesondere auf Verfahren zum Gateway-Wechsel für dieses System, sowie auf
Gateways, funkfähige
Terminals und Radiokommunikationssysteme zur Anwendung bei diesem
Verfahren.
-
Da
sich Internetdienste, wie www (World Wide Web) etc., in den letzten
Jahren schnell verbreitet haben, befinden sich nun die Erweiterung
der Computernetzwerkausmaße
und die Vielfältigkeit
der Verbindungsmoden auf dem Vormarsch.
-
Um
diesem Fortschritt zu entsprechen, benötigt man Gateways, welche intelligente
Terminals und Server über
ein Netzwerk verbinden, um die Verarbeitungseigenschaften zu verbessern
und diese Funktionen zu erweitern.
-
Als
Beispiel für
die Vielfältigkeit
von Verbindungsmoden sei ein „Mobilcomputing" betrachtet: Hierbei
handelt es sich um ein Funkkommunikationsnetzwerk, welches in der
Lage ist, mit einem Computernetzwerk zu kommunizieren unter Verwendung
eines Mobilterminalnetzwerks, wie eines Mobiltelefonnetzwerks, unter
Hinzufügung
eines intelligenten Terminals mit einer Radiokommunikationsfunktion, selbst
bei einer gerade stattfindenden Bewegung oder selbst an einem Ort,
wo keine Verbindung möglich
ist.
-
Die 4 und 5 sind
Konzeptdarstellungen, welche den Kommunikationsmodus unter Verwendung
des oben erwähnten
Funkkommunikationsnetzwerks zeigen.
-
5 zeigt
einen Aufbau des Funkkommunikationsnetzwerks mit einem öffentlichen
Netzwerk oder einem hausgebundenen Netzwerk, beispielsweise einem
Local Area Netzwerk (LAN).
-
Wenn
ein Nutzer an einem Terminal 1 eine Anwendung durchführen will,
erfolgt die Kommunikation zwischen dem Terminal 1 und einem
Server 6 unter Durchlaufen einer Radiobasisstation 2,
eines Netzwerks 3 und eines Gateways 11 oder 12,
und so wird die Anwendung durchgeführt.
-
6 zeigt
ein Beispiel für
ein Funkkommunikationsnetzwerk, bei welchem die Gateways selbst eine
Serverfunktion aufweisen, ohne dass ein Netzwerk durchlaufen würde, das
in einem vergleichsweise kleinen Bereich, wie beispielsweise in
einem Büro, betrieben
wird, wie es 5 zeigt. Die Kommunikation erfolgt
nämlich
zwischen dem Terminal 1 und dem Gateway 11 oder 12 über die
Radiobasisstation 2, und damit ist die Anwendung durchzuführen.
-
Das
oben beschriebene Funkkommunikationsnetzwerk ist notwendig zur Erweiterung
der Funktionen von- Gateways, um den Wechsel von Netzwerken zu erlauben
und den Betrieb von Netzwerken zeitweise für regelmäßige Wartung etc. zu unterbrechen.
Um den Netzwerkbetrieb selbst dann fortzusetzen, wenn das Gateway
nicht arbeitet, wird eine Gatewayverbindungswechselfunktion für das Netzwerk
benötigt,
d. h. eine Mehrzahl von Gateways müssen vorbereitet sein, wie
in den 5 und 6 gezeigt ist, und wenn das
Gateway 11 aufhört
zu arbeiten, wird die Kommunikation zwischen dem Terminal und dem
Server durch ein anderes Gateway 12 fortgesetzt.
-
Das
Prinzip des Kommunikationsprotokolls zwischen dem Terminal und dem
Gateway sei anhand von 7 erläutert.
-
Eine
Anwendung 71 in dem Terminal ist ein Programm wie ein www-Browser,
mit dem ein Nutzer unmittelbar arbeitet. Und eine Anwendung 75 im Gateway,
wie es in dem Beispiel der 6 als eine Serverfunktion
enthaltendes Gateway gezeigt ist, ist ein Programm zum Senden und
Empfangen von Informationen mit einer Anwendung in dem Terminal, beispielsweise
einer www-Serversoftware.
-
Ein
Session-Layer-Protokoll 72 ist ein Protokoll, welches eine
Transfersteuerfunktion bietet, die verschiedenen Anwendungen 71 und 75,
beispielsweise, gemeinsam ist, also ein Mittel wie eine Transferverarbeitung
der Aufteilung in übertragbare
Daten und der Übertragung
pro aufgeteilte Einheit. Und eine Management-Entität bei der
Management-Entität 73 ist
ein Programm zum Managen von Systemressourcen (wie einem Speicher),
welche von einer Mehrzahl von Session-Prozessen benutzt werden,
die bei der Datenkommunikation zwischen einem Terminal und einem
Server vorkommen, und zum Managen von Verarbeitungen über das
gesamte System (beispielsweise Festhalten eines Gatewaywechseltimings).
Ein niederes Protokoll 74 ist ein Programm und eine Vorrichtung
zur Durchführung
einer Kommunikationssteuerung.
-
8 zeigt
die Kommunikationsabfolge in dem Kommunikationsmodus.
-
Ein
Session-Layer-Protokoll 802 in einem Terminal 1 steht
in Kommunikation 803 mit einem Lession-Layer-Protokoll 804 im
Gateway 11, um die Anwendung 801 durchzuführen. Zu
diesem Zeitpunkt gibt ein Operateur eine Gatewaywechselinstruktion 808 an
eine Management-Entität 805 in
Gateway 11, und die Management-Entität 805 sendet eine Trenn-Notiz 809 an
das Session-Layer-Protokoll 802 im
Terminal 1 über
das Session-Layer-Protokoll 804. Demgemäss gibt das Session-Layer-Protokoll 802 im Terminal 1 die Trennanzeige
(Display) 810 an die Anwendung 801 weiter oder
nicht, und dann wird die Durchführung
der Anwendung 801 unterbrochen.
-
Nachdem
das Gateway 11 die Trenn-Nachricht 809 ausgesendet
hat, unterbricht das Gateway 11 seine Tätigkeit entsprechend dem Befehl
des Operateurs oder der Funktion des Gateways 11. Um die
so unterbrochene Anwendung 801 wieder weiterlaufen zu lassen,
fordert danach das Terminal 1 das Session-Layer-Protokoll 802 auf,
entsprechend der in ihm selbst enthaltenen Information 801 wieder
mit dem Gateway 12 zu verbinden.
-
Nachdem
die Session 812 zwischen dem Session-Layer-Protokoll 802 und
dem Session-Layer-Protokoll 806 im Gateway eingerichtet
ist, geht der Zustand in die Kommunikation 813 über und
es wird möglich,
die aufgehobene Anwendung 801 wieder durchzuführen.
-
Bei
der oben beschriebenen konventionellen Technik tritt jedoch das
folgende Problem auf: Wenn nämlich
der Gatewayverbindungswechsel durchgeführt wird, weil ein Gateway
aufgehört
hat zu arbeiten, muss das Terminal die laufende Anwendung zeitweilig
beenden und sie dann nach dem Wiederverbinden mit einem anderen
Gateway von vorn durchführen.
-
Um
die Anwendung nach einem Gatewaywechsel, wie oben beschrieben, durch
das Terminal wieder weiterlaufen zu lassen, muss zunächst in
dem Terminal die Adresseninformation über eine Mehrzahl von Gateways,
die für
den Wechsel in Frage kommen, gespeichert werden. D. h. aber, dass
die Information, die nur für
den Wechsel der Verbindung des Gateways benötigt wird, immer im Terminal
gespeichert ist, was eine verschwenderische Benutzung der Ressourcen
darstellt. Und dies ist ein weiteres Problem für das Terminal, dass kompakt
sein soll und viele Funktionen haben soll.
-
Ein
weiteres Problem besteht darin, dass immer dann, wenn sich die Netzwerkkonstitution
durch Hinzufügen,
Entfernen usw. von Server oder Gateways ändert, die im Terminal gespeicherte
Gatewayadresseninformation aktualisiert werden muss. Und wenn die
Verbindung zu einem anderen Gateway wechselt, muss die Information,
wie Terminal-Portnummer, Terminal-Adresse und Terminal-Leistungsfähigkeit
zwischen dem Terminal und dem Wechsel-Ziel(exchange destination)-Gateway ausgetauscht
werden. Da dieser Austausch viel Zeit benötigt, vergeht eine lange Zeit,
ehe die Anwendung wieder aufgenommen wird. Auch dies ist ein Problem.
-
Ein
Ergebnis der „Verhandlung" (negotiation) zwischen
dem Terminal und dem Wechsel-Ziel-Gateway besteht darin, dass dann,
wenn das Gateway nicht die Kapazität oder Ressource hat, die zur
Kommunikationsleistungsfähigkeit
des Terminals passt, das Terminal die Verbindung mit dem Gateway
beendet. Das Terminal versucht immer wieder eine Verbindung mit
einem anderen Gateway herzustellen, bis es ein Gateway findet, dass
zu der Kommunikationsleistungsfähigkeit
des Terminals passt, und dies ist sehr schlecht für die Betriebseffizienz.
Es besteht aber eine Möglichkeit,
dass diese Bedingungen eintreten, und das stellt ebenfalls ein Problem
dar.
-
Die
Erfindung wurde vorgeschlagen, um die oben genannten Probleme zu
lösen bzw.
zu verbessern. Die Aufgabe der Erfindung besteht in der Schaffung
eines Verfahrens zum automatischen Gatewaywechsel und einer entsprechenden
Vorrichtung, wobei es möglich
ist, die Gatewayverbindung zu wechseln, ohne die in einem Terminal
laufende Anwendung abzubrechen, und es nicht notwendig ist, dass das
Terminal immer Informationen über
mehrere Gateways bereithält,
wobei es ferner für
das Terminal einfach ist, sich verschiedenen Änderungen der Netzwerkkonstitution
anzupassen, und es möglich ist,
die Zeit für
das „Aushandeln” der Verbindung
eines Terminals mit einem Gateway abzukürzen, und es ferner möglich ist,
zu einer Zeit ein Terminal mit einem Gateway zu verbinden, das eine
zu dem Terminal passende Ressource und Leistungsfähigkeit
hat.
-
Die
US-A 5457680 bezieht
sich auf ein Datengateway für
mobile Datenfunk(radio)terminals in einem Datenkommunikationsnetzwerk.
In dem System können
mobile Datenfunkterminals mit festen Basisstationen kommunizieren,
wobei jede Basisstation einen Zellularbereich definiert. Die Basisstationen
stehen in Kommunikation mit einem Heimmobildatengateway oder einem
Servermobildatengateway.
-
Prozessoren,
auf welchen Anwendungen laufen, sind über ein Netzwerk mit den Mobildatengateways
verbunden. Diese Schrift beschreibt ein „Hand-Off"-Verfahren
zwischen Mobildatengateways.
-
Die
Erfindung findet Anwendung in dem Fall, dass es bei einem Kommunikationssystem,
welches die Kommunikation zwischen einem funkfähigen Terminal und einem Servergateway
herstellt, erforderlich ist, von einem ursprünglich benutzten Gateway aus
irgend einem Grunde einem anderen Gateway zu wechseln.
-
Gemäß der Erfindung
ist ein Kommunikationssystem vorgesehen, welches eine Kommunikation
zwischen einem funkfähigen
Terminal und einem Server herstellt, der dem funkfähigen Terminal
Dienste über
ein Gateway anbietet und es dem funkfähigen Terminal erlaubt, von
einem Gateway zu einem anderen Gateway zu wechseln, wobei das funkfähige Terminal
mit einer Kommunikationsaktivierungeinrichtung versehen ist zum
Empfang der Adresse eines Wechsel-Ziel-Gateways ebenso wie einer
Gatewaywechselnachricht und zur Ausführung einer Startsequenz mit
dem Wechsel-Ziel-Gateway.
-
Im
Falle der Benachrichtigung des Terminal mit der Information, die
erforderlich ist für
die Kommunikation mit dem Server über ein Wechsel-Ziel-Gateway,
führt eine
Neustartaktivierungseinrichtung in dem funkfähigen Terminal eine Neustartsequenz
für die
Kommunikation mit dem Wechsel-Ziel-Gateway durch, anstatt die Kommunikation mit
dem Wechsel-Original-Gateway aufzuheben. Es kann vorkommen, dass
die Wechselnachricht von dem Wechsel-Original-Gateway ausgesandt wird, wenn das funkfähige Terminal
keine Dienste vom Server empfängt.
Dann startet die Kommunikationsaktivierungseinrichtung in dem funkfähigen Terminal die
Kommunikation mit dem Server über
das Wechsel-Ziel-Gateway.
-
Zum
Zeitpunkt des Gatewaywechsels kann das Wechsel-Original-Gateway
vorab die Information, die für
die Kommunikation mit dem funkfähigen Terminal
zum Wechsel-Ziel-Gateway erforderlich ist, mit Hilfe einer Informationswechseleinrichtung übertragen,
und kann die Bestätigung
der Zulässigkeit, die
Kommunikation von dem Wechsel-Ziel-Gateway aus zu starten, erhalten.
-
Falls
eine Informationswechseleinrichtung zwischen den Gateways vorhanden
ist, kann das Wechsel-Original-Gateway zu dem Wechsel-Ziel-Gateway
die Leistungsfähigkeit
bzw. Eignung zusammen mit der Adresse des funkfähigen Terminals übertragen.
Wenn also das Wechsel-Ziel-Gateway eine zu geringe eigene Leistungsfähigkeit
hat und nicht mit dem Terminal zusammenpasst, dann informiert es
das Wechsel-Original-Gateway über
das Maximum seiner eigenen Leistungsfähigkeit.
-
Nachdem
das Wechsel-Original-Gateway das funkfähige Terminal über die
maximale Leistungsfähigkeit
informiert hat, startet das funkfähige Terminal die Kommunikation über das
Wechsel-Ziel-Gateway unter den Bedingungen dieser maximalen Leistungsfähigkeit
neu. Kann die Kommunikation unter den Bedingungen der maximalen
Leistungsfähigkeit
nicht durchgeführt
werden, dann muss die Kommunikation aufgrund der Beurteilungseinrichtung
im Wechsel-Original-Gateway
oder der Beurteilungseinrichtung im funkfähigen Terminal unterbrochen
werden.
-
Es
besteht jedoch eine Möglichkeit,
dass eine unvollständige
Transaktion nach dem Unterbrechungsvorgang übrig bleibt.
-
Hat
das Gateway keine Informationswechseleinrichtung, dann informiert
das Wechsel-Original-Gateway den Server entsprechend dem Wechsel-Ziel-Gateway über die
Adresse des Antwortenden (des funkfähigen Terminals) vor der Neustartinstruktion
des funkfähigen
Terminals. Auf diese Weise wird die unvollständige Transaktion zum Zeitpunkt des
Neustarts komplettiert. Hat das Gateway eine Informationswechseleinrichtung,
dann informiert das Wechsel-Original-Gateway
das Wechsel-Ziel-Gateway über
die Transaktionsbedingungen, und damit ist die unvollständige Transaktion
zum Zeitpunkt des Neustarts zu vervollständigen.
-
Es
kann vorkommen, dass die Kommunikationsbedingungen zwischen dem
funkfähigen
Terminal und dem Server sich vor und nach dem Austausch von Informationen ändert. Dann
sind entsprechend der Neustartsequenz die letzten Kommunikationsbedingungen
an das Wechsel-Ziel-Gateway zu senden.
-
Die
oben im Zusammenhang mit der Erfindung erwähnten Begriffe werden in der
nachfolgenden Beschreibung erläutert
und sind auch in den Zeichnungen gleichermaßen verwendet.
-
Die
Informationsmitteilungseinrichtung: Eine Wechselinstruktion wird
von einem Operator eines Gateways an ein Wechsel-Original-Gateway
gegeben. Die Management-Entität
in dem Wechsel-Original-Gateway empfangt die Wechselinstruktion,
editiert den Inhalt der Mitteilung an das funkfähige Terminal und informiert
dieses über
den Inhalt der Mitteilung mit Hilfe des Session-Layer-Protokolls. Die Informationsmitteilungseinrichtung
besteht somit aus der Management-Entität und dem Session-Layer-Protokoll
in einem Gateway.
-
Die
Informationsaustauscheinrichtung: ist in dem Wechsel-Original-Gateway
bzw. dem Wechsel-Ziel-Gateway enthalten und führt den Austausch von Informationen,
wie etwa die Adresse des funkfähigen
Terminals, wechselseitig zwischen den Management-Entitäten durch.
Es erübrigt
sich zu sagen, dass die Editierung des Inhaltes der Mitteilung von der
Management-Entität
durchgeführt
wird, die Informationsaustauscheinrichtung besteht ebenfalls aus der
Management-Entität.
In den Zeichnungen erfolgt der Informationsaustausch zwischen den
Management-Entitäten,
jedoch kann die Anordnung so getroffen werden, dass der Informationsaustausch
zwischen den Session-Layer-Protokollen beider Gateways durchgeführt wird.
Auch in diesem Falle wird der Informationsaustausch von der Management-Entität zum Session-Layer-Protokoll
geliefert.
-
Die
Neustartaktivierungseinrichtung: Bei Empfang der Information, wie
etwa der Wechsel-Ziel-Gatewayadresse, führt das Session-Layer-Protokoll
in dem funkfähigen
Terminal die Neustartfolge nach Durchführung der Unterbrechungsverarbeitung
der Kommunikation mit dem Wechsel-Original- Gateway durch. Die Neustartaktivierungseinrichtung
besteht somit aus dem Session-Layer-Protokoll in dem funkfähigen Terminal.
Die Kommunikationsaktivierungseinrichtung führt nicht die Unterbrechungsverarbeitung
durch und unterscheidet sich von der Neustartaktivierungseinrichtung.
In diesem Fall besteht die Kommunikationsaktivierungseinrichtung
ebenfalls aus dem Session-Layer-Protokoll.
-
Die
Beurteilungseinrichtung: Wie oben beschrieben beurteilt diese Einrichtung,
ob die Kommunikation zwischen dem funkfähigen Terminal und dem Wechsel-Ziel-Gateway durchgeführt werden kann
durch Vergleichen der Leistungsfähigkeit
des funkfähigen
Terminals mit dem Wechsel-Ziel-Gateway. Es gibt zwei Fälle, in
denen diese Einrichtung in dem funkfähigen Terminal und in dem Wechsel-Ziel-Gateway
enthalten ist. In beiden Fällen
hat die Management-Entität die Beurteilung
vorzunehmen.
-
1 ist
eine Schemaansicht eines Funkkommunikationsnetzwerks über ein öffentliches
Netz oder ein internes Netz mit Gateways, welche sich bei dieser
Ausführung
der Erfindung in einen gemeinsamen Server teilen.
-
2 zeigt
einen Aufbau eines Funkkommunikationsnetzwerks über ein öffentliches Netz oder ein internes
Netz mit Gateways, welche bei dieser Ausführungsform der Erfindung selbst
Informationen beinhalten.
-
3 zeigt
das Schema eines Funkkommunikationsnetzwerks über ein öffentliches Netz oder ein internes
Netz, wobei jedes Gateway bei dieser Ausführungsform der Erfindung mit
seinem eigenen Server verbunden ist.
-
4 zeigt
den Aufbau eines Funkkommunikationsnetzwerkes mit Gateways, welche
selbst Informationen enthalten, ohne dass bei dieser Ausführung der
Erfindung ein öffentliches
Netz oder internes Netz durchlaufen wird.
-
5 zeigt
den Aufbau eines Funkkommunikationssystems über ein öffentliches Netz oder ein internes
Netz mit Gateways, welche sich bei der Ausführung der konventionellen Erfindung
in einen gemeinsamen Server teilen.
-
6 zeigt
den Aufbau eines Funkkommunikationsnetzwerks über ein öffentliches Netz oder ein internes
Netz mit Gateways, welche bei der Ausführung der konventionellen Erfindung
selbst Informationen beinhalten.
-
7 ist
ein Diagramm, welches die Positionierung des Session-Layer-Protokolls
und der Management-Entität
bei der Session-Layer in den Protokollstapel zwischen dem Terminal
und dem Gateway zeigt.
-
8 zeigt
die Sequenz des Gatewaywechsels in der konventionellen Erfindung
bei der Konfiguration gemäß 6.
-
9 zeigt
eine Sequenz des Gatewaywechsels bei der Ausführung dieser Erfindung bei
der Struktur gemäß 1.
-
10 zeigt
eine Sequenz des Gatewaywechsels bei der Ausführung der Erfindung bei der Struktur
gemäß 2.
-
11 zeigt
eine Sequenz des Gatewaywechsel bei der Ausführung der Erfindung gemäß 3.
-
12 zeigt
ein konkretes Beispiel der Gatewaywechselsequenz bei der Erfindung.
-
13 zeigt
eine Sequenz für
den Fall, dass die Kommunikation zwischen dem Terminal und dem Server
für die
Dauer der Verhandlung zwischen Gateways entsteht.
-
14 zeigt
eine Sequenz zur Veranschaulichung des Timings zum Stoppen des Gateways
in einer Kommunikation mit einem Mehrfachterminal.
-
15 zeigt
eine Sequenz im Falle der Durchführung
des Verbindungswechsel zu einem anderen Gateway wegen des Empfang
einer Wechsel-Abweisung von dem Wechsel-Ziel-Gateway durch die Gatewayverhandlungen.
-
16 zeigt
eine Folge im Falle des Wechsel-Ziel-Gateways ohne die Leistungsfähigkeit
der Anpassung an das Terminal.
-
17 zeigt
eine Sequenz im Falle der Anzeige durch die Anwendung im Terminal,
dass der Gatewaywechsel jetzt läuft.
-
18 zeigt
eine Sequenz für
den Gatewaywechsel bei der Ausführung
der Erfindung gemäß dem Aufbau
nach 1.
-
19 zeigt
ein konkretes Beispiel für
eine Sequenz des Gatewaywechsel bei der Erfindung.
-
20 zeigt
eine Sequenz der Rückübertragungssteuerung
des Gateways und des Terminals bei dieser Erfindung.
-
21 zeigt
eine Sequenz einer Transaktionsverarbeitung, die nach einer GateWechselnachricht
generiert wird.
-
22 zeigt
eine Sequenz einer Transaktionsverarbeitung ohne Erhalt von Daten
als Antwort auf eine generierte Anfrage vor der GatewayWechselnachricht.
-
23 zeigt
eine Sequenz einer Transaktionsverarbeitung, die Daten als Antwort
auf eine vor der GatewayWechselnachricht generierte Anfrage erhält.
-
24 zeigt
eine Sequenz des Gatewaywechsels bei der Ausführungsform 5 dieser Erfindung.
-
25 zeigt
eine Sequenz einer Transaktionsverarbeitung, die generiert wird
nach der GatewayWechselnachricht zum Zeitpunkt des Gatewaywechsels,
wie es in der Ausführungsform
dieser Erfindung beschrieben wird.
-
26 zeigt
eine Sequenz einer Transaktionsverarbeitung ohne Erhalt von Daten
als Antwort auf eine vor der Gatewaywechselnotiz generierte Anfrage
zur Zeit des Gatewaywechsels, wie es bei der Ausführungsform
5 dieser Erfindung beschrieben ist.
-
27 zeigt
eine Sequenz einer Transaktionsverarbeitung unter Erhalt von Daten
als Antwort auf eine vor dem Gatewaywechsel generierte Anfrage zum
Zeitpunkt des Gatewaywechsels, wie es bei der Ausführungsform
5 dieser Erfindung beschrieben ist.
-
Die
Ausführungsformen
der Erfindung werden nachfolgend erläutert:
-
Ausführungsform
1
-
1 zeigt
den Aufbau eines Funkkommunikationsnetzwerks mit Gateways, die einen
gemeinsamen Server haben, wobei bei dieser Ausführungsform der Erfindung die
Kommunikation über
ein öffentliches
Netz läuft.
-
Ein
Terminal 1 ist ein Funk-Terminal wie ein Notebook-Personalcomputer,
der mit einem Mobiltelefon verbunden ist. Eine Basisstation 2 stellt
eine Basisstation für
das Mobiltelefon dar, und ein Netzwerk 3 ist ein öffentliches
Netz für
Mobiltelefon.
-
Ein
Gateway 4 teilt sich mit einer Gateway 5 in einen
Server 6, der mit dem Netz 3 über das Gateway 4 und 5 verbunden
ist. Das Gateway 4, 5 ist mit einer Informationsaustauscheinrichtung
versehen, um bei dieser Erfindung die „Verhandlungen" zwischen den Gateways
durchzuführen.
Die Informationsaustauscheinrichtung enthält eine Verbindungseinrichtung 13 in
Form eines Kabels oder einer Funkverbindung, die es erlaubt, direkt
mit dem Gateway 4 und 5 zu kommunizieren; andererseits
kann auch eine Verbindungseinrichtung 14 zwischen dem Server 6,
dem Gateway 4 und 5 oder die durch das Netzwerk 3 verlaufende
Verbindung als diese Einrichtung benutzt werden.
-
Das
Terminal 1 ist mit dem Server 6 über die Basisstation 2,
das Netz 3 und das Gateway 4 oder 5 verbunden.
In diesem Falle wird die Anwendung unter Verwendung der im Server 6 enthaltenen
Information 7 durchgeführt.
-
Weil
das Gateway 4 stoppt (zu arbeiten aufhört), während das Terminal 1 über das
Gateway 4 mit dem Server 6 verbunden ist, sollte
vom Gateway 4 zum Gateway 5 gewechselt werden. 9 zeigt eine
Schaltsequenz von Gateway 4 zum Gate 5 nach dem
Stoppen des Gateways 4.
-
Ein
Session-Layer-Protokoll 902 im Terminal 1 tritt über das
Gateway 4 in Kommunikation mit der Anwendung 911 im
Server 6, um die Anwendung 901 auszuführen.
-
Weil
das in der Kommunikation 903 zwischen dem Session-Layer-Protokoll 902 im
Terminal 1 und dem Session-Layer-Protokoll 904 im
Gateway 2 verwendete Kommunikationsprotokoll verschieden von
dem der Kommunikation 907 zwischen dem Session-Layer-Protokoll 904 im
Gateway 4 und dem Server 6 ist, besorgt zu dieser
Zeit ein Protokollübersetzer 905 im
Gateway 4 die Protokollübersetzung.
Das für
die Kommunikation 903 benutzte Kommunikationsprotokoll
wird nämlich
von dem Protokollübersetzer 905 in
dasjenige übersetzt,
welches bei der Kommunikation 907 zwischen dem Gateway 4 und
dem Server 6 verwendet wird. Daher ist es möglich, die Kommunikation
zwischen dem Terminal 1 und dem Server 6 durchzuführen.
-
Es
gibt jedoch Anwendungen, bei welchen keine Protokollübersetzung
erforderlich ist, dann erfolgt auch keine Protokollübersetzung
in dem Gateway.
-
Wenn
unter diesen Bedingungen vom Operator eine Serverwechselinstruktion 912 ausgegeben wird,
solange das Terminal 1 in Kommunikation mit dem Server 6 steht,
führt die
Management-Entität 906 im
Gateway 4 die Verhandlungen mit der Management-Entität 910 im
Gateway 5 durch, um die Kommunikation des Terminals vom
Gateway 4 zum Gateway 5 zu übersetzen.
-
D.
h., die Management-Entität 906 im
Gateway 4 sendet eine Sessionwechselanfrage 913 zur Management-Entität 910 im
Gateway 5. Zu diesem Zeitpunkt kann die Auswahl eines Wechsel-Ziel-Gateways
(d. h. das Gateway 5), welche die Sessionwechselanfrage 913 vom
Gateway 14 erhält, durchgeführt werden
entsprechend der Information des anderen Gateways, die vorab im
Gateway 4 gespeichert ist oder entsprechend einer Instruktion
des Operators. Die Sessionwechselanfrage 913 ist der Management-Entität 910 im
Gateway 5 zusammen mit weiterer Information, wie Adresse,
Session-ID, maximale Datengröße und Fenstergröße des Terminal,
welches nun verbunden wird, zuzusenden.
-
Die
Management-Entität 910 im
Gateway 5 behandelt die Information zusammen mit der Sessionwechselanfrage 913 an
das Session-Layer-Protokoll 908. Wenn das Session-Layer-Protokoll 908 den Inhalt
der Information bestätigt,
dann ergibt sich der Zustand, dass der Sessionswechsel durchgeführt werden
kann, und die Management-Entität 910 im Gateway 5 schickt
die Sessionwechselbestätigung 914 an
die Management-Entität 906 im
Gateway 4.
-
Nachdem
die Management-Entität 906 im Gateway 4 die
Sessionwechselbestätigung 914 erhalten
hat, schickt sie die Wechselinstruktion 922 an das Session-Layer-Protokoll 904,
und diese sendet daraufhin eine Wechsel-Zziel-Gatewayadresse zusammen
mit der Wechselnachricht 915 an das Session-Layer-Protokoll 902 im
Terminal 1.
-
Demgemäss kann
das Terminal 1 die Adresseninformation des Gateways 5 des
Wechsel-Ziel-Gateways durch die Wechselnachricht 915 erhalten.
-
Nachdem
die Protokoll-Session-Layer 902 im Terminal 1 die
Wechselnachricht 915 zusammen mit der Adresseninformation
erhalten hat, sendet sie an das Session-Layer-Protokoll 904 im
Gateway 14 die Unterbrechungsnachricht 916 zu
einem günstigen
Zeitpunkt für
die Unterbrechung der Session, beispielsweise zum Zeitpunkt, wo
die Durchführungsanwendung 901 nicht
in Kommunikation mit der Anwendung 911 im Server 6 steht.
-
Das
Session-Layer-Protokoll 904 in Gateway 4 informiert
die Management-Entität 906 über den Empfang
der Unterbrechungsnachricht 916, und die Management-Entität 906 sendet
die Unterbrechungsinstruktion 923 an das Session-Layer-Protokoll 904.
Dieses sendet daraufhin die Unterbrechungsbestätigung 917 an das
Session-Layer-Protokoll 902 im Terminal 1, und
die Session zum Terminal 1 wird aufgehoben.
-
Das
Terminal 1 kann indessen nach dem Senden der Unterbrechungsnachricht 916 an
das Session-Layer-Protokoll 904 im Gateway die Serververbindungswechselsequenz
unabhängig
vom Zustand des Gateways 4 fortsetzen.
-
Daher
können
die Schritte der Unterbrechungsinstruktion 923 und der
Unterbrechungsbestätigung 917 entfallen,
und ohne die Unterbrechungsinstruktion 923 kann das Session-Layer-Protokoll 904 die
Unterbrechungsbestätigung 917 unabhängig an
das Session-Layer-Protokoll 902 im Terminal 1 schicken.
Es gibt einen Fall, wo beim Typ des Gateways 4 nur die
Unterbrechungsinstruktion 923 weggeschickt wird, die Unterbrechungsbestätigung 917 dagegen
nicht. In beiden Fällen
wird, wenn es keine Unterbrechungsbestätigung 917 gibt, die
Session des Terminals 1 nach dem Wegschicken der Unterbrechungsnachricht 916 aufgehoben.
-
Wenn
das Session-Layer-Protokoll 902 im Terminal 1 die
Wechselnachricht 915 erhält, erhält die Anwendung 901 die
Instruktion, die Gateway-Wechsel-Anzeige vorzunehmen. Entsprechend der
Funktion der Anwendung 901 oder der Instruktion durch den
Nutzer kann das Session-Layer-Protokoll 902 im Terminal 1 die
Unterbrechungsnachricht 916 an das Session-Layer-Protokoll 904 im
Gateway 4 schicken.
-
Danach
schicht das Session-Layer-Protokoll 902 im Terminal 1 eine
Neustart-Nachricht 918,
welche Informationen, wie Terminal-Adresse usw., enthält, an das
Session-Layer-Protokoll 908 im Gateway 5. Weil
das Session-Layer-Protokoll 908 im Gateway 5 zu
diesem Zeitpunkt fertig für
einen Neustart der Session entsprechend der Sessionwechselanfrage 913 und
der Sessionwechselbestätigung 914 ist,
wird die Neustart-Bestätigung 919 zum
Terminal geschickt, sobald die Neustart-Nachricht 918 vom
Session-Layer-Protokoll 902 im Terminal erhalten ist.
-
Entsprechend
der Neustart-Bestätigung 919 vom
Session-Layer-Protokoll 908 im Gateway 5 startet
die Session des Terminals 1, welche aufgehoben wurde, sofort
wieder. Daher ist es möglich,
die Kommunikation 920 und 921 mit dem Session-Layer-Protokoll 902 im
Terminal 1 und der Anwendung 911 im Server 6 über den
Protokollübersetzer 909 im
Gateway 5 zu etablieren, um die Anwendung 901 durchzuführen.
-
18 zeigt
eine Sequenz für
den Fall der Benutzung „Trennen" anstatt des oben
erwähnten „Unterbrechens" und „Trennen" anstatt des oben
erwähnten „Neustarts".
-
Eine
Wechselnachricht 2515 in 8 entspricht
der Wechselnachricht 915 in der Sequenz gemäß 9,
und die Sequenz bis zu diesem Schritt ist in beiden Zeichnungen
ganz die gleiche, so dass dies hier nicht nochmals wiederholt wird.
Danach trennt das Session-Layer-Protokoll 2502 im Terminal 1 die Session
nach dem Aussenden der Trennnachricht 2516.
-
Gemäß der Wechsel-Ziel-Gatewayadresse, die
zum Terminal 1 zusammen mit der Wechselnachricht 2525 gesendet
wurde, sendet danach das Session-Layer-Protokoll 2502 im Terminal 1 die
Verbindungsnachricht 2518 an die Protokoll-Session-Lager 2508 im
Gateway 5 und diese betrachtet die Verbindungsnachricht
als neue Session und sendet eine Verbindungsbestätigung 2519 an das
Session-Layer-Protokoll 2508 im
Terminal 1. Auf diese Weise kann das Session-Layer-Protokoll 2502 im
Terminal 1 die Etablierung der Session bestätigen.
-
Nach
der Etablierung der Session steht das Session-Lager-Protokoll 2502 im
Terminal 1 in Kommunikation 2520 und 1021 mit
der Anwendung 2511 im Server 6 über den
Protokollaustausch 2509 im Gateway, um die Anwendung 2501 auszuführen.
-
Entsprechend
den oben beschriebenen Sequenzen ist es möglich, den Gatewayverbindungswechsel
des Terminals 1 in kurzer Zeit durchzuführen und den Gatewayverbindungswechsel
ebenfalls ohne große
Einflüsse
auf die Anwendung 901 (2501) im Terminal und auf
einen Nutzer durchzuführen.
-
Mit
anderen Worten ist es möglich,
die Anwendung gerade dort wieder aufzunehmen, wo sie verblieben
war, ehe der Gatewaywechsel stattgefunden hat, ohne nochmals von
Beginn die ganze Anwendung wieder zu durchlaufen, weil das Gateway 5 durch
die oben erläuterte
Verhandlungsprozedur die notwendige Information besitzt.
-
Ausführungsform
2
-
2 zeigt
die Struktur des Funkkommunikationsnetzwerks bei dieser Ausführungsform
der Erfindung über
ein öffentliches
Netz oder ein internes Netz, wobei jedes Gateway selbst eine Serverfunktion
mit Information hat, um eine Terminalanwendung durchzuführen.
-
Ein
Terminal 1 ist ein funkfähiges Terminal, wie ein Personaldigitalassistent
(PDA) einschließlich eines
Privattelefons (personal phone).
-
Eine
Basisstation 2 ist eine Basisstation für ein Privattelefon, und ein
Netzwerk 3 ist ein öffentliches
Netz für
ein Privattelefon.
-
Ein
Gateway 4 und 5 ist jeweils mit dem Netzwerk 3 verbunden
und mit einer Verbindungseinrichtung 13 versehen als Informationsaustauschmittel,
um bei dieser Erfindung die Verhandlung zwischen den Gateways durchzuführen. Die
Verbindungseinrichtung 13 für die Durchführung der
Verhandlungen zwischen den Gateways kann eine Kabel- oder eine Funkverbindung
sein, andererseits kann das Verbindungsverfahren auch über das
Netzwerk 3 verfügbar
sein.
-
Das
Terminal 1 ist mit dem Gateway 4 oder 5 über die
Basisstation 2 und das Netzwerk 3 verbunden und
führt eine
Anwendung aus unter Benutzung der Information 7 im Gateway 4 oder
der Information 8 im Gateway 5.
-
Es
ist auch ein Aufbau ohne Durchlaufen eines öffentlichen Netzes oder eines
internen Netzes denkbar, wie es 4 zeigt.
-
Bei
der Struktur nach 4 ist nämlich das Terminal 1 mit
dem Gateway 4 über
die Basisstation 2 und andererseits mit dem Gateway 5 über die
Basisstation 10 verbunden, wobei die Anwendung ausgeführt wird
unter Verwendung der Information 7 im Gateway 4 oder
der Information 8 im Gateway 5.
-
In
beiden 2 und 4 enthält die Information im Gateway 5 die
Information 7 im Gateway 4 oder hat die Information
mindestens derselbe Bedeutung wie die Information 7.
-
10 zeigt
eine Sequenz für
den Fall, dass das Terminal 1 das Gateway 4 stoppt,
das mit dem Terminal 1 in Verbindung steht, und den Verbindungswechsel
zum Gateway 5 durchführt.
-
Die
Gatewaywechselsequenz bei der Ausführungsform 2 wird
in Folgendem gemäß den 2 und 10 erläutert.
-
Eine
Anwendung 1001 im Terminal 1 führt die Verbindung 1003 mit
der Anwendung 1005 als Server im Gateway über ein
Session-Layer-Protokoll 1002 im Termin 1 und ein
Session-Layer-Protokoll 1004 im Gateway 4 durch.
-
Wenn
das Terminal 1 wie oben in Verbindung mit dem Gateway 4 steht
und falls eine Serverwechselinstruktion 1010 des Operators
ergeht, führt
eine Managemententität 1006 im
Gateway 4 die Verhandlungen mit einer Management-Entität 1009 im
Gateway 5, um die Verbindung des Terminals 1 vom
Gateway 4 auf das Gateway 5 zu ändern.
-
Die
Management-Entität 1006 im
Gateway 4 sendet nämlich
eine Sessionwechselanfrage 1011 zur Management-Entität 1009 im
Gateway 5. Nun kann die Wahl eines Wechsel-Ziel-Gateways,
das die Sessionwechselanfrage 1011 vom Gateway 4 erhalten
hat, gemäß der Information
des anderen Gateways, die im Gateway 4 zuvor gespeichert
worden ist, oder entsprechend der Instruktion des Operators durchgeführt werden.
-
Hier
enthält
die Information 8 im Gateway 5 die Information 7 im
Gateway 4, die zur Ausführung der
Anwendung 1001 durch das Terminal benutzt wird, oder hat
zumindestens dieselbe Bedeutung wie die Information 7.
-
Da
die Schritte nach der Sessionwechselanfrage 1011, also
die Schritte „Sessionwechselanfrage 1011 → Sessionwechselbestätigung 112 → Sessionwechselinstruktion 1019 → Wechselnachricht 1013" dieselben sind
wie die Schritte „Sessionwechselanfrage 913 → Sessionwechselbestätigung 914 → Sessionwechselinstruktion 922 → Wechselnachricht 913" wird hier eine
detaillierte Erklärung
weggelassen.
-
Das
Session-Layer-Protokoll 1004 im Gateway 4 erhält die Wechselnachricht 1013 und
sendet die Wechsel-Ziel-Adresse zum Session-Layer-Protokoll 1002 im
Terminal 1. Dadurch kann das Terminal 1 die Adresseninformation
des Gateways 5 erhalten, welches das Wechsel-Ziel-Gateway
ist.
-
Ferner
sind die Schritte nach Erhalt der Wechselnachricht 1013,
also „Wechselnachricht 1013 → Unterbrechungsnachricht 1014 → Unterbrechungsinstruktion 1020 → Unterbrechungsbestätigung 1015 → Neustart-Nachricht 1016 → Neustart-Bestätigung 1017" dieselben wie
die Schritte in 9, also „Wechselnachricht 915 → Unterbrechungsnachricht 916 → Unterbrechungsinstruktion 923 → Unterbrechungsbestätigung 917 → Neustart-Nachricht 918 → Neustart-Bestätigung 919", und daher
wird die Erläuterung
hier weggelassen.
-
Gemäß der Neustart-Bestätigung 1017 vom Session-Layer-Protokoll 1007 im
Gateway 5 beginnt die Session des Terminals, die aufgehoben
war, sofort. Nach dem Starten der Session führt das Session-Layer-Protokoll 1002 im
Terminal 1 die Kommunikation 1018 mit der Anwendung 1008 im
Gateway durch, um die Anwendung 1001 auszuführen.
-
In
gleicher Weise bei 9 ist es möglich, nachdem das Terminal 1 die
Unterbrechungsnachricht 1015 zum Session-Layer-Protokoll 1004 im Gateway 4 geschickt
hat, die Sequenz des Serververbindungswechsels unabhängig vom
Zustand des Gateways 4 fortzusetzen. Daher können die
Schritte der Unterbrechungsinstruktion 1020 und der Unterbrechungsbestätigung 1015 weggelassen
werden, und das Session-Layer-Protokoll 1004 die Unterbrechungsbestätigung 1015 an
das Session-Layer-Protokoll 1002 im Terminal 1 schicken,
ohne die Unterbrechungsinstruktion 1020 zu erhalten.
-
Ebenso
wie bei 9 gibt es einen Fall, dass einige
Typen von Gateways nur die Unterbrechungsinstruktion 1020 aussenden,
nicht aber die Unterbrechungsbestätigung 1015. In beiden
Fällen,
wenn die Unterbrechungsbestätigung 1015 nicht
weggeschickt wird, wird die Session des Terminals 1 unterbrochen, nachdem
die Unterbrechungsnachricht 1014 weggeschickt ist. Dies
kann folgendermaßen
geschehen: Das Session-Layer-Protokoll 1002 im
Terminal 1 instruiert bei Empfang der Wechselnachricht 1030 die Anwendung 1001,
die Gatewaywechselanzeige vorzunehmen. Gemäß der Funktion der Anwendung 1001 oder
der Instruktion durch den Nutzer kann das Session-Layer-Protokoll 1002 im
Terminal 1 die Unterbrechungsnachricht 1014 zum
Session-Layer-Protokoll 1004 im Gateway 4 schicken.
-
Gemäß der oben
beschriebenen Sequenz ist es möglich,
den Gatewayverbindungswechsel des Terminals 1 in kurzer
Zeit durchzuführen
und außerdem
den Gatewayverbindungswechsel des Terminals 1 ohne große Einflüsse auf
die Anwendung 1001 im Terminal 1 und auf den Nutzer
vorzunehmen.
-
Ausführungsform
3
-
3 zeigt
die Struktur eines Funkkommunikationsnetzwerks, bei dem jedes Gateway
bei dieser Ausführungsform
der Erfindung mit seinem eigenen Server über ein öffentliches Netz oder ein internes Netz
verbunden ist.
-
Ein
Terminal 1 ist ein Terminal für ein Mobiltelefon mit Datenverarbeitungsfunktion,
wie etwa ein Smartphone. Eine Basisstation 2 ist eine Basisstation für ein Mobiltelefon,
und ein Netzwerk 3 ist beispielsweise ein internes Netz.
Ein Gateway 4 ist mit dem Netzwerk 3 bzw. dem
Server verbunden, und ein Gateway 5 ist mit dem Netzwerk 3 bzw.
dem Server 9 verbunden.
-
Die
Gateways 4 und 5 haben eine Verbindungseinrichtung
zur Durchführung
der Verhandlungen zwischen den Gateways unter Verwendung der Informationsaustauschmittel,
bei dieser Erfindung. Die Verbindungseinrichtung kann ein Kabel
oder eine Funkverbindung sein, und auch das Netzwerk 3 kann zur
Verfügung
stehen.
-
Das
Terminal 1 ist mit dem Server 6 über die Basisstation 2,
das Netzwerk 3 und das Gateway 4 verbunden und
führt die
Anwendung gemäß der Information 7 im
Server 6 aus. Andererseits ist das Terminal 1 mit
dem Server 9 über
die Basisstation 2, das Netzwerk 3 und das Gateway 5 verbunden
und fuhrt die Anwendung gemäß der Information 8 im
Server 9 durch.
-
Die
Information 8 im Server 9 beinhaltet die Information 7 im
Server 6 oder hat zumindest dieselbe Bedeutung wie die
Information 7.
-
Wenn
das Gateway 14 stoppt, solange das Terminal 1 über das
Gateway 4 in Verbindung mit dem Server 6 steht,
führt das
Terminal 1 den Verbindungswechsel zum Gateway 5 und
Server 6 durch, und diese Folge ist in 11 gezeigt.
-
Die
Gatewaywechselsequenz bei der Ausführung 3 wird später anhand
der 3 und 11 erläutert.
-
Ein
Session-Layer-Protokoll 1102 im Terminal 1 führt die
Kommunikation in der Anwendung 1108 im Server 6 über das
Gateway 4 durch, um die Anwendung 1101 auszuführen.
-
Wenn
in diesem Fall das Kommunikationsprotokoll, das bei der Kommunikation 1103 zwischen dem
Session-Layer-Protokoll 1102 im Terminal 1 und dem
Session-Layer-Protokoll 1104 im Gateway 4 benutzt
wird, verschieden vom Kommunikationsprotokoll ist, welches bei der
Kommunikation 1107 zwischen Server 6 und Session-Layer-Protokoll 1104 im Gateway 4 benutzt
wird, dann muss eine Protokollübersetzung
durch den Protokollübersetzer 1105 im Gateway 4 erfolgen.
-
Die
Kommunikation 1103 wird von dem Protokollübersetzer 1105 in
das Kommunikationsprotokoll übersetzt,
das bei der Kommunikation 1107 zwischen dem Gateway 4 und
dem Server 6 benutzt wird, und damit ist es möglich, die
Kommunikation zwischen Terminal 1 und Server 6 vorzunehmen.
Es gibt jedoch Anwendungen, bei welchen keine Protokollübersetzung
erforderlich ist, und in diesem Fall besteht keine Notwendigkeit
für eine
Protokollübersetzung
im Gateway.
-
Wenn
hier, während
das Terminal 1 in Kommunikation mit dem Server 6 steht,
die Serverwechselinstruktion 1113 vom Operator ausgegeben
wird, dann führt
die Management-Entität 1106 (eine
Informationseinrichtung) im Gateway 4 die Verhandlungen
mit der Management-Entität 1111 im
Gateway 5, damit das Terminal 1 den Verbindungswechsel
zum Gateway 5 und Server 9 vornimmt.
-
Die
folgende Sequenz, also die Schritte „Sessionwechselanfrage 1114 → Sessionwechselbestätigung 1115 → Wechselinstruktion 1123 → Wechselnachricht 1116" ist die gleiche
wie die Schritte in 9, also „Sessionwechselanfrage 913 → Sessionwechselbestätigung 914 → Wechselinstruktiion 911 → Wechselnachricht 915", so dass eine
detaillierte Erläuterung
hier entfällt.
-
Wenn
das Session-Layer-Protokoll 1102 im Terminal 1 die
Wechselnachricht 1116 erhält, wird eine Unterbrechungsnachricht 1117 an
das Session-Layer-Protokoll 1104 im
Gateway 4 zu einem geeigneten Zeitpunkt geschickt, um die
Session zu unterbrechen, so wie wenn die Anwendung 1101 bei
der Ausführung
nun nicht in Kommunikation mit der Anwendung 1108 im Server 6 steht.
-
Die
folgenden Schritte, also die Schritte „Unterbrechungsnachricht 1117 → Unterbrechungsinstruktion 1124 → Unterbrechungsbestätigung" und „Neustart-Nachricht 1119 → Neustart-Bestätigung 1120" sind dieselben
wie die Schritte in 9 „Wechselnachricht 915 Unterbrechungsnachricht 916 → Unterbrechungsinstruktion 923 →Unterbrechungsbestätigung 917" und „Neustart-Nachricht 918 → Neustart-Bestätigung 919", und daher
erfolgt hier keine detaillierte Erläuterung.
-
In
gleicher Weise wie in 9 kann Terminal 1 die
Sequenz für
den Serververbindungswechsel unabhängig vom Zustand des Gateways 4 nach
dem Senden der Unterbrechungsnachricht 1117 an das Session-Layer-Protokoll 1104 im
Gateway 4 fortführen.
Daher sind die Schritte der Unterbrechungsinstruktion 1124 und
der Unterbrechungsbestätigung 1118 nicht
immer erforderlich. Und wenn keine Unterbrechungsbestätigung 1118 vorliegt,
dann wird die Session des Terminals 1 nach dem Aussenden
der Unterbrechungsnachricht 1117 unterbrochen.
-
Und
in gleicher Weise wie bei 9 kann beim
Erhalt einer Wechselnachricht 1116 das Session-Layer-Protokoll 1102 im
Terminal 1 die Anwendung 1101 anweisen, das Gatewaywechseldisplay vorzunehmen,
andererseits kann das Session-Layer-Protokoll 1102 im Terminal 1 die
Unterbrechungsnachricht 1117 an das Session-Layer-Protokoll 1104 im
Gateway 4 entsprechend der Funktion der Anwendung 1101 oder
einer Instruktion des Nutzers schicken.
-
Gemäß der Neustart-Bestätigung 1120 vom Session-Layer-Protokoll 1109 im
Gateway 5 startet die Session des Terminals 1,
welches aufgehoben war, von Neuem. Nach dem Start der Session hat
das Session-Layer-Protokoll 1102 im Terminal 1 die
Kommunikation 1121 und 1122 mit der Anwendung 1112 im
Server 9 über
das Gateway 5 vorzunehmen, um die Anwendung 1101 auszuführen.
-
Bei
Benutzung der oben beschriebenen Sequenz kann der Gatewayverbindungswechsel
des Terminals 1 in kurzer Zeit und ohne großen Einfluss auf
die Anwendung 1101 und den Nutzer durchgeführt werden.
-
Ausführungsform
4
-
Hier
werden konkrete Beispiele von Anwendungen der Gateway-Wechselsequenz
bei der Struktur gemäß 1 anhand
der 12–17 erläutert.
-
Wenn
das Gateway 4 stoppt, während
das Terminal 1, von dem ein www-Browser, der von einem Nutzer benutzt
wird, in Verbindung mit einer www-Server-Software im Server 6 über das
Gateway 4 steht, dann wird die Verbindung des Terminals
vom Gateway 4 zum Gateway 5 umgewechselt, wobei
die Sequenz in 12 dargestellt ist.
-
Das
Session-Layer-Protokoll 1202 sendet den vom www-Browser 1201 im
Terminal vom Benutzer eingegebenen Befehl an die www-Server-Software 1211 im
Server 6 über
das Gateway 4.
-
In
diesem Fall ist das Kommunikationsprotokoll zwischen dem Session-Layer-Protokoll 1202 im Terminal 1 und
dem Session-Layer-Protokoll 1204 im Gateway 4 ein
Funkkommunikationsprotokoll, andererseits ist das Kommunikationsprotokoll
zwischen dem Session-Layer-Protokoll 1204 im Gateway 4 und
dem Server 6 ein Hypertexttransferprotokoll (http). Damit
die beiden Protokolle zueinander passen, erfolgt daher eine Protokollübersetzung
durch den Protokollübersetzer 1205 im
Gateway 4.
-
Wenn
hier beispielsweise der Benutzer im Terminal 1 mit dem
www-Browser 1201 arbeitet und die Eingabe und der Zugriff
zu einer Datei //www, xxx/xyz, htm, die im Server 6 gespeichert
wird, ausgeführt
wird, dann wird INVOKE < REQUEST
(get, //www, xxx/xyz, htm) > 1203,
d. h., ein Funkkommunikationsbefehl, vom Protokollübersetzer 1205 übersetzt
in REQUEST (get, //www, xxx/xyz, htm) 1207, also ein http-Befehl,
und zum Server 6 geschickt.
-
Die
www-Server-Software 1201 im Server 6 erhält REQUEST
(get, //www, xxx/xyz, htm) 1207 und sendet Dateidaten von
//www, xxx/xyz, htm mittels RESPONSE (Daten) 1212 aus.
-
Die
RESPONSE (Daten) 1212 der http-Antwort werden vom Protokollübersetzer 1205 übersetzt in
REPLAY < RESPONSE
(Daten) > 1213,
also eine Antwort des Funkkommunikationsprotokolls, und werden vom
Session-Layer-Protokoll 1204 im Gateway zum Terminal 1 geschickt.
Damit kann die Kommunikation zwischen dem Terminal 1 und
dem Server 6 durchgeführt
werden, und der Nutzer kann die Dateidaten von //www, xxx/xyz, htm
im Server 6 mit Hilfe des www-Browsers 1201 durchschauen.
-
Wird
die Serverwechselinstruktion 1214 des Operators ausgegeben,
während
das Terminal 1 in Verbindung mit dem Server 6 steht,
wie oben, dann führt
die Management-Entität 1206 im
Gateway 4 die Verhandlung mit der Management-Entität 1210 im Gateway 5 durch,
damit das in Kommunikation befindliche Terminal 1 den Verbindungswechsel
zum Gateway 5 vornimmt.
-
Mit
anderen Worten sendet die Management-Entität 1206 im Gateway 4 die
Sessionwechselanfrage 1205 an die Management-Entität 1210 im Gateway 5.
Die folgenden Schritte, also die Schritte „Sessionwechselbestätigung 1216 → Wechselinstruktion 1217 → Wechselnachricht 1218" und „Unterbrechungsnachricht 1219 → Unterbrechungsinstruktion 1220 → Unterbrechungsbestätigung 1221" sind dieselben
wie die Schritte in 9 „Sessionwechselbestätigung 914 → Wechselinstruktion 922 → Wechselnachricht 915" und „Unterbrechungsnachricht 916 → Unterbrechungsinstruktion 923 → Unterbrechungsbestätigung 917" und damit erfolgt
hier keine detaillierte Erläuterung.
-
In
gleicher Weise wie bei 9 kann das Terminal 1 nach
Aussenden der Unterbrechungsnachricht 1219 an das Session-Layer-Protokoll 1204 im
Gateway 4 mit der Serververbindungswechselsequenz unabhängig vom
Zustand des Gateways 5 fortfahren. Daher sind die Schritte
der Unterbrechungsinstruktion 1220 und Unterbrechungsbestätigung 1221 nicht
immer erforderlich. Und wenn die Unterbrechungsinstruktion 1220 nicht
vorliegt, dann kann das Session-Layer-Protokoll 1204 unabhängig die
Unterbrechungsbestätigung 1221 an
das Session-Layer-Protokoll 1202 im
Terminal 1 senden.
-
Es
gibt einige Arten von Gateways 4, welche nur die Unterbrechungsinstruktion 1220 ohne
Unterbrechungsbestätigung 1221 aussenden.
In beiden Fällen
wird, wenn keine Unterbrechungsbestätigung 1221 vorliegt,
die Session des Terminals 1 nach Aussenden der Unterbrechungsnachricht 1219 aufgehoben.
-
Wenn
zu dieser Zeit der www-Browser 1201 schon die Dateidaten
von //www, xxx/xyz, htm, erhalten hat, dann kann der Nutzer fortfahren,
die Daten durchzusehen, anstatt die Session aufzuheben. Es erübrigt sich
zu sagen, dass keine Notwendigkeit besteht, die Ausführung des
www-Browsers 1201 der Anwendung im Terminal 1 zu
unterbrechen.
-
Nach
Erhalt der Wechselnachricht 1218 weist das Session-Layer-Protokoll 1202 im
Terminal 1 den www-Browser 1201 an, die Gateway-Wechselanzeige
vorzunehmen, und entsprechend der Funktion des www-Browsers 1201 oder
der Nutzerinstruktion kann das Session-Layer-Protokoll 1202 im
Terminal 1 die Unterbrechungsnachricht 1219 an
das Session-Layer-Protokoll 1204 im Gateway 1 aussenden.
-
Die
Schritte des Aussendens der Neustart-Nachricht 1222 vom
Terminal 1 und der Neustart-Bestätigung 1223 vom Gateway 5 sind
die gleichen wie die Neustart-Nachricht 918 und
die Neustart-Bestätigung 919,
die in 9 gezeigt sind, und damit entfallen hier weitere
Erläuterungen.
-
Gemäß den oben
beschriebenen Sequenzen ist die Session des Terminals 1,
welche unterbrochen war, neu zu starten.
-
Wenn
unter diesen Bedingungen der Nutzer mit dem www-Browser 1201 im
Terminal arbeitet und Befehl gibt, auf eine Datei von //www, xxx/xyz,
htm zuzugreifen, dann wird INVOKE < REQUEST
(get, //www, xxx/xyz, htm) > 1224,
also ein Funkkommunikationsprotokollbefehl, vom Protokollübersetzer 1209 im
Gateway 5 übersetzt
in REQUEST (get, //www, xxx/xyz, htm) 1225, das ist ein
http-Befehl, und zum Server 6 geschickt.
-
Die
www-Server-Software 1211 im Server 6 erhält das REQUEST
(get, //www, xxx/xyz, htm) 1205 und sendet Dateidaten //www,
xxx/xyz, htm durch RESPONSE (Daten) 1226 aus.
-
Die
RESPONSE (Daten) 1226, also eine http-Antwort, wird vom
Protokollübersetzer 1209 im Gateway 5 übersetzt
in REPLAY < RESPONSE
(Daten) > 1227,
das ist eine Antwort des Funkkommunikationsprotokolls, und vom Session-Layer-Protokoll 1208 im
Gateway 5 zum Terminal 1 gesendet.
-
Entsprechend
diesen Schritten ist es möglich,
die Kommunikation zwischen Terminal 1 und Terminal 6 über das
Gateway 5 vorzunehmen, und ein Nutzer kann die Dateidaten
von //www, xxx/xyz, htm im Server 6 mit Hilfe des www-Browsers 1201 durchsehen.
-
<Die
Erzeugung einer neuen Verbindung während der Verhandlung>
-
Mit
Bezug auf 13 wird hier eine Sequenz für den Fall
erläutert,
dass eine neue Kommunikation zwischen dem Terminal und dem Server
während
der Verhandlungen gebildet wird.
-
Die
Sessionverbindungswechselabfrage vom Gateway 4 an das Gateway 5 und
die Schritte von den Instruktionen bis zu den Bestätigungen
zwischen dem Session-Layer-Protokoll
und der Management-Entität
im Gateway 5 sind hierbei die gleichen wie in 12.
-
Danach
entsteht die Kommunikation zwischen dem Terminal 1 und
dem Server 6, ehe die Sessionwechselbestätigung vom
Gateway 5 an das Gateway 4 geschickt wird, wobei
die Bedingungen in 13 veranschaulicht sind.
-
Somit
tritt der Fall ein, dass ein Unterschied besteht zwischen den Kommunikationsbedingungen zwischen
dem Terminal 1 und dem Gateway 4, was durch die
Sessionwechselanfrage vom Gateway 4 zum Gateway 5 mitgeteilt
wird, und der Kommunikationsbedingung zwischen dem Terminal 1 und
dem Gateway 4, nachdem Terminal 1 die Kommunikation mit
dem Server 6 durchgeführt
hat, ehe die Sessionwechselbestätigung
abgeschickt wurde. Die Folge kann sein, dass diese Kommunikationsbedingungen nicht
zueinander passen.
-
Die
Information, welche die Kommunikationsbedingungen zwischen dem Terminal 1 und
dem Gateway 5 beinhaltet, ist TID, wie am linken Ende der 13 gezeigt.
Hier ist das TID, das zusammen mit der Sessionwechselanfrage vom
Gateway 4 ans Gateway 5 geschickt wurde, TID = 1,
wie in der oberen Position dargestellt. Das TID, nachdem das Terminal 1 die
Kommunikation mit dem Server 6 durchführt, ist TID = 2,
wie in der mittleren Position gezeigt. Daher ist das zum Gateway 5 geschickte
TID = 1 im gegenwärtigen
Status verschieden vom TID = 2, und es besteht die Möglichkeit,
dass ein Fehler in der Kommunikationsverarbeitung zwischen Terminal 1 und
Gateway 5 nach dem Gatewayverbindungswechsel auftritt.
-
Selbst
wenn die Kommunikation zwischen dem Terminal 1 und dem
Server 6 während
der Verhandlungen zwischen den Gateways entsteht, muss zur Aufrechterhaltung
der TID-Anpassung das letzte TID (TID = 2 in 13)
gleichzeitig mit dem Senden der Neustart-Nachricht vom Terminal 1 ans
Gateway 5 gesendet werden.
-
<Das
Wechselverfahren für
ein Mehrfachterminal>
-
Das
Stopp-Timing für
das Gateway in Verbindung mit einem Mehrfach(Plural)-Terminal ist in 4 erläutert.
-
Das
Gateway 4 steht in Verbindung mit einem Gateway 1, 15 bzw. 17.
Unter diesen Bedingungen wird die Sessionwechselverhandlung zwischen den
Gateways 4 und 5 in gleicher Weise wie in 12 durchgeführt.
-
Obwohl
die Sessionwechselverhandlung gemäß 14 mit
dem Terminal 1, 17 und 15 gleichzeitig
durchgeführt
wird, kann die Verhandlung auch mit jedem Terminal unabhängig erfolgen.
-
Nach
Durchführung
der Sessionwechselverhandlung mit dem Gateway 4 und 5 (Sessionwechselanfrage 1401 → Sessionwechselbestätigung 1402) sendet
das Gateway 4 die Wechselnachricht zum Terminal 1, 17 bzw. 15.
Jedes Terminal 1, 17 und 15 sendet die
Unterbrechungsnachricht 1403a, 1403b und 1403c an
das Gateway 4. Nach Erhalt der Unterbrechungsinstruktion 1404a, 1404b und 1404c von jedem
Terminal, das mit dem Gateway 4 in Verbindung steht, sendet
das Gateway 4 die Unterbrechungsbestätigung 1405a, 1405b und 1405c an
jedes Terminal, und hört
dann auf zu arbeiten.
-
Andererseits
hat jedes Gateway 4 einen Toleranzzeitraum von der Wechselnachricht
an das Terminal bis zur Unterbrechungsnachricht an das Gateway 4,
und wenn der Toleranzzeitraum abgelaufen ist, kann eine Sequenz
zum Stoppen des Gateways 4 vorgeschlagen werden, selbst
wenn es ein Terminal gibt, ohne dass die Unterbrechungsnachricht
an das Gateway 4 geschickt wird.
-
<Der
Fall der Zurückweisung
des Wechsel-Ziel-Gateways>
-
In 15 wird
eine Sequenz für
den Fall erklärt,
dass der Verbindungswechsel des Terminals vom Wechsel-Ziel-Gateway
bei der Verhandlung zurückgewiesen
wird.
-
Soweit
die Sessionwechselanfrage vom Gateway 4 an das Gateway 5 gesendet
wird, ist die Folge die gleiche wie in 12. Das
Gateway 5 sendet die Sessionwechselzurückweisung 1501 an
das Gateway 4 wegen Mangel an Leistungsfähigkeit
und Überlastung.
Nach Erhalt der Sessionwechselzurückweisung 1501 sendet
das Gateway 4 die Sessionwechselanfrage 502 an
das Gateway 16 als neues Wechsel-Ziel. Paßt Leistungsfähigkeit
des Gateways 16 zum Terminal, dann sendet es die Sessionwechselbestätigung 1503 an
das Gateway 4, und dann wird der Verbindungswechsel durchgeführt.
-
Wie
oben beschrieben, kann das Gateway 4 selbst dann, wenn
der Verbindungswechsel vom Wechsel-Ziel-Gateway zurückgewiesen
wird, die Verhandlung mit einem anderen Gateway durchführen, um
ein Wechsel-Ziel-Gateway
zu finden. Diese Funktion kann in die Management-Entität im Wechsel-Original-Gateway
enthalten sein. Die Konstruktion ist dabei die Folgende. Eine Mehrzahl
von Wechsel-Ziel-Gateways kann zuvor mit Prioritätsreihenfolge im Speicher des
Gateways 4 gespeichert sein. Nach Erhalt der Zurückweisungsnachricht
kann die Management-Entität
das als nächstes
angeführte Wechsel-Ziel-Gateway
aus dem Speicher auslesen, und die Sequenz für den Informationsaustausch kann
automatisch durchgeführt
werden.
-
<Der
Fall eines Leistungsfähigkeitsmangels
des Wechsel-Ziel-Gateways>
-
Die
Sequenz in dem Fall, dass das Wechsel-Ziel-Gateway die Information
eines Leistungsfähigkeitsmangels
für das
Terminal zusammen mit der Sessionwechselbestätigung bei der Verhandlung aussendet,
wird mit Bezug auf 16 erläutert.
-
Die
Sequenz, soweit das Gateway 4 die Sessionwechselanfrage
an das Gateway 5 sendet, ist die gleiche wie in 12.
-
Wenn
das Gateway 5 nicht alle Ressourcen anbieten kann, die
vom Terminal entsprechend der Information gefordert werden, welche
das Gateway 4 zusammen mit der Sessionwechselanfrage aussendet,
wobei diese Information eine maximale Dateigröße, Fenstergröße etc.
ist, sendet das Gateway 5 an das Gateway 4 die
Information über
die maximalen Ressource zusammen mit der Sessionwechselbestätigung 1601.
D. h., das Gateway 4 erhält die maximale Ressource,
welche das Gateway 5 dem den Verbindungswechsel verlangenden
Terminal anbieten kann.
-
Das
Gateway sendet die mögliche
maximale Ressource an das Terminal 1 zusammen mit der Wechselnachricht 1602.
Entsprechend dieser Information ändert
das Terminal 1 seine Leistungsfähigkeit (die Information seiner
eigenen Leistungsfähigkeit),
um zur maximalen Ressource des Gateways 5 zu passen.
-
Nach
dem Verbindungswechsel zum Gateway 5 kann gemäß diesem
Prozedere das Terminal 1 die Kommunikation aufgrund der
geänderten
Leistungsfähigkeit
durchführen.
Das Wechsel-Original-Gateway ist mit einer Beurteilungseinrichtung versehen,
welche beurteilt, ob es möglich
ist, die Kommunikation zwischen dem Wechsel-Ziel-Gateway und dem
Terminal 1 durchzuführen,
und wenn dies nicht möglich
ist, kann die Verbindung aufgehoben werden.
-
Weiterhin
ist das Terminal mit einer Beurteilungseinrichtung versehen, die
beurteilt, ob es möglich
ist, die Kommunikation aufgrund der mitgeteilten Leistungsfähigkeit
durchzuführen,
und wenn das nicht möglich
ist, kann die Annahme von Diensten beendet werden.
-
<Der
Fall des Rückübertragungsschritts>
-
19 zeigt
eine Sequenz im Fall des Terminals 1, wobei das Gateway 4 bzw. 5 ein
Datenrückübertragungsprotokoll
enthält.
Obwohl das Rückübertragungsprotokoll
bei der Session-Lager gemäß 19 an
niedrigerer Stelle steht, braucht nicht gesagt zu werden, dass das
Rückübertragungsprotokoll in
der Session Lager enthalten ist.
-
Nachdem
gemäß 12 INVOKE < REQUEST (get, //www,
xxx/xyz, htm) > 1203 (ein
Befehl des Funkkommunikationsprotokolls) vom Protokollübersetzer 1205 übersetzt
ist in REQUEST (get, //www, xxx/xyz, htm) 1207 (ein Befehl
von http) und an den Server 6 gesendet worden ist, sendet
das Session-Layer-Protokoll 1204 im Gateway ACK 1228 (Bestätigung des
Funkkommunikationsprotokolls) an das Session-Layer-Protokoll 1202 im
Terminal 1. Bei Empfang des ACK 1228 entscheidet
das Terminal 1, dass das Gateway 4 INVOKE < REQUEST (get, //www,
xxx/xyz, htm) > 1203 erhalten
hat.
-
Wenn
vom Protokollübersetzer 1205 im Gateway 4 RESPONSE
(Daten) 1212 (eine Antwort von http) in REPLAY < RESPONSE (Daten) > 1213 (eine
Antwort des Funkkommunikationsprotokolls) übersetzt ist und dann vom Session-Layer-Protokoll 1204 im
Gateway an das Terminal 1 gesendet ist, dann sendet das
Session-Layer-Protokoll 1202 im Terminal 1 bei
Empfang von REPLAY < RESPONSE (Daten) > 1213 ACK 1230 an
das Gateway 4. Bei Erhalt von ACK 1230 entscheidet
das Gateway 4, dass Terminal 1 das REPLAY <RESPONSE (Daten) > 1212 empfangen
hat.
-
Nach
der Neustart-Bestätigung 1223 wird
INVOKE < REQUEST
(get, //www, xxx/xyz, htm) > 1224 vom
Protokollübersetzer 1209 im
Gateway 5 übersetzt
in REQUEST (get, //www, xxx/xyz, htm) 1225 und dann zum
Server 6 geschickt. Zu dieser Zeit sendet das Session-Layer-Protokoll 1208 im
Gateway 5 AK 1231 an das Session-Layer-Protokoll 1202 im Terminal 1,
und bei Empfang von REPLAY < RESPONSE
(Daten) > 1227 sendet
das Session-Layer-Protokoll 1202 im Terminal 1 AK 1233 an
das Gateway 5.
-
Das
Rückübertragungsprotokoll
im Terminal 1, Gateway 4 und 5 wird später anhand
von 20 erläutert.
-
Wenn
das Terminal 1 AK 1314 vom Gateway 4 nicht
innerhalb einer festgelegten Zeit nach dem Aussenden von INVOKE < REQUEST (get, //www, xxx/xyz,
htm) > 1309 erhalten
kann, dann führt
das Rückübertragungsprotokoll 1303 im
Terminal 1 die Rückübertragung
von INVOKE < REQUEST
(get, //www, xxx/xyz, htm) > 1310 durch.
-
Wenn
ACK 1314 vom Gateway 4 zurückkommt, stoppt das Terminal 1 die
Rückübertragung. Das
Terminal 1 enthält
einen Timer zum Auszählen der
festgelegten Zeit, die einen maximalen festgelegten Wert für die Frequenz
der Rückübertragung
hat. Wenn die Frequenz der Rückübertragung über einem maximalen
festgelegten Wert liegt, dann trennt das Terminal 1 die
Verbindung auf aufgrund einer Entscheidung, dass irgendein Fehler
in der Kommunikation zwischen dem Terminal 1 und dem Gateway 4 vorliegt.
-
Gleichzeitig,
wenn das Gateway 4 ACK 1319 vom Terminal 1 nicht
innerhalb einer festgelegten Zeit nach dem Aussenden von REPLAY <RESPONSE (Daten) > 1316 erhalten
kann, führt
das Rückübertragungsprotokoll 1304 im
Gateway 4 die Rückübertragung
von REPLAY <RESPONSE
(Daten) > 1317 durch.
-
Wenn
ACK 1319 vom Terminal 1 zurückkommt, stoppt das Gateway 4 die
Rückübertragung. Das
Gateway 4 enthält
einen Timer zum Auszählen der
festgelegten Zeit, die einen maximal festgelegten Wert für die Frequenz
der Rückübertragung
hat. Während
die Frequenz der Rückübertragung über dem
maximalen festgelegten Wert liegt, dann trennt das Gateway 4 die
Kommunikation zwischen dem Terminal 1 und dem Gateway 4 auf
aufgrund einer Entscheidung, dass irgendein Fehler in der Kommunikation
vorliegt.
-
<Die
Unterbrechungsanzeige>
-
17 zeigt
eine Sequenz im Fall der Durchführung
der Unterbrechungsanzeige für
den Nutzer.
-
Die
Sequenz bis zur Wechselnachricht 1714 ist die gleiche wie
in 12 und wird daher hier nicht wiederholt.
-
Das
Session-Layer-Protokoll 1702 im Terminal 1 sendet
die Unterbrechungsnachricht 1706 an das Session-Layer-Protokoll 1704 im
Gateway 4, und gleichzeitig wird die Unterbrechungsanzeigenachricht 1708 an
die Anwendung 1701 im Terminal gesendet. Wenn die Anwendung 1701 die
Unterbrechungsanzeigenachricht 1708 erhält, wird das Unterbrechungsanzeige 1709 auf
dem Bildschirm des Terminals 1 ausgeführt.
-
Als
Unterbrechungsanzeige 1709 zeigt der Bildschirm Nachrichten
an, wie „das
Gateway wegen des „Version-up"-Betriebs stoppt,
und der Verbindungswechsel zum Gateway 5 wird vorgenommen", mit dem Ziel, dem
Nutzer verständlich
zu machen, dass es im Gateway, Terminal und Netzwerk kein Problem
gibt.
-
Danach
sendet das Session-Layer-Protokoll 1702 im Terminal 1 die
Neustart-Nachricht 1711 an das
Session-Layer-Protokoll 1710 im Gateway 5, und das
Session-Layer-Protokoll 1710 im Gateway 5 sendet
die Neustart-Bestätigung 1712 zurück zum Session-Layer-Protokoll 1702 im
Terminal 1.
-
Andererseits
kann das Session-Layer-Protokoll 1702 im Terminal 1 gemäß der Instruktion
des Nutzers während
einer Zeit des Unterbrechungsanzeige 1709 die Neustart-Nachricht 1711 an
das Session-Layer-Protokoll 1710 im Gateway 5 senden.
-
Nach
Empfang der Neustart-Nachricht 1712 sendet das Session-Layer-Protokoll 1702 im
Terminal 1 die Neustartanzeigenachricht 1713 an
die Anwendung 1701, welche die Unterbrechungsanzeige 1709 bei
Empfang der Neustartanzeigenachricht 1713 fertig stellt.
-
<Die
Erzeugung des Funkkommunikationsprotokollbefehls nach der Wechselnachricht>
-
1 zeigt
die Sequenz im Fall der Erzeugung eines Befehls des Funkkommunikationsprotokolls
vom Terminal 1 unmittelbar nach der Wechselnachricht. Bei
dieser Ausführungsform
wird ein Transaktionskonzept eingeführt.
-
Die
logische Verbindung zwischen Terminal 1 und Gateway 4 wird
als „Session" bezeichnet, und die
aktuelle Datenkommunikation durch die Anwendung wird als „Transaktion" bezeichnet. Die
Transaktion gibt die Betriebsabfolge und Verarbeitung von der Anfrage/Nachricht
des Nutzers bis zur entsprechenden Antwort des Servers oder von
der Anfrage/Mitteilung des Servers bis zur entsprechenden Antwort
des Nutzers an. Hier enthält
eine Session mehrere Transaktionen. Um Anfrage/Nachricht/Antwort
entsprechend zu unterscheiden, hat jede Transaktionseinheit einen
Identifizierer (eine Transaktionsidentifizierung).
-
Die
Sequenz bis zur Wechselnachricht 1713 ist die gleiche wie
in 19 und wird hier nicht mehr erläutert.
-
Weil
das Gateway 4 bereits die GatewayWechselnachricht 1713 an
das Session-Layer-Protokoll 1702 im
Terminal 1 geschickt hat, hält es den Inhalt von INVOKE < REQUEST (get, //www,
xxx/xyz, htm) > 1719 fest.
-
Nach
Erhalt der Wechselnachricht 1713 sendet das Session-Layer-Protokoll 1702 im
Terminal 1 die Unterbrechungsnachricht 1714 an
das Session-Layer-Protokoll 1705 im Gateway 5.
Das Session-Layer-Protokoll 1705 im Gateway 5 informiert
die Management-Entität 1707 über den
Empfang der Unterbrechungsnachricht 1705, und die Management-Entität 1707 sendet
an die Management-Entität 1711 im
Gateway 5 die Transaktionsinformation 1716 (Transaktionsbedingungen,
Transaktions-ID, und den Inhalt von INVOKE < REQUEST (get, //www, xxx/xyz, htm) >).
-
Die
folgenden Schritte, also die Schritte „Unterbrechungsbestätigung 1015 → Neustart-Nachricht 1717 → Neustart-Bestätigung 1718" ist die gleiche wie
die der Schritte „Unterbrechungsbestätigung 917 → Neustart-Nachricht 918 → Neustart-Bestätigung 919" in 9 und
wird hier nicht nochmals erläutert.
-
Wenn
die Session zwischen dem Session-Layer-Protokoll 1702 im
Terminal 1 und dem Session-Layer-Protokoll 1709 im
Gateway 5 beginnt, greift das Session-Layer-Protokoll 1709 im Gateway 5 auf
die Transaktionsbedingungen und das Transaktions-ID zurück, welches
es als Transaktion 1716 erhalten hat, und übersetzt
den Inhalt von REQUEST in REQUEST (get, //www, xxx/xyz, htm) > 1720 mit
Hilfe des Protokollübersetzers 1710 und
sendet es an den Server 6.
-
Die
Sequenz von dem folgenden Schritt bis ACK 1725 des Funkkommunikationsprotokolls
ist dieselbe wie in 19 und wird hier nicht mehr
erläutert.
-
Es
kann hier vorgesehen werden, dass INVOKE < REQUEST (get, //www, xxx/xyz, htm) > 1719, wie
vom Terminal 1 gesendet, vom Protokollübersetzer 1720 im
Gateway 4 übersetzt
wird in REQUEST (get, //www, xxx/xyz, htm) > 1720 und an die Management-Entität 1711 im
Gateway 5 als Transaktionsinformation 1716 gesendet
wird.
-
Und
obwohl die Management-Entität 1707 im
Gateway 4 die Kommunikation mit der Management-Entität 1711 im
Gateway 5 nach Empfang der Unterbrechungsnachricht 1714 durchführt, kann
die Kommunikation auch vor Empfang der Unterbrechungsnachricht 1714 durchgeführt werden.
-
Im
Fall, dass ACK nicht vom Terminal 1 und dem Gateway 4, 5 gesendet
wird, kann die Sequenz in gleicher Weise wie die Sequenz ohne Senden
von ACK 1722 und 1725 durchgeführt werden, weil nämlich die
Sequenz ACK nicht immer notwendig ist.
-
Im
Falle, dass das Terminal 1 und das Gateway 4 und 5 Rückübertragungsprotokolle
enthalten, kann dieselbe Sequenz durchgeführt werden.
-
<Die
Wechselinstruktion vor Erzeugung der Antwort des Servers>
-
Mit
Bezug auf 22 wird nun eine Sequenz für den Fall
erläutert,
dass die Serverwechselinstruktion von einem Operator des Gateways 4 ausgeht, ehe
das Gateway 4, welches schon einen Befehl des Funkkommunikationsprotokolls
vom Terminal 1 erhalten hat und eine entsprechende ACK
des Funkkommunikationsprotokolls an das Terminal 1 ausgeschickt
hat, die http-Antwort
vom Server erhält.
-
Mit
Ausnahme der Bedingungen ohne Erzeugung einer http-Antwort vom Server 6 und
einer ACK entsprechend der Antwort vom Terminal 1 ist in 22 die
Sequenz bis zur Wechselnachricht 1813 die gleiche wie in 19 und
wird hier nicht mehr erläutert.
-
Das
Gateway 4 behält
den Inhalt von REQUEST (get, //www, xxx/xyz, htm) > 1823, das
zum Server 6 geschickt worden ist, bis es vom Server die entsprechende
RESPONSE (DATEN) 1819 erhält.
-
Das
Session-Layer-Protokoll 1802 im Terminal 1 erhält die Wechselnachricht 1813 und
sendet dann die Unterbrechungsnachricht 1814 an das Session-Layer-Protokoll 1805 im
Gateway 4. Das Session-Layer-Protokoll 1805 im
Gateway 4 informiert die Management-Entität 1807,
dass die Unterbrechungsnachricht 1814 empfangen worden
ist, und erhält vom
Server 6 RESPONSE (Daten) 1819 entsprechend REQUEST
(get, //www, xxx/xyz, htm) > 1823. Damit
kann der Protokollübersetzer 1806 im
Gateway 4 von dem REQUEST (get, //www, xxx/xyz, htm) des
http-Befehls übersetzen
zur Antwort des Funkkommunikationsprotokolls (die äquivalenten
Daten zu REPLAY < RESPONSE
(Daten) > 1820,
wie später
beschrieben. Danach empfängt
die Management-Entität 1811 im
Gateway 5 die Transaktionsinformation 1816 (die
Transaktionsbedingungen, die Transaktions-ID und den Inhalt des übersetzten
REPLAY < RESPONSE
(Daten) >) über die
Management-Entität 1807 im
Gateway 4.
-
Die
folgende Sequenz der Unterbrechungsbestätigung 1815 und die
Neustart-Nachricht
ist die gleiche wie in 19 und wird daher hier nicht
weiter erläutert.
Wenn die Session zwischen dem Session-Layer-Protokoll 1802 im
Terminal 1 und dem Session-Layer-Protokoll 1809 im
Gateway 5 neu startet, betrachtet das Session-Layer-Protokoll 1809 im Gateway 5 die
empfangenen Transaktionsbedingungen und Transaktions-ID als Transaktionsinformation und
sendet REPLAY < RESPONSE
(Daten) > 1820 vom
Session-Layer-Protokoll 1809 an das Session-Layer-Protokoll 1802 im
Terminal 1.
-
Die
Sequenz ACK des Funkkommunikationsprotokolls ist dieselbe wie in 9,
so dass hier auf eine Erläuterung
verzichtet wird.
-
Die
Anordnung kann hier so getroffen werden, dass REPLAY < RESPONSE (Daten) > 1819, wie
vom Server 6 gesendet, nicht vom Protokollübersetzer 1806 in
Gateway 4 übersetzt
wird, und von der Management-Entität 1807 im Gateway 4 an
die Management-Entität 1811 im
Gateway 5 als Transaktionsinformation 1816 gesendet
wird und schließlich vom
Protokollübersetzer 1810 im
Gateway 5 in REPLAY < RESPONSE
(Daten) > 1820 übersetzt
wird.
-
Wenn
das ACK nicht vom Terminal 1, Gateway 4 und 5,
ausgesendet wird, kann dieselbe Sequenz ohne Aussendung von ACK 1824 und 1821 durchgeführt werden.
Daher ist der Schritt von ACK nicht immer erforderlich.
-
Nun
kann dieselbe Sequenz wie die in 21 gezeigte
durchgeführt
werden, d. h. der Inhalt von REQUEST wird zum Gateway 5 als
Transaktionsinformation 1816 gesendet, und das Gateway 5 sendet
den http-Befehl an den Server 6. Und wenn das Terminal 1 und
das Gateway 4 und 5 das Rückübertragungsprotokoll enthalten,
kann auch dieselbe Sequenz durchgeführt werden.
-
<Fall
ohne ACK vom Terminal>
-
Im
Falle, dass, mit Bezug auf 23, die Serverwechselinstruktion
vom Operator des Gateways 4 ausgeht, wenn das ACK des Funkkommunikationsprotokolls
nicht vom Terminal 1 zurückgesendet wird, hat eine Sequenz
durch das Gateway 4 die Antwort des Funkkommunikationsprotokolls
zum Terminal gesendet nach Empfang des Befehls des Funkkommunikationsprotokolls
vom Terminal 1 und der Antwort des http vom Server 6,
und diese Sequenz wird später
noch erläutert.
-
Die
Sequenz bis zur Wechselnachricht 1913, mit Ausnahme, dass
ACK entsprechend REPLAY < RESPONSE
(Daten) > 1924 nicht
vom Terminal 1 zum Gateway gesendet worden ist, ist die
gleiche wie in 19 und wird daher hier nicht
erläutert.
-
Während dieser
Zeit führt
aber das Rückübertragungsprotokoll 1904 im
Gateway 4 die Rückübertragungssteuerung
des REPLAY < RESPONSE (Daten) > 1924 durch.
-
Nach
Empfang der Wechselnachricht 1913 sendet das Session-Layer-Protokoll 1902 im
Terminal 1 die Unterbrechungsnachricht 1914 an
das Session-Layer-Protokoll 1905 im
Gateway 5.
-
Das
Session-Layer-Protokoll 1905 im Gateway 5 informiert
die Management-Entität 1907 darüber, dass
die Unterbrechungsnachricht 1914 empfangen wurde. Die Management-Entität 1907 sendet
an die Management-Entität 1911 im
Gateway 5 die Transaktionsinformation einschließlich der
Transaktionsbedingungen, der Häufigkeit
der Rückübertragung
der Transaktions-ID,
des Vorrückwertes
des Rückübertragungstimers
und des Inhalts von REPLAY <RESPONSE
(Daten) >.
-
Die
folgende Sequenz der Unterbrechungsbestätigung 1915 und der
Neustart-Nachricht
ist dieselbe wie in 19 und wird hier nicht nochmals
erläutert.
-
Nachdem
die Sitzung zwischen dem Session-Layer-Protokoll 1902 im
Terminal 1 und im Session-Layer-Protokoll 1909 im
Gateway 5 neu startet, referiert das Session-Layer-Protokoll 1909 im
Gateway 5 die Transaktionsbedingungen, die Häufigkeit der
Rückübertragung
der Transaktions-ID und den Vorrückwert
des Rückübertragungstimers,
wie als Transaktionsinformation 1916 empfangen, und sendet
dann den Inhalt von RESPONSE (Daten) 1926 vom Rückübertragungsprotokoll 1908 zum
Session-Layer-Protokoll 1902 im Terminal 1.
-
Die
Sequenz von ACK 1927 des Funkkommunikationsprotokolls ist
die gleiche wie in 19 und wird hier nicht mehr
erläutert.
-
Hier
ist RESPONSE (Daten) 1923 inzwischen zum REPLAY <RESPONSE (Daten) > des Funkkommunikationsprotokolls
vom Protokollübersetzer 1906 im
Gateway 4 übersetzt
worden. Wenn jedoch die Management-Entität 1907 im Gateway 4 die
Transaktionsinformation 1916 an die Management-Entität 1911 im
Gateway 5 sendet, ist der Inhalt von RESPONSE (Daten) in
die Transaktionsinformation 1916 in einem Format der http-Protokollantwort einzufügen, und
kann dann wieder zu REPLAY < RESPONSE
(Daten) > 1926 des
Funkkommunikationsprotokolls vom Protokollübersetzer 1910 im
Gateway übersetzt
werden.
-
Die
Sequenz im Fall, dass das Gateway 4 und 5 ACK
nicht sendet, kann in gleicher Weise wie die Sequenz durchgeführt werden,
bei der ACK 1922 des Funkkommunikationsprotokolls nicht
ausgesendet wird.
-
Die
Sequenz im Falle, dass Terminal 1 und Gateway 5 das
Rückübertragungsprotokoll
enthalten, kann in gleicher Weise durchgeführt werden.
-
Gemäß der oben
beschriebenen Sequenz ist es selbst dann, wenn die Anwendung im
Terminal die Daten für
die Anfrage nicht erhält,
möglich,
den Gatewaywechsel des Terminals vorzunehmen. Daher ist es möglich, den
Gatewayverbindungswechsel ohne viel Einfluss auf die Anwendung im
Terminal und den Nutzer vorzunehmen.
-
Ausführungsform
5
-
Selbst
bei einer üblichen
Struktur, wie sie beispielsweise 5 zeigt,
lassen sich in einem Fall, wo es keinen Verbindungskanal zwischen
Gateways gibt und die Verhandlung zwischen Gateways nicht durch
die Verbindungseinrichtung zwischen Gateways über ein Netzwerk und die Verbindungseinrichtung
zwischen einem Mehrfach-Gateway und einem Server durchgeführt werden
kann, durch Anwendung der Erfindung in einem solchen Falle Wirkungen
erzielen.
-
Mit
Bezug auf die 5, 24, 25, 26 und 27 wird
die Gateway-Wechsel-Sequenz ohne Verhandlungseinrichtung zwischen Gateways
bei der Ausführungsform 5 erläutert. Ein Gateway 11 und
ein Gateway 12 teilen sich in einen Server 6,
der dadurch mit dem Netzwerk 3 verbunden wird. Die Gateways 11 und 12 sind
nicht mit einer Einrichtung für
Verhandlungen zwischen ihnen versehen. Das Terminal 1 ist
mit dem Server 6 über
eine Basisstation 2, das Netzwerk 3 und das Gateway 11 oder 12 verbunden,
wobei die Anwendung unter Verwendung der Information 7 im
Server 6 durchgeführt wird.
-
Das
Session-Layer-Protokoll 2002 im Terminal 1 führt die
Kommunikation mit der Anwendung 2011 im Server 6 über das
Gateway 11 durch, um die Anwendung 2001 auszuführen. Da
das bei der Kommunikation 2003 zwischen dem Session-Layer-Protokoll 2002 im
Terminal 1 und dem Session-Layer-Protokoll 2004 im Gateway 11 benutzte
Kommunikationsprotokoll sich von dem in der Kommunikation 2007 zwischen
dem Session-Layer-Protokoll 2004 im Gateway 11 und
dem Server 6 unterscheidet, sorgt der Protokollübersetzer 2005 im
Gateway 11 für
die Protokollübersetzung.
-
Die
Kommunikation 2003 wird durch den Protokollübersetzer 2005 in
das Kommunikationsprotokoll übersetzt,
das bei der Kommunikation 2007 zwischen dem Gateway 11 und
dem Server 6 verwendet wird; damit kann die Kommunikation
zwischen Terminal 1 und Server 6 durchgeführt werden. Es
gibt aber einige Anwendungsarten, welche keine Protokollübersetzung
erfordern, und in diesem Fall erfolgt keine Protokollübersetzung
nicht im Gateway.
-
Wenn
die Serverwechselinstruktion 2002 vom Operator ausgegeben
wird, während
das Terminal 1 in Kommunikation mit dem Server 6 steht,
dann sendet die Management-Entität 2006 im
Gateway 11 die Wechselinstruktion 2013 zum Session-Layer-Protokoll 2004,
damit das kommunizierende Terminal 1 den Verbindungswechsel
zum Gateway 12 vornimmt.
-
Nach
Empfang der Wechselnachricht 2014 teilt das Session-Layer-Protokoll 2004 dem
Session-Layer-Protokoll 2002 im Terminal 1 Information der
Wechsel-Ziel-Gatewayadresse
usw. mit. Zu dieser Zeit kann die Wahl des Wechsel-Ziel-Gateways, vom Gateway 11 informiert,
durchgeführt
werden durch Suchen des Gateways mit zulässiger Leistungsfähigkeit
für das
Terminal 1 entsprechend der Information der anderen Gateways,
die zuvor im Gateway 11 aufgezeichnet war, oder andernfalls
entsprechend der Instruktion des Operators.
-
Wenn
das Terminal 1 zum ersten Mal die Wechselnachricht 2014 erhält, kann
es die Adresseninformation des Gateways 12 als Wechsel-Ziel-Gateway
erhalten. Das Terminal 1 empfangt nämlich die Information für den Serververbindungswechsel
durch die Wechselnachricht 2014 vom Gateway 11.
Daher ist es nicht erforderlich, immer die Information eines Mehrfachgateways
für den
Gatewayverbindungsaustausch im internen Speicher des Terminals 1,
beispielsweise eine Harddisk, IC-Karte, Flash-ROM, EEP-ROM und RAM
mit Batterieunterstützung
zu speichern.
-
Nach
Empfang der Wechselnachricht 2014 sendet das Session-Layer-Protokoll 2002 im
Terminal 1 die Unterbrechungsnachricht 2015 an
das Session-Layer-Protokoll 2004 im
Gateway 11 zu einem geeigneten Zeitpunkt für die Unterbrechung
der Sitzung, beispielsweise zu dem Zeitpunkt, wo die Ausführungsanwendung 2001 nicht
in Kommunikation mit der Anwendung 2011 im Server 6 steht.
-
Das
Session-Layer-Protokoll 2004 im Gateway 11 informiert
die Management-Entität 2006 über den
Empfang der Unterbrechungsnachricht 2015, und die Management-Entität 2006 sendet
die Unterbrechungsnachricht 2016 an das Session-Layer-Protokoll 2004 im
Gateway 11.
-
Nach
Empfang der Unterbrechungsnachricht 2016 sendet das Session-Layer-Protokoll 2004 im Gateway 11 die
Unterbrechungsbestätigung 2017 an das
Session-Layer-Protokoll 2002 im Terminal 1.
-
Danach
wird das Session-Layer-Protokoll 2002 im Terminal 1 unterbrechen.
-
Das
Terminal 1 kann aber nach Senden der Unterbrechungsnachricht 2015 an
das Session-Layer-Protokoll 2004 im Gateway 1 mit
der Serververbindungswechselsequenz unabhängig von den Bedingungen des
Gateways 11 fortfahren.
-
Demgemäss ist alles
in Ordnung mit der Unterbrechungsinstruktion 2016 und der
Unterbrechungsbestätigung 2017,
oder das Session-Layer-Protokoll 2004 kann die Unterbrechungsbestätigung 2017 an
das Session-Layer-Protokoll 2002 im Terminal 1 unabhängig ohne
Unterbrechungsinstruktion 2016 senden. Es gibt auch einen
Fall, bei dem in einem Typ von Gateway nur die Unterbrechungsinstruktion
ohne die Unterbrechungsbestätigung 2017 ausgesendet
wird.
-
In
beiden Fällen
wird dann, wenn es keine Unterbrechungsbestätigung 2017 gibt,
die Session des Terminal 1 nach dem Aussenden der Unterbrechungsinstruktion 2015 unterbrochen.
Die Anordnung kann folgendermaßen
getroffen werden: Wenn das Session-Layer-Protokoll 2002 im
Terminal 1 die Wechselnachricht 2014 empfängt, wird
die Anwendung 2001 instruiert, die Gatewaywechselanzeige auszuführen. Entsprechend
der Funktion der Anwendung 2001 oder der Instruktion des
Nutzers, sendet das Session-Layer-Protokoll 2002 im Terminal 1 die Unterbrechungsnachricht 2015 an
das Session-Layer-Protokoll 2004 im Gateway 11.
-
Das
Session-Layer-Protokoll 2002 im Terminal 1 sendet
an das Session-Layer-Protokoll 2008 im Gateway 12 die
Neustart-Nachricht einschließlich
Information von Terminal-Adressen, Session-ID, maximale Datengröße, Window-Größe etc..
-
Nach
Empfang der Neustart-Nachricht 2018 sendet das Session-Layer-Protokoll 2008 im
Gateway 12 die Neustart-Bestätigung 2019. Entsprechend
der Neustart-Bestätigung 2019 vom
Session-Layer-Protokoll 2008 im Gateway 12 wird
die Sitzung des aufgehobenen Terminals 1 neu gestartet.
-
Nach
dem Neustart der Sitzung führt
das Session-Layer-Protokoll 2002 im Terminal 1 die
Kommunikation 2020 und 2021 mit der Anwendung 2011 im
Server 6 über
den Protokollübersetzer 2009 im Gateway
durch, um die Anwendung 2001 auszuführen.
-
Es
wird angenommen, dass das Gateway 12 das Terminal 1 über ein
Gateway informiert, welches die Leistungsfähigkeit hat, zum Terminal 1 als
Wechsel-Ziel-Gateway
in den oben beschriebenen Sequenzen zu passen. Im Falle der Entscheidung,
dass das Wechsel-Ziel-Gateway nicht die Leistungsfähigkeit
hat, um nach dem Verbindungswechsel zum Wechsel-Ziel-Gateway zum
Terminal 1 zu passen, erfolgt somit kein Wechsel mit schlechter
Effizienz, so dass der Verbindungswechsel zu einem anderen Gateway
nochmals vorgenommen werden sollte. Es ist auch möglich, den
Gatewayverbindungswechsel ohne großen Einfluss auf die Anwendung 2001 im Terminal
und den Nutzer vorzunehmen.
-
Mit
Bezug auf 25 wird die Sequenz für den Fall
der Erzeugung eines Befehls des Funkkommunikationsprotokolls vom
Terminal 1 unmittelbar nach der Wechselnachricht 2113 erläutert.
-
Die
Sequenz bis zur Wechselnachricht 2113 ist dieselbe wie
in 24 und wird daher hier nicht mehr erläutert.
-
Der
Protokollübersetzer 2016 im
Gateway 4 übersetzt
von INVOKE < REQUEST
(get, //www, xxx/xyz, htm) > 2119 des
Funkkommunikationsprotokollbefehls in REQUEST (get, //www, xxx/xyz,
htm) 2116 des http-Befehls und sendet dies zum Server 6. Zur
gleichen Zeit der Information von REQUEST (get, //www, xxx/xyz,
htm) 2116 an den Server 6 überträgt das Gateway 4 auch
die Adresse des Gateways, zu welchem RESPONSE (Daten) (hier als 2122 gezeigt) entsprechend
dem REQUEST (get, //www, xxx/xyz, htm) 2116 gesendet worden
ist.
-
Die
mitgeteilte Gatewayadresse kann als vom http-Befehl unterschiedliche
Information behandelt werden wie oben, andernfalls kann sie in den http-Befehl
eingebaut sein. Ist die Gatewayadresse im http-Befehl enthalten,
dann muss der Server 6 den http-Befehl analysieren und
dann die Gatewayadresse herausziehen.
-
Die
folgende Sequenz der Unterbrechungsbestätigung 2115 und der
Neustart-Nachricht
ist die gleiche wie in 24 und wird daher hier nicht
beschrieben.
-
Nachdem
die Sitzung zwischen dem Session-Layer-Protokoll 2102 im
Terminal 1 und dem Session-Layer-Protokoll 2109 im
Gateway 5 beginnt, nimmt das Session-Layer-Protokoll 2109 im
Gateway 5 Bezug auf die Transaktionsbedingungen und die Transaktions-ID,
wie von der Neustart-Nachricht 2117 erhalten,
und sendet ACK 2121 des Funkkommunikationsprotokolls zum
Terminal 1. Das Gateway 5 empfangt vom Server 6 RESPONSE
(Daten) 2122 von der http-Antwort entsprechend dem REQUEST (get,
//www, xxx/xyz, htm) 2116 vom http-Befehl, welches vom
Protokollübersetzer 2110 übersetzt
worden ist, in REPLAY < RESPONSE
(Daten) > 2123 der Funkkommunikationsprotokollantwort,
und wird dann zum Session-Layer-Protokoll 2102 im Terminal 1 gesendet.
Nun kann ACK 2121 vom Session-Layer-Protokoll 2105 im
Gateway 4 an das Terminal 1 gesendet werden.
-
Die
Sequenz vom nächsten
Schritt bis zu ACK 2124 ist dieselbe wie in 19 und
wird daher hier nicht weiter erläutert.
-
Als
nächstes
wird mit Bezug auf 26 eine Sequenz für den Fall
erläutert,
dass die Serveraustauschinstruktion vom Operator des Gateways 4 erzeugt
worden ist, ehe dieses die http-Antwort entsprechend dem http-Befehl
vom Server erhalten hat. Das Gateway hatte INVOKE < REQUEST (get, //www,
xxx/xyz, htm) > 2222 des
Funkkommunikationsprotokollbefehls vom Terminal 1 empfangen
und in Antwort darauf REQUEST (get, //www, xxx/xyz, htm) zum Server 6 gesendet
und gleichzeitig ACK 2224 zum Terminal 1 gesendet.
-
Die
Sequenz bis zur Wechselnachricht 2213 ist dieselbe wie
in den 24 und 19 und
wird daher nicht mehr erläutert.
-
Das
Session-Layer-Protokoll 2202 im Terminal 1 sendet
nach Empfang der Wechselnachricht 2213 die Unterbrechungsnachricht 2214 an
das Session-Layer-Protokoll 2205 im
Gateway 4.
-
Das
Session-Layer-Protokoll 2205 im Gateway 4 teilt
der Management-Entität 2207 den
Empfang der Unterbrechungsnachricht 2214 mit, und die Management-Entität 2007 im
Gateway 4 sendet die Nachricht 2225 an den Server 6 zur Übertragung
von RESPONSE (Daten) 2216 an das Gateway 5.
-
Die
Sequenz der Unterbrechungsbestätigung 2215 und
der Neustart-Nachricht ist dieselbe wie in 24, so
dass hier keine Erläuterung
mehr erfolgt.
-
Nachdem
die Sitzung zwischen dem Session-Layer-Protokoll 2202 im
Terminal 1 und dem Session-Layer-Protokoll 2209 im
Gateway 5 neu gestartet ist, greift das Session-Layer-Protokoll 2209 im Gateway 5 auf
die mit der Neustart-Nachricht 2217 empfangenen Transaktionsbedingungen
und die Transaktions-ID zurück, übersetzt
RESPONSE (Daten) 2216, wie vom Server 6 erhalten,
in REPLAY < RESPONSE
(Daten) > 2220 mit
Hilfe des Protokollübersetzers 210 und
sendet es an das Terminal 1.
-
Die
Sequenz von ACK des Funkkommunikationsprotokolls ist dieselbe wie
in 19 und wird daher hier nicht weiter erläutert.
-
Als
nächstes
wird mit Bezug auf 27 hier eine Sequenz für den Fall
erläutert,
dass die Serverwechselinstruktion vom Operator des Servers 4 erzeugt
wird, wenn das ACK des Funkkommunikationsprotokolls nicht vom Terminal 1 zurückkehrt,
obwohl das Gateway 4 den Funkkommunikationsprotokollbefehl
von dem Terminal und die http-Antwort vom Server 6 erhalten
hat und auch die Antwort des Funkkommunikationsprotokollbefehls
zum Terminal gesendet hat.
-
Die
Sequenz bis zur Wechselnachricht 2313 ist dieselbe wie
bei den 19 und 22, so
das hier keine weitere Erläuterung
erfolgt.
-
Aber
während
dieser Periode wird die in 20 veranschaulichte
Rückübertragungssteuerung
für REPLAY < RESPONSE (Daten) > 2324 vom Rückübertragungsprotokoll 2304 im
Gateway 4 durchgeführt.
-
Die
in 27 gezeigte Sequenz nach den nächsten Schritten wird hier
erläutert.
-
Nach
Empfang der Wechselnachricht 2313 sendet das Session-Layer-Protokoll 2302 im
Terminal 1 die Unterbrechungsnachricht 2314 zum
Session-Layer-Protokoll 2305 im
Gateway 4. Dieses informiert die Management-Entität 2307 über den
Empfang der Unterbrechungsnachricht 2314.
-
Das
Session-Layer-Protokoll 2305 im Gateway 4 behält den Inhalt
von REQUEST (get, //www, xxx/xyz, htm) 2320 bis zum Empfang
von ACK 2329 vom Terminal 1. Unter diesen Bedingungen
sendet das Gateway 4 REQUEST (get, //www, xxx/xyz, htm) 2316 zum
Server 6.
-
Gleichzeitig
mit der Mitteilung von REQUEST (get, //www, xxx/xyz, htm) 2316 an
den Server 6 überträgt das Gateway 4 auch
die Adresse des Gateways, an welches RESPONSE (Daten) (hier als 2327 gezeigt)
entsprechend dem REQUEST (get, //www, xxx/xyz, htm) 2316 gesendet
worden ist.
-
Die
mitgeteilte Gatewayadresse kann als von dem http-Befehl unterschiedliche
Information behandelt werden, wie oben, andererseits kann sie im http-Befehl
enthalten sein. Ist die Gatewayadresse in dem http-Befehl enthalten,
dann muss der Server 6 den http-Befehl analysieren und
dann die Gatewayadresse herausziehen.
-
Die
Sequenz der Unterbrechungsbestätigung 2315 und
die Neustart-Nachricht danach ist dieselbe wie in 24 und
wird daher hier nicht erläutert.
-
Nachdem
die Sitzung zwischen dem Session-Layer-Protokoll 2302 im
Terminal 1 und dem Session-Layer-Protokoll 2309 im
Gateway 5 neu startet, greift das Session-Layer-Protokoll 2209 im
Gateway 5 auf die durch die Neustart-Nachricht 2317 empfangenen
Transaktionsbedingungen und Transaktions-ID zurück, übersetzt RESPONSE (Daten) 2327, wie
vom Server 6 erhalten, mit Hilfe des Protokollübersetzers 2310 in
REPLAY < RESPONSE
(Daten) > 2328 und
sendet es an das Terminal 1.
-
Die
folgende Sequenz bis zum ACK im Funkkommunikationsprotokoll ist
dieselbe wie in 19 und wird hier nicht mehr
beschrieben.
-
Entsprechend
den oben beschriebenen Sequenzen ist es selbst dann, wenn keine
Verhandlungseinrichtung zwischen dem Gateway und der Anwendung vorhanden
ist und das Terminal die Daten für
die Anfrage nicht erhält,
möglich
den Gatewayverbindungswechsels des Terminals durchzuführen. Es ist
also möglich,
den Gatewayverbindungswechsel ohne große Einflüsse auf die Anwendung im Terminal und
den Nutzer vorzunehmen.
-
Die
oben beschriebenen Ausführungsformen sind
zwar so beschaffen, dass das Wechsel-Original-Gateway nach dem Verbindungswechsel
unterbricht (suspends), aber dieses „Unterbrechen" ist keine notwendige
Voraussetzung, und es braucht nicht gesagt zu werden, dass das Ziel-Original-Gateway fortfahren
kann zu arbeiten.
-
Es
wird bei der obigen Ausführungsform
angenommen, dass das Terminal die Wechselinstruktion zur Zeit des
Empfangs der Dienste vom Server erhält, aber die Erfindung ist
nicht hierauf beschränkt. Selbst
wenn das Terminal nämlich
nicht die oben genannten Dienste empfängt, kann das Original-Gateway
nur die Wechselnachricht an das Terminal schicken, und außer der
Wechselnachricht kann die notwendige Information zum Starten der
Kommunikation mit dem Wechsel-Ziel-Gateway an das Terminal geschickt
werden.
-
Man
kann den vorteilhaften Effekt gemäß der oben beschriebenen Erfindung
erhalten, d. h., selbst wenn das in Verbindung mit dem Terminal
stehende Gateway stoppt, können
die Verbindungswechselverhandlungen zwischen den Gateways vor dem Stop
des Gateways durchgeführt
werden, und demgemäß ist es
ohne Beenden der im Terminal ausgeführten Anwendung möglich, in
kurzer Zeit eine Verbindung mit einem anderen Gateway wieder herzustellen,
das die Leistungsfähigkeit
des Zusammenpassens mit dem Terminal hat.
-
Und
auch wenn die Anwendung nicht die Daten für die Anfrage erhält, kann
der Gatewaywechsel durchgeführt
werden. Mit anderen Worten, wenn das Wechsel-Original-Gateway die Transaktionsbedingungen
zum Wechsel-Ziel-Gateway überträgt, dann kann
das Terminal den Gatewaywechsel ohne Rücksicht auf die Transaktionsbedingungen
vornehmen.
-
Können die
Verbindungswechselverhandlungen nicht zwischen den Gateways unmittelbar
durchgeführt
werden oder empfängt
die Anwendung nicht die Daten für
die Anfrage, dann lässt
sich der Gatewaywechsel durchführen.
Es ist möglich,
eine Verbindung mit einem anderen Gateway, dessen Leistungsfähigkeit
zum Terminal passt, in kürzer
Zeit als üblich wieder
herzustellen.
-
In
beiden Fällen
ist es nicht erforderlich, dass das Terminal immer die Information
eines Mehrfachgateways mit der passenden Leistungsfähigkeit
für das
Terminal enthält,
und daher ist es für
das Terminal leicht, den Wechsel der Netzwerkstruktur zu entsprechen.
-
Bei
dieser Anmeldung umfasst der Begriff „funkfähiges Terminal" ein Gerät wie ein
Computerterminal, welches Signale von entfernter Stelle empfangen
und senden kann, z. B. durch eine entfernte und/oder drahtlose Kommunikation
(wie Funk, optische oder irgendeine andere elektromagnetische Kommunikation)
und solche Signale verarbeiten kann.
-
Der
Ausdruck „Wechsel-Original-Gateway" umfasst das Orignalgateway
oder das Gateway, mit dem die Kommunikation aufhört, wenn das verwendete Gateway
ausgetauscht oder gewechselt wird. Gleichermaßen kann der Ausdruck „Wechsel-Ziel-Gateway" als Zielgateway
verstanden werden, d. h. das Gateway, zu welchem eine Kommunikation
nach dem Wechsel des benutzten Gateways umgeleitet wird.
-
Der
Ausdruck „Session-Layer-Protokoll" kann als „Session-Layer-Protokoll
Einrichtung" aufgefasst
werden.