Nothing Special   »   [go: up one dir, main page]

DE60221905T2 - Verfahren zum senden von verbindungsorientierten oder verbindungslosen daten - Google Patents

Verfahren zum senden von verbindungsorientierten oder verbindungslosen daten Download PDF

Info

Publication number
DE60221905T2
DE60221905T2 DE60221905T DE60221905T DE60221905T2 DE 60221905 T2 DE60221905 T2 DE 60221905T2 DE 60221905 T DE60221905 T DE 60221905T DE 60221905 T DE60221905 T DE 60221905T DE 60221905 T2 DE60221905 T2 DE 60221905T2
Authority
DE
Germany
Prior art keywords
connection
sctp
application
oriented
connectionless
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
DE60221905T
Other languages
English (en)
Other versions
DE60221905D1 (de
Inventor
Gabriel Ramos-Escano
Fabio Longoni
Raquel Sanchez
Sami Kekki
Ivan Arias-Rodriguez
Seppo Vesterinen
Janne Marin
Janne Tervonen
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.)
Nokia Oyj
Original Assignee
Nokia Oyj
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 Nokia Oyj filed Critical Nokia Oyj
Publication of DE60221905D1 publication Critical patent/DE60221905D1/de
Application granted granted Critical
Publication of DE60221905T2 publication Critical patent/DE60221905T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/169—Special adaptations of TCP, UDP or IP for interworking of IP based networks with other networks 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Optical Communication System (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Earth Drilling (AREA)
  • Cable Accessories (AREA)
  • Coupling Device And Connection With Printed Circuit (AREA)

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung bezieht sich auf mobile Telekommunikationssysteme. Insbesondere bezieht sich die vorliegende Erfindung auf ein neues und verbessertes Verfahren und System zum Senden verbindungsorientierter oder verbindungsloser Daten zwischen zwei Endpunkten ohne Verwendung von peer-to-peer-Signalisierung.
  • HINTERGRUND DER ERFINDUNG
  • Die Übertragung von Information in Kommunikationsnetzwerken basiert auf der Verwendung von unterschiedlichen Arten von Protokollarchitekturen. Es kann allgemein gesagt werden, dass, je mehr Protokollschichten existieren in einer Protokollarchitektur, desto komplexer wird die Architektur. Im Allgemeinen umfasst praktisch jede Protokollarchitektur Anwendungs- und Transportschichten. Die Anwendungsschicht stellt Dienste für Anwendungsprogramme bereit, die sicherstellen, dass die Kommunikation möglich ist. Die Anwendungsschicht ist nicht die Anwendung selbst, die die Kommunikation macht. Sie ist eine Dienstschicht, die sicherstellt, dass der andere Teilnehmer identifiziert wird und erreicht werden kann, oder sie kann entweder den Nachrichtensender oder den Nachrichtenempfänger oder beide authentifizieren. Ferner kann die Anwendungsschicht auch eine Übereinstimmung an beiden Enden über Fehlerherstellungsprozeduren sicherstellen, Datenintegrität und Privatsphäre und kann auf der Anwendungshöhe Protokoll- und Datensyntaxregeln bestimmen. Es kann bequem sein, sich die Anwendungsschicht als den Aufbaudienst auf hoher Ebene für das Anwendungsprogramm oder als einen interaktiven Benutzer vorzustellen.
  • Die Transportschicht stellt die zuverlässige Ankunft von Nachrichten sicher und kann Fehlerüberprüfungsmechanismen und Datenflusssteuerungen bereitstellen. Die Transportschicht stellt Dienste sowohl für die verbindungsorientierte Übertragung als auch für verbindungslose Übertragung bereit. Für die verbindungsorientierte Übertragung kann eine Übertragung in Form von Paketen gesendet werden oder ankommen, die an dem anderen Ende zu einer vollständige Nachricht rekonstruiert werden müssen.
  • Es sind eine Anzahl von unterschiedlichen Standards bekannt, die die Kommunikation zwischen Mobilstationen und den Basisstationen als auch mit anderen Netzwerkelementen regeln. Ein Beispiel eines derzeit bekannten Standards ist der Globales System für mobile Kommunikationen(GSM, englisch: Global System for Mobile communications)-Standard. Derzeit wird an sogenannten Dritte-Generation-Standards gearbeitet. Diese Dritte-Generation-Standards werden durch das sogenannte 3.Generation Partnership Project (3GPP) erzeugt und die definieren das sogenannte 3GPP-System, das umfasst: UMTS Terrestrisches Funkzugangsnetz (UTRAN, englisch: UMTS Terrestrial Radio Access Network), GSM/EDGE Funkzugangsnetz (GERAN, englisch: Radio Access Network), Paket- und leitungsvermittelte Kernnetzdomänen usw.
  • Derzeit wird in den Dritte-Generation-Standards vorgeschlagen, das Internetprotokoll (IP) in dem Funkzugangsnetz (RAN, englisch: radio access network) zu verwenden. In diesem Dokument beziehen wir uns auf dieses als ein IP-basiertes Funkzugangsnetz IP RAN. Das IP RAN kann mit einem Dritte-Generation-Kernnetz durch eine Standard Iu-Schnittstelle verbunden werden. In den IP RAN Netzen besteht ein Bedarf für die Zusammenarbeit zwischen dem Signalisierungssystem Nr. 7 (SS7) und IP-Domänen, um die Lieferung von Signalisierungs-Verbindungs-Steuer-Teil(SCCP, englisch: Signalling Connection Control Part)-Benutzernachrichten, wie beispielsweise Funkzugangsnetzanwendungsteil(RANAP, englisch: Radio Access Network Application Part)-Signalisierung zu ermöglichen, als auch neue Dritte-Generation-Netzprotokollnachrichten über IP zwischen zwei Signalisierungsendpunkten. RANAP ist ein Funkzugangsnetzsignalisierungsprotokoll, das Mechanismen aufweist, die Prozeduren zwischen dem Kernnetz und dem Funkzugangsnetz handhaben bzw. steuern.
  • Eine Schichtstruktur wurde vorgeschlagen. Diese Schichtstruktur verwendet das Stromsteuerübertragungsprotokoll (SCTP, englisch: Stream Control Transmission Protocol), welches ein Protokoll ist, das durch die Internet Engineering Task Force (IETF) standardisiert ist und spezifiziert ist in RFC 2960. Das SCTP stellt einen zuverlässigen Transportdienst bereit, der sicherstellt, dass Daten über das Netzwerk ohne Fehler und in Reihenfolge transportiert werden. Das SCTP-Protokoll läuft direkt auf der IP-Schicht und ist gestaltet, öffentliches Telefonnetz(PSTN, englisch: Public Switched Telephone Network)-Signalisierungsnachrichten zu transportieren, ist aber zu breiteren Anwendungen im Stande und kann in den IP RAN-Netzwerken als ein gemeinsames Protokoll verwendet werden. Es wurden Anpassungsschichten zwischen der SCTP-Schicht und der RANAP-Schicht vorgeschlagen, wie in 1a veranschaulicht ist. Das derzeitige Dritte Generation Partnerschaftsprojekt (3GPP, englisch: Third Generation Partnership Project) schlägt die Verwendung des SCCP unter dem RANAP und die Einführung der SCCP MTP3-Benutzeranpassungsschicht(M3UA)-Protokolls als eine Anpassungsschicht vor. Als eine Alternative kann das SS7 SCCP-Benutzeranpassungsschicht(SUA)-Protokoll als eine Anpassungsschicht zwischen dem RANAP und dem SCTP verwendet werden. Diese Anpassungsschichten sind für das RANAP und für beliebige andere Dritte Generation Anwendungsteilnachrichten zwischen zwei Endpunkten anwendbar, die gesamt innerhalb eines IP-Netzwerks enthalten sind.
  • Ein Problem bei der vorgeschlagenen Schichtstruktur ist, dass es zu viele Schichten gibt. So wie die Anzahl von Schichten sich vergrößert, so vergrößert sich die Komplexität und die Leistung wird verringert.
  • Bei allen IP RAN besteht ein Bedarf, den derzeitigen Steuerebenenprotokollstack zu optimieren (auch als Signalisierungsträger bezeichnet), da der SS7-Protokollstack (SCCP-basiert) relativ schwer einzurichten ist. In derzeitigen 3GPP-Spezifikationen (bis zur Auflage '5) und Ausführungen baut der Signalisierungsträger, auf Anfrage von einem Ende, und löst die Signalisierungsverbindung mit dem anderen Ende mit peer-to-peer-Signalisierungsnachrichten. Das dafür verwendete Protokoll ist SCCP, aber es werden auch andere Kandidaten in dem 3GPP diskutiert, das SUA stellt ähnliche peer-to-peer-Nachrichten für den Aufbau der Signalisierungsverbindung bereit.
  • Eine Alternative zur Verwendung von peer-to-peer-Signalisierungstransportprotokollen (Anpassungsschicht L5; wie das SUA oder SCCP/M3UA) unterhalb der Anwendung die Verbindungen aufzubauen und zu lösen, ist die Verwendung von Anpassungsschichten, die denselben Dienst ohne irgendeine peer-to-peer-Nachricht bereitstellen. Zum Beispiel senden sie, wenn Anpassungsschichtprotokolle, wie das SUA oder SCCP/M3UA von der Anwendung eine Trennungsanfrage empfangen, eine Trennungsprotokolldateneinheit (PDU) an den entfernten Endpunkt. Es gibt eine peer-to-peer-Kommunikation. Bei dieser Alternative werden keine peer-to-peer-Nachrichten benötigt, um die Trennung bereitzustellen.
  • Daher ist ein Problem bei dieser Alternative, wie eine Signalisierungsverbindung aufgebaut und gelöst wird: Der Verbindungsaufbau und das Lösen durch Senden von PDUs ist nicht möglich. Ein anderes Problem taucht auf, wenn keine Signalisierungstransport-peer-to-peer-Protokolle wie das SUA oder SCCP/M3UA unterhalb der Anwendung vorhanden sind. Das Problem ist, wie man verbindungslose und verbindungsorientierte Dienste unterscheidet.
  • KURZFASSUNG DER ERFINDUNG
  • Die vorliegende Erfindung beschreibt ein Verfahren in Übereinstimmung mit Anspruch 1, ein Verbindungs-Steuerprogramm in Übereinstimmung mit Anspruch 22 und ein System in Übereinstimmung mit Anspruch 35 zum Senden von verbindungsorientierten und verbindunglosen Daten zwischen zwei Endpunkten in einer Protokollarchitektur, die wenigstens eine Anwendungsschicht und eine Transportschicht und eine oder mehrere Anwendungen umfasst, die die Anwendungsschicht verwenden.
  • Bei diesem Verfahren sendet eine Quellanwendung eine Anfragenachricht an den ersten Endpunkt an die Transportschicht. Die Anfragenachricht gibt auch an, welcher Dienst (verbindungsorientiert oder verbindungslos) durch die Transportschicht bereitgestellt werden soll. Bei der Transportschicht wird eine Transportverbindungskennung ausgewählt und/oder zugeteilt. Dann wird ein Datenrahmen an den zweiten Endpunkt gesendet, wobei der Datenrahmen die ausgewählte Transportverbindungskennung, Zielanwendungsinformation und/oder Datentypinformation umfasst. Die Zielanwendungsinformation und die Datentypinformation sind auf Grundlage der Anfragenachricht eingeschlossen. Der Datenrahmen wird an der Transportschicht bei dem zweiten Endpunkt empfangen. Basierend auf der Datentypanzeige wird bestimmt, ob der Datenrahmen sich auf den verbindungsorientierten oder verbindungslosen Dienst bezieht. Schlussendlich wird eine Anwendungsnachricht an die Zielanwendung an dem zweiten Endpunkt auf Grundlage der Zielanwendungsinformation gesendet.
  • Bei einem bevorzugten Ausführungsbeispiel sind die Anwendungsschicht und die Transportschicht direkt miteinander verbunden und das Transportprotokoll auf der Transportschicht ist das SCTP. In diesem Fall bezieht sich die Verbindungskennung auf die SCTP-StreamID. Weiterhin sind bei einem bevorzugten Ausführungsbeispiel die Anwendungsschicht und die Transportschicht miteinander durch eine Verbindungssteuerung verbunden. Es wird auch der Ausdruck SCTP-Steuerung verwendet, wenn über die Verbindungssteuerung gesprochen wird. Die SCTP-Steuerung ist eine Anpassungsschicht oder ein Treiber zwischen der Anpassungsschicht und der SCTP-Schicht, der SCTP-ähnliche Dienste der Anwendung bereitstellt. Eine wichtige Tatsache ist, dass die SCTP-Steuerung kein peer-to-peer-Protokoll ist. Ihre Verwendung vereinfacht den Protokollstack und zwei überlappende Adressierungs-/Routingmechanismen werden vermieden.
  • Bei einem Ausführungsbeispiel der vorliegenden Erfindung kennzeichnet der Wert des Protokoll-Nutzdaten-Kennungs-(PPI)-Parameters die Zielanwendung und den Datentyp (verbindungsorientiert oder verbindungslos).
  • Bei einem Ausführungsbeispiel der vorliegenden Erfindung kennzeichnet der Wert des Protokoll-Nutzdaten-Kennungs(PPI)-Parameters die Zielanwendung und die Streamnummer (Stromnummer), die den Datentyp verwendet hat (verbindungsorientiert oder verbindungslos).
  • Bei einem Ausführungsbeispiel der vorliegenden Erfindung kennzeichnet der Wert des Protokoll-Nutzdaten-Kennungs-Parameters die Zielanwendung und der SCTP-unordered-Flag den Datentyp (verbindungsorientiert oder verbindungslos).
  • Bei einem Ausführungsbeispiel der vorliegenden Erfindung kennzeichnet der Wert des Protokoll-Nutzdaten-Kennungs-Parameters die Zielanwendung und die Streamnummer, die den Datentyp verwendet hat (verbindungsorientiert oder verbindungslos). Der unordered Flag wird auf "1" für verbindungslose Dienste gesetzt.
  • Da es keine peer-to-peer-Signalisierungskommunikation gibt, ist der/das Transportaufbau/-lösen durch Senden von PDUs nicht möglich. Daher stellt die Verbindung zur Steuerung eine lokalen Aufbau/Trennung von Signalisierungsverbindungen bereit. Es muss festgehalten werden, dass die vorliegende Erfindung auf jeden Fall erweitert werden kann, bei dem der Signalisierungstransport keine peer-to-peer-Nachricht bereitstellt, um den/die Aufbau/Trennung von Ressourcen auszuführen. Die vorliegende Erfindung ist auf jedes andere Signalisierungsträgerprotokoll anwendbar, das keinen peer-to-peer-Verbindungsaufbau und -lösennachrichten hat, auch sogar wenn sie zusammen mit dem SCTP und der SCTP-Steuerung veranschaulicht wird.
  • Die vorliegende Erfindung ist in der Lage, dieselbe Art von Diensten bereitzustellen, wie ein Signalisierungsprotokoll, wie SCCP/M3UA oder SUA der Anwendung, d.h. verbindungsorientierte und verbindungslose Dienste, aber ohne Verwendung von peer-to-peer-Nachrichten. Dieser vereinfachte Protokollstack hat auch klare Vorteile. Der Overhead, der durch das SCCP/M3UA, SUA oder jedes andere peer-to-peer-Anpassungsprotokoll, das verwendet wird, eingeführt wird, wird vermieden. Weiterhin werden auch Überlappungsadressierungs-Routingmechanismen vermieden.
  • Die vorliegende Erfindung erlaubt den Aufbau und das Lösen von Verbindungen, unter Verwendung eines vereinfachten Protokollstacks. Der Vorteil dieser Art von Protokollarchitektur ist, dass sie Komplexität (Implementierung und Betrieb) verringert und auch die Verarbeitungsanforderung an den Signalisierungsträger. Ein weiterer Vorteil ist, dass die vorliegende Erfindung die Verzögerung für den Aufbau und das Lösen der Verbindungen reduziert. Insbesondere die Aufbauverzögerung hat einen direkten Einfluss auf die Dienstqualität, die der Endbenutzer erfährt.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Die beigefügten Zeichnungen, die enthalten sind, um ein weiteres Verständnis der Erfindung zu ermöglichen und einen Teil dieser Beschreibung bilden, veranschaulichten Ausführungsbeispiele der Erfindung und helfen zusammen mit der Beschreibung die Prinzipien der Erfindung zu erklären. In den Zeichnungen:
  • 1a ist ein Blockdiagramm, das einen bekannten Protokollstack veranschaulicht.
  • 1b und 1c veranschaulichen den lokalen Transportverbindungsaufbau an den Quell- und Zielendpunkten, in Übereinstimmung mit der vorliegenden Erfindung,
  • 2a und 2b veranschaulichen den lokalen Transportverbindungslösevorgang an dem Quell- und Zielendpunkt, in Übereinstimmung mit der vorliegenden Erfindung,
  • 3a ist ein Blockdiagramm, das einen bevorzugten Protokollstack veranschaulicht, in Übereinstimmung mit der vorliegenden Erfindung,
  • 3b ist ein Blockdiagramm, das eine Verbindungssteuerung veranschaulicht, in Übereinstimmung mit der vorliegenden Erfindung,
  • 4a ist ein Flussdiagramm, das den Mechanismus veranschaulicht, der auf der Verwendung des PPI-Parameters basiert, um verbindungsorientierte und verbindungslose Dienste durch den Quellendpunkt zu unterscheiden, in Übereinstimmung mit der vorliegenden Erfindung,
  • 4b ist ein Flussdiagramm, das den Mechanismus veranschaulicht, der auf der Verwendung des PPI-Parameters basiert, um verbindungsorientierten und verbindungslosen Dienst durch den Zielendpunkt zu unterscheiden, in Übereinstimmung mit der vorliegenden Erfindung,
  • 5a ist ein Flussdiagramm, das den Mechanismus veranschaulicht, der auf der Reservierung von Strömen basiert, um verbindungsorientierte und verbindungslose Dienste durch den Quellendpunkt zu unterscheiden, in Übereinstimmung mit der vorliegenden Erfindung,
  • 5b ist ein Flussdiagramm, das den Mechanismus veranschaulicht, der auf der Reservierung von Strömen (Streams) basiert, um verbindungsorientierte und verbindungslose Dienste durch den Zielendpunkt zu unterscheiden, in Übereinstimmung mit der vorliegenden Erfindung,
  • 6a ist ein Flussdiagramm, das den Mechanismus veranschaulicht, der auf der Verwendung des SCTP-unordered-Flag-Parameters basiert, um verbindungsorientierte und verbindungslose Dienste durch den Quellendpunkt zu unterscheiden, in Übereinstimmung mit der vorliegenden Erfindung, und
  • 6b ist ein Flussdiagramm, das den Mechanismus veranschaulicht, der auf der Verwendung des SCTP-unordered-Flag-Parameters basiert, um verbindungsorientierte und verbindungslose Dienste durch den Zielendpunkt zu unterscheiden, in Übereinstimmung mit der vorliegenden Erfindung,
  • 7 zeigt ein Ausführungsbeispiel des Systems, bei welchem die vorliegende Erfindung verwendet werden kann, und
  • 8 zeigt eine Anordnung, die eine IP RAN logische Architektur zeigt, die in Ausführungsbeispielen der vorliegenden Erfindung verwendet wird.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Es wird nun detailliert auf die Ausführungsbeispiele der vorliegenden Erfindung Bezug genommen, wobei Beispiele von ihr in den beigefügten Zeichnungen veranschaulicht sind.
  • 1a zeigt einen bekannten Steuerebenenprotokollstack für eine Iu-Schnittstelle, die derzeit in der 3GPP-Standardisierung vorgeschlagen wird. Diese ist in dem Dritte Generation Partnerschaftsprojekt 3GPP, Technical specification group TSG offenbart; IP-Transport in UTRAN Work Task Technical Report TR25.933 (Version 5.0.0). Der Protokollstack hat sechs Schichten. Die erste Schicht ist die physikalische Schicht L1. Oben auf der physikalischen Schicht L1 ist die Verbindungsschicht L2. Oben auf dieser ist die IP-Schicht L3.
  • Oben auf der IP-Schicht ist die SCTP-Schicht, L4. Wie vorher erwähnt wurde, basiert dies auf dem IETF-Protokoll, das in RFC2960 spezifiziert ist. Diese Schicht wird zum Beispiel dafür verwendet, PSTN-Signalisierungsnachrichten zu transportieren, aber sie kann auch für ein gemeinsames Protokoll für IP RAN-Steuerebenenschnittstellen verwendet werden. Das SCTP ist ein Transportprotokoll, das oben auf einem verbindungslosen Paketnetzwerk, wie beispielsweise IP, betrieben wird. Es erlaubt die nacheinanderfolgende Auslieferung von Benutzernachrichten, innerhalb mehrerer Ströme (= Streams), mit der Möglichkeit, der Reihenfolge von Ankunftslieferung von einzelnen Benutzernachrichten. Das SCTP ist von Natur aus verbindungsorientiert. Das SCTP stellt das Mittel für jeden SCTP-Endpunkt bereit, um dem anderen Endpunkt während eines zugehörigen Aufbaus mit einer Liste von Transportadressen zu versorgen, wie beispielsweise mehrere IP-Adressen in Kombination mit einem SCTP-Port, durch welchen der Endpunkt erreicht werden kann und von welchem es SCTP-Pakete hervorbringen wird. Die Vereinigung umfasst Übertragungen über alle möglichen Quellen-/Zielkombinationen, die von jedem Endpunkt erzeugt werden können.
  • Oben auf der SCTP-Schicht ist eine Anpassungsschicht L5. Die Anpassungsschicht ist bereits in der SCCP-Benutzeranpassungsschicht (SUA) oder dergleichen erwähnt. In 1a stellt die Funknetzschicht RANAP die Schicht L6 dar. Eine ähnliche Art von Protokollstacks kann in anderen Schnittstellen auch durch Wechseln der Schicht oberhalb der Transportschicht (XXXAP) verwendet werden. In der Iur-Schnittstelle ist die Funknetzkschicht eine RNSAP(Funknetzsubsystemanwendungsteil, englisch: Radio Network Subsystem Application Part)-Schicht. Das RNSAP ist ein Funknetzsubsystemsignalisierungsprotokoll für die Iur-Schnittstelle. Der Steuerebenenprotokollstack, der in 3a gezeigt ist, wird in der Iu-Schnittstelle verwendet, die ursprünglich in 3GPP konstruiert wurde, um zwischen der Funknetzsteuerung (RNC) und dem Kernnetz (CN) verwendet zu werden.
  • 1b und 1c veranschaulichen den lokalen Signalisierungstransportverbindungsaufbauvorgang bei den Quell- und Zielendpunkten. Eine Anwendung an dem Quellendpunkt sendet eine Anfrage (10) an die niedrigere Schicht, um eine Signalisierungsverbindung aufzubauen. Die Anfrage soll die Anwendungsverbindungskennung umfassen. Die Anfrage kennzeichnet auch, welcher Dienst (verbindungsorientiert oder verbindungslos) durch die Transportschicht bereitgestellt werden soll. Die Anfrage kann auch Anwendungsdaten umfassen, die an eine Zielanwendung gesendet werden sollen. Eine unbenutzte Transportverbindungskennung wird an der Transportschicht für die Verbindung zugeteilt (11) und wird mit der Anwendungsverbindungskennung für weitere Routingzwecke während der Dauer der Verbindung abgebildet. Danach kann ein Datenrahmen an den Zielendpunkt gesendet werden (12) zusammen mit der zugeteilten Transportverbindungskennung. Wenn das Transportprotokoll, das verwendet wird, das SCTP ist, bezieht sich die Transportverbindungskennung zum Beispiel auf die SCTP-StreamID (StromID). Die Transportverbindungskennung ist typischerweise in dem Kopf des Datenrahmens. Wenn keine Anwendungsdaten in der Anfrage für die Verbindung vorhanden waren, wird ein Nulldatenwert gesendet (wenn es von dem Signalisierungsprotokoll ermöglicht wird). Es kann ein Aufbaubestätigungsprimitiv an die Anwendung an den Quellendpunkt gesendet werden. Der lokale Aufbau der Signalisierungsverbindung an dem Quellendpunkt ist nun vollendet (13) bzw. abgeschlossen.
  • An dem Zielendpunkt wird der Datenrahmen empfangen (14a) an einer Transportverbindungskennung (z.B. die SCTP-StreamID), die nicht als reserviert gekennzeichnet ist. Daher wird interpretiert, dass der Datenrahmen eine Anfrage für eine neue Signalisierungsverbindung ist. Eine Anwendungsverbindungskennung wird für diese spezifische Verbindung ausgewählt und sie wird mit der Transportverbindungskennung (z.B. die SCTP-StreamID) für weitere Routingzwecke während der Dauer der Verbindung (14b) abgebildet. Eine Verbindungskennungsnachricht wird daher an die Zielanwendung gesendet (15) an dem Zielendpunkt. Die Anwendung an dem Zielendpunkt kann eine Verbindungsanfrage an die untere Schicht (Transportschicht) senden. Der lokale Aufbau der Signalisierungsverbindung an dem Zielendpunkt ist nun vollendet (16).
  • Die 2a und 2b veranschaulichen den lokalen Transportverbindungslösevorgang an den Quell- und Zielendpunkten.
  • Eine Anwendung an dem Zielendpunkt sendet eine Anwendungslöseanfragenachricht (20) und wartet auf die entfernte Antwort (21). Die Anwendungslöseanfragenachricht wird an die Transportschicht unter Verwendung eines Datenprimitivs übertragen. Dann wird die Nachricht durch die Anwendung an dem Zielendpunkt (24) empfangen. Die Anwendung an dem Zielendpunkt sendet dann (25) die Anwendungslöseabschlussnachricht an die Quellanwendung. Die Anwendung an dem Zielendpunkt sendet einen Verbindungsanfrageprimitiv an die Transportschicht, um die lokal verwendeten Ressourcen (26) zu lösen.
  • Wenn eine Anwendung an dem Quellendpunkt die Anwendungslöseabschlussnachricht als Antwort auf die vorhergehende Anwendungslöseanfragenachricht empfängt (22), soll sie das lokale Lösen der Quellen auf Transporthöhe an dem Quellendpunkt auslösen. Daher wird die Anwendung einen Trennungsanfrageprimitiv an die Transportschicht senden, die von der Transportschicht als eine lokale Trennung interpretiert wird. Nach Empfang des Verbindungsanfrageprimitivs sind alle Transportressourcen gelöst (23). Es muss festgehalten werden, dass das lokale Lösen der Transportressourcen durch die Anwendung an jedem Endpunkt ausgelöst wird, wenn die Löseanwendungsnachricht empfangen wird. Es werden keine peer-to-peer-Transporttrennungsnachrichten (z.B. SCTP PDUs) für die Trennung benötigt.
  • 3a zeigt den Steuerebenenprotokollstack in bevorzugten Ausführungsbeispielen der vorliegenden Erfindung. Der Protokollstack hat Schichten L1 bis L4 und L6, sowie der Steuerstack von 1a. Allerdings gibt es keine Anpassungsschicht L5. Stattdessen umfasst der Protokollstack die SCTP-Steuerung zwischen der Anwendungsschicht L6 und dem SCTP bei Schicht L4. Die SCTP-Steuerung ist eine Anpassungsschicht oder ein Treiber zwischen der Anwendung und der SCTP-Schicht, die SCCP-ähnliche Dienste der Anwendung bereitstellt. Es ist allerdings wichtig, zu realisieren, dass die SCTP-Steuerung kein peer-to-peer-Protokoll ist (wie z.B. das SUA von M3UA).
  • 3b ist ein Blockdiagramm, das eine Verbindungssteuerung IHND veranschaulicht. Die Verbindungssteuerung IHND bezieht sich bei einer bevorzugten Ausführungsform auf die SCTP-Steuerung. Die SCTP-Steuerung umfasst ein Mittel zum Empfangen von IF1 einer Quellanwendungsanfragenachricht von einer Anwendung, ein Mittel zum Wählen und/oder Zuteilen von ID-Verbindungskennungen (Transport- und Anwendungsverbindungskennungen), ein Mittel zum Einschließen der IM ausgewählten oder zugeteilten Transportverbindungskennung, Zielanwendungsinformation, Datentypinformation und/oder Nutzdaten in einen Datenrahmen, die an den zweiten Endpunkt an der Transportschicht geschickt werden sollen, ein Mittel zum Lesen RM einer Transportverbindungserkennung, Zielanwendungsinformation und/oder Datentypinformation von einem empfangenen Datenrahmen, ein Mittel zum Bestimmen DM, ob ein empfangener Datenrahmen sich auf einen verbindungsorientierten oder verbindungslosen Dienst bezieht, basierend auf der Datentypkennung, ein Mittel zum Erkennen DEM, wenn ein empfangener Datenrahmen einer neuen oder einer bereits existierenden Signalisierungsverbindung entspricht, ein Mittel zum Auswählen (SEL) einer Anwendungsverbindungskennung, wenn der empfangene Datenrahmen einer neuen Signalisierungsverbindung entspricht, und ein Mittel zum Senden IF2 einer Anwendungsnachricht an die Zielanwendung an der Anwendungsschicht, basierend auf der Zielanwendungsinformation.
  • Die Verbindungssteuerung verbindet eine Anwendungsschicht und eine Transportschicht miteinander. Die Verbindungssteuerung umfasst ferner ein Mittel zum Erzeugen CM einer SCTP-Verknüpfung zwischen Endpunkten und ein Mittel zum Speichern SM der Beziehung zwischen der gewählten SCTP-StreamID und der Anwendungsverbindungskennung innerhalb einer Anwendung. Ein Mittel zum Auswählen ID wird auch zum Auswählen einer SCTP-StreamID bereitgestellt, innerhalb der SCTP-Verknüpfung basierend auf der Tatsache, ob der fragliche Dienst verbindungsorientiert oder verbindungslos ist. Es ist auch ein Mittel zum Lesen RM bereitgestellt, um die gespeicherten SCTP-StreamIDs zu überprüfen.
  • Bei einem Ausführungsbeispiel ist auch ein Mittel zum Auswählen ID zum Auswählen eines geeigneten Wertes für den Protokoll-Nutzdaten-Kennungs-Parameter bereitgestellt, wobei der Protokoll-Nutzdaten-Kennungs-Parameter die Zielanwendung und/oder verbindungslosen oder verbindungsorientierten Dienst kennzeichnet.
  • Bei einem Ausführungsbeispiel ist auch ein Mittel zum Auswählen ID zum Setzen oder Zurücksetzen des SCTP-unordered-Flagparameters, wobei das Zurücksetzen des SCTP-unordered- Flagparameters den verbindungsorientierten Dienst kennzeichnet und das Setzen den verbindungslosen Dienst.
  • Bei einem Ausführungsbeispiel ist auch ein Mittel zum Bestimmen DM zum Bestimmen bereitgestellt, ob der Datenrahmen sich auf einen verbindungsorientierten oder verbindungslosen Dienst bezieht, basierend auf dem Protokoll-Nutzdaten-Kennungs-Parameterwert.
  • Bei einem Ausführungsbeispiel ist auch ein Mittel zum Bestimmen DM zum Bestimmen der Zielanwendung bereitgestellt, basierend auf dem Protokoll-Nutzdaten-Erkennungs-Parameterwert.
  • Bei einem Ausführungsbeispiel ist auch ein Mittel zum Bestimmen DM zum Bestimmen bereitgestellt, ob der Datenrahmen sich auf einen verbindungsorientierten oder verbindungslosen Dienst bezieht, basierend auf der SCTP-StreamID.
  • Bei einem Ausführungsbeispiel ist auch ein Mittel zum Erkennen DEM zum Bestimmen bereitgestellt, ob die SCTP-StreamID sich auf eine Signalisierungsverbindungsanfrage oder auf eine existierende Verbindung bezieht.
  • Bei einem Ausführungsbeispiel ist auch ein Mittel zum Bestimmen DM zum Bestimmen bereitgestellt, basierend auf dem SCTP-unordered-Flag, ob der Datenrahmen sich auf einen verbindungsorientierten oder verbindungslosen Dienst bezieht.
  • Die oben genannten Mittel sind in einem bevorzugten Ausführungsbeispiel mit Hardware- und/oder Softwarekomponenten ausgeführt.
  • 4a ist ein Flussdiagramm, das den Mechanismus veranschaulicht, der auf der Verwendung des PPI-Parameters basiert, um verbindungsorientierte und verbindungslose Dienste zwischen Endpunkten zu unterscheiden.
  • Im Falle des verbindungsorientierten Dienstes soll eine Signalisierungsverbindung aufgebaut werden bevor die tatsächliche Datenübertragung gestattet wird. Im Folgenden wird zuerst die Signalisierungsverbindungseinrichtung erklärt. Eine Anwendung fragt eine Signalisierungsverbindungseinrichtung durch Senden einer Anfrage an die SCTP-Steuerung (40) an. Die Anfrage gibt insbesondere an, dass der verbindungsorientierte Dienst durch die Transportschicht bereitgestellt werden sollte. Die SCTP-Steuerung erzeugt eine SCTP-Verknüpfung zwischen dem Quell- und dem Zielendpunkt, wenn sie nicht schon vorher erzeugt wurde. Eine SCTP-Verknüpfung ist eine Protokollbeziehung zwischen SCTP-Endpunkten, die aus zwei SCTP-Endpunkten und Protokollzustandsinformation zusammengestellt ist. Eine Verknüpfung kann eindeutig gekennzeichnet werden durch die Transportadressen, die von den Endpunkten in der Verknüpfung verwendet werden. Zwei SCTP-Endpunkte dürfen nicht mehr als eine SCTP-Verknüpfung zwischen ihnen jeweils haben. Nach Erzeugung der Verknüpfung wählt die SCTP-Steuerung einen Strom innerhalb der SCTP-Verknüpfung (41) aus. Der ausgewählte Strom kann nicht einer sein, der bereits bei einer anderen Verbindung verwendet wird. Der Strom wird durch eine eindeutige Stromnummer bzw. Streamnummer (StreamID) gekennzeichnet. Die SCTP-Steuerung macht die Abbildung der StreamID innerhalb der Verknüpfung und die Anwendungsverbindungskennung ist innerhalb der Anwendung und speichert die Abbildungsinformation (42). Der Abbildungsvorgang simuliert die lokale Einrichtung der Signalisierungsverbindung auf der Quellendpunktseite. Die Abbildung ist für Routingprozesse während der Dauer der Verbindung notwendig. Gespeicherte Information wird nicht gelöst, bis die Signalisierungsverbindung gelöst ist.
  • Wenn eine Signalisierungsverbindung nicht aufgebaut wurde, soll die Quellanwendung einen Wert für die Anwendungsverbindungskennung (connID) wählen, jedes Mal dann, wenn eine neue Verbindung von diesem Anwendungsendpunkt angefragt wird. Im Falle einer eingehenden Anfrage an der Zielanwendung soll die SCTP-Steuerung einen connID(Anwendungsverbindungskennung)-Wert für jede neue eingehende Verbindungseinrichtungsanfrage wählen. Die SCTP-Steuerung verarbeitet eine neue eingehende Verbindung, wenn die empfangene StreamID in der Datenübertragung nicht in der zugewiesenen Stromliste in der SCTP-Steuerung eingeschlossen ist (d.h. die empfangene StreamID wird nicht für eine andere Signalisierungsverbindung verwendet). Der connID-Parameter wird nur in verbindungsorientierten Diensten verwendet. Die StreamID kennzeichnet einen Strom innerhalb einer Verknüpfung. Bei einem Ausführungsbeispiel sind Ströme unidirektional, so dass eine Kennung für jede Richtung der Verknüpfung zugewiesen wird.
  • Die SCTP-Steuerung an dem Quellendpunkt wählt einen geeigneten Wert für den Nutzdaten-Protokollkennungs-(PPI)-Parameter (43). Bei diesem Ausführungsbeispiel der Erfindung kennzeichnet der PPI-Wert die Zielanwendung und unterscheidet den verbindungsorientierten Dienst von dem verbindungslosen Dienst. Schlussendlich überträgt das SCTP eine SCTP PDU an die entfernte SCTP (44). Wenn in der Anwendungsanfrage Anwendungsdaten vorhanden waren, können die Daten als Nutzdaten innerhalb der SCTP PDU übertragen werden.
  • Wenn die Signalisierungsverbindung für einen verbindungsorientierten Dienst bereits aufgebaut wurde oder der Dienst verbindungslos ist, ist die Funktionalität leicht unterschiedlich zu der, wenn nur die Signalisierungsverbindung eingerichtet wird. Wenn die SCTP-Steuerung an dem Quellendpunkt Anwendungsdaten empfängt, können die Daten entweder verbindungsorientiert oder verbindungslos sein (45). Wenn die SCTP-Steuerung verbindungsorientierte Daten (46) von einer oben liegenden Anwendung, die bereits eine Signalisierungsverbindung eingerichtet hat, empfängt, wird die SCTP-Steuerung die vorherigen zugewiesenen Ströme für diese Signalisierungsverbindung innerhalb der Verknüpfungen (47) verwenden. Die SCTP-Steuerung wählt einen geeigneten Wert für die PPI. In diesem Falle kennzeichnet die PPI sowohl das Anwendungsprotokoll und den verbindungsorientierten Dienst (48). Schlussendlich überträgt die Quell-SCTP die SCTP PDU an die Ziel-SCTP (49). Die Anwendungsaten werden als Nutzdaten innerhalb der SCTP PDU übertragen.
  • Wenn die SCTP-Steuerung verbindungslose Daten (46) von der oberen Anwendung empfängt, wählt die SCTP-Steuerung eine der unbenutzten SCTP-Ströme innerhalb der Verknüpfung (410). Ein nicht verwendeter SCTP-Strom bezieht sich z.B. auf einen Strom, der nicht speziell verwendet wird oder für verbindungsorientierte Dienste zugeteilt wird. Wenn eine Verknüpfung zwischen den Quellen- und Zielendpunkten nicht vorher erzeugt würde, wird sie erzeugt. Als nächstes wählt die SCTP-Steuerung den geeigneten Wert für die PPI (411). In diesem Falle kennzeichnet die PPI sowohl das Anwendungsprotokoll als auch den verbindungslosen Dienst. Schlussendlich überträgt die Quell-SCTP die SCTP PDU an das Ziel-SCTP (412). Die Anwendungsdaten werden als Nutzdaten innerhalb der SCTP PDU übertragen.
  • 4b ist ein Flussdiagramm, das den Mechanismus veranschaulicht, der auf der Verwendung des PPI-Parameters basiert, um verbindungsorientierte und verbindungslose Dienste durch den Zielendpunkt zu unterscheiden.
  • Im Falle eines verbindungsorientierten Dienstes soll die Einrichtung der Signalisierungsverbindung, die durch die Quelle angefragt wurde, vor dem Start der Datenübertragung abgeschlossen bzw. vollendet sein. Das SCTP an dem Zielendpunkt empfängt eine SCTP PDU (413). Die SCTP-Steuerung überprüft den Wert des PPI-Feldes des empfangenen Datenpakets (414) und bestimmt, basierend auf dem PPI-Wert, dass der SCTP PDU sich auf einen verbindungsorientierten Dienst bezieht (415). Wenn die StreamID innerhalb der Verknüpfung nicht vorher benutzt wurde (d.h. die StreamID ist nicht gerade in der SCTP-Steuerung zugewiesen), schließt die SCTP-Steuerung, dass der SCTP PDU sich auf eine Signalisierungsverbindungsangabe (eingehende Verbindungsanfrage) (415) bezieht und speichert die StreamID (416a). Dann wählt die SCTP-Steuerung eine Anwendungsverbindungskennung (connID) und bildet sie auf die Transportverbindungskennung ab (z.B. SCTP-StreamID) innerhalb der Verknüpfung für weitere Routingzwecke während der Länge der Verbindung (416b) ab. Die Anwendungsverbindungskennung kennzeichnet eine besondere Verbindung innerhalb der Zielanwendung. Der Abbildungsvorgang simuliert die lokale Einrichtung der Signalisierungsverbindung an der Zielendpunktseite. Nach diesem überprüft die SCTP-Steuerung den PPI, um die Zielanwendung zu identifizieren (417) und sendet eine Verbindungkennungsprimitiv an die Zielanwendung, die durch den PPI-Wert (418) angegeben wird.
  • Wenn allerdings die StreamID innerhalb der Verknüpfung vorher benutzt wurde (d.h. sie wurde bereits in der SCTP-Steuerung gespeichert), schließt die SCTP-Steuerung, dass eine Signalisierungsverbindung bereits vorher eingerichtet wurde für diesen Benutzer und die SCTP PDU-Nutzdaten den verbindungsorientierten Anwendungsdaten entsprechen. Dann verwendet die SCTP-Steuerung die StreamID, um die Zielanwendungsverbindungskennung zu wissen (connID) (419a). Die Anwendungsverbindungskennung kennzeichnet eine bestimmte Verbindung innerhalb der Zielanwendung. Die SCTP-Steuerung überprüft die PPI, um die Zielanwendung zu identifizieren (419b) und sendet die SCTP PDU-Nutzdaten (Benutzerdaten) an die identifizierte Zielanwendung (420).
  • Eine weitere Alternative ist, dass das PPI-Feld angibt, dass die Daten sich auf einen verbindungslosen Dienst (414) beziehen. In diesem Falle verwendet die SCTP-Steuerung den PPI-Wert, um die Zielanwendung (421) zu identifizieren. Schlussendlich sendet die SCTP-Steuerung die SCTP-Nutzdaten (Benutzerdaten) an die identifizierte Zielanwendung als verbindungslose Daten (422). Die Ausführung des in 4a und 4b dargestellten Mechanismus' kann durch Einschließen der verbindungslosen und verbindungsorientierten Werte für jedes der Protokolle, das in dem PPI-Feld definiert ist, ausgeführt werden. Der Mechanismus benötigt keine Veränderung in dem SCTP RFC und auch nicht in Anwendungsstandards.
  • 5a ist ein Flussdiagramm, das den Mechanismus veranschaulicht, der auf der Reservierung von Strömen basiert, um verbindungsorientierte und verbindungslose Dienste durch den Quellendpunkt zu unterscheiden. In diesem Falle wird die SCTP-Steuerung eine bestimmte Stromnummer (z.B. StreamID = 1) oder einer Gruppe von Strömen verwenden, um den verbindungslosen Dienst zu identifizieren. Der spezifische reservierte Wert(e) ist (sind) in beiden SCTP-Endpunkten (Quelle und Ziel) bekannt. Der Rest der StreamIDs wird für verbindungsorientierte Dienste verwendet.
  • Im Falle eines verbindungsorientierten Dienstes soll eine Signalisierungsverbindung eingerichtet werden, bevor mit der tatsächlichen Datenübertragung begonnen wird und diese gestartet wird. Im Folgenden wird zuerst die Signalisierungsverbindungseinrichtung erklärt. Eine Anwendung fragt eine Signalisierungsverbindungseinrichtung an, indem sie eine Anfrage an die SCTP-Steuerung (50) sendet. Die SCTP-Steuerung erzeugt eine SCTP-Verknüpfung zwischen der Quelle und dem Zielendpunkt, wenn sie noch nicht vorher erzeugt wurde. Danach wählt die SCTP-Steuerung einen Strom innerhalb der SCTP-Verknüpfung (51). Der Strom wird durch eine eindeutige Stromnummer (StreamID) identifiziert. Es muss festgehalten werden, dass die gewählte StreamID nicht aus den Stromnummern gewählt werden kann, die für verbindungslose Dienste reserviert sind. Die SCTP-Steuerung übernimmt das Mapping bzw. Abbilden der StreamID innerhalb der Verknüpfung und die Anwendungsverbindungskennung innerhalb der Anwendung und speichert die Abbildungsinformation (52). Der Abbildungsvorgang simuliert die lokale Einrichtung der Signalisierungsverbindung auf der Quellendpunktseite. Die Abbildung ist für Routingzwecke während der Dauer der Verbindung notwendig. Gespeicherte Information wird nicht gelöst, bis die Signalisierungsverbindung gelöst ist.
  • Die SCTP-Steuerung an dem Quellendpunkt wählt einen geeigneten Wert für den Nutzdaten-Protokoll-Kennungs-(PPI)-Parameter (53). Bei diesem Beispiel kennzeichnet der PPI-Wert nur die Zielanwendung. Schlussendlich überträgt die SCTP eine SCTP PDU an den entfernten SCTP (54). Wenn Anwendungsdaten in der Zielanwendungsanfrage vorhanden waren, können die Daten als Nutzdaten innerhalb der SCTP PDU übertragen werden.
  • Wenn die Signalisierungsverbindung für einen verbindungsorientierten Dienst bereits aufgebaut wurde oder der Dienst verbindungslos ist, kann die Funktionalität leicht unterschiedlich sein, als die, wenn nur die Signalisierungsverbindung eingerichtet wird. Wenn die SCTP-Steuerung an dem Quellendpunkt Anwendungsdaten empfängt, können die Daten entweder verbindungsorientiert oder verbindungslos sein (55). Die Anwendungsdatenanfrage gibt an, welcher Dienst (verbindungsorientiert oder verbindungslos) durch die Transportschicht bereitgestellt werden soll. Wenn die SCTP-Steuerung verbindungsorientierte Daten von einer oberen Anwendung empfängt, die bereits eine Signalisierungsverbindung (56) eingerichtet hat, wird die SCTP-Steuerung den vorher zugeteilten Strom für die Signalisierungsverbindung innerhalb der Verknüpfung (57) verwenden. Die SCTP-Steuerung wählt den geeigneten Wert für die PPI. In diesem Falle kennzeichnet die PPI nur die Zielanwendung (58). Schlussendlich überträgt die Quell-SCTP die SCTP PDU an die Ziel-SCTP (59). Die Anwendungsdaten werden als Nutzdaten innerhalb der SCTP PDU übertragen.
  • Wenn die SCTP-Steuerung verbindungslose Daten von der oberen Anwendung (56) empfängt, wählt die SCTP-Steuerung einen der Ströme, die in der SCTP-Verknüpfung für den Transport von verbindungsloser Signalisierung zugeteilt ist (d.h. StreamID = 1, oder ein Strom aus der Gruppe von Strömen wird für die verbindungslose Signalisierung verwendet). (510). Wenn eine Verknüpfung zwischen den Quell- und Zielendpunkten nicht vorher erzeugt wurde, wird sie an diesem Punkt erzeugt. Als nächstes wählt die SCTP-Steuerung den geeigneten Wert für die PPI (511). In diesem Fall kennzeichnet die PPI nur die Zielanwendung. Schließlich überträgt die Quell-SCTP die SCTP PDU an die Ziel-SCTP (512). Die Anwendungsdaten werden als Nutzdaten innerhalb der SCTP PDU übertragen.
  • 5b ist ein Flussdiagramm, das den Mechanismus veranschaulicht, der auf der Reservierung von Strömen basiert, um verbindungsorientierte und verbindungslose Dienste durch den Zielendpunkt zu unterscheiden.
  • Im Falle eines verbindungsorientierten Dienstes soll die Einrichtung der Signalisierung, die durch die Quelle angefragt wurde, vor Start der Datenübertragung vollendet sein. Die SCTP an dem Zielendpunkt empfängt eine SCTP PDU (513). Die SCTP-Steuerung überprüft den Wert des SCTP-StreamID (514). Die StreamID bestimmt den Typ der empfangenen Daten (verbindungsorientiert oder verbindungslos). Wenn die StreamID nicht unter den zu verbindungslose Dienste zugeteilten/reservierten StreamID(s) ist, dann bezieht sich die StreamID auf einen verbindungsorientierten Dienst (515). Wenn die StreamID innerhalb der Verknüpfung vorher nicht benutzt wurde (d.h., dass die StreamID derzeit nicht der SCTP-Steuerung zugeteilt ist), schließt die SCTP-Steuerung, dass das SCTP PDU sich auf eine Signalisierungsverbindungsangabe (eingehende Verbindungsanfrage) bezieht und speichert und teilt die StreamID für diese Signalisierungsverbindung zu (516a). Dann wählt die SCTP-Steuerung eine Anwendungsverbindungskennung und bildet sie auch für die Transportverbindungskennung ab (d.h. die SCTP-StreamID), innerhalb der Verknüpfung für weitere Routingzwecke während der Dauer der Verbindung (516b). Die Anwendungsverbindungskennung identifiziert eine bestimmte Verbindung innerhalb der Zielanwendung. Der Abbildungsvorgang simuliert die lokale Einrichtung der Signalisierungsverbindung auf der Zielendpunktseite. Danach überprüft die SCTP-Steuerung den PPI, um die Zielanwendung zu identifizieren (517) und sendet eine Verbindungsangabeprimitive an die Zielanwendung, die durch den PPI-Wert (518) angegeben ist.
  • Allerdings schließt die SCTP-Steuerung, wenn die StreamID innerhalb der Verknüpfung vorher benutzt wurde (d.h. sie ist in der SCTP-Steuerung gespeichert), dass eine Signalisierungsverbindung bereits vorher für diesen Benutzer eingerichtet wurde und die SCTP PDU-Nutzdaten den verbindungsorientierten Anwendungsdaten entsprechen. Dann verwendet die SCTP-Steuerung die StreamID, um die Anwendungsverbindungskennung (connID)(519a) zu kennen. Die Anwendungsverbindungskennung identifiziert eine bestimmte Verbindung innerhalb der Zielanwendung. Die SCTP-Steuerung überprüft den PPI, um die Zielanwendung zu identifizieren (519b). Danach sendet die SCTP-Steuerung die SCTP PDU-Nutzdaten (Benutzerdaten) an die identifizierte Zielanwendung (520).
  • Eine andere Möglichkeit ist, dass die Stromnummer (d.h. die StreamID = 1) angibt, dass sich die Daten auf einen verbindungslosen Dienst (514) beziehen. In diesem Falle verwendet die SCTP-Steuerung den PPI-Wert, um die Zielanwendung (521) zu identifizieren. Schlussendlich sendet die SCTP-Steuerung die SCTP-Nutzdaten (Benutzerdaten) an die identifizierte Zielanwendung als verbindungslose Daten (522). Die Ausführung des in 5a und 5b dargestellten Mechanismus' kann durch Reservierung eines bestimmten Stromes für verbindungslose Dienste geschehen. Der Mechanismus benötigt keine Veränderung in der SCTP RFC und auch nicht in Anwendungsstandards.
  • 6a ist ein Flussdiagramm, das den Mechanismus veranschaulicht, der auf der Verwendung des SCTP-unordered-Flagparameters basiert, um die verbindungsorientierten und verbindungslosen Dienste durch den Quellendpunkt zu unterscheiden. Der ursprüngliche Zweck des unordered Flags (U-Bit) in dem SCTP ist in RFC 2960 spezifiziert. Das unordered Bit gibt an, wenn es auf "1" gesetzt ist, dass dies eine ungeordnete Datenkette ist, und dass es keine Stromreihenfolgenummer gibt, die dieser DATA-Kette zugeordnet ist. Daher muss der Empfänger das Stromreihenfolgenummerfeld ignorieren. Nach Zusammenbau (wenn nötig) müssen die ungeordneten Datenketten an die obere Schicht durch den Empfänger ohne einen Versuch der Neuordnung gesendet werden. Wenn eine ungeordnete Benutzernachricht fragmentiert ist, muss jedes Fragment seine U-Bits auf "1" gesetzt haben.
  • Im Falle eines verbindungsorientierten Dienstes soll eine Signalisierungsverbindung vor oder beim Beginn des Starts der tatsächlichen Datenübertragung eingerichtet werden. Im Folgenden wird zuerst die Signalisierungsverbindungseinrichtung erklärt. Eine Anwendung fragt eine Signalisierungsverbindungseinrichtung durch Senden einer Anfrage an die SCTP-Steuerung (60) an. Die SCTP-Steuerung erzeugt eine SCTP-Verknüpfung zwischen dem Quell- und dem Zielendpunkt, wenn sie nicht vorher schon erzeugt wurde. Danach wählt die SCTP-Steuerung einen der bereits nicht zugeteilten Ströme innerhalb der SCTP-Verknüpfung (61). Der Strom wird durch eine eindeutige Stromnummer (StreamID) gekennzeichnet. Die SCTP-Steuerung nimmt das Abbilden der StreamID innerhalb der Verknüpfung und der Anwendungsverbindungskennung innerhalb der Anwendung vor und speichert die Abbildungsinformation (62). Der Abbildungsvorgang simuliert die lokale Einrichtung der Signalisierungsverbindung auf der Quellendpunktseite. Die Abbildung ist nötig für Routingprozesse während der Dauer der Verbindung. Gespeicherte Information wird nicht losgelöst, bis die Signalisierungsverbindung gelöst ist.
  • Die SCTP-Steuerung an dem Quellendpunkt wählt einen geeigneten Wert für die Nutzlast-Protokoll-Kennungs-(PPI)-Parameter (63). Der PPI-Wert kennzeichnet die Zielanwendung. Allerdings wird nun der Diensttyp (verbindungsorientiert oder verbindungslos) auf eine von der in den vorherigen Beispielen verschiedene Art und Weise angegeben. In diesem Falle wird das SCTP-"unordered flag"-Parameter verwendet, um zwischen verbindungsorientierten und verbindungslosen Diensten zu unterscheiden. Das unordered Flag wird nicht mit verbindungsorientierten Diensten (64) gesetzt. Schlussendlich überträgt die SCTP eine SCTP PDU an die entfernte SCTP (65). Wenn Anwendungsdaten in den Anwendungsanfragen vorhanden waren, können die Daten als Nutzdaten innerhalb der SCTP PDU übertragen werden.
  • Wenn die Signalisierungsverbindung für einen verbindungsorientierten Dienst bereits aufgebaut wurde oder der Dienst verbindungslos ist, ist die Funktionalität leicht unterschiedlich von der, wenn nur die Signalisierungsverbindung eingerichtet wird. Wenn die SCTP-Steuerung an dem Quellendpunkt Anwendungsdaten empfängt, können die Daten entweder verbindungsorientiert oder verbindungslos sein (66, 67). Die Anwendungsdatenanfrage gibt an, welcher Service (verbindungsorientiert oder verbindungslos) durch die Transportschicht bereitgestellt werden soll. Wenn die SCTP-Steuerung verbindungsorientierte Daten von einer oberen Anwendung empfängt, die bereits eine Signalisierungsverbindung eingerichtet hat, wird die SCTP-Steuerung den vorherigen zugeteilten Strom für diese Signalisierungsverbindung innerhalb der Verknüpfung (68) verwenden. Die SCTP-Steuerung wählt den geeigneten Wert für die PPI. In diesem Falle gibt die PPI nur die Zielanwendung an (69). Der SCTP-"unordered flag"-Parameter wird wiederum dafür verwendet, zwischen verbindungsorientierten und verbindungslosen Diensten zu unterscheiden. Das unordered Flag wird nicht bei verbindungsorientierten Diensten (610) gesetzt. Schlussendlich überträgt die Quell-SCTP das SCTP PDU an die Ziel-SCTP (611). Die Anwendungsdaten werden als Nutzdaten innerhalb des SCTP PDU übertragen.
  • Wenn die SCTP-Steuerung verbindungslose Daten von der oberen Anwendung empfängt, wählt die SCTP-Steuerung jeden der SCTP-Ströme innerhalb der Verknüpfung (612). Wenn eine Verknüpfung zwischen den Quell- und Zielendpunkten nicht vorher erzeugt wurde, wird sie jetzt erzeugt. Als nächstes wählt die SCTP-Steuerung den geeigneten Wert für die PPI. In diesem Falle kennzeichnet die PPI nur die Zielanwendung (613). In diesem Fall wird der SCTP-unordered-Flag-Parameter verwendet, um zwischen verbindungsorientierten und verbindungslosen Diensten zu unterscheiden. Das unordered Flag wird nun gesetzt, um anzugeben, dass es ein verbindungsloser Dienst ist (614). Schlussendlich überträgt die Quell-SCTP den SCTP PDU an die Ziel-SCTP (615). Die Anwendungsdaten werden als Nutzdaten innerhalb der SCTP PDU übertragen.
  • 6b ist ein Flussdiagramm, das den Mechanismus veranschaulicht, welcher auf der Verwendung des SCTP-unordered-Flagparameters basiert, um zwischen verbindungsorientierten und verbindungslosen Diensten durch den Zielendpunkt zu unterscheiden. Die Unterstützung für diesen Mechanismus an dem empfangenen Endpunkt würde Änderungen in dem aktuellen Standard-SCTP-Primitiven benötigen.
  • Im Falle eines verbindungsorientierten Dienstes soll die Einrichtung der Signalisierungsverbindung, die durch die Quelle angefragt wurde, abgeschlossen werden, bevor mit der Datenübertragung begonnen wird. Die SCTP an dem Zielendpunkt empfängt eine SCTP PDU (616). Die SCTP-Steuerung überprüft, ob das unordered Flag gesetzt ist ("1") oder nicht ("0") (617). Wenn es nicht gesetzt ist, beziehen sich die empfangenen SCTP-Daten auf einen verbindungsorientierten Dienst. Wenn die StreamID innerhalb der Verknüpfung vorher nicht benutzt wurde (d.h. die StreamID ist nicht in der SCTP-Steuerung gespeichert) (618), schließt die SCTP-Steuerung, dass der SCTP PDU sich auf eine Signalisierungsverbindungsangabe (eingehende Verbindungsanfrage) bezieht und speichert die StreamID (619a). Dann wählt die SCTP-Steuerung eine Anwendungsverbindungskennung (connID) und bildet sie auf die Transportverbindungskennung (z.B. SCTP-StreamID) innerhalb der Verknüpfung ab, für weitere Routingprozesse während der Dauer der Verbindung (619b). Die Anwendungsverbindungskennung kennzeichnet eine bestimmte Verbindung innerhalb der Zielanwendung. Der Abbildungsvorgang simuliert die lokale Einrichtung der Signalisierungsverbindung auf der Zielendpunktseite. Danach überprüft die SCTP-Steuerung die PPI, um die Zielanwendung (620) zu identifizieren und sendet eine Verbindungsangabeprimitive an die Zielanwendung, die durch den PPI-Wert (621) angegeben wird.
  • Allerdings wird, wenn die StreamID innerhalb der Verknüpfung vorher benutzt wurde (d.h. sie wurde in der SCTP-Steuerung gespeichert), die SCTP-Steuerung schließen, dass eine Signalisierungsverbindung bereits vorher für den Benutzer eingerichtet wurde und dass die SCTP PDU-Nutzdaten den verbindungsorientierten Anwendungsdaten entsprechen. Dann verwendet die SCTP-Steuerung die StreamID, um die Anwendungsverbindungskennung (622a) zu kennen. Die Anwendungsverbindungskennung identifiziert eine bestimmte Verbindung innerhalb der Zielanwendung. Die SCTP-Steuerung überprüft den PPI, um die Zielanwendung (622b) zu identifizieren und sendet die SCTP PDU-Nutzdaten (Benutzerdaten) an die identifizierte Zielanwendung (623).
  • Eine andere Alternative ist, dass das unordered Flag ("1") angibt, dass die Daten sich auf einen verbindungslosen Dienst (617) beziehen. In diesem Falle verwendet die SCTP-Steuerung den PPI-Wert, um die Zielanwendung (624) zu identifizieren. Schlussendlich sendet die SCTP-Steuerung die SCTP-Nutzdaten (Benutzerdaten) an die identifizierte Zielanwendung als verbindungslose Daten (625).
  • Eine weitere Alternative ist, die Funktionalitäten, die in 5 bis 6 veranschaulicht sind, zu kombinieren. In diesem Falle wird die SCTP-Steuerung für eine bestimmte Stromnummer (z.B. StreamID = 1) oder eine Gruppe von Strömen verwendet, um verbindungslose Dienste zu identifizieren. Der (die) gewählte Strom (Ströme) für verbindungslose Nachrichten wird eine ungeordnete Übertragung von Nachrichten verwenden, indem das unordered Flag gesetzt wird. Der Hauptvorteil dieser Lösung gegenüber der Lösung, die mit 5a und 5b veranschaulicht wurde, ist, dass in diesem Fall das "Kopf der Leitungsblockieren" (englisch: "Head of Line blocking") vermieden wird: Wenn ein Paket in dem gewählten Strom verloren geht, werden die nächsten Pakete ohne Warten auf die Neuübertragung des verlorenen Pakets übertragen.
  • Als eine Schlussfolgerung beschreiben die in diesem Erfindungsmechanismus dargelegten Mechanismen einen vereinfachten Protokollstack, der in der Lage ist, dieselbe Art von Diensten nach der Anwendung bereitzustellen, wie ein Signalisierungsprotokoll wie zum Beispiel SCCP/M3UA oder SUA, das bedeutet verbindungsorientierte und verbindungslose Dienste und den Aufbau von Signalisierungsverbindungen. Dieser vereinfachte Protokollstack hat klare Vorteile: Reduktion der Überlast (Overhead), die durch das SCCP/M3UA, SUA oder irgendein anderes verwendetes peer-to-peer-Anpassungsprotokoll eingeführt wird; Vermeiden des Überlappens von Adressierungs-/Routingmechanismen, usw. Solche Lösungen benötigen keine Veränderungen der existierenden Spezifikationen und peer-to-peer-Signalisierung, außer bei dem in 6a und 6b dargestellten Mechanismus.
  • 7 veranschaulicht ein Ausführungsbeispiel des Systems, bei welchem die vorliegende Erfindung verwendet werden kann. Das System umfasst drei Funkzugangsnetze: das UTRAN, IP-RAN und GERAN. Das GERAN (GSM/EDGE-Funkzugangsnetz) ist ein erweitertes GSM-Funkzugangsnetz. Erweitert hierin bedeutet, dass das GERAN das EDGE als eine Funktechnologie verwendet. Das EDGE ermöglicht die Verwendung des UMTS-Dienstes mit 800/900/1800/1900 MHz Frequenzbändern. Das GERAN bietet die vollen Vorteile von GPRS (allgemeines Paketfunksystem) auszuschöpfen. Das Basisstationsubsystem (BSS) des GERAN kann mit dem GSM-Kernnetz durch Gb(zwischen dem BSS und einem GSM SGSN) und A (zwischen einem BSS und einem GSM MSC)-Schnittstellen verbunden werden. Das BSS kann ferner mit dem UMTS-Netzwerk durch Schnittstellen Iu-ps (zwischen einem BSS und einem 3G SGSN) und Iu-cs (zwischen einem BSS und einem 3G MSC) verbunden werden. Das BSS kann ferner mit dem RNC des UTRAN oder mit einer anderen BSS durch eine Iur-g-Schnittstelle verbunden werden. Das BSS weist eine Basisstationsteuerung (BSC) und Basis-Sende-Empfängerstationen (BTS) auf. In dem GERAN wird die Luftschnittstelle zwischen dem BTS und dem Teilnehmergerät (UE) als Um bezeichnet.
  • Die IP RAN (Internetprotokollfunkzugangsnetz, englisch: Internet Protocol Radio Access Network) ist eine RAN-Architektur, die dahingehend vollständig optimiert ist, IP-Verkehr zu tragen und basiert auf einer IP-Transporttechnologie. In dem IP RAN werden einige der Funktionen der zentralisierten Funkzugangssteuerung (RNC und BSC) zu der Basisstation IP BTS verlagert. In dieser Konfiguration ist die Teilung der Funktionalitäten zwischen Netz(werk)elementen fundamental neu festgelegt, um den Bedürfnissen des IP-Verkehrs gerecht zu werden. Dies unterscheidet sich deutlich von der einfachen Verwendung von IP als eine Transportlösung mit bestehenden Netzwerkarchitekturen, wie zum Beispiel GSM (Global System for Mobile Communications, globales System für Mobilkommunikation) und dem CDMA (Code Division Multiple Access, Codemultiplexzugang) basierten Funkzugangsnetzen. Die Funkzugangsnetze sind mit dem Kernnetz CN verbunden. 7 umfasst auch ein Teilnehmerendgerät UE. Das Teilnehmerendgerät UE bezieht sich vorzugsweise auf ein Mobilgerät, zum Beispiel ein Mobiltelefon. Das Teilnehmerendgerät UE kann mit einem oder mehreren Funkzugangsnetzen verbunden werden.
  • Es muss festgehalten werden, dass 7 nur ein Ausführungsbeispiel eines Systems veranschaulicht, bei welchem die vorliegende Erfindung verwendet werden kann. Das System kann weitere Elemente umfassen, die nicht in 7 dargestellt sind. Elemente dieser Art können eines oder mehrere der folgenden sein: bedienende Mobil-Aufenthaltszentrale (SMLC, englisch: Serving Mobile Location Center), gemeinsamer Ressourcenverwaltungsserver (CRMS, englisch: Common Resource Manager Server), Betriebs- und Unterhaltungsserver (OMS, englisch: Operation and Maintenance Server) und Transportressourcenserver.
  • Die vorliegende Erfindung kann auf jede Schnittstelle erweitert werden, die den SCCP/M3UA/SCTP/IP-Stack aufweist, z.B. die Iur, Iu, A-Schnittstelle. Daher ist es klar, dass die Anwendungsschicht variieren kann. Es kann z.B. sein: der Funkzugangsnetanwendungsteil (RANAP), Funknetzsubsystemanwendungsteil (RNSAP), Basissystemanwendungsteil (BSSAP) usw. Weiterhin kann der in der vorliegenden Erfindung beschriebene Endpunkt einer der folgenden sein: eine Basisstation, eine Steuerung, eine Funknetzsteuerung, ein Kernnetz, ein Funknetzzugangsserver, Gateway, Server, Mobilknoten, Router, drahtloser Router, Computer, SGSN, GPRS-Gateway-Unterstützungsknoten (GGSN), jedes geeignete Funkzugangsnetz oder Kernnetzelement oder dergleichen.
  • 8 zeigt ein Ausführungsbeispiel der vorliegenden Erfindung, das ein Beispiel einer IP RAN logischen Struktur aufweist. IP-Basis-Sende-Empfängerstationen 82 sind gezeigt. Das Endteilnehmergerät 80 ist eingerichtet, mit der Basis-Sende-Empfängerstation 82 über eine drahtlose Verbindung zu kommunizieren. Das Teilnehmerendgerät kann ein Mobiltelefon sein, Computer, persönlicher digitaler Assistent oder irgendeine andere solche Einheit. Die Basisstationen können herkömmliche Basisstationen 82a sein oder können IP-Basisstationen 82b sein, die den IP-Transport unterstützen. Die herkömmlichen Basisstationen sind mit einer Steuerung verbunden, die in dem veranschaulichten Ausführungsbeispiel eine RNC 84 ist. Die RNC 84 ist mit den Basisstationen 82a über eine Iub-Schnittstelle verbunden.
  • Die IP-Basisstationen 82b sind mit einer IP-Steuerung verbunden, die als eine RNAS 86 bezeichnet wird (Funknetzzugangsserver). Diese kann einige ähnliche Funktionen der RNC bereitstellen und kann auch als eine IP basierte RNC bezeichnet werden. Die RNAS 86 ist mit den Basisstationen über eine Iu'-Schnittstelle verbunden. Die RNC 84 und die RNAS 86 können miteinander über eine Iur-Schnittstelle kommunizieren. Es kann auch mehr als ein Server 88 bereitgestellt werden, der in der Lage ist, mit der RNC 84, der RNAS 86 und den IP-Basisstationen 82b oder nur mit einigen von diesen zu kommunizieren. Beispiele dieser Server sind: bedienende Mobil-Aufenthaltszentrale (SMLC, englisch: Serving Mobile Location Center), gemeinsamer Ressourcenverwaltungsserver (CRMS, englisch: Common Resource Manager Server) und Betrieb- und Unterhaltungsserver (OMS, englisch: Operation and Maintenance Server).
  • Die IP-Basisstationen 82b und das RNAS 86 bilden ein IP RAN 90. Die Basisstationen 82a und die RNC 84 bilden ein eher herkömmliches RAN 92. Sowohl das RNC 84 und das RNAS 86 sind eingerichtet, mit einem Kernnetz 94 über eine Iu-Schnittstelle zu kommunizieren.
  • Es sollte begrüßt werden, dass 8 eine schematische Ansicht eines Netzes ist. Das eher herkömmliche RAN 92 kann bei einigen Ausführungsbeispielen der vorliegenden Erfindung weggelassen werden. Bei einigen Ausführungsbeispielen der vorliegenden Erfindung kann ein gesondertes RNC-Element zwischen der Basisstation und dem RNAS in dem IP RAN bereitgestellt werden. Das RNAS kann durch eine IP-basierte RNC ersetzt werden. Das IP BTS ist eine Basisstation, welche IP unterstützt und einige Funktionen des RNC. Dies ist so, da in allen IP-Netzwerken es nicht notwendig ist, RNCs als solche zu haben. Es sind auch bereitgestellt aber nicht gezeigt, Benutzerebenengateways für paketvermittelten (RNGW) und leitungsvermittelten (CSGW) Verkehr. Diese sind zwischen den RANs und/oder dem Kernnetz oder anderen Netzen angeordnet. Folglich geht die Steuerebene durch RNAS, welches wie ein normales RNC aussieht, zu anderen Netz(werk)elementen in dem Kernnetz(werk), so dass ein bedienender GPRS(allgemeiner Paketfunkdienst)-Unterstützungsknoten SGSN oder andere Funkzugangsnetzelemente, wie beispielsweise eine Funknetzsteuerung oder Basisstationsteuerung. Die Benutzerebene geht dann durch drei dieser Benutzerebenengateways RNGW und CSGW. Zusätzliche Elemente können auch in der gezeigten Anordnung in alternativen Ausführungsbeispielen der vorliegenden Erfindung enthalten sein.
  • In einem Ausführungsbeispiel der 8 ist die Anpassungsschicht in den Kommunikationssteuerstacks des IP BTS und des RNAS weggelassen. Es sollte allerdings begrüßt werden, dass die Ausführungsbeispiele der vorliegenden Erfindung auch irgendwo anders angewendet werden können. Das SCTP kann in der Steuerebene zwischen diesen anderen Netzelementen genauso oder alternativ verwendet werden. Nur das Protokoll oben auf der SCTP verändert sich. In Ausführungsbeispielen der vorliegenden Erfindung kann das SCTP in verschiedenen Schnittstellen von IP basierten RAN verwendet werden. Zum Beispiel kann es zwischen zwei Basisstationen, zwischen einer Basisstation und einer Steuerung (entweder RNC oder RNAS) verwendet werden. Ausführungsbeispiele der Erfindung können auch zwischen Steuerungen (RNCs oder RNASes) verwendet werden. Darüber hinaus können Ausführungsbeispiele der Erfindung zwischen verschiedenen Arten von Servereinheiten verwendet werden, wie beispielsweise bedienender Mobilaufenthaltszentrale SMLC oder gemeinsamer Ressourcenverwaltungsserver CRMS und IP-Basisstationen oder RNCs/RNASes. Ausführungsbeispiele der vorliegenden Erfindung können auch zwischen einem IP BTS und einem UTRAN RNC verwendet werden.
  • Einem Fachmann ist es offensichtlich, dass mit dem Fortschreiten der Technologie die Grundidee der Erfindung auf verschiedene Arten ausgeführt werden kann. Die Erfindung und ihre Ausführungsbeispiele sind daher nicht auf die hierin beschriebenen Beispiele begrenzt, sondern sie variieren innerhalb des Schutzbereiches der Ansprüche.

Claims (47)

  1. Verfahren zum Senden von verbindungs-orientierten und verbindungslosen Daten zwischen zwei Endpunkten in einer Protokoll-Architektur, umfassend mindestens eine Anwendungsschicht und eine Transportschicht und eine oder mehrere Anwendungen, die die Anwendungsschicht verwenden, dadurch gekennzeichnet, dass das Verfahren die Schritte umfasst: • Senden einer Quellanwendungs-Anfragenachricht mit einer Anwendung an dem ersten Endpunkt an die Transportschicht, wobei mit der Quellanwendung angegeben wird, welcher Dienst von der Transportschicht bereitgestellt werden soll, wobei der Dienst verbindungs-orientiert oder verbindungslos ist; • Zuteilen einer Transportverbindungskennung innerhalb der Transportschicht an dem ersten Endpunkt; • Senden eines Datenrahmens an den zweiten Endpunkt, wobei der Datenrahmen mindestens die zugeteilte Transportverbindungskennung, Zielanwendungsinformationen und Datentypinformationen umfasst; • Empfangen des Datenrahmens auf der Transportschicht an dem zweiten Endpunkt; • Bestimmen an dem zweiten Endpunkt, ob der Datenrahmen sich auf einen verbindungs-orientierten oder verbindungslosen Dienst bezieht, auf Grundlage der Datentypinformationen; und • Senden einer Anwendungsnachricht an die Zielanwendung an dem zweiten Endpunkt auf Grundlage der Zielanwendungsinformationen.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Anwendungsschicht und die Transportschicht direkt miteinander verbunden sind.
  3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Transportprotokoll auf der Transportschicht das SCTP ist und die Transportverbindungskennung sich auf die SCTP-StreamID bezieht.
  4. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass wenn eine Anwendung das Aufbauen einer Signalisierungsverbindung anfragt, das Verfahren weiter folgende Schritte umfasst: • Erzeugen einer SCTP-Verknüpfung zwischen dem ersten und zweiten Endpunkt; • Auswählen einer nicht verwendeten SCTP-Streamnummer innerhalb der SCTP-Verknüpfung; • Verbinden der SCTP-Streamnummer der SCTP-Verknüpfung mit der Anwendungsverbindungskennung innerhalb der Signalisierungsverbindungs-Anfrage von der Anwendung; und • Speichern der Verbindung zwischen der ausgewählten SCTP-Streamnummer und der Anwendungsverbindungskennung innerhalb der Anwendung auf der Transportschicht; und • falls die Verbindungsanfrage eine Anwendungsnachricht enthielt, die Anwendungsnachricht als Nutzdaten in einer SCTP-Nachricht geliefert wird.
  5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass wenn die Signalisierungsverbindung bereits aufgebaut wurde und eine Anwendung verbindungs-orientierte Daten an die Transportschicht sendet, das Verfahren weiter den Schritt umfasst: • Auswählen der SCTP-Streamnummer, die bereits der Signalisierungsverbindung zuteilt ist, innerhalb der SCTP-Verknüpfung.
  6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass wenn eine Signalisierungsverbindung gelöst wird, das Verfahren die Schritte umfasst: • Senden einer Anwendungslösenachricht von der Anwendung an einem Endpunkt an die Anwendung an dem anderen Endpunkts; • Senden einer Anwendung-Löse-Abschluss-Nachricht von der Anwendung an die Anwendung des anderen Endpunkts; • Lösen der zugeteilten Verbindungskennung auf der Transportschicht an dem Zielendpunkt auf Grundlage der Anwendungslösenachricht; • Empfangen einer Anwendungs-Löse-Antwort-Nachricht an einem Endpunkt von der Anwendung an dem anderen Endpunkt; und • Lösen der zugeteilten Verbindungskennung auf Grundlage der Anwendung-Löse-Abschluss-Nachricht auf der Transportschicht an dem ersten Endpunkt.
  7. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass das Verfahren weiter den Schritt umfasst: • Auswählen eines geeigneten Werts für den Protokoll-Nutzdaten-Kennungs-Parameter, wobei der Protokoll-Nutzdaten-Kennungs-Parameter die Zielanwendung und den verbindungs-orientierten Dienst kennzeichnet.
  8. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass das Verfahren weiter die Schritte umfasst: • Auswählen einer SCTP-Streamnummer, die speziell für den verbindungsorientierten Dienst verwendet wird; und • Auswählen eines geeigneten Werts für den Protokoll-Nutzdaten-Kennungs-Parameter, wobei der Protokoll-Nutzdaten-Kennungs-Parameter die Zielanwendung kennzeichnet.
  9. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass das Verfahren weiter die Schritte umfasst: • Auswählen eines geeigneten Werts für den Protokoll-Nutzdaten-Kennungs-Parameter, wobei der Protokoll-Nutzdaten-Kennungs-Parameter das verwendete Anwendungsprotokoll angibt; und • Nicht- bzw. Rück-Setzen des SCTP-unordered-Hag-Parameters, wobei das Nicht- bzw. Rück-Setzen des SCTP-unordered-Flag-Parameters einen verbindungsorientierten Dienst angibt.
  10. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass das Verfahren weiter die Schritte umfasst: • Auswählen einer SCTP-Streamnummer speziell für verbindungs-orientierte Dienste; • Auswählen eines geeigneten Werts für den Protokoll-Nutzdaten-Kennungs-Parameter, wobei der Protokoll-Nutzdaten-Kennungs-Parameter die Zielanwendung kennzeichnet; und • Nicht- bzw. Rück-Setzen des SCTP-unordered-Flag-Parameters, wobei das Nicht- bzw. Rück-Setzen des SCTP-unordered-Flag-Parameters einen verbindungsorientierten Dienst angibt.
  11. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass wenn eine Anwendung verbindungslose Daten an die Transportschicht sendet, das Verfahren weiter die Schritte umfasst: • Erzeugen einer SCTP-Verknüpfung zwischen dem ersten und zweiten Endpunkt falls diese noch nicht erzeugt wurde; • Auswählen einer nicht verwendeten SCTP-Streamnummer innerhalb der SCTP-Verknüpfung; und • Auswählen eines geeigneten Werts für den Protokoll-Nutzdaten-Kennungs-Parameter, wobei der Protokoll-Nutzdaten-Kennungs-Parameter die Zielanwendung und den verbindungslosen Dienst kennzeichnet.
  12. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass wenn eine Anwendung verbindungslose Daten an die Transportschicht sendet, das Verfahren weiter die Schritte umfasst: • Erzeugen einer SCTP-Verknüpfung zwischen dem ersten und zweiten Endpunkt falls diese noch nicht erzeugt wurde; • Auswählen einer SCTP-Streamnummer, die speziell für verbindungslose Dienste reserviert ist; und • Auswählen eines geeigneten Werts für den Protokoll-Nutzdaten-Kennungs- Parameter, wobei der Protokoll-Nutzdaten-Kennungs-Parameter die Zielanwendung kennzeichnet.
  13. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass wenn eine Anwendung verbindungslose Daten an die Transportschicht sendet, das Verfahren weiter die Schritte umfasst: • Erzeugen einer SCTP-Verknüpfung zwischen dem ersten und zweiten Endpunkt falls diese noch nicht erzeugt wurde; • Auswählen irgendeiner SCTP-Streamnummer innerhalb der SCTP-Verknüpfung; und • Auswählen eines geeigneten Werts für den Protokoll-Nutzdaten-Kennungs-Parameter, wobei der Protokoll-Nutzdaten-Kennungs-Parameter das verwendete Anwendungsprotokoll kennzeichnet; und • Setzen des SCTP-unordered-Flag-Parameters auf '1', wobei das Setzen des SCTP-unordered-Flag-Parameters einen verbindungslosen Dienst anzeigt.
  14. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass wenn eine Anwendung verbindungslose Daten an die Transportschicht sendet, das Verfahren weiter die Schritte umfasst: • Erzeugen einer SCTP-Verknüpfung zwischen dem ersten und zweiten Endpunkt falls diese noch nicht erzeugt wurde; • Auswählen einer SCTP-Streamnummer, die speziell für verbindungslose Dienste verwendet wird; • Setzen des SCTP-unordered-Flag-Parameters auf '1'; und • Auswählen eines geeigneten Werts für den Protokoll-Nutzdaten-Kennungs-Parameter, wobei der Protokoll-Nutzdaten-Kennungs-Parameter die Zielanwendung kennzeichnet.
  15. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass an dem zweiten Endpunkt das Verfahren weiter die Schritte umfasst: • Bestimmen auf Grundlage des Werts des Protokoll-Nutzdaten-Kennungs-Parameters, dass der Datenrahmen sich auf einen verbindungs-orientierten Dienst bezieht; und falls die SCTP-Streamnummer innerhalb des Datenrahmens noch nicht verwendet wurde, folgern, dass sich der Datenrahmen auf eine neue Signalisierungsverbindung bezieht und Speichern der SCTP-Streamnummer; • Auswählen einer Anwendungsverbindungs-Kennung und Abbilden derselben in die SCTP-Streamnummer; • Bestimmen der Zielanwendung auf Grundlage des Werts des Protokoll-Nutzdaten-Kennungs-Parameters, und • Senden einer Signalisierungs-Verbindungs-Angabe und/oder der Nutzdaten der SCTP-Nachricht an die Zielanwendung.
  16. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass an dem zweiten Endpunkt das Verfahren weiter die Schritte umfasst: • Bestimmen auf Grundlage des Werts des Protokoll-Nutzdaten-Kennungs-Parameters, dass der Datenrahmen sich auf einen verbindungslosen Dienst bezieht; • Bestimmen der Zielanwendung auf Grundlage des Werts des Protokoll-Nutzdaten-Kennungs-Parameter, und • Senden der Nutzdaten der SCTP-Nachricht an die Zielanwendung.
  17. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass an dem zweiten Endpunkt das Verfahren weiter die Schritte umfasst: • Bestimmen auf Grundlage der SCTP-Streamnummer, dass der Datenrahmen sich auf einen verbindungs-orientierten Dienst bezieht; und falls die SCTP-Streamnummer innerhalb des Datenrahmens noch nicht verwendet wurde, folgern, dass sich der Datenrahmen auf eine neue Signalisierungsverbindung bezieht und Speichern der SCTP-Streamnummer; • Auswählen einer Anwendungsverbindungs-Kennung und Abbilden derselben in die SCTP-Streanmummer; • Bestimmen der Zielanwendung auf Grundlage des Werts des Protokoll- Nutzdaten-Kennungs-Parameters, und • Senden einer Signalisierungs-Verbindungs-Angabe und/oder der Nutzdaten der SCTP-Nachricht an die Zielanwendung.
  18. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass an dem zweiten Endpunkt das Verfahren weiter die Schritte umfasst: • Bestimmen auf Grundlage der SCTP-Streamnummer, dass der Datenrahmen sich auf einen verbindungslosen Dienst bezieht; • Bestimmen der Zielanwendung auf Grundlage des Werts des Protokoll-Nutzdaten-Kennungs-Parameters, und • Senden der Nutzdaten der SCTP-Nachricht an die Zielanwendung.
  19. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass an dem zweiten Endpunkt das Verfahren weiter die Schritte umfasst: • Bestimmen auf Grundlage des SCTP-unordered-Flags, dass der Datenrahmen sich auf einen verbindungs-orientierten Dienst bezieht; und falls die SCTP-Streamnummer innerhalb des Datenrahmens noch nicht verwendet wurde, folgern, dass sich der Datenrahmen auf eine neue Signalisierungsverbindung bezieht und Speichern der SCTP-Streamnummer; • Auswählen einer Anwendungsverbindungs-Kennung und Abbilden derselben in die SCTP-Streamnummer; • Bestimmen der Zielanwendung auf Grundlage des Werts des Protokoll-Nutzdaten-Kermungs-Parameters, und • Senden einer Signalisierungs-Verbindungs-Angabe und/oder der Nutzdaten der SCTP-Nachricht an die Zielanwendung.
  20. Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass an dem zweiten Endpunkt das Verfahren weiter die Schritte umfasst: • Bestimmen auf Grundlage des SCTP-unordered-Flags, dass der Datenrahmen sich auf einen verbindungslosen Dienst bezieht; • Bestimmen der Zielanwendung auf Grundlage des Werts des Protokoll-Nutzdaten-Kennungs-Parameters, und • Senden der Nutzdaten der SCTP-Nachricht an die Zielanwendung.
  21. Verfahren nach Anspruch 14, dadurch gekennzeichnet, dass an dem zweiten Endpunkt das Verfahren weiter die Schritte umfasst: • Bestimmen auf Grundlage der SCTP-Streamnummer, dass der Datenrahmen sich auf einen verbindungslosen Dienst bezieht; • Bestimmen der Zielanwendung auf Grundlage des Werts des Protokoll-Nutzdaten-Kennungs-Parameters, und • Senden einer Signalisierungsverbindungs-Angabe und/oder der Nutzdaten der SCTP-Nachricht an die Zielanwendung.
  22. Verbindungs-Steuerprogramm zum Senden und Empfangen von verbindungsorientierten und verbindungslosen Daten zwischen zwei Endpunkten in einer Protokoll-Architektur, umfassend mindestens eine Anwendungsschicht und eine Transportschicht und eine oder mehrere Anwendungen, die die Anwendungsschicht verwenden, dadurch gekennzeichnet, dass das Verbindungs-Steuerprogramm umfasst: • Programmkode zum Empfangen (IF1) einer Quellanwendungs-Anfragenachricht von einer Anwendung; • Programmkode zum Zuteilen (ID) einer Transportverbindungskennung; • Programmkode zum Einschließen (IM) von mindestens der zugeteilten Transportverbindungskennung, Zielanwendungsinformationen und Datentypinformationen in einem Datenrahmen, der an einen zweiten Endpunkt gesendet werden soll, auf der Transportschicht; • Programmkode zum Lesen (RM) von einer Transportverbindungskennung, Zielanwendungsinformationen und Datentypinformationen von einem empfangenen Datenrahmen; • Programmkode zum Bestimmen (DM), ob der Datenrahmen sich auf einen verbindungs-orientierten oder verbindungslosen Dienst bezieht, auf Grundlage der Datentypangabe; und • Programmkode zum Erfassen (DEM), ob ein empfangener Datenrahmen einer neuen oder einer bereits vorhandenen Signalisierungsverbindung entspricht; • Programmkode zum Auswählen (SEL) einer Anwendungsverbindungskennung falls der empfangene Datenrahmen einer neuen Signalisierungsverbindung entspricht; und • Programmkode zum Senden (IF2) einer Anwendungsnachricht an die Zielanwendung auf der Anwendungsschicht auf Grundlage der Zielanwendungsinformationen.
  23. Verbindungs-Steuerprogramm nach Anspruch 22, dadurch gekennzeichnet, dass die Verbindungs-Steuerung weiter Programmkode umfasst, der angepasst ist, die Anwendungsschicht und Transportschicht miteinander zu verbinden.
  24. Verbindungs-Steuerprogramm nach Anspruch 22 oder 23, dadurch gekennzeichnet, dass das Transportprotokoll auf der Transportschicht SCTP ist.
  25. Verbindungs-Steuerprogramm nach Anspruch 22, 23 oder 24, dadurch gekennzeichnet, dass die Verbindungs-Steuerung weiter umfasst: • Programmkode zum Erzeugen (CM) einer SCTP-Verknüpfung zwischen Endpunkten.
  26. Verbindungs-Steuerprogramm nach Anspruch 25, dadurch gekennzeichnet, dass: • Programmkode zum Auswählen (ID) auch zum Auswählen einer SCTP-Streamnummer innerhalb der SCTP-Verknüpfung, auf Grundlage der Tatsache, ob der fragliche Dienst verbindungs-orientiert oder verbindungslos ist, bereitgestellt wird.
  27. Verbindungs-Steuerprogramm nach Anspruch 26, dadurch gekennzeichnet, dass die Verbindungs-Steuerung weiter umfasst: • Programmkode zum Speichern (SM) der Beziehung zwischen der ausgewählten SCTP-Streamnummer und der Anwendungsverbindungskennung innerhalb der Anwendung; und • Programmkode zum Lesen (RM), der auch zum Überprüfen der gespeicherten SCTP-Streamnummer bereitgestellt wird.
  28. Verbindungs-Steuerprogramm nach Anspruch 22, 23, 24, 25, 26 oder 27, dadurch gekennzeichnet, dass: • Programmkode zum Auswählen (ID) auch zum Auswählen eines geeigneten Werts für den Protokoll-Nutzdaten-Kennungs-Parameter bereitgestellt wird, wobei der Protokoll-Nutzdaten-Kennungs-Parameter die Zielanwendung und/oder einen verbindungslosen oder verbindungs-orientierten Dienst kennzeichnet.
  29. Verbindungs-Steuerprogramm nach Anspruch 22, 23, 24, 25, 26, 27 oder 28, dadurch gekennzeichnet, dass die Verbindungs-Steuerung weiter umfasst: • Programmkode zum Auswählen (ID), der auch zum Setzen oder Nicht- bzw. Rück-Setzen des SCTP-unordered-Flag-Parameters bereitgestellt wird, wobei das Nicht- bzw. Rück-Setzen des SCTP-unordered-Flag-Parameters einen verbindungsorientierten Dienst angibt und das Setzen einen verbindungslosen Dienst angibt.
  30. Verbindungs-Steuerprogramm nach Anspruch 22, 23, 24, 25, 26, 27, 28 oder 29, dadurch gekennzeichnet, dass: • Programmkode zum Bestimmen (DM) auch zum Bestimmen bereitgestellt wird, ob der Datenrahmen sich auf einen verbindungs-orientierten oder verbindungslosen Dienst bezieht, auf Grundlage des Werts des Protokoll-Nutzdaten-Kennungs-Parameters.
  31. Verbindungs-Steuerprogramm nach Anspruch 22, 23, 24, 25, 26, 27, 28, 29 oder 30, dadurch gekennzeichnet, dass: • Programmkode zum Bestimmen (DM) auch zum Bestimmen der Zielanwendung auf Grundlage des Werts des Protokoll-Nutzdaten-Kennungs-Parameter bereitgestellt wird.
  32. Verbindungs-Steuerprogramm nach Anspruch 22, 23, 24, 25, 26, 27, 28, 29, 30 oder 31, dadurch gekennzeichnet, dass: • Programmkode zum Bestimmen (DM) auch zum Bestimmen bereitgestellt wird, ob der Datenrahmen sich auf einen verbindungs-orientierten oder verbindungslosen Dienst bezieht, auf Grundlage der SCTP-Streamnummer.
  33. Verbindungs-Steuerprogramm nach Anspruch 32, dadurch gekennzeichnet, dass: • Programmkode zum Ermitteln (DM) auch zum Bestimmen, ob die SCTP-Streamnummer sich auf eine neue Signalisierungs-Verbindungs-Anfrage oder eine vorhandene Verbindung bezieht, bereitgestellt wird.
  34. Verbindungs-Steuerprogramm nach Anspruch 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32 oder 33, dadurch gekennzeichnet, dass: • Programmkode zum Bestimmen (DM) auch zum Bestimmen, auf Grundlage des SCTP-unordered-Flags, ob sich der Datenrahmen auf einen verbindungsorientierten oder verbindungslosen Dienst bezieht bereitgestellt wird.
  35. System zum Senden und Empfangen von verbindungs-orientierten und verbindungslosen Daten zwischen zwei Endpunkten in einer Protokoll-Architektur, umfassend mindestens eine Anwendungsschicht und eine Transportschicht und eine oder mehrere Anwendungen, die die Anwendungsschicht verwenden, dadurch gekennzeichnet, dass das System eine Verbindungs-Steuerung umfasst, wobei die Verbindungs-Steuerung umfasst: • Mittel zum Empfangen (IF1) einer Quellanwendungs-Anfragenachricht von einer Anwendung; • Mittel zum Zuteilen (ID) einer Transportverbindungskennung; • Mittel zum Einschließen (IM) von mindestens der zugeteilten Transportverbindungskennung, Zielanwendungsinformationen und Datentypinformationen in einem Datenrahmen, der an dem zweiten Endpunkt gesendet werden soll, auf der Transportschicht; • Mittel zum Lesen (RM) von einer Transportverbindungskennung, Zielanwendungsinformationen und/oder Datentypinformationen von einem empfangenen Datenrahmen; • Mittel zum Bestimmen (DM), ob sich ein Datenrahmen auf einen verbindungsorientierten oder verbindungslosen Dienst bezieht, auf Grundlage der Datentypangabe; und • Mittel zum Erfassen (DEM), ob ein empfangener Datenrahmen einer neuen oder einer bereits vorhandenen Signalisierungsverbindung entspricht; • Mittel zum Auswählen (SEL) einer Anwendungsverbindungskennung, falls der empfangene Datenrahmen einer neuen Signalisierungsverbindung entspricht; und • Mittel zum Senden (IF2) einer Anwendungsnachricht an die Zielanwendung auf der Anwendungsschicht auf Grundlage der Zielanwendungsinformationen.
  36. System nach Anspruch 35, dadurch gekennzeichnet, dass die Verbindungs-Steuerung (IHND) angepasst ist, die Anwendungsschicht und Transportschicht miteinander verbinden.
  37. System nach Anspruch 35 oder 36, dadurch gekennzeichnet, dass das Transportprotokoll auf der Transportschicht SCTP ist.
  38. System nach Anspruch 37, dadurch gekennzeichnet, dass die Verbindungs-Steuerung (IHND) weiter umfasst: • Mittel zum Erzeugen (CM) einer SCTP-Verknüpfung zwischen Endpunkten.
  39. System nach Anspruch 38, dadurch gekennzeichnet, dass: • Mittel zum Auswählen (ID) auch zum Auswählen einer SCTP-Streamnummer innerhalb der SCTP-Verknüpfung bereitgestellt werden, auf Grundlage der Tatsache, ob der fragliche Dienst verbindungs-orientiert oder verbindungslos ist.
  40. System nach Anspruch 35, 36, 37, 38 oder 39, dadurch gekennzeichnet, dass die Verbindungs-Steuerung (IHND) weiter umfasst: • Mittel zum Speichern (SM) der Beziehung zwischen der ausgewählten SCTP-Streamnummer und der Verbindungskennung innerhalb der Anwendung; und • Mittel zum Lesen (RM), die auch zum Überprüfen von gespeicherten SCTP-Streamnummer bereitgestellt werden.
  41. System nach Anspruch 35, 36, 37, 38, 39 oder 40, dadurch gekennzeichnet, dass: • Mittel zum Auswählen (ID) auch zum Auswählen eines geeigneten Werts für den Protokoll-Nutzdaten-Kennungs-Parameter bereitgestellt werden, wobei der Protokoll-Nutzdaten-Kennungs-Parameter die Zielanwendung und/oder einen verbindungslosen oder verbindungs-orientierten Dienst kennzeichnet.
  42. System nach Anspruch 35, 36, 37, 38, 39, 40 oder 41, dadurch gekennzeichnet, dass: • Mittel zum Auswählen (ID) auch zum Setzen oder Nicht- bzw. Rück-Setzen des SCTP-unordered-Flag-Parameters bereitgestellt werden, wobei das Nicht- bzw. Rück-Setzen des SCTP-unordered-Flag-Parameters einen verbindungs-orientierten Dienst angibt und der Setzen einen verbindungslosen Dienst angibt.
  43. System nach Anspruch 35, 36, 37, 38, 39, 40, 41 oder 42, dadurch gekennzeichnet, dass: • Mittel zum Bestimmen (DM) auch zum Bestimmen bereitgestellt werden, ob der Datenrahmen sich auf einen verbindungs-orientierten oder verbindungslosen Dienst bezieht, auf Grundlage des Werts des Protokoll-Nutzdaten-Kennungs-Parameters.
  44. System nach Anspruch 35, 36, 37, 38, 39, 40, 41, 42 oder 43, dadurch gekennzeichnet, dass: • Mittel zum Bestimmen (DM) auch zum Bestimmen der Zielanwendung auf Grundlage des Werts des Protokoll-Nutzdaten-Kennungs-Parameters bereitgestellt werden.
  45. System nach Anspruch 35, 36, 37, 38, 39, 40, 41, 42, 43 oder 44, dadurch gekennzeichnet, dass: • Mittel zum Bestimmen (DM) auch zum Bestimmen, ob der Datenrahmen sich auf einen verbindungs-orientierten oder verbindungslosen Dienst bezieht, auf Grundlage einer SCTP-Streamnummer, bereitgestellt werden.
  46. System nach Anspruch 45, dadurch gekennzeichnet, dass: • Mittel zum Ermitteln (DEM) auch zum Bestimmen bereitgestellt werden, ob die SCTP-Streamnummer sich auf eine neue Signalisierungs-Verbindungs-Anfrage oder eine vorhandene Verbindung bezieht.
  47. System nach Anspruch 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45 oder 46, dadurch gekennzeichnet, dass: • Mittel zum Bestimmen (DM) auch zum Bestimmen, auf Grundlage des SCTP-unordered-Flags, bereitgestellt werden, ob der Datenrahmen sich auf einen verbindungs-orientierten oder verbindungslosen Dienst bezieht.
DE60221905T 2002-06-07 2002-06-07 Verfahren zum senden von verbindungsorientierten oder verbindungslosen daten Expired - Lifetime DE60221905T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/FI2002/000499 WO2003105438A1 (en) 2002-06-07 2002-06-07 Method for sending connection-oriented or connectionless data

Publications (2)

Publication Number Publication Date
DE60221905D1 DE60221905D1 (de) 2007-09-27
DE60221905T2 true DE60221905T2 (de) 2008-05-15

Family

ID=29724849

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60221905T Expired - Lifetime DE60221905T2 (de) 2002-06-07 2002-06-07 Verfahren zum senden von verbindungsorientierten oder verbindungslosen daten

Country Status (7)

Country Link
US (1) US20050117529A1 (de)
EP (2) EP1871074A1 (de)
JP (1) JP4229907B2 (de)
AT (1) ATE370598T1 (de)
AU (1) AU2002313013A1 (de)
DE (1) DE60221905T2 (de)
WO (1) WO2003105438A1 (de)

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7366782B2 (en) * 2003-04-14 2008-04-29 At&T Corp. Systems and methods for termination of session initiation protocol
US9123077B2 (en) 2003-10-07 2015-09-01 Hospira, Inc. Medication management system
US8065161B2 (en) 2003-11-13 2011-11-22 Hospira, Inc. System for maintaining drug information and communicating with medication delivery devices
US7028106B2 (en) * 2003-12-05 2006-04-11 Hewlett-Packard Development Company, L.P. Remapping routing information entries in an expander
US7801135B2 (en) * 2005-05-19 2010-09-21 Cisco Technology, Inc. Transport protocol connection synchronization
CN1929440B (zh) * 2005-09-09 2011-04-20 华为技术有限公司 基于中转站对业务流进行管理的方法和系统
KR101289469B1 (ko) * 2005-12-10 2013-08-23 한국전자통신연구원 이동 통신 시스템에서 ｉｐ 관리 메시지를 위한 연결 설정방법 및 그 장치
US7558560B2 (en) * 2005-12-15 2009-07-07 Motorola, Inc. System and method for initiating communications between mobile stations
EP2092470A2 (de) 2006-10-16 2009-08-26 Hospira, Inc. System und verfahren für den vergleich und die verwendung von aktivitätsinformationen und konfigurationsinformationen aus verwaltungssystemen mit mehreren geräten
US7769009B1 (en) * 2006-12-11 2010-08-03 Sprint Communications Company L.P. Automatic peer to peer mobile device data replication
CN101578850A (zh) * 2007-01-15 2009-11-11 艾利森电话股份有限公司 标识会议中的参与者
US20080301320A1 (en) * 2007-05-31 2008-12-04 Morris Robert P Method And System For Managing Communication Protocol Data Based On MIME Types
CN101511104B (zh) * 2008-02-15 2013-03-20 华为技术有限公司 基于小型蜂窝接入网络的通信方法及设备
JP4998316B2 (ja) * 2008-02-20 2012-08-15 富士通株式会社 通信システム及び通信処理方法並びにノード
CN101572835A (zh) * 2008-04-30 2009-11-04 华为技术有限公司 层次化有序地址分组网络中数据链路层信息传送和控制管理的方法及装置
WO2010023552A2 (en) 2008-08-29 2010-03-04 Accenture Global Services Gmbh Buddy list for blocked service
JP5040862B2 (ja) * 2008-09-03 2012-10-03 日本電気株式会社 Ｓｃｔｐアソシエーション集約装置、その装置を含む通信システムおよびルーティング方法
JP5075784B2 (ja) 2008-10-01 2012-11-21 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム及び送信側ノード
EP2345300A2 (de) * 2008-10-07 2011-07-20 University Of South Florida Architektur und zweischichtiges protokoll für ortsbewusste echtzeit-anwendungen
EP2345262A4 (de) 2008-10-08 2015-01-14 Univ South Florida Adaptive ortsdatenpufferung für ortsbewusste anwendungen
US8271106B2 (en) 2009-04-17 2012-09-18 Hospira, Inc. System and method for configuring a rule set for medical event management and responses
CN101997862B (zh) * 2009-08-28 2014-07-02 中兴通讯股份有限公司 一种实现单条偶联支持多用户的方法和装置
CN101873259B (zh) * 2010-06-01 2013-01-09 华为技术有限公司 Sctp报文识别方法和装置
CN102469622B (zh) 2010-11-16 2014-12-03 中兴通讯股份有限公司 多模控制器入局消息处理方法、装置及多模控制器
US9594875B2 (en) 2011-10-21 2017-03-14 Hospira, Inc. Medical device update system
EP2663158B1 (de) * 2012-05-10 2017-08-16 Alcatel Lucent Übertragung von Nachrichten
AU2014225658B2 (en) 2013-03-06 2018-05-31 Icu Medical, Inc. Medical device communication method
JP6621748B2 (ja) 2013-08-30 2019-12-18 アイシーユー・メディカル・インコーポレーテッド 遠隔輸液レジメンを監視および管理するシステムならびに方法
US9662436B2 (en) 2013-09-20 2017-05-30 Icu Medical, Inc. Fail-safe drug infusion therapy system
US10311972B2 (en) 2013-11-11 2019-06-04 Icu Medical, Inc. Medical device system performance index
US10042986B2 (en) 2013-11-19 2018-08-07 Icu Medical, Inc. Infusion pump automation system and method
ES2984732T3 (es) 2014-04-30 2024-10-30 Icu Medical Inc Sistema de asistencia al paciente con reenvío de alarma condicional
US9724470B2 (en) 2014-06-16 2017-08-08 Icu Medical, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
US9539383B2 (en) 2014-09-15 2017-01-10 Hospira, Inc. System and method that matches delayed infusion auto-programs with manually entered infusion programs and analyzes differences therein
WO2016189417A1 (en) 2015-05-26 2016-12-01 Hospira, Inc. Infusion pump system and method with multiple drug library editor source capability
EP3589073B1 (de) * 2016-04-12 2022-02-09 Telefonaktiebolaget LM Ericsson (Publ) Mehrere sctp-assoziationen pro s1ap-verbindung und bewegen einer s1ap-signalisierungsverbindung zwischen sctp-assoziationen
NZ750032A (en) 2016-07-14 2020-05-29 Icu Medical Inc Multi-communication path selection and security system for a medical device
WO2018189882A1 (ja) 2017-04-14 2018-10-18 富士通株式会社 無線通信装置、無線通信方法、及び無線通信システム
EP3617931B1 (de) * 2017-04-28 2022-07-20 Sony Group Corporation Kommunikationsvorrichtung und -verfahren
EP3824386B1 (de) 2018-07-17 2024-02-21 ICU Medical, Inc. Aktualisierung von infusionspumpenmedikamentenbibliotheken und betriebssoftware in einer vernetzten umgebung
US10964428B2 (en) 2018-07-17 2021-03-30 Icu Medical, Inc. Merging messages into cache and generating user interface using the cache
WO2020018389A1 (en) 2018-07-17 2020-01-23 Icu Medical, Inc. Systems and methods for facilitating clinical messaging in a network environment
US11139058B2 (en) 2018-07-17 2021-10-05 Icu Medical, Inc. Reducing file transfer between cloud environment and infusion pumps
WO2020023231A1 (en) 2018-07-26 2020-01-30 Icu Medical, Inc. Drug library management system
US10692595B2 (en) 2018-07-26 2020-06-23 Icu Medical, Inc. Drug library dynamic version management
CA3138528A1 (en) 2019-05-08 2020-11-12 Icu Medical, Inc. Threshold signature based medical device management

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6273622B1 (en) * 1997-04-15 2001-08-14 Flash Networks, Ltd. Data communication protocol for maximizing the performance of IP communication links
US7002988B1 (en) * 1998-12-04 2006-02-21 Tekelec Methods and systems for communicating SS7 messages over packet-based network using transport adapter layer interface
GB9905835D0 (en) * 1999-03-15 1999-05-05 Lucent Technologies Inc Telecommunications signalling using the internet protocol
CA2319944A1 (en) * 1999-09-21 2001-03-21 Alcatel Usa Sourcing Lp System and method for transporting in/ain signaling over an internet protocol (ip) network
EP1134942A1 (de) * 2000-03-15 2001-09-19 Telefonaktiebolaget L M Ericsson (Publ) Verfahren und Anordnung zur Steuerung von Nicht-Echtzeit-Anwendung Flüssen
DE10034687A1 (de) * 2000-07-17 2002-02-07 Siemens Ag Verfahren und Übertragungseinrichtung für ein Kommunikations-system zum Übertragen von Daten mittels eines Punkt-zu-Punkt-Protokolls (SCTP)
FI20002093A (fi) * 2000-09-22 2002-03-23 Nokia Corp Osoitetiedon siirtäminen protokollapinossa

Also Published As

Publication number Publication date
WO2003105438A1 (en) 2003-12-18
EP1871074A1 (de) 2007-12-26
JP2005529552A (ja) 2005-09-29
EP1512259A1 (de) 2005-03-09
JP4229907B2 (ja) 2009-02-25
DE60221905D1 (de) 2007-09-27
EP1512259B1 (de) 2007-08-15
US20050117529A1 (en) 2005-06-02
ATE370598T1 (de) 2007-09-15
AU2002313013A1 (en) 2003-12-22

Similar Documents

Publication Publication Date Title
DE60221905T2 (de) Verfahren zum senden von verbindungsorientierten oder verbindungslosen daten
DE60213147T2 (de) Verfahren zur Dienstqualitätsauswahl in einem drahtlosen Kommunikationssystem
DE602004005994T2 (de) Verteiltes Dienstgüte-Verwaltungssystem
DE60014852T2 (de) Headerkompression in echtzeitdiensten
DE60214144T2 (de) Verfahren und Vorrichtung zur bereitstellung von unterschiedlichen Dienstqualitätsstufen in einer Funkpaketdatendienstverbindung
DE19950653B4 (de) Verfahren zum Betreiben eines Mobilfunknetzes
DE60112480T2 (de) Dienstqualität (QoS) für ein Universales Mobiltelekommunikationssystem (UMTS) mit Unterstützung einer Verhandlung einer einstellbaren Dienstqualität
DE60206894T2 (de) Verfahren und vorrichtung zur herstellung eines protokoll-proxy für ein mobiles host-endgerät in einer multimediasitzung
DE60300432T2 (de) Vorrichtung und Verfahren zur Optimierung des Netzwerkverkehrs
DE19800772C2 (de) Verfahren und Vorrichtung zur Verbindung mit einem Paketaustauschnetz
DE10302788B4 (de) Einrichtung und Verfahren zum Umordnen von TFTs in einem Mobilkommunikationssystem
DE60218431T2 (de) Transfer von ip-daten in einem kommunikationssystem unter verwendung mehrerer logischer verbindungen für komprimierte felder auf der grundlage verschiedener kontexte
DE60031673T2 (de) Aufbau eines paketnetzrufes zwischen einem mobilen endgerät und einer anpassungsfunktion
DE19730159B4 (de) Kommunikationsverfahren und System
DE10239061A1 (de) Verfahren zum Übertragen von Nutzdatenobjekten
DE10361704A1 (de) Vorrichtung und Verfahren zum Aufbauen einer Verbindung in einem aus mobilen Knoten gebildeten Funknetzwerk
DE60012168T2 (de) Verfahren und anordnung zur übertragung multimediabezogener information in einem paketvermittelten zellularen funknetz mit externer verbindung
DE60221295T2 (de) System auf der basis des internet-protokolls
DE60130498T2 (de) Verfahren und vorrichtung zur trägerberechtigung in einem drahtlosen kommunikationsnetzwerk
DE10393436T5 (de) Bitratensteuermittel in einem Telekommunikationssystem
DE602005005834T2 (de) Konfliktauflösung unter Anwendungen, die Datenverbindungen zwischen einem mobilen Kommunikationsgerät und einem drahtlosen Paketdatennetzwerk benötigen
DE60020475T2 (de) Übertragungsverfahren zwischen einem Peripheriegerät und einem Kunden in einem Rechnernetzwerk
WO2007025905A1 (de) Kommunikationssystem, vermittlungsknoten-rechner und verfahren zur bestimmung eines kontrollknotens
DE602004000763T2 (de) Verfharen zur Verwaltung der Dienstqualität (QOS) in einem Mobilfunkkommunikationssystem
DE60032070T2 (de) Architektur zur Bereitstellung von Leistungsmerkmalen für drahtlose Anrufe in einem drahtlosen Telekommunikationssystem

Legal Events

Date Code Title Description
8364 No opposition during term of opposition