DE69937859T2 - Übertragungssystem zum Kommunikationsaufbau zwischen einem intelligenten Radioterminal und einem Server - Google Patents

Übertragungssystem zum Kommunikationsaufbau zwischen einem intelligenten Radioterminal und einem Server Download PDF

Info

Publication number
DE69937859T2
DE69937859T2 DE69937859T DE69937859T DE69937859T2 DE 69937859 T2 DE69937859 T2 DE 69937859T2 DE 69937859 T DE69937859 T DE 69937859T DE 69937859 T DE69937859 T DE 69937859T DE 69937859 T2 DE69937859 T2 DE 69937859T2
Authority
DE
Germany
Prior art keywords
gateway
change
communication
terminal
exchange
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69937859T
Other languages
English (en)
Other versions
DE69937859D1 (de
Inventor
Reiko Nagoya-shi Yasue
Noritake Yokohama-shi Okada
Nobukazu Higashi-ku Nagoya-shi Ohnishi
Hirohisa Shikatsu-cho Nishikasugaigun Ozaki
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Original Assignee
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Application granted granted Critical
Publication of DE69937859D1 publication Critical patent/DE69937859D1/de
Publication of DE69937859T2 publication Critical patent/DE69937859T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/04Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24Negotiation of communication capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/328Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the presentation layer [OSI layer 6]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/20Manipulation of established connections
    • H04W76/22Manipulation of transport tunnels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0011Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/12Reselecting a serving backbone network switching or routing node
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08Upper layer protocols
    • H04W80/10Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16Gateway arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

  • 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 1217 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.

Claims (26)

  1. Kommunikationssystem zur Herstellung einer Kommunikation zwischen einem funkfähigen intelligenten Terminal (1) und einem Server (6), welches Dienste über ein Gateway an das funkfähige intelligente Terminal (1) liefert und das funkfähige intelligente Terminal (1) in die Lage versetzt, von dem Gateway zu einem anderen Gateway zu wechseln, dadurch gekennzeichnet, dass das funkfähige intelligente Terminal (1) mit einer Kommunikationsaktivierungseinrichtung (902) versehen ist zum Empfang der Adresse eines Wechsel-Ziel-Gateways sowie einer Gatewaywechselnachricht und zur Durchführung einer Startsequenz mit dem Wechsel-Ziel-Gateway.
  2. Kommunikationssystem nach Anspruch 1, bei welchem das funkfähige intelligente Terminal (1) mit einer Neustartaktivierungseinrichtung (918) versehen ist, welche so eingerichtet ist, dass sie die laufende Kommunikation mit dem Wechsel-Original-Gateway unterbricht und eine Neustartsequenz für die Kommunikation mit dem Wechsel-Ziel-Gateway aufgrund der von der Kommunikationsaktivierungsrichtung erhaltenen Adresse durchführt.
  3. Kommunikationssystem nach Anspruch 2, weiterhin mit einer Informationsaustauscheinrichtung, bei welcher dann, wenn eine unvollständige Transaktion nach der Unterbrechung der Kommunikation mit dem Wechsel-Original-Gateway verbleibt, das Wechsel-Original-Gateway über die Informationsaustauscheinrichtung das Wechsel-Ziel-Gateway über die Information des Antwortenden nach einer Anfrage des Terminals vor der Neustartsequenz in Kenntnis setzt.
  4. Kommunikationssystem nach Anspruch 3, bei welchem die Informationsaustauscheinrichtung in Betrieb ist, wenn die unvollständige Transaktion in dem Fall auftritt, dass eine Anfrage von dem funkfähigen intelligenten Terminal (1) an den Server (6) generiert wird, nachdem das Wechsel-Original-Gateway eine Wechselnachricht an das funkfähige intelligente Terminal (1) sendet, diese Anfrage jedoch nicht beim Server (6) ankommt.
  5. Kommunikationssystem nach Anspruch 3, bei welchem die Informationsaustauscheinrichtung in Betrieb ist, wenn die unvollständige Transaktion in dem Fall auftritt, dass die von dem funkfähigen intelligenten Terminal (1) generierte Anfrage beim Server (6) angekommen ist, ehe das Wechsel-Original-Gateway die Wechselnachricht an das funkfähige intelligente Terminal (1) sendet, und wobei als Antwort auf die Anfrage das Wechsel-Original-Gateway an das funkfähige intelligente Terminal (1) ACK zurücksendet.
  6. Kommunikationssystem nach Anspruch 3, bei welchem die Informationsaustauscheinrichtung in Betrieb ist, wenn die unvollständige Transaktion in dem Fall auftritt, dass die Anfrage von dem funkfähigen intelligenten Terminal (1) an den Server (6) generiert wird, ehe das Wechsel-Original-Gateway die Wechselnachricht an das funkfähige intelligente Terminal (1) sendet, und wobei die ACK als Antwort auf die Anfrage bei dem Wechsel-Original-Gateway in dem Stadium eintrifft, wo die Verarbeitung unterbrochen ist, jedoch nicht beim funkfähigen intelligenten Terminal (1) ankommt.
  7. Kommunikationssystem nach einem der Ansprüche 1–6, bei welchem das Gateway mit einer Informationsaustauscheinrichtung versehen ist, welche zwischen dem Wechsel-Original-Gateway und dem Wechsel-Ziel-Gateway Information austauschen kann, die erforderlich ist für die Kommunikation zwischen dem Server (6) und dem funkfähigen intelligenten Terminal (1) über das Wechsel-Ziel-Gateway nach Empfang einer Gatewaywechselnachricht (915), während das Wechsel-Original-Gateway die Kommunikation zwischen dem funkfähigen intelligenten Terminal (1) und dem Server (6) relaismäßig behandelt.
  8. Kommunikationssystem nach Anspruch 7, bei welcher die Neustartaktivierungseinrichtung (918) im Falle, dass die Information der Kommunikationsbedingungen im funkfähigen intelligenten Terminal (1) vor und nach dem Informationsaustausch zwischen dem Wechsel-Original-Gateway und dem Wechsel-Ziel-Gateway über die Informationsaustauscheinrichtung unterschiedlich von dem Wechsel-Original-Gateway ist, von dem funkfähigen intelligenten Terminal (1) eine Nachricht an das Wechsel-Ziel-Gateway gibt mit Informationen, welche die Inkompatibilität der Kommunikationsbedingungen zum Zeitpunkt der Verbindung der Kommunikation mit dem Wechsel-Ziel-Gateway ergänzen.
  9. Kommunikationssystem nach Anspruch 8, bei welchem die Inkompatibilität auftritt infolge der Kommunikation zwischen dem funkfähigen intelligenten Terminal (1) und dem Wechsel-Original-Gateway und bei dem die Kommunikation für den Zeitraum des Informationsaustausches erzeugt wird.
  10. Kommunikationssystem nach Anspruch 8 oder 9 mit einer Informationsaustauscheinrichtung, wobei dann, wenn eine unvollständige Transaktion nach der Unterbrechung der Verarbeitung der Kommunikation mit dem Wechsel-Original-Gateway verbleibt, das Wechsel-Original-Gateway das Wechsel-Ziel-Gateway vor der Neustartsequenz über die unvollständigen Transaktionen informiert.
  11. Kommunikationssystem nach einem der Ansprüche 7–10 mit einer Informationsaustauscheinrichtung, bei welcher die vom Wechsel-Original-Gateway an das Wechsel-Ziel-Gateway (5) gesendete Information eine Information über die Leistungsfähigkeit des Terminals enthält und dann, wenn das Wechsel-Ziel-Gateway nicht der Leistungsfähigkeit des Terminals entspricht, die Einrichtung eine Nachricht von dem Wechsel-Ziel-Gateway an das Wechsel-Original-Gateway über die Leistungsfähigkeit, welche das Wechsel-Ziel-Gateway dem Terminal anbieten kann, liefert.
  12. Kommunikationssystem nach Anspruch 11, weiterhin mit einer Entscheidungseinrichtung in dem funkfähigen intelligenten Terminal (1) zur Entscheidung, ob die Kommunikation mit dem Wechsel-Ziel-Gateway entsprechend der mitgeteilten Leistungsfähigkeit neu starten soll oder nicht.
  13. Kommunikationssystem nach Anspruch 12, bei welchem die Entscheidungseinrichtung in dem Wechsel-Original-Gateway entscheidet, ob es möglich ist, eine Kommunikation mit dem Terminal aufgrund der Leistungsfähigkeit des Wechsel-Ziel-Gateways durchzuführen, und wenn dies nicht möglich ist, das Wechsel-Original-Gateway stoppt.
  14. Kommunikationssystem nach einem der Ansprüche 7–13 mit einer Informationsaustauscheinrichtung, bei welcher dann, wenn ein erstes benanntes Wechsel-Ziel-Gateway den Wechsel ablehnt, die Einrichtung den Informationsaustausch mit einem anderen benannten Wechsel-Ziel-Gateway durchführt.
  15. Kommunikationssystem nach einem der vorstehenden Ansprüche, bei welchem das Wechsel-Original-Gateway und das Wechsel-Ziel-Gateway einen gemeinsamen Server (6) benutzen.
  16. Kommunikationssystem nach einem der Ansprüche 1 – 14, bei welchem das Wechsel-Original-Gateway und das Wechsel-Ziel-Gateway jeweils ihren eigenen Server (6) mit äquivalentem Inhalt benutzen.
  17. Kommunikationssystem nach Anspruch 16, bei welchem das Wechsel-Original-Gateway und das Wechsel-Ziel-Gateway jeweils einen eingebauten Server (6) mit äquivalentem Inhalt enthalten.
  18. Kommunikationssystem nach einem der vorstehenden Ansprüche, bei welchem die Gatewayaustauschnachricht (915) und die Adresse des Wechsel-Ziel-Gateways von dem Wechsel-Original-Gateway (4) gesendet werden.
  19. Funkfähiges intelligentes Terminal (1) zur Herstellung einer Kommunikation mit einem Server (16), der über ein Gateway Dienste anbietet, wobei das Termin enthält: eine Neustartaktivierungseinrichtung (918), welches so ausgebildet ist, dass sie die laufende Kommunikation mit dem Wechsel-Original-Gateway unterbricht und eine Neustartsequenz für eine Kommunikation mit Wechsel-Ziel-Gateway ausführt, dadurch gekennzeichnet, dass das funkfähige intelligente Terminal weiterhin enthält: eine Kommunikationsaktivierungseinrichtung, welche die Adresse eines Wechsel-Ziel-Gateways sowie eine Gatewayaustauschnachricht empfängt.
  20. Funkfähiges intelligentes Terminal (1) nach Anspruch 19, mit einem Display, welches eine Nachricht über die Unterbrechung der Kommunikation für einen Zeitraum vom Beginn der Unterbrechung der Kommunikation bis zum Neustart der Kommunikation anzeigt.
  21. Funkfähiges intelligentes Terminal (1) nach Anspruch 19 oder 20, mit einem Display, welches nach Empfang einer Stopnachricht von dem Wechsel-Original-Gateway dann, wenn das Wechsel-Ziel-Gateway die Kommunikation mit dem Terminal ablehnt anstatt die Wechselnachricht zu akzeptieren, eine Stopnachricht anzeigt.
  22. Funkfähiges intelligentes Terminal (1) nach Anspruch 19, 20 oder 21, bei welchem im Fall, dass eine Inkompatibilität in den Kommunikationsbedingungen mit einem Wechsel-Original-Gateway vorliegt, ehe oder nachdem die für den Wechsel erforderliche Information zwischen dem Wechsel-Original-Gateway und dem Wechsel-Ziel-Gateway ausgetauscht ist, die die Inkompatibilität ergänzende Information mittels der Neustartsequenz an das Wechsel-Ziel-Gateway gesendet wird.
  23. Kommunikationsverfahren zur Herstellung einer Kommunikation zwischen einem funkfähigen intelligenten Terminal (1) und einem Server (6), welcher über ein Gateway Dienste an das funkfähige intelligente Terminal (1) liefert und dieses in die Lage versetzt, von dem Gateway zu einem anderen Gateway zu wechseln, dadurch gekennzeichnet, dass das funkfähige intelligente Terminal (1) die Adresse eines Wechsel-Ziel- Gateways sowie einer Gatewaywechselnachricht erhält und eine Startsequenz mit dem Wechsel-Ziel-Gateway durchführt.
  24. Kommunikationsverfahren nach Anspruch 23 mit den folgenden Schritten: Mitteilung der Generierung des Gatewaywechsels und der für die Kommunikation mit dem Server (6) über ein Wechsel-Ziel-Gateway erforderlichen Information und Empfang einer Gatewaywechselnachricht, und Durchführung einer Neustartsequenz für die Kommunikation mit dem Wechsel-Ziel-Gateway nach Erhalt der für die Kommunikation mit dem Server (6) über das Wechsel-Ziel-Gateway erforderlichen Information von dem Wechsel-Original-Gateway.
  25. Kommunikationsverfahren nach Anspruch 24 mit den folgenden weiteren Schritten: Benachrichtigung des funkfähigen intelligenten Terminals (1) mit der Information, welche für die Kommunikation zwischen dem funkfähigen intelligenten Terminal (1) und dem Server (6) über das Wechsel-Ziel-Gateway erforderlich ist, nach Erhalt der Gatewaywechselnachricht (915), während das Wechsel-Original-Gateway die Kommunikation zwischen dem funkfähigen intelligenten Server (1) und dem Server (6) relaismäßig behandelt hat, und Ausführung einer Neustartsequenz für die Kommunikation mit dem Wechsel-Ziel-Gateway zugleich mit der Unterbrechung der Kommunikation mit dem Wechsel-Original-Gateway durch das funkfähige intelligente Terminal (1), welches von dem Wechsel-Original-Gateway Information erhält, die für die Kommunikation mit dem Server (6) über das Wechsel-Ziel-Gateway erforderlich ist.
  26. Kommunikationsverfahren nach Anspruch 23, 24 oder 25 mit den folgenden Schritten: Weitergabe der Nachricht vom Wechsel-Original-Gateway an das Wechsel-Ziel-Gateway, welche für die Kommunikation zwischen dem funkfähigen intelligenten Terminal (1) und dem Server (6) über das Wechsel-Ziel-Gateway erforderlich ist, und Empfang der Gatewaywechselnachricht (915) während das Wechsel-Original-Gateway Kommunikation zwischen dem funkfähigen intelligenten Terminal (1) und dem Server (6) relaismäßig bearbeitet.
DE69937859T 1998-07-17 1999-07-19 Übertragungssystem zum Kommunikationsaufbau zwischen einem intelligenten Radioterminal und einem Server Expired - Lifetime DE69937859T2 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP20300698 1998-07-17
JP20300698 1998-07-17
JP27493898 1998-09-29
JP27493898 1998-09-29

Publications (2)

Publication Number Publication Date
DE69937859D1 DE69937859D1 (de) 2008-02-14
DE69937859T2 true DE69937859T2 (de) 2008-12-18

Family

ID=26513686

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69937859T Expired - Lifetime DE69937859T2 (de) 1998-07-17 1999-07-19 Übertragungssystem zum Kommunikationsaufbau zwischen einem intelligenten Radioterminal und einem Server

Country Status (4)

Country Link
US (1) US7103028B1 (de)
EP (3) EP0973300B1 (de)
CN (1) CN1221110C (de)
DE (1) DE69937859T2 (de)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9913209D0 (en) * 1999-06-07 1999-08-04 Nec Technologies Uk Ltd Wireless communication
FI113234B (fi) * 2000-02-01 2004-03-15 Nokia Corp Menetelmä ja laite ominaisuustiedon välittämiseksi
JP3456189B2 (ja) * 2000-03-31 2003-10-14 日本電気株式会社 移動通信システム
DE60115530T2 (de) 2000-04-20 2006-08-17 Nokia Corp. Verfahren zur Übertragung von Ressourceninformation
JP4095258B2 (ja) * 2001-04-03 2008-06-04 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム、関門交換機選択サーバ及び関門交換機選択方法
JP3948278B2 (ja) 2001-12-27 2007-07-25 富士ゼロックス株式会社 外部ネットワーク接続のための設定情報割当方法
US7984157B2 (en) * 2002-02-26 2011-07-19 Citrix Systems, Inc. Persistent and reliable session securely traversing network components using an encapsulating protocol
JP3957537B2 (ja) * 2002-03-18 2007-08-15 日本電気株式会社 データ通信システムおよび方法、サーバ
US7110377B2 (en) * 2002-10-10 2006-09-19 Qualcomm Incorporated Dormant handoff in a packet data network
US8406222B2 (en) * 2004-07-30 2013-03-26 Sharp Kabushiki Kaisha Control system of communication network
CN1976509B (zh) 2005-11-28 2011-07-06 华为技术有限公司 一种终端切换方法及系统
CN101039506B (zh) * 2006-03-15 2011-02-02 华为技术有限公司 一种移动管理实体/用户面实体迁移方法
CN101114928B (zh) * 2006-07-24 2011-04-20 华为技术有限公司 一种实现负载均衡的系统及方法
CN100584093C (zh) * 2006-08-15 2010-01-20 华为技术有限公司 一种在移动通信系统中转移用户设备的方法及系统
KR20090060924A (ko) * 2007-12-10 2009-06-15 삼성전자주식회사 복수 개의 UPnP IGD 들을 이용한 인터넷 게이트웨이서비스 제공 방법 및 이를 위한 장치
GB2473019B (en) * 2009-08-27 2015-10-21 Wireless Data Services Ltd Device management
KR101688857B1 (ko) * 2010-05-13 2016-12-23 삼성전자주식회사 컨텐츠 중심 네트워크(ccn)에서 단말 및 허브의 통신 방법 및 컨텐츠 중심 네트워크를 위한 단말
WO2012138268A1 (en) * 2011-04-06 2012-10-11 Telefonaktiebolaget L M Ericsson (Publ) A method for managing handover of a user equipment
JP6044882B2 (ja) * 2012-03-02 2016-12-14 株式会社Pfu 情報処理システム、管理端末装置、情報処理装置、情報処理方法、及びプログラム
KR102090797B1 (ko) * 2013-12-20 2020-04-14 삼성전자주식회사 전자 장치, 게이트웨이 장치, 홈 네트워크 시스템 및 홈 네트워크에서 마스터 게이트웨이 결정 방법
CN111770586B (zh) 2019-04-02 2022-06-28 华为技术有限公司 会话处理的方法、通信装置及通信系统

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4698839A (en) * 1986-06-03 1987-10-06 Devaney David B Mobile telephone switching office
US5341496A (en) * 1990-08-29 1994-08-23 The Foxboro Company Apparatus and method for interfacing host computer and computer nodes using redundant gateway data lists of accessible computer node data
JP2773424B2 (ja) 1990-11-20 1998-07-09 株式会社日立製作所 ネットワークシステムおよび接続コンピュータ切替え方法
CA2040234C (en) * 1991-04-11 2000-01-04 Steven Messenger Wireless coupling of devices to wired network
US5457680A (en) * 1993-05-18 1995-10-10 International Business Machines Corporation Data gateway for mobile data radio terminals in a data communication network
JPH086887A (ja) 1994-06-17 1996-01-12 Hitachi Ltd サーバ接続切替方法
US5577022A (en) 1994-11-22 1996-11-19 Qualcomm Incorporated Pilot signal searching technique for a cellular communications system
FI98586C (fi) * 1995-01-10 1997-07-10 Nokia Telecommunications Oy Pakettiradiojärjestelmä ja menetelmiä datapaketin reitittämiseksi protokollariippumattomasti pakettiradioverkoissa
US5812819A (en) * 1995-06-05 1998-09-22 Shiva Corporation Remote access apparatus and method which allow dynamic internet protocol (IP) address management
US5991287A (en) * 1996-12-30 1999-11-23 Lucent Technologies, Inc. System and method for providing seamless handover in a wireless computer network
US6154461A (en) * 1997-05-14 2000-11-28 Telxon Corporation Seamless roaming among multiple networks
US6104929A (en) * 1997-06-20 2000-08-15 Telefonaktiebolaget Lm Ericsson Data packet radio service with enhanced mobility management
SE519638C2 (sv) * 1997-07-02 2003-03-25 Ericsson Telefon Ab L M Förfarande och anordning för uppkopplande i ett telekommunikationsnät
US6137783A (en) * 1997-12-02 2000-10-24 Ericsson Inc System and method for reduced network information handovers
US6122293A (en) * 1998-02-13 2000-09-19 Telefonaktiebolaget Lm Ericsson Method and system for link adaptation having a variable update interval
US6400954B1 (en) * 1998-05-15 2002-06-04 Tlelefonaktiebolaget Lm Ericsson (Publ) Methods and systems for mode selection based on access network capacity

Also Published As

Publication number Publication date
EP1684468A1 (de) 2006-07-26
US7103028B1 (en) 2006-09-05
EP1684468B1 (de) 2013-11-06
EP2262176A1 (de) 2010-12-15
CN1221110C (zh) 2005-09-28
EP0973300B1 (de) 2008-01-02
EP2262176B1 (de) 2013-07-10
CN1243370A (zh) 2000-02-02
EP0973300A3 (de) 2001-09-05
EP0973300A2 (de) 2000-01-19
DE69937859D1 (de) 2008-02-14

Similar Documents

Publication Publication Date Title
DE69937859T2 (de) Übertragungssystem zum Kommunikationsaufbau zwischen einem intelligenten Radioterminal und einem Server
DE69434896T2 (de) Zugriffsverfahren auf ein drahtloses lokales ad-hoc Netzwerk über ein zellulares Weitbereichnetzwerk mit Koppelung des LAN-MAC-Paketkopfes.
DE60213147T2 (de) Verfahren zur Dienstqualitätsauswahl in einem drahtlosen Kommunikationssystem
DE602005002551T2 (de) Kommunikationssteuerverfahren und drahtloskommunikationsvorrichtung
DE3853022T2 (de) Verfahren zur Ausbreitung von Netzwerkzustandsnachrichten.
DE69832057T2 (de) Datendienst in einem mobilen kommunikationsnetz
DE19950653B4 (de) Verfahren zum Betreiben eines Mobilfunknetzes
DE60031673T2 (de) Aufbau eines paketnetzrufes zwischen einem mobilen endgerät und einer anpassungsfunktion
DE60316751T2 (de) Verfahren zur Bestimmung der Wiederherstellung der RLC Entität während der SRNS Relocation
DE60319071T2 (de) Vefahren zum datentransfer in mobil- und festtelekommunikationssystemen
DE60319019T2 (de) Verfahren zum aufbau und abbau einer dienstverbindung zwischen einem drahtlosen lokalen netz und benutzerendgerät
DE60114097T2 (de) Verfahren und System zur Verbesserung der Netzleistungsfähigkeit unter Verwendung eines leistungssteigernden Proxies
DE69434826T2 (de) Datenübertragung in einem Funktelefonnetz
EP1308067B1 (de) Verfahren und mobiles datenübertragungssystem zur durchführung eines handovers unter datenduplizierung
DE60120354T2 (de) Rsvp-verarbeitung in 3g-netzwerken
DE60224212T2 (de) Netzwerk mit mehreren sub-netzwerken
DE60107827T2 (de) Zuteilung von betriebsmitteln beim paketvermittelten datentransfer
DE19730159B4 (de) Kommunikationsverfahren und System
DE69929193T2 (de) Verfahren zur steuerung von kommunikation sowie kommunikationssystem
DE60115530T2 (de) Verfahren zur Übertragung von Ressourceninformation
DE202004019527U1 (de) Unabhängige und effiziente Lieferung von Diensten an drahtlose Vorrichtungen, die fähig sind, mehrere Funkschnittstellen und Netzinfrastrukturen zu unterstützen
DE19900436A1 (de) Verfahren zum Handover, Mobilstation für ein Handover und Basisstation für ein Handover
DE19800772A1 (de) Verfahren und Vorrichtung zur Verbindung mit einem Paketaustauschnetz
DE112006001618B4 (de) Verfahren und Vorrichtung zum Verringern der Latenz während Änderungen einer drahtlosen Konnektivität
DE60309493T2 (de) Kommunikationsendgerät mit Energiesparsteuerung, Verfahren und Computerprogramm und Aufzeichnungsmedium zum Speichern des Programms

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: PANASONIC CORP., KADOMA, OSAKA, JP