AT412378B - Verbindungssteuerung in einem transit-telekommunikationsnetz - Google Patents

Description

   <Desc/Clms Page number 1> 
 



   Die Erfindung betrifft ein Verfahren zum Steuern von Verbindungen, insbesondere zum Verbin- dungsaufbau und/oder-abbau, zwischen Transitnetz-Terminals eines Transitnetzes mit einer zentralen Steuereinrichtung, einer Anzahl von Transitnetz-Terminals sowie gegebenenfalls einer oder mehreren, dem Transitnetz internen Relaisstellen, unter Verwendung von Transitnetz-Kom- munikationsstrecken, die jeweils zwischen zwei der Terminals und/oder Relaisstellen verlaufen, wobei die Steuerung der Kommunikationsstrecken, insbesondere das Belegen und Freigeben derselben für Verbindungen zwischen Terminals, von der Steuereinrichtung aufgrund von Signali- sierungsinformation durchgeführt wird, die zwischen der Steuerstation und den Terminals ausge- tauscht wird. 



   Ebenso bezieht sich die Erfindung auf eine Terminal-Einrichtung für ein Transitnetz mit einer zentralen Steuereinrichtung, für den Verbindungsauf- und-abbau in dem Transitnetz in Zusam- menwirken mit anderen Transitnetz-Terminals sowie gegebenenfalls einer oder mehreren, dem Transitnetz internen Relaisstellen unter Verwendung von Kommunikationsstrecken, die jeweils zwischen der Terminal-Einrichtung und einem anderen Terminal oder einer Relaisstelle verlaufen, wobei die Terminal-Einrichtung zum Austausch von Signalisierungsinformation mit der Steuerein- richtung zur Steuerung der Kommunikationsstrecken, insbesondere das Belegen und Freigeben derselben für Verbindungen, eingerichtet ist. 



   Unter Transitnetz wird im Rahmen dieser Offenbarung ein Kommunikationsnetz verstanden, das keine von Netzteilnehmer genutzten Endstellen aufweist ; stattdessen erfolgt der Zugang zu einem Transitnetz ausschliesslich von anderen Kommunikationsnetzen aus, und zwar über die Terminals des Transitnetzes, denen aufseiten der angebunden   Kommunikationsnetze   oftmals z. B. 



  Gateways entsprechen. Ein Terminal des Transitnetzes ist somit kein Endgerät (eines Netzteil- nehmers), sondern eine Schnittstelleneinrichtung zu einem anderen Kommunikationsnetz. Ein bekanntes Beispiel eines Transitnetz ist ein Satellitensystem, das anderen Netzen Satellitenver- bindungen zur Verfügung stellt und auf dessen Terminals   ("Satellitenterminals")   von diesen ande- ren Netzen aus zugegriffen wird; freilich kann ein Transitnetz auch als Kabelnetz (z.B. Glasfaser- netz), Funknetz oder ein hybrides - aus mehreren Netztypen zusammengesetztes - Netz realisiert sein. Wichtig dabei ist, dass das Transitnetz ein zentrales Steuerzentrum zur Steuerung der im Netz verlaufenden Kommunikationsstrecken aufweist. 



   In vielen derzeit verwendeten Transitnetzen, insbesondere in der derzeit aktuellen Generation von stationären Satellitenkommunikationssystemen (z. B. auf Basis des DVB-RCS Standards), ist keine verbindungsorientierte Kommunikation zwischen Satellitenterminals definiert. Garantierte Bandbreiten auf dem Satelliten-Link sind nur für Dienste mit konstanter Bitrate vorgesehen. Diens- te variabler Bitrate, wie z. B. viele Internetanwendungen, können nur nach dem "best-effort" Prinzip bedient werden. Dadurch ist es für viele Anwendungen nicht möglich, sowohl eine gute Dienstqua- lität als auch eine effiziente Nutzung der Satellitenkapazität zu erreichen. 



   Es sind derzeit Ansätze zur Entwicklung einer nächsten Generation von Breitband- Satellitenkommunikationssystemen bekannt, die auf einer effizienteren Systemarchitektur beruhen soll und höherwertige Dienste in besserer Qualität anzubieten gestatten soll. Zu diesem Zweck soll eine verbindungsorientierte Kommunikationsform verwendet werden. Eine typische Architektur für ein solches Satellitennetz SAN ist in Fig. 1 schematisch dargestellt; weitere Erläuterungen können den Artikeln "Fast Internet Service via on board processing   -satellites:   the EuroSkyWay optimised techniques" von G. Losquadro et al. und "The ESW home gateway supporting IP and MPEG Services for residential users" von G. Losquadro et al., aus den Proceedings der 19th AIAA Inter- national Communications Satellite Systems Conference, Tolosa, April 2001, entnommen werden. 



   Die Hauptkomponenten dieses Systemtyps sind ein Satellit SAT mit "On-Board Processing", eine Netzwerk-Steuerstation NCC ('Network Control Center'), sowie eine Anzahl von   -Satellitenter-   minals ST1, ST2. Die - hier bodengestützten - Satellitenterminals ST1, ST2 (weitere Terminals ST3, ST4 sind angedeutet) stellen die Schnittstelle zwischen jeweils zugehörenden Teilnehmer- Endgeräten TE1, TE2 und/oder terrestrischen Telekommunikationsnetzen TN1, TN2 und dem eigentlichen Satellitensystem BSS dar. Die angebundenen Endgeräte TE1, TE2 bzw. Netze TN1, TN2 gehören den bekannten Kommunikationsnetz-Typen, wie z.B. ISDN, ATM, Intemet (auf der Basis des IP), an. 



   Aufgabe der Satellitenterminals ST1, ST2 ist es, dafür zu sorgen, dass bei Bedarf entspre- chend den Teilnehmeranfragen geeignete Verbindungen über das Satellitensystem angefordert 

 <Desc/Clms Page number 2> 

 bzw. abgebaut werden. Die dazu nötige Signalisierung - in Fig. 1 durch gepunktete Pfeile ssg 
 EMI2.1 
 bezeichnet. Die Steuerstation NCC erhält Verbindungswünsche über das interne Signalisierungs- system und entscheidet auf Basis der aktuellen Systemauslastung und den Charakteristiken der gewünschten Verbindung - wie z. B. geforderte Bandbreite und Qualität -, ob die neue Verbindung akzeptiert werden kann. Im Falle einer positiven Antwort werden einerseits die beiden betroffenen 
Satellitenterminals über interne Signalisierung informiert, andererseits wird ein entsprechender 
Befehl zum Durchschalten der Verbindung an den Satelliten SAT geschickt.

   Der geostationäre 
Satellit SAT schliesslich ermöglicht es, Kanäle seil, scl2 zwischen Satellitenterminals ST1, ST2 direkt "on-board" durchzuschalten, d. h. sie werden direkt zu einem Kommunikationsweg verknüpft. 



   Auf diese Weise können die Verkehrsdaten (z. B. Sprache und/oder Video, oder andere Daten) in "Single-Hop"-Kommunikation ausgetauscht werden. Die hierfür verwendeten Kommunikations- strecken bestehen in der Regel zwischen einem Satellitenterminal und einem Satelliten, jedoch können bei Bedarf auch Kommunikationsstrecken von Satellit zu Satellit eingesetzt werden (soge- nannte Intersatellite-Links). 



   Tiefergehende Information zu Breitbandsatellitensystemen kann der Web-Seite http://www.ana-   lysys.com/default¯acl.asp?mode=article & iLeftArticle=30   entnommen werden, sowie spezifisch über -jeweils -ein-bestimmtes -Satellitensystemen folgenden -Web-Seiten: http://www.euroskyway.it/   website/html¯eng/index.html   zu dem EuroSkyWay-System;   http://www.skybridgesatellite.com/   zu 
 EMI2.2 
   http://www.isr.umd.edu/CSHCN/presentations/conferences/staif99/bravman.pdfzu   OrbLink. 



   Für die Steuerung (Aufbau, Erhalt, Abbau) von Verbindungen in Satellitensystemen sehen die bekannten Lösungsansätze die Verwendung von Protokollen vor, die von terrestrischen digitalen Telefonnetzen her bekannt sind, und zwar typischerweise (Breitband-)ISDN-basierte Protokolle. 



  Diese werden der speziellen Topologie eines Satellitennetzwerks allerdings nicht gerecht und sind für diese spezielle Problemstellung unnötig komplex. 



   Verfahren zur Sicherung einer bestimmten Verbindungsqualität und/oder zur Herstellung von Punkt-zu-Mehrpunkt-Verbindungen, die allerdings durch einzelne Punkt-zu-Punkt-Verbindungen realisiert werden, sind in der WO 01/11837 A1, EP 1 067 736 A2 und WO 01/24498 A1 offenbart. 



  Diese Verfahren behandeln jedoch nicht die Situation in einem Transitnetz. 



   Es ist daher Aufgabe der Erfindung, einen Weg zur Vereinfachung und zugleich Leistungsstei- gerung für die Verbindungssteuerung in Transitnetzen, insbesondere Satellitensystemen, aufzu- zeigen. 



   Diese Aufgabe wird von einem Verfahren sowie einer Terminaleinrichtung der eingangs genannten Art gelöst, bei welchen für den Austausch der Signalisierungsinformation ein Signalisie- rungsprotokoll verwendet wird, mit zumindest folgenden, dem SIP-Standard entsprechenden Request-Nachrichtentypen : - ein Nachrichtentyp (entsprechend INVITE) zum Einleiten eines Verbindungsaufbaus, - ein Nachrichtentyp (entsprechend BYE) zum Einleiten eines Verbindungsabbaus, und - ein Nachrichtentyp (entsprechend ACK) zum Bestätigen eines vorangegangenen Aus- tauschs von Signalisierungsinformation, sowie zumindest einem dem SIP-Standard entsprechenden Response-Nachrichtentyp (entspre- chend insbesondere 200) für Bestätigungsmeldungen und/oder Fehlermeldungen.

   Seitens eines Transitnetz-Terminals ist eine Interworking-Funktion vorgesehen, deren Aufgabe ist, einen Verbin- dungswunsch, der von einem bei dem Terminal angebundenen Telekommunikationsnetz an dieses Terminal gesendet wird, zu empfangen und erst nach erfolgtem Aufbau einer Verbindung über das Transitnetz an jenes Terminal, das die Gegenstelle der Transitnetz-Verbindung darstellt, transparent weiterzuleiten. 



   Die Erfindung sieht somit vor, die verwendeten Nachrichten dem SIP-Standard nachzugestal- ten. Es liegt hierbei auf der Hand, dass die Nachrichten nicht völlig der im SIP-Standard definierten Form gehorchen müssen, sondern ein diesem äquivalente Gestaltung ausreicht, bei gleicher Funktion der Nachrichten; beispielsweise können die Namen der Nachrichten und/oder der Felder in den Nachrichten anders lauten, oder das Syntaxformat kann abweichen. Durch optimierende Anpassung auf ein gegebenes Transitnetz - z.B. Satellitennetz - können auch Felder, die in diesem konkreten Transitnetz-Typ nicht benötigt werden, weggelassen oder anstatt verpflichtend nur 

 <Desc/Clms Page number 3> 

 optional verwendet werden.

   Durch den Einsatz einer dem SIP-Protokoll entsprechenden Signalisie- rung gelingt eine überraschend einfache und dennoch zuverlässige Implementation der Signalisie- rung im Transitnetz, insbesondere in einem Satellitensystem. 



   Das mit dem Namen SIP ('Session Initiation Protocol') bezeichnete Protokoll ist ein IETF- Standardprotokoll zur Initiierung interaktiver "Sitzungen" ('sessions'), wie Videokonferenzen, Inter- net-Telefonie und Instant-Messaging in einem IP-basierten Netzwerk. SIP beruht auf einem Stand- ard, der von der   Multiparty-Multimedia-Session-Control-Arbeitsgruppe   (MMUSIC) der IETF entwik- kelt wurde und in RFC 3261 (Stand Juni 2002) definiert ist. Für weitere Informationen zum SIP- Protokoll sei auf die SIP-Web-Site von Henning Schulzrinne unter http://www.cs.columbia.edu/   -hgs/sip/   verwiesen. Dort können neben technischen Hintergrundinformationen auch eine umfang- reiche Zusammenstellung von unterschiedlichen SIP-Implementierungen, insbesondere SIP- Clients und-Server, entnommen werden. 



   Zur Initiierung eines Verbindungsauf- oder-abbaus, der in Standard-SIP von den Endstellen aus erfolgt, sieht die Erfindung zudem eine Interworking-Funktion vor. Hierbei ist es günstig, wenn aufgrund des von der Interworking-Funktion empfangenen Verbindungswunsches seitens des Terminals eine Nachricht gemäss dem Nachrichtentyp zum Einleiten eines Transitnetz-Verbin- dungsaufbaus erzeugt und an die zentrale Steuereinrichtung gesendet wird. Es ist auch zweckmä- &num;ig, wenn die Interworking-Funktion aufgrund des empfangenen Verbindungswunsches einen Setup-Request erzeugt, aufgrund dessen die Nachricht zum Einleiten eines Transitnetz-Verbin- dungsaufbaus erzeugt wird. 



   Im Folgenden wird ein kurzer, auf der Web-Site   http://www.reibotd.de/knowhow/sip/   beruhen- der Überblick über SIP-Protokoll gegeben, soweit dies für das Verständnis der Erfindung erforder- lich ist. Die Herstellung von SIP-Verbindungen zwischen mobilen Endgeräten in einem satelliten- gestützten UMTS-Netz ist auch in dem Artikel 'Session Establishment over Satellite-UMTS' von V. Y.H. Kueh et al., 3G Mobile Communication Technologies, 3rd International Conference, 2002, Conference Publication No. 489, S. 107-112, ISSN 0537-9989, behandelt. 



   SIP beruht auf dem IP-Protokoll und ähnelt in seinen Grundzügen auf den wohlbekannten Pro- tokollen SMTP und HTTP. Wie diese beiden verwendet SIP für die Kommunikation zwischen einem SIP-Client und einem SIP-Server textbasierte Nachrichten, mittels derer Requests ("Anfor- derungen") des Clients und Responses ("Antworten") des Servers realisiert werden. 



   SIP verwendet dabei über weite Strecken auch HTTP-Syntax. SIP-Requests rufen wie bei HTTP definierte Aktionen auf der Serverseite hervor. Dazu stehen sechs Methoden zur Verfügung. 



  SIP verfügt zudem über eigene Sicherungsmechanismen, die für die Zuverlässigkeit der Übermitt- lung zuständig sind. Wie HTTP/1. 1 kann SIP auch mehrere Requests und Responses über eine TCP-, UDP- oder SCTP-Verbindung übermitteln. Für die Adressierung von Kommunikationspart- nern verwendet SIP eine E-Mail-ähnliche Adressendarstellung der Form   user&commat;domain,     user&commat;ip-   adresse oder   telefonnummer&commat;gateway.   



    Das SIP-System kennt zwei Komponenten : User Agent und den Netzwerkserver. Der User   Agent wird dabei auf Seiten des Anwenders (z. B. einer rufenden Endstelle) ausgeführt. Er enthält den Protokoll-Client - auch User Agent Client (UAC) genannt - und einen Protokoll Server, den man als User Agent Server (UAS) bezeichnet. Der UAC initiiert die Anrufe, der UAS beantwortet eingehende Anrufe. Server-seitig sind (unter anderem) zwei unterschiedliche Typen vorgesehen: Proxy- und Redirect-Server. Der SIP-Proxy-Server übemimmt ähnliche Aufgaben wie ein SMTP- Server bzw. HTTP-Proxy. Er nimmt Requests des Clients entgegen, bestimmt wohin sie geleitet werden sollen und leitet anschliessend die Requests weiter. Der Redirect-Server ist für Nachrichten zum Empfänger zuständig.

   Er nimmt Requests entgegen und teilt dem Client mit, mit welchem Server der Agents Kontakt aufnehmen soll. Auch SIP greift dabei immer wieder auf das DNS (Domain Name Service) zurück, wenn es gilt, einen anderen Server aufzuspüren. 



   Wie bei HTTP unterscheidet man zwischen SIP-Requests und-Responses. Ein SIP-Request besteht aus drei Teilen: einer Startzeile (Request-Zeile bzw. Status-Zeile), Header-Feldem mit fest definierten Format und Inhalten, sowie (nach einer Leerzeile) einem Nachrichtenrumpf (kurz Rumpf) der aus einem oder mehreren Rumpffeldem ('body fields') besteht. Die verschiedenen Header-Felder enthalten Informationen über Call-Services, Adressen und Protokoll-Merkmale. SIP definiert sechs Request-Typen: INVITE, BYE, -OPTIONS, ACK, REGISTER und CANCEL. 



   Der wichtigste Request-Typ ist INVITE, die für die Initiierung eines Anrufes zwischen Client und 

 <Desc/Clms Page number 4> 

 Server verantwortlich ist. Mit dieser Methode kann ein Anrufer einen Angerufenen zu einem Tele- fonat   &num;einladen".   Die Informationen, die in den zugehörigen   Header-Fetdem   enthalten sind, sind denen beim Versand einer elektronischen Nachricht sehr ähnlich. Sie übermitteln unter anderem die Adresse des Anrufenden und die des Angerufenen, Betreff, Priorität und Routing-Informati- onen. Der Rumpf der Nachricht kann optional MIME-kodierte Inhalte enthalten, beispielsweise SMIL- oder XML-Inhalte. 



   Über die REGISTER-Methode werden an einen SIP-Server Standortinformationen übermittelt, wo ein SIP-Client zu erreichen ist, damit eintreffende Antworten eines oder mehrerer Kommunika- tionspartner an diesen weitergeleitet werden. 



   BYE beendet die Sitzung zwischen zwei Terminals. ACK bestätigt den zuverlässigen Nachrich- tenaustausch und CANCEL versucht, einen bereits verschickten Request zu löschen. OPTIONS kann optionale Informationen über den Anwender enthalten. 



   Ausserdem legt SIP für Responses sechs Gruppen von Status-Nachrichten fest, die jeweils mit einer dreistelligen Zahl (1xx, 2xx, 3xx, 4xx, 5xx, 6xx) bezeichnet werden. 



   Die in dem SIP-Standard definierten Nachrichtentypen sind jedoch nicht alle für die Erfindung unbedingt erforderlich; vielmehr garantieren schon die obengenannten Nachrichtentypen (INVITE, BYE, ACK sowie 200) das grundsätzliche Funktionieren der Erfindung. Die erfindungsgemässe Lösung lässt selbstverständlich zu, dass das Signalisierungsprotokoll noch weitere Request- und/oder Response-Nachrichtentypen vorsieht, die dem SIP-Standard entsprechen, insbesondere die folgenden: - ein Nachrichtentyp (entsprechend CANCEL) zum Unterbrechen eines Verbindungsauf- baus ; - ein Nachrichtentyp (entsprechend REGISTER) zum Anmelden eines Satellitenterminals im 
Satelliten-Telekommunikationssystem;

   - ein oder mehrere Nachrichtentypen (entsprechend insbesondere 100- und/oder 4xx- und/oder 5xx-Responses) für Antworten nicht-endgültiger Art sowie für ein Satellitentermi- nal bzw. den Server betreffende Fehlermeldungen. 



  Solche weiteren Nachrichtentypen können in Abhängigkeit von der aktuellen Implementation vorteilhaft sein. 



   Wenn die Erfindung für Satellitensysteme - für die sie in erster Line entwickelt wurde - verwen- det wird, kommen ihre Vorteile in besonderem Ausmass zur Geltung. In diesem Fall geht es somit um das Steuern von Verbindungen zwischen Satellitenterminals eines Satelliten- Telekommunikationssystems mit zumindest einem Satelliten unter Verwendung von Satelliten- Kommunikationsstrecken, die jeweils zwischen einem Satellitenterminal und einem Satelliten oder zwischen zwei Satelliten verlaufen. Die Steuerung der Satelliten-Kommunikationsstrecken, wird von der Steuereinrichtung unter Austausch von Signalisierungsinformation mit den Satellitentermi- nals und zur Verarbeitung der Signalisierungsinformation zur entsprechenden Steuerung der Satelliten-Kommunikationsstrecken durchgeführt. 



   Eine bevorzugte Weiterbildung der Erfindung gestattet die Errichtung von Punkt-zu-Mehrpunkt- Sitzungen, denen die besonderen Eigenschaften eines Transitnetzes und insbesondere Satelliten- systems, insbesondere die Broadcast-Funktionalität des Satelliten sowie die dem Satellitensystem zugrunde liegende Architektur, entgegen kommt. Hierfür ist es zweckmässig, wenn in den nach dem Signalisierungsprotokoll ausgetauschten Nachrichten, insbesondere Nachrichten nach dem Nach- richtentyp zum Einleiten eines Verbindungsaufbaus (INVITE), die Nennung mehrerer gerufenen Terminals zulässig ist, wobei solche Nachrichten für die Steuerung von Punkt-zu-Mehrpunkt- Verbindungen verwendet werden. 



   Vorteilhafterweise kann zur ökonomischen Behandlung von Fehlermeldungen ein zusätzlicher Response-Nachrichtentyp verwendet werden, mit dem eine Fehlermeldung in Bezug auf sämtliche gerufenen (Satelliten-)Terminals einer Punkt-zu-Mehrpunkt-Verbindung signalisiert wird. Ausserdem können in den Bestätigungsmeldungen für Punkt-zu-Mehrpunkt-Verbindungen, zumindest jedoch in einem Teil von diesen, Rumpffelder nach einem zusätzlichen Rumpffeld-Typ verwendet werden, wobei mittels jedes solchen Rumpffelds eine Fehlermeldung in Bezug auf ein gerufenes (Satelliten-)Terminal der betreffenden Punkt-zu-Mehrpunkt-Verbindung signalisiert wird. 



   In einer besonders einfachen Variante kann das Signalisierungsprotokoll als auf dem IP-Proto- koll und/oder einem diesen übergeordneten Protokoll, wie TCP oder UDP, aufsetzendes Signalisie- 

 <Desc/Clms Page number 5> 

 rungsprotokoll realisiert sein. 



   Um den speziellen Erfordernisse einer Verbindung im Transitnetz zu entsprechen, ist es sinn- voll, wenn im Rumpf einer von einem Terminal an die Steuerstation gesendeten Request-Nachricht die Angabe erwünschter bzw. benötigter Verbindungsparameter zulässig ist. Die so übersendeten Verbindungsparameter können insbesondere einen oder mehrere der folgenden Kenngrössen betreffen : Verbindungstyp, Service-Kategorie, maximale Datenrate, Verwendungsfaktor, maximale Burst-Grösse, gewünschte Priorität der Verbindung, Cell-Delay-Variation, maximaler Cell-Transfer- Delay. 



   In einer bevorzugten Ausführungsform der Erfindung - insbesondere bei einem Satellitensys- tem - wird die Zuteilung von Bandbreiten zur Datenübertragung seitens des bzw. der Satelliten durch eine dynamische Ressourcenverwaltung in Abhängigkeit von den angeforderten Verbin- dungsqualitäten gesteuert, um eine optimale Auslastung zu erreichen und die Verbindungsqualität zu verbessern. Hierbei kann die einem Satelliten zugeordnete Ressourcenverwaltung im Rahmen eines On-Board-Systems auf diesem Satelliten ablaufen. 



   Die Erfindung samt weiterer Vorzüge wird im Folgenden anhand eines nicht einschränkenden Ausführungsbeispieles näher erläutert, wobei die beigefügten Zeichnungen herangezogen werden. 



  Die Zeichnungen zeigen in schematischer Form: 
Fig. 1 ein Satellitenkommunikationsnetz mit "On-Board Processing"; 
Fig. 2 den Aufbau einer Punkt-zu-Punkt-Verbindung im Netz der Fig. 1; 
Fig. 3 den Abbau der Verbindung der Fig. 2 ; 
Fig. 4 den Aufbau einer Punkt-zu-Mehrpunkt-Verbindung; 
Fig. 5 den teilweise erfolgreichen Aufbau einer Punkt-zu-Mehrpunkt-Verbindung; 
Fig. 6 die Erweiterung einer Punkt-zu-Mehrpunkt-Verbindung; 
Fig. 7 den Abbau der Verbindung der Fig. 4; 
Fig. 8 ein ISDN-Interworking anhand des Signal austauschs der fig. 2. 



   Die Erfindung kann für verschiedene Typen und Architekturen eines Transitnetzes eingesetzt werden. Dem Ausführungsbeispiel wird ein Satellitennetz SAN mit einem Breitband- Satellitensystem BSS der in der Beschreibungseinleitung anhand Fig. 1 dargestellten Art zu Grun- de gelegt. Wie bereits erwähnt verfügt ein solches System BSS über einen geostationären Satelli- ten SAT mit "On-Board Processing", eine zentrale Netzwerk-Steuerstation NCC, die eine Steuer- einrichtung im Sinne der Erfindung darstellt, und eine Anzahl von (typischerweise mehreren tau- send) Satellitenterminals ST1, ST2, ST3, ST4, die in dem hier betrachteten Ausführungsbeispiel bodengestützt sind und mit unterschiedlichen Sende- und Empfangskapazitäten ausgestattet sein können. 



   Der Satellit SAT verfügt im Rahmen seines On-Board-Processing-Systems über eine eigene dynamische Ressourcenverwaltung. Diese ist für die tatsächliche Zuteilung von Bandbreite zum Übertragen von Daten zuständig. Bei einem erfolgreichen Verbindungsaufbau wird die Ressour- cenverwaltung informiert, dass eine Verbindung mit bestimmter Verbindungsqualität zwischen den beteiligten Satellitenterminals besteht. Die Ressourcenverwaltung ist damit angewiesen, diesen Terminals (die in der Verbindungsqualität definierte) Bandbreite zum Übertragen von Daten zuzu- weisen, wann immer die Terminals Daten übertragen möchten. Die Zuweisung der Ressourcen auf dem Satelliten-Link erfolgt damit   &num;dynamisch",   also immer genau dann, wenn ein Satellitenterminal diese Ressourcen benötigt.

   Während der Zeit, in der ein Satellitenterminal keine Daten sendet, können diese Ressourcen für andere Verbindungen genutzt werden. 



   Die Erfindung verwendet als' Ausgangspunkt den SIP-Standard gemäss tETF-Standard RFC 3261   ("Standard-SIP").   Ausgehend von diesem Standard wird das Protokoll im Rahmen der hier beschriebenen Erfindung wird für den Einsatz in der beschriebenen Satellitenarchitektur opti- miert. Dabei wird die Ähnlichkeit der Satellitenarchitektur mit einem SIP-Netzwerk mit Proxy-Server ausgenutzt : Ein SIP-Proxy-Server kann Verbindungen zwischen verschiedenen SIP-Endgeräten (z. B. SIP-Telefonen) herstellen. Die Aufgaben des Steuerzentrums NCC sind denen eines SIP- Proxy-Servers sehr ähnlich. Die Satellitenterminals ST1, ST2 entsprechen den SIP-Endgeräten im SIP-Netz. Das sich so ergebende modifizierte SIP-Protokoll kann somit als   "Sat-SIP"   bezeichnet werden. 



   Aufgrund der speziellen Architektur des hier zugrunde gelegten Satellitennetzes werden in Sat- SIP folgende Vereinfachungen vorgeschlagen: 

 <Desc/Clms Page number 6> 

 
1. Sat-SIP kommt mit wesentlich weniger Header-Feldern in den Nachrichten aus als Stan- dard-SIP. Konkret sind in Sat-SIP nur folgende Header-Felder notwendig : accept, allow, error-info, from, to, cseq, call-id, expires und retry-after, sowie die drei Header-Felder für   die Authentifizierung : WWW-Authenticate,Authorization und Authentication-Info.   



   2. Sat-SIP kommt mit wesentlich weniger Nachrichten als Standard SIP aus. Konkret sind in   Sat-SIP nur folgende Nachrichten vorgesehen : BYE, CANCEL, INVITE, REGISTER,   
100,200, sowie 4xx und 5xx-Nachrichten. In Sat-SIP werden die gleichen Namen für die einzelnen Nachrichtentypen wie in Standard-SIP verwendet, jedoch könnten ebenso ande- re Bezeichner verwendet werden, ohne dass die Funktionalität des Protokolls beeinträch- tigt würde. 



   Dagegen soll Sat-SIP folgende funktionale Erweiterungen im Vergleich zu Standard-SIP ermöglichen: - Unterstützung von Punkt-zu-Mehrpunkt (ptmp, 'point to multiple point') Sitzungen. Bei einer pmtp Verbindung sind ein rufendes und mehrere angerufene Terminals eingebunden. Ver- fahren zum Aufbau und Abbau solcher Verbindungen sowie zum Hinzufügen oder Entfer- nen von Teilnehmern sind in Sat-SIP definiert. Diese Verfahren werden weiter unten näher beschrieben. Natürlich unterstützt das Sat-SIP Protokoll weiterhin (wie Standard-SIP) den 
 EMI6.1 
 einem rufenden und einem gerufenen Terminal. 



   - Einsatz eines Verfahrens zur Zugangskontrolle für Verbindungen, nämlich des weiter unten erläuterten CAC, welches hier die Zulassung von Verbindungen im Satellitensystem SAN kontrolliert. In den Verbindungsaufbau- und -abbauprozessen sind entsprechende Stellen vorgesehen, wo ein solches Verfahren einzubauen ist. Es kann jedoch in Sat-SIP offen bleiben, welches konkrete Verfahren verwendet wird. 



   - Konfiguration eines Ressourcen-Steuerungssystems. In den Verbindungsaufbau- und -abbauprozessen sind entsprechende Stellen vorgesehen, wo eine solche Konfiguration einzubauen ist. Da verschiedenartige Ressourcen-Steuerungssysteme in verschiedenen 
Satellitensystemen eingesetzt werden können, lässt Sat-SIP offen, wie die Ansteuerung konkret funktioniert. Die Ressourcensteuerung kann in der Steuerstation NCC und/oder on-board, also auf dem Satelliten, vorgesehen sein, wie dies z. B. vom EuroSkyWay- 
System her bekannt ist. Der Vorteil der letzteren Variante liegt darin, dass die Signallauf- zeiten geringer sind und somit Ressourcen-Anforderungen rascher behandelt werden kön- nen, was den Nachteil der grösseren Komplexität von On-Board-Systemen aufwiegen kann. 



   Für die Implementierung dieser Erweiterungen werden folgende Änderungen und Erweiterun- gen bei Nachrichten und   Header-Feldem   vorgeschlagen : 
1. In der INVITE-Nachricht können neue Rumpffelder enthalten sein, die es erlauben, Para- meter zur Beschreibung der Verbindungsqualität zu transportieren. Diese Rumpffelder ersetzen den SDP-Rumpf, der in Standard-SIP vorgesehen ist. 



   2. Im Header-Feld to, das zur Bezeichnung des gerufenen Endgeräts dient, können ein oder mehrere Terminals angegeben werden. Im Fall dass mehr als ein Terminal angegeben wird, wird eine ptmp Verbindung aufgebaut. (In Standard-SIP kann im Header-Feld to nur ein Endgerät spezifiziert werden.) 
3. Ein weiteres Rumpffeld (namens 4xx Final Response", kurz 4FIN) wurde eingeführt, das speziell bei ptmp Verbindungen benötigt wird. Dieses Rumpffeld wird - sofern benötigt - in der 200-Nachricht verwendet. 



   4. Eine neue Nachricht (namens 499 All Terminals Failed") speziell für ptmp Verbindungen wurde eingeführt. Diese Nachricht muss 4FIN Rumpffelder enthalten. 



   Die unter Ziffer 1 genannten neuen Rumpffelder werden insbesondere dafür verwendet, dass ein Satellitenterminal der Steuerstation NCC Charakteristika der angeforderten Verbindung über- mitteln kann. Zur Beschreibung dieser Charakteristika sind nämlich andere Parameter notwendig als bei Verbindungen des Standard-SIP im SDP-Rumpf enthalten sind. Im Ausführungsbeispiel sind folgende Parameter zur Beschreibung der angeforderten Verbindungscharakteristik vorgese- hen : Verbindungstyp (unidirektional oder bidirektional; ptp oder ptmp), Service-Kategorie, maxima- le Datenrate, Verwendungsfaktor (das Verhältnis zwischen durchschnittlicher und maximaler Datenrate), maximale Burst-Grösse (maximale, auf einmal zu sendende Datenmenge), gewünschte 

 <Desc/Clms Page number 7> 

 Priorität der Verbindung, Cell-Delay-Variation, maximaler Cell-Transfer-Delay.

   Bei bidirektionalen Verbindungen können alle Merkmale - ausgenommen den Verbindungstyp - für jede Verbindungs- richtung angegeben werden. 



   Die unter Ziffern 2 bis 4 genannten Erweiterungen beziehen sich auf ptmp Verbindungen, die weiter unten näher behandelt werden. 



   Mit Sat-SIP wird daher - ein "Verbindungsbewusstsein" in den Satellitenterminals ST1, ST2 und in der zentralen 
Steuerstation NCC hergestellt; - dieses Verbindungsbewusstsein in Zusammenarbeit mit geeigneten Verfahren wie dem 
CAC für die Zulassung neuer Rufe ins System verwendet ;   - die Ressourcensteuerung des Satellitensystems entsprechend der neu hergestellten Ver-   bindung konfiguriert. Mit dieser Konfiguration ist eine Nutzdatenverbindung zwischen den 
Satellitenterminals hergestellt, sodass diese beginnen können, Nutzdaten über den Satellit zu übertragen. 



   In der Steuerstation NCC ist wie erwähnt ein Verfahren zur Zulassung von Verbindungen im Satellitennetz eingerichtet, das in dieser Offenbarung als CAC ('Connection Admission Control') 
 EMI7.1 
 ist grundsätzlich auch eine Realisierung als Hardwareeinheit möglich. Das CAC entscheidet z.B. nach einem statistischen Algorithmus, ob aufgrund der aktuellen Systemauslastung eine angefor- derte Verbindung zugelassen werden kann, ohne dadurch die Service-Qualität bereits bestehender Verbindungen einzuschränken oder zu gefährden. Fällt die Entscheidung positiv aus, wird die Verbindung aufgebaut. Anderenfalls wird der Verbindungsaufbau erfolglos abgebrochen. Ein Verfahren solcher Art ist beispielsweise in EP 1 146 763 A2 beschrieben, deren Inhalt als Teil dieser Offenbarung aufgenommen wird. 



   Das CAC ist vor allem im Hochlastbereich sehr vorteilhaft, setzt aber ein Verbindungsbewusst- sein voraus. Es sei darauf hingewiesen, dass das CAC kein wesentliches Element der Erfindung ist. Vielmehr kann in einer vereinfachten Ausführungsform der Erfindung auf die Einbeziehung eines CAC verzichten werden, wenn der Vorteil einer garantierten Service-Qualität für akzeptierte Verbindungen nicht erforderlich ist. 



   Grundsätzlich kann das Sat-SIP Protokoll ebenso wie Standard-SIP ptp Sitzungen steuern. 



  Wie bereits oben beschrieben, werden dazu im wesentlichen die im SIP-Standard definierten Nachrichten und Finite-State-Maschinen verwendet. Die wesentlichen Erweiterungen bestehen in der Berücksichtigung der Prozeduren für Qualitätssicherung (QoS, 'Quality of Service') und Res- sourcenmanagement insofern, als bereits vom Sat-SIP Protokoll her die Voraussetzungen geschaf- fen werden, um diese Prozeduren in einem Satellitensystem effizient zu unterstützen. Aus der Sicht des im SIP-Standard definierten Protokolls sind QoS und Ressourcenmanagement durch andere Protokolle abzudecken, da für Standard SIP nur die Applikationssicht entscheidend ist. 



   Eine bereits erwähnte, jedoch wesentliche Erweiterung gegenüber dem Standard SIP sind ptmp Sitzungen. Während das Standard SIP Protokoll Mehrpunkt-Sitzungen ('multicast sessions') und Konferenz-Sitzungen immer als mehrere ptp Sitzungen (z. B. über eine Konferenz-Bridge) aufbaut, kann in der Erfindung günstigerweise eine andere Lösung eingesetzt werden, die auch im Sat-SIP realisiert ist. Die Möglichkeit des pmtp ist wegen der Broadcast-Funktionalität des Satelli- ten sowie die zugrunde liegende Architektur sehr gut geeignet. 



   Die Signalisierungsnachrichten werden vom Satellitenterminal ST1 bzw. ST2 über einen eige- nen Signalisierungskanal (in der Figur nicht dargestellt), den sogenannten RASC ('Random Access Channel'), über den Satelliten SAT (in Fig. 2 und 3 der Übersichtlichkeit halber nicht dargestellt) und zur Steuerstation NCC transportiert, bzw. von dort über den Satelliten an das betreffende Satellitenterminal ST1 bzw. ST2. Der RASC ist ein nicht kollisionsfreier Kanal und kann z. B. unter Verwendung der bekannten ALOHA- oder slotted-ALOHA-Verfahren realisiert werden. 



   Im Steuerzentrum NCC wird aufgrund der übertragenen QoS- und Verkehrs-Parameter ent- schieden, ob die neue Verbindung im Kommunikationsnetz zugelassen werden kann. Eine Zulas- sung erfolgt, wenn die QoS aller bereits im Netz bestehenden Verbindungen nicht beeinträchtigt wird. Verfahren dieser Art sind aus dem Stand der Technik wohlbekannt. 



   Fig. 2 zeigt den Nachrichtenfluss für einen erfolgreichen ptp Rufaufbau in einem Signalablaufs- diagramm. In den Signalablaufsdiagrammen verläuft die Zeitachse vertikal nach unten, und die 

 <Desc/Clms Page number 8> 

 zwischen den verschiedenen, als vertikale Linien symbolisierten Stellen ausgetauschten Nachrich- ten sind als Pfeile dargestellt. Für die in den Signalablaufsdiagrammen ausgetauschten Nachrich- ten werden in dieser Offenbarung dreistellige Bezugszeichen verwendet, wobei die zweite Ziffer das Satellitenterminal STn (n=1,   ..., 4)   bezeichnet, mit dem die Nachricht ausgetauscht wird, und die dritte Ziffer die Art der Nachricht angibt (z. B. bezeichnet eine letzte Ziffer 1 eine INVITE-Nach- richt). 



   Die in dem Vorgang der Fig. 2 ausgetauschten Nachrichten p11-p24 sind ausserdem in Tabelle 1 (im Anhang dieser Beschreibung) wiedergegeben. Für die in den Tabellen 1, 3 und 4 wiederge- gebenen Nachrichten werden folgende Annahmen getroffen: - Die im Satellitensystem intern verwendete Kennung des NCC lautet NCCID. 



   - Die im Satellitensystem intern verwendete Kennungen der Satellitenterminals ST1, ST2, 
ST3 und ST4 lauten   ST11D,   ST2ID, ST31D, ST4ID. 



   - Im Body der INVITE Nachricht sind einige, nicht jedoch alle in Sat-SIP definierten QoS 
Parameter enthalten. In einer Implementierung werden abhängig vom konkreten Satelliten- system, dem verwendeten CAC und der Verbindungsart nur die benötigten QoS Parameter (alle oder wie hier nur ein Teil) im Body-Feld der INVITE Nachrichten transportiert. Weiters werden bei bi-direktionalen Verbindungen die QoS-Parameter für die Vorwärts- und Rück- 
 EMI8.1 
 
Parameter für die Vorwärtsrichtung angegeben. In jedem Fall müssen jedoch zwei Para-   meter, die den Verbindungstyp spezifizieren, angegeben werden : (Punkt-zu-Punkt:   "true" oder "false") und UNI (unidirektional: "true" oder "false"). 



   - Zur besseren Lesbarkeit wurden bei den Nachrichten jeweils die vollen Feldbezeichner verwendet. Sat-SIP sieht jedoch wie Standard-SIP vor, die Bezeichner häufig vorkommen- der Felder abzukürzen, damit die Nachrichten kürzer werden. Beispielsweise könnte an-   statt "From:" ebenso "f:" oder statt "Call-ID" einfach "i :" einer Nachricht stehen.   



   Der Aufbau einer ptp Sitzung wird durch einen Request p11"INVITE" des (rufenden) Satelliten- terminals ST1 eingeleitet. Durch eine Rückwärtsnachricht p12 "100" wird die erfolgreiche Ankunft   der INVITE-Nachricht bestätigt. Seitens des NCC findet eine CAC-Prüfung statt ; ist durch das   Bezugszeichen C1 symbolisiert. Bei erfolgreichem CAC wird die Verbindung zugelassen, sowie Ressourcenmanagementprozeduren zur Belegung von Ressourcen auf den Übertragungsstrecken angestossen und das gerufene Satellitenterminal ST2 durch eine INVITE-Nachricht p21 informiert. 



  Wenn das gerufene Terminal ST2 die Verbindung annehmen kann, antwortet es mit einer 200-Nachricht p23, die an das NCC zurückgesendet wird. Nach erfolgreicher Beendigung der Ressource-Zuweisung wird die 200-Nachricht p13 an das rufende Terminal ST1 weiter geleitet, das seinerseits den Empfang durch eine ACK-Nachricht p14 quittiert, die entsprechend als Nach- richt p24 an das gerufene Terminal ST2 weiter geleitet wird. Damit ist der Rufaufbau abgeschlos- sen und die Satellitenterminals können mit der Übertragung der Nutzinformation s12 beginnen. Die Zuteilung der Verbindungsstrecken erfolgt, je nach Implementation, z. B. nach erfolgreichem CAC parallel zum Senden der INVITE-Nachricht p21 ; es könnte hierfür jedoch auch die Bestätigung p23 abgewartet werden. Im Gegensatz zu Standard-SIP erübrigt sich bei diesem Ablauf eine RINGING- Nachricht. 



   Zur Berücksichtigung der längeren Signallaufzeiten in Satellitennetzwerken werden die im Standard-SIP definierten Timer angepasst. Tabelle 2 zeigt ein Beispiel eines Satzes sinnvoller Werte für ein GEO-System nach Fig. 

Claims (22)

1. Dem Wertesatz liegt die Annahme zugrunde, dass eine unzuverlässige Transportschicht wie UDP verwendet wird, weshalb auch die Werte für Retrans- mission angeführt sind. Selbstverständlich sind die gezeigten Werte in Abhängigkeit von der ver- wendeten Konfiguration (LEO, MEO, GEO, etc. ) an das jeweilige Satellitensystem anzupassen. In Tabelle 2 wird - über Standard-SIP hinaus - ein Zeitparameter satT verwendet, der im betrachteten Beispiel den Wert 500 ms hat. Sollte eine zuverlässige Transportschicht verwendet werden, wie z. B. TCP, oder die Retransmission wird von der physikalischen Schicht des Satellitenprotokoll- Schichtenmodells übernommen, so können (entsprechend Standard-SIP) die Timer für die Konfi- guration der Retransmission auf den Wert 0 gesetzt werden. Die nicht erfolgreichen Fälle sowie die Möglichkeit der Annullierung eines Rufaufbauwunsches verlaufen unter Berücksichtigung des oben Gesagten analog zu denen im SIP-Standard; eine Behandlung in dieser Offenbarung erübrigt sich daher. <Desc/Clms Page number 9> Fig. 3 zeigt den Nachrichtenfluss eines erfolgreichen ptp Rufabbau, z. B. des Abbaus der nach Fig.

2 hergestellten Verbindung. Der Abbau wird durch eine BYE-Nachricht p15, p16 initiiert, die ebenfalls durch eine 200-Nachricht p26, p16 quittiert wird. Der Vorgang entspricht den Vorgängen des Standard-SIP. Anschliessend werden mittels eines CAC-Aufrufs C2 die im Steuerzentrum NCC belegten Ressourcen freigeschaltet bzw. die QoS-Parameter zurückgesetzt. Fig. 4 zeigt einen erfolgreichen Rufaufbau für einen ptmp Ruf. Anders als im Standard SIP wer- den für eine ptmp Sitzung nicht einzelne ptp Sitzungen zusammengeschaltet, sondern der ptmp Ruf wird im Steuerzentrum NCC insgesamt abgehandelt. Die von dem rufenden Satellitenterminal ST1 an das Steuerzentrum NCC gesendete, den Rufaufbau einleitende INVITE-Nachricht m11 enthält die Identifikationen und Parameter sämtlicher gerufener Satellitenterminals ST2, ST3, ST4, die zu der gewünschten ptmp Sitzung zusammengeschaltet werden sollen. Der Ablauf des Rufaufbaus zwischen dem rufenden Satellitenterminal ST1 und dem Steuer- zentrum NCC vollzieht sich gänzlich den Prozeduren des Standard-SIP entsprechend, wodurch die Finite-State Maschinen nicht angepasst werden mussten. Als weiterer Vorteil dieser Verfahrens- weise ergibt sich, dass die Signalisierungslast am RASC minimiert wird, wodurch auch die Kollisi- onswahrscheinlichkeit herabgesetzt wird. Dies ist ein wesentliches Erfordernis für Übertragungs- strecken in Satellitennetzen, wo die Ressourcen teuer und daher wertvoll sind. Zwischen dem Steuerzentrum NCC und den gerufenen Satellitenterminals ST2, ST3, ST4 werden jeweils einzelne Sub-Sitzungen aufgebaut, die zu der gemeinsamen ptmp gehören und durch eine gemeinsame call-id-Nummer identifiziert werden. Die gerufenen Satellitenterminals antworten mit unterschiedlichen Rückwärtsnachrichten, je nachdem ob das betreffende Satellitenterminal an der ptmp Sitzung teilnehmen kann oder nicht. Im Fall des erfolgreichen Rufaufbaus konzentriert die Steuerstation NCC alle von den gerufenen Terminals kommenden Rückwärtsnachrichten (200 oder 4xx Nachrichten). Der Aufbau der ptmp Sitzung (Fig. 4) erfolgt somit ähnlich dem einer ptp Sitzung (Fig. 2); zur Verdeutlichung werden für die in Fig. 4,5 und 7 ausgetauschten Nachrichten Bezugszeichen der Form 3nm verwendet, die denen in Fig. 2 und 3 (der Form 1nm) entsprechen. Tabelle 3 gibt die ausgetauschten Nachrichten der Fig. 4 und 5 wieder. Durch eine Rückwärtsnachricht m12 "100" wird die erfolgreiche Ankunft der INVITE-Nachricht bestätigt. Seitens des NCC findet eine CAC- Prüfung C3 statt ; diese erfolgreich, wird die Verbindung zugelassen und Ressourcenmanage- mentprozeduren zur Belegung von Ressourcen auf den Übertragungsstrecken angestossen ; ters werden die gerufenen Terminals ST2, ST3, ST4 durch INVITE-Nachrichten m21, m31, m41 informiert. Die gerufenen Satellitenterminals antworten mit 200-Nachrichten m23, m33, m43. Diese werden gebündelt in einer 200-Nachricht m13 an das rufende Satellitenterminal ST1 weiter gelei- tet. Die quittierende ACK-Nachricht m14 wird durch Nachrichten m24, m34, m44 an die gerufenen Satellitenterminals weiter geleitet, woraufhin die Satellitenterminals mit der Übertragung der Nutzin- formation s4 in der ptmp Sitzung beginnen können. In Fig. 5 ist der Fall berücksichtigt, dass eines der gerufenen Satellitenterminals - z. B. das Ter- minal ST3 - die Teilnahme an der ptmp Sitzung nicht annimmt. Dieses Terminal antwortet dann mit einer 486-Nachricht (Bezugszeichen m37), während die anderen Terminals, die den Ruf akzeptie- ren, mit 200 (Bezugszeichen m23, m24) antworten. In diesem Fall wird eine 200-Nachricht m13' übertragen, die zusätzlich im Rumpf die Identifikation derjenigen Terminals enthält, die negativ quittiert haben. Für jede 4xx-Antwort eines eingeladenen Satellitenterminals ST3 wird ein 4FIN- Rumpffeld (4FIN für '4xx Final Response') angehängt, das die Kennung des ablehnenden Satelli- tenterminals und den zugehörenden 4xx-Antworttyp enthält; die 200-Nachricht m13' weist somit ein 4FIN-Rumpffeld mit der Information auf, dass das Satellitenterminal ST3 mit 486 geantwortet hat. An der Schnittstelle zwischen dem Steuerstation NCC und dem rufenden Satellitenterminal ST1 wird somit auch in diesem Fall nur eine 200-Nachricht m13' übertragen, was die Finite-State- Maschine des rufenden Satellitenterminals vereinfacht und die Beibehaltung der standardgemässen Maschine gestattet. Die so aufgebaute ptmp Sitzung s3 bezieht in diesem Fall dieses Satelliten- terminal ST3 nicht ein. Im Übrigen entspricht der Aufbau der Sitzung s3 nach Fig. 5 dem Vorgang des erfolgreichen Aufbaus wie in fig. 4 beschrieben. Falls - bezugnehmend auf Fig. 5a - alle eingeladenen Terminals ST2, ST3, ST4 mit einer 4xx- Nachricht m27, m37, m47 antworten, wird anstelle einer 200-Nachricht m13' eine 499-Nachricht m17 erstellt. Ebenso wie bei der Nachricht m13' wird für jede 4xx-Antwort an die 499-Nachricht <Desc/Clms Page number 10> m17 jeweils ein 4FIN-Rumpffeld angehängt (vgl. Tabelle 3). Weiters können durch das erfindungsgemässe Sat-SIP Protokoll auch Prozeduren zur Einbe- ziehung zusätzlicher Teilnehmer - Add Party" - oder des Ausscheidens einzelner Teilnehmer - Drop Party" - in Bezug auf eine ptmp Sitzung unterstützt werden. Tabelle 4 gibt die ausgetausch- ten Nachrichten der Fig. 6 und 7 wieder. Fig. 6 zeigt ein Beispiel eines Add-Party-Vorgangs, bei- spielsweise das nachträgliche Einbeziehen des Satellitenterminals ST3 im Anschluss an den Vorgang der Fig. 5, sodass ausgehend von der Sitzung s3 eine Sitzung s4' erreicht wird, in die das Terminal ST3 ebenfalls eingebunden ist, entsprechend dem Ergebnis der Fig. 4. Dieser Fall ver- läuft wie der Aufbau einer eigenen Sitzung (Fig. 2), und die einzelnen Nachrichten sind mit Bezug- zeichen bnm entsprechend den Nachrichten pnm der Fig. 2 bezeichnet. Der Unterschied zu dem Vorgang der Fig. 2 besteht darin, dass gegenüber den Parametern, die bei der Herstellung der ptmp-Verbindung nach Fig. 5 in den Header-Feldem der Wert des Parameters cseq erhöht wird, um den Ablauf als eigene Transaktion zu kennzeichnen, während der Parameter callid gleich ist. Wenn mehrere INVITE-Nachrichten innerhalb einer Sitzung verwendet werden, beispielsweise um mehrere Satellitenterminals zu einer ptmp-Sitzung einzuladen oder um - wie hier - ein Satelliten- terminal nachträglich einzuladen, enthält jede INVITE-Nachricht die gleiche callid; um zwischen den einzelnen INVITE-Nachrichten unterscheiden zu können, erhalten sie verschiedene cseq- Werte. Dies entspricht dem Standard-SIP. Gleiches geschieht bei den BYE-Nachrichten, während in einer ACK oder CANCEL-Nachricht die gleiche cseq wie die jeweils zugehörende INVITE- Nachricht verwendet wird. Die INVITE-Nachricht b11weicht von der entsprechenden Nachricht p11 insbesondere darin ab, dass sie einen leeren Nachrichtenrumpf hat. Fig. 7 zeigt den erfolgreichen Rufabbau im ptmp Fall. Wiederum wird die gesamte Information über die zu benachrichtigenden Satellitenterminals an das rufende Satellitenterminal ST1 in einer gemeinsamen BYE-Nachricht m15 übertragen, um einerseits den RASC-Kanal effektiv zu nützen und andererseits standardkonform zu bleiben. Zur Rückmeldung wird eine gemeinsame Quittie- rung m16 verwendet. Im nicht erfolgreichen Fall wird wiederum der Rumpf der 200 Nachricht verwendet, um dem rufenden Satellitenterminal ST1 diejenigen Teilnehmer mitzuteilen, die eine negative Quittung geschickt haben. Auf Seiten der Satellitenterminals ST2, ST3, ST4 ist der Vor- gang gänzlich analog zu dem Vorgang der Fig. 3 ; entsprechen in Fig. 5 die Nachrich- ten m25, m35, m45 (BYE) und m26, m36, m46 (200) den Nachrichten p25 bzw. p26 der Fig. 3. Auch hier werden abschliessend mittels eines CAC-Aufrufs C4 die im Steuerzentrum NCC belegten Ressourcen freigeschaltet bzw. die QoS-Parameter zurückgesetzt. QoS- und/oder Verkehrs-Parameter können für eine bestehende Sat-SIP-Sitzung neu verhan- delt werden, indem diese Informationen in einer neuerlichen INVITE-Nachricht vom rufenden Terminal ST1 dem Steuerzentrum NCC mitgeteilt werden. Falls die neuen Parameter vom CAC akzeptiert werden, schickt das Steuerzentrum NCC entsprechende INVITE-Nachrichten an die gerufenen Terminals weiterleitet. Sobald alle gerufenen Terminals mit einer 200 Nachricht geant- wortet haben, schickt das Steuerzentrum NCC eine 200-Nachricht an das rufende Satellitenterminal. Dieses antwortet mit einer ACK-Nachricht an das Steuerzentrum, welches wiederum eine ACK-Nachricht an jedes der gerufenen Satellitenterminals schickt. Das Ändern von QoS- und/oder Verkehrs-Parametern kann nur das rufende Terminal veranlassen. Der Sat-SIP Call Control Prototyp wird weitgehend in SDL ('Specification and Description Lan- guage') geschrieben. Die Architektur des Sat-SIP Call Control Prototypes, der das Sat-SIP Proto- koll implementiert, orientiert sich im wesentlichen an den vom SIP Standard geforderten funktiona- len Einheiten. Folglich sind die Terminal-Sat-SIP-Software und die Steuerstation-Sat-SIP-Software in Prozesse entsprechend Transaction User, Client Transaction und Server Transaction unterteilt. Client und Server Transactions sind in Standard-SIP beschrieben und vollständig sowie - mit Ausnahme der angepassten Timer - unverändert in Sat-SIP übemommen. Darüber hinaus müssen gegebenenfalls für Koordinationszwecke (für die Steuerung der ver- schiedenen Prozessinstanzen) zusätzliche über den Standard hinausgehende Prozesse eingeführt werden. Der SIP-Standard beschreibt z. B. nur, dass bestimmte Aufgaben von bestimmten logi- schen Entitäten übernommen werden müssen, nicht jedoch, wie dies im konkreten Fall zu tun ist. Analoges gilt auch für die Software-Architektur des Satellitenterminals. Ein weiterer wichtiger Punkt ist die Frage des Zusammenwirken ('Interworking') von Sat-SIP mit bestehenden terrestrischen Protokollen und zwar verbindungsorientierten (ISDN, ATM) wie auch <Desc/Clms Page number 11> verbindurigslosen Protokollen (IP). Hiezu ist eine eigene Interworking-Einheit im Satellitenterminal notwendig, die entweder aus einer im Satellitenterminal aus dem terrestrischen Netz ankommen- den Nachricht (ISDN, ATM) oder aus einem ankommenden Packet (IP) einen Trigger für einen Verbindungswunsch ableitet, bzw. entsprechende Parameter aus der ankommenden Nachricht ableitet und eine geeignete Sat-SIP INVITE Nachricht absetzt. Gegebenenfalls muss auch das Mapping der Parameter auf die Sat-SIP Parameter in der Interworking-Einheit stattfinden (Ab- schluss der ankommenden Verbindung), oder die ankommenden Nachrichten werden über den aufgebauten Nutzkanal übertragen. Auf Besonderheiten des jeweiligen terrestrischen Protokolls (Timerverhalten, bei TCP/IP TCP Splitting) muss dann individuell Rücksicht genommen werden. Fig. 8 zeigt ein Beispiel eines Signalablaufs mit einem Interworking zwischen dem ISDN Proto- koll und dem Sat-SIP Protokoll. Seitens einer dem rufenden Satellitenterminal ST1 zugeordneten ISDN-Interworking-Funktion IF1 sei eine Q.931 SETUP-Nachricht q1 empfangen worden. Die ankommende SETUP-Nachricht wird nun von der IWF "zurückgehalten", um zu prüfen, ob für den zu erwartenden (ISDN) Verkehr ein Verbindungswunsch akzeptiert werden kann; erst dann kann die SETUP-Nachricht an das gerufene Terminal ST2 bzw. dessen Interworking-Funktion IF2 wei- tergesendet werden. Die Interworking-Funktion IF1 generiert somit aus der SETUP-Nachricht einen EMI11.1 darstellt. Der Setup-Request ip1 enthält dabei alle Informationen aus der angekommenen SETUP- Nachricht, die für die Generierung einer INVITE Nachricht p11notwendig sind {also im wesentli- chen die Verkehrs- und QoS Parameter). Innerhalb des Satellitensystems folgen die Nachrichten p11, p21 usw. auf dieselbe Weise wie oben anhand der Fig. 2 diskutiert wurde. Auf der gerufenen Seite ST2 wird dann beim Eintreffen der INVITE-Nachricht p21 eine Setup-Indikation pi1 (setup¯ind) erzeugt, die an die Interworking-Funktion IF2 des gerufenen Satellitenterminals ST2 geht. Der Empfang wird durch ein Setup-Response pi3 (setup¯resp) quittiert. Diese enthält alle Parameter, die zur Generierung der 200 Nachricht p23 notwendig sind, die dann über den Satelli- ten an das rufende Satellitenterminal ST1 als Nachricht p13 zurückgeschickt wird. Aus dieser wird im rufenden Satellitenterminal ST1 eine Setup-Bestätigung ip3 (setup¯cnf, 'setup confirmation'), die ihrerseits wieder durch eine Nachricht ip4 (setup¯cmp¯req, 'setup completion request') quittiert wird. Dies führt zum Aussenden einer ACK Nachricht p14, p24, die die Transaktion im Satelliten- system abschliesst (Fig. 2). Auf der gerufenen Seite wird die ACK-Nachricht p24 wieder in eine Bestätigung pi4 (setup¯cmp¯ind, 'setup complete indication') umgewandelt. Damit ist die Sat-SIP Sitzung s12 und der zugehörige Nutzkanal über den Satelliten aufgebaut. Die in der rufenden Interworking-Funktion IF1 wartende Q.931 SETUP-Nachricht q1 wird nun über einen dedizierten Signalisierungskanal an das gerufene Satellitenterminal ST2/IF2 übertragen (vollständige Trennung von Signalisierungs- und Nutzinformation), und von dort an .eine nachge- ordnete ISDN-Vermittlungsstelle weiter geleitet, die das Q.931 Protokoll nach bekannter Art abar- beitet. Der Signalisierungskanal kann dabei permanent z. B. durch Konfiguration einem oder meh- reren Satellitenterminals zugewiesen sein, oder er wird bei Bedarf aufgebaut, z. B. ebenfalls nach dem beschriebenen Verfahren. Die Signalisierungsinformationen für ein bestimmtes Satellitenter- minal durchlaufen somit einen "Single Hop". Zwischen den beiden Interworking-Funktionen IF1, IF2 läuft nun die standardkonforme ISDN Signalisierung ab, wobei der Informationsaustausch über die Sat-SIP Sitzung s12 transparent abläuft. Die Signalisierung für den Rufabbau ergibt sich aus dem oben Gesagten in entsprechender Weise. Die Erfindung ist freilich nicht auf das oben behandelte Beispiel des Sat-SIP eingeschränkt, vielmehr kann sie auch in allgemeineren Systemen eingesetzt werden. So ist die Erfindung z. B. auch mit einem Schmalband-Satellitensystemverwendbar. Die Ressourcensteuerung des Satelliten SAT kann on-board oder in der Steuerstation NCC lokalisiert sein. Ausserdem muss die Steuersta- tion NCC nicht als vom Satelliten getrennte terrestrische Stelle realisiert sein, sondern kann zur Gänze oder teilweise on-board sein. Auch kann ein Kommunikations-Satellitensystem ohne "On Board Processing" verwendet werden. In diesem Falle läuft die Datenverbindung im "Double-Hop" vom rufenden Satellitenterminal über eine zentrale Bodenstation zum gerufenen Satellitenterminal. Auch können die Verbindungen unter Einbeziehung terrestrischer Netzwerk-Verbindungen (ohne Satellit) erstellt werden, die ebenfalls gemäss der Erfindung, z. B. über Sat-SIP, signalisiert werden. <Desc/Clms Page number 12> Tabelle 1 : Sat-SIP-Nachrichten der Fig. 2 und 3 (ptp) EMI12.1 INVITE satsip:NCCID Sat-SIP/1.0 To : 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1" < satsip:ST1ID > Call-ID: 324&commat;ST1 ID CSeq : 1 INVITE EMI12.2 p12 : NCC ST1 Sat-SIP/1.0 100 Trying To : 'Terminal ST2" < satsip:ST2ID > EMI12.3 Call-ID: 324&commat;ST1 ID CSeq : 1 INVITE p21: NCC ST2 INVITE satsip:ST2lD Sat-SIP/1.0 To : 'Terminal ST2" < satsip:ST2ID > From: 'Terminal ST1" < satsip:ST1ID > EMI12.4 CSeq : 1 INVITE PTP=true,UNI=true,FUF=90,FPDR=256 p23 : ST2 NCC Sat-SIP/1.0 200 OK To: 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 324&commat;ST1 ID CSeq : 1 INVITE p13 :NCC ST1 Sat-SIP/1.0 200 OK To : 'Terminal ST2" < satsip:ST2ID > EMI12.5 CSeq : 1 INVITE P14 : ST1 NCC ACK satsip:NCCID Sat-SIP/1.0 To : 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1" < satsip:ST1ID > Call-ID: 324&commat;ST1 ID CSeq : 1 ACK p24 : NCC - ST2 ACK satsip:ST2lD Sat-SIP/1.0 To : 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1" < satsip:ST1ID > Call-ID: 324&commat;ST1 ID CSeq : 1 ACK <Desc/Clms Page number 13> p15: ST1 NCC BYE satsip:NCCID Sat-SIP/1.0 To : 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1" < satsip:ST1ID > EMI13.1 CSeq : 1 BYE p25 : NCC ST2 BYE satsip:ST2lD Sat-SIP/1.0 To : 'Terminal ST2" < satsip:ST2ID > EMI13.2 CSeq : 1 BYE p26 : ST2 - NCC Sat-SIP/1.0 200 OK EMI13.3 From : 'Terminal ST1" " < satsip:ST1 ID > Call-ID: 324&commat;ST1 ID CSeq : 1 BYE p16 : NCC ST1 Sat-SIP/1.0 200 OK To : 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1" " < satsip:ST1 ID > EMI13.4 CSeq : 1 BYE Tabelle 2 : Timer-Werte für Sat-SIP (beispielhafte Werte für Konfiguration der Fig. 1) EMI13.5 <tb> Zustand <SEP> Timer <SEP> SIP <SEP> Default-Wert <SEP> Sat-SIP <SEP> Wert <SEP> Zweck <tb> <tb> <tb> INVITE <SEP> Client <SEP> T1 <SEP> 500 <SEP> ms <SEP> 2*satT <SEP> (= <SEP> 1000 <SEP> ms) <SEP> Round <SEP> Trip <SEP> Time <tb> <tb> <tb> Transaction <tb> <tb> <tb> <tb> <tb> <tb> (17.1.1) <tb> <tb> <tb> <tb> A <SEP> T1 <SEP> (= <SEP> 500 <SEP> ms) <SEP> T1 <SEP> (= <SEP> 1000 <SEP> ms) <SEP> Controls <SEP> request <SEP> retrans- <tb> <tb> <tb> mission <tb> <tb> <tb> <tb> B <SEP> 64*T1 <SEP> (= <SEP> 32 <SEP> s) <SEP> 64*satT <SEP> (= <SEP> 32 <SEP> s) <SEP> Controls <SEP> transaction <SEP> time- <tb> <tb> <tb> out <tb> <tb> <tb> <tb> D <SEP> 32 <SEP> s <SEP> or <SEP> 0 <SEP> 32 <SEP> s <SEP> Controls <SEP> answering <SEP> for <tb> <tb> <tb> retransmitted <SEP> request <tb> <tb> <tb> <tb> Non-INVITE <SEP> T2 <SEP> 4 <SEP> s <SEP> 4 <SEP> s <SEP> Stops <SEP> the <SEP> increasing <SEP> inter- <tb> <tb> <tb> Client <SEP> Transac- <SEP> val <SEP> of <SEP> the <SEP> retransmission <tb> <tb> <tb> tion <SEP> time <tb> <tb> <tb> <tb> <tb> <tb> (17.1.2) <tb> <tb> <tb> <tb> T4 <SEP> 5 <SEP> s <SEP> 5 <SEP> s <SEP> Time <SEP> buffer <SEP> where <SEP> a <SEP> re- <tb> <tb> <tb> <tb> transmitted <SEP> response <SEP> may <tb> <tb> be <SEP> received <tb> <tb> <tb> <tb> <tb> E <SEP> T1 <SEP> (= <SEP> 500 <SEP> ms) <SEP> T1 <SEP> (=1000 <SEP> ms) <SEP> Controls <SEP> request <SEP> retrans- <tb> <tb> <tb> mission <tb> <Desc/Clms Page number 14> EMI14.1 <tb> Zustand <SEP> Timer <SEP> SIP <SEP> Default-Wert <SEP> Sat-SIP <SEP> Wert <SEP> Zweck <tb> <tb> <tb> F <SEP> 64*T1 <SEP> (= <SEP> 32 <SEP> s) <SEP> 64*satT <SEP> (=32 <SEP> s) <SEP> Controls <SEP> transaction <tb> <tb> <tb> timeout <tb> <tb> <tb> <tb> K <SEP> T4 <SEP> (= <SEP> 4 <SEP> s) <SEP> or <SEP> 0 <SEP> T4 <SEP> (= <SEP> 4 <SEP> s) <SEP> Time <SEP> buffer <SEP> where <SEP> a <SEP> re- <tb> <tb> <tb> transmitted <SEP> response <SEP> may <tb> <tb> <tb> be <SEP> received <tb> <tb> <tb> <tb> <tb> INVITE <SEP> Server <SEP> G <SEP> T1 <SEP> (500 <SEP> ms) <SEP> or <SEP> 0 <SEP> T1 <SEP> (= <SEP> 1000 <SEP> ms) <SEP> Controls <SEP> response <SEP> retrans- <tb> <tb> <tb> Transaction <SEP> mission <tb> <tb> <tb> <tb> <tb> <tb> (17.2.1 <SEP> ) <SEP> <tb> <tb> <tb> <tb> <tb> H <SEP> 64*T1 <SEP> (= <SEP> 32 <SEP> s) <SEP> 64*satT <SEP> (= <SEP> 32 <SEP> s) <SEP> Controls <SEP> transaction <SEP> time- <tb> <tb> <tb> out <tb> <tb> <tb> <tb> I <SEP> T4 <SEP> (= <SEP> 5 <SEP> s) <SEP> or <SEP> 0 <SEP> T4 <SEP> (= <SEP> 5 <SEP> s) <SEP> Time <SEP> buffer <SEP> where <SEP> a <SEP> re- <tb> <tb> <tb> transmitted <SEP> request <SEP> may <tb> EMI14.2 EMI14.3 <tb> Non-INVITE <SEP> J <SEP> 64*T1 <SEP> (= <SEP> 32 <SEP> s) <SEP> or <SEP> 0 <SEP> 64*satT <SEP> (= <SEP> 32 <SEP> s) <SEP> Time <SEP> buffer <SEP> where <SEP> a <SEP> re- <tb> <tb> Server <SEP> Trans- <SEP> transmitted <SEP> request <SEP> may <tb> <tb> action <SEP> be <SEP> received <tb> EMI14.4 Tabelle 3 : Sat-SIP-Nachrichten der Fig. 4 und 5 (ptmp) m11 :ST1 NCC INVITE satsip:NCCID Sat-SIP/1.0 To : 'Terminal ST2" < satsip:ST2ID > , "Terminal ST3" < satsip:ST3ID > , 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1ID > Call-ID: 325&commat;ST1 ID CSeq : 1 INVITE PTP=false,UNI=true,FUF=100,FPDR=512 m12 : NCC ST1 Sat-SIP/1. 0 100 Trying To : 'Terminal ST2" < satsip:ST2ID > , 'Terminal ST3" < satsip:ST3ID > , 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1 ID > EMI14.5 CSeq : 1 INVITE m21: NCC ST2 INVITE satsip:ST2lD Sat-SIP/1.0 To : 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 325&commat;ST11D CSeq : 1 INVITE EMI14.6 <Desc/Clms Page number 15> m31:NCC ST3 INVITE satsip:ST3lD Sat-SIP/1.0 To : 'Terminal ST3" < satsip:ST3ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 325&commat;ST11D CSeq : 1 INVITE PTP=false,UNI=true,FUF=100,FPDR=512 m41: NCC ST4 INVITE satsip:ST2lD Sat-SIP/1.0 To : 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1 " < satsip:ST1 ID > Call-ID: 325@ST1ID CSeq : 1 INVITE EMI15.1 m23 : ST2 NCC Sat-SIP/1.0 200 OK To : 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 325&commat;ST1 ID CSeq : 1 INVITE m33 : ST3 NCC Sat-SIP/1.0 200 OK To : 'Terminal ST3" < satsip:ST3ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 325&commat;ST11D CSeq : 1 INVITE m43 : ST4 - NCC Sat-SIP/1.0 200 OK To : 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1 ID > EMI15.2 CSeq : 1 INVITE m13 :NCC ST1 Sat-SIP/1.0 200 OK To : 'Terminal ST2" < satsip:ST2ID > , "Terminal ST3" < satsip:ST3ID > , 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 325&commat;ST11D CSeq : 1 INVITE m14 : ST1 NCC ACK satsip:NCCID Sat-SIP/1.0 To : 'Terminal ST2" < satsip:ST2ID > , 'Terminal ST3" < satsip:ST3ID > , 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1ID > Call-ID: 325&commat;ST1 ID CSeq : 1 ACK <Desc/Clms Page number 16> m24 : NCC - > ST2 ACK satsip:ST2lD Sat-SIP/1.0 To: 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 325&commat;ST11D CSeq : 1 ACK m34 : NCC ST3 ACK satsip:ST3lD Sat-SIP/1.0 To : 'Terminal ST3" < satsip:ST3ID > From : 'Terminal ST1" < satsip:ST1ID > Call-ID: 325&commat;ST1 ID CSeq : 1 ACK m44 : NCC - > ST4 ACK satsip:ST4lD Sat-SIP/1.0 To : 'Terminal ST4" < satsip:ST4ID > EMI16.1 Call-ID: 325&commat;ST1 ID CSeq : 1 ACK m11: ST1 NCC INVITE satsip:NCCID Sat-SIP/1.0 To : "Terminal ST2" < satsip:ST2ID > , 'Terminal ST3" < satsip:ST3ID > , 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 326&commat;ST1 ID CSeq : 1 INVITE PTP=false,UNI=true,FUF=100,FPDR=512 m12 : NCC ST1 Sat-SIP/1.0 100 Trying To : "Terminal ST2" < satsip:ST2ID > , 'Terminal ST3" < satsip:ST3ID > , 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1ID > Call-ID: 326&commat;ST1 ID CSeq : 1 INVITE m21: NCC - ST2 INVITE satsip:ST2lD Sat-SIP/1.0 To : 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1" < satsip:ST1 ID > EMI16.2 CSeq : 1 INVITE PTP=false,UNI=true,FUF=100,FPDR=512 m31: NCC ST3 INVITE satsip:ST3lD Sat-SIP/1.0 To : 'Terminal ST3" < satsip:ST3ID > From : Terminal ST1" < satsip:ST1ID > EMI16.3 CSeq : 1 INVITE <Desc/Clms Page number 17> EMI17.1 m41 :NCC ST4 INVITE satsip:ST2lD Sat-SIP/1.0 To : 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1ID > EMI17.2 CSeq : 1 INVITE PTP=false,UNI=true,FUF=100,FPDR=512 m23 : ST2 NCC Sat-SIP/1.0 200 OK To: 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1" < satsip:ST1 ID > EMI17.3 m43 : ST4 NCC Sat-SIP/1.0 200 OK To : 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 326&commat;ST1 ID CSeq : 1 INVITE m37 : ST3 - > NCC Sat-SIP/1.0 486 Busy Here To : 'Terminal ST3" < satsip:ST3ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 326&commat;ST1 ID CSeq : 1 INVITE Errorinfo : Busy Here Retryafter : 10 EMI17.4 Sat-SIP/1.0 200 OK To : "Terminal ST2" < satsip:ST2ID > , "Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1ID > Call-ID: 326&commat;ST1 ID CSeq : 1 INVITE 4FIN:SatSIP/1.0 486 Busy Here To : 'Terminal ST3" < satsip:ST3ID > Error-Info: "Busy Here" Retryafter: 10 m14 : ST1 NCC ACK satsip:NCCID Sat-SIP/1.0 To : 'Terminal ST2" < satsip:ST2ID > , "Terminal ST3" < satsip:ST3ID > , 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1 ID > EMI17.5 CSeq : 1 ACK <Desc/Clms Page number 18> m24 : NCC ST2 ACK satsip:ST2lD Sat-SIP/1.0 To : 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1" < satsip:ST1 ID > EMI18.1 CSeq : 1 ACK m34 : NCC - ST3 ACK satsip:ST3lD Sat-SIP/1.0 To : 'Terminal ST3" < satsip:ST3ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 326&commat;ST1 ID CSeq : 1 ACK m44 : NCC ST4 ACK satsip:ST4lD Sat-SIP/1.0 To : 'Terminal ST4" < satsip:ST4ID > EMI18.2 CSeq : 1 ACK m27 : ST2 - > NCC Sat-SIP/1.0 486 Busy Here To : 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1" < satsip:ST1ID > EMI18.3 CSeq : 1 INVITE Errorinfo : Busy Here Retryafter : 10 m37 : ST3 NCC Sat-SIP/1.0 486 Busy Here To: 'Terminal ST3" < satsip:ST3ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 326&commat;ST1 ID CSeq : 1 INVITE Errorinfo : Busy Here Retryafter : 10 m47 : ST4 NCC Sat-SIP/1.0 486 Busy Here To : 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 326&commat;ST1 ID CSeq : 1 INVITE Errorinfo : Busy Here Retryafter : 10 m17 :NCC ST1 SatSIP/1.0 499 "All Terminals failed" To : 'Terminal ST2" < satsip:ST2ID > , "Terminal ST3" < satsip:ST3ID > 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID:326&commat;ST1 ID CSeq: 1 INVITE <Desc/Clms Page number 19> 4FIN: SatSIP/1.0 486 Busy Here To : 'Terminal ST2" < satsip:ST2ID > Error-Info: "Busy Here" Retryafter : 10 4FIN:SatSIP/1.0 486 Busy Here To : 'Terminal ST3" < satsip:ST3ID > Error-Info: "Busy Here" Retryafter : 10 4FIN:SatSIP/1.0 486 Busy Here To : 'Terminal ST4" < satsip:ST4ID > Error-Info: "Busy Here" Retryafter : 10 Tabelle 4 : Sat-SIP-Nachrichten der Fig. 6 und 7 (Add-Partv. Drop-Partv b11: ST1 NCC EMI19.1 To : 'Terminal ST3" < satsip:ST3ID > From : 'Terminal ST1" < satsip:ST1ID > Call-ID: 326&commat;ST1 ID CSeq : 2 INVITE b12 : NCC - > ST1 Sat-SIP/1. 0 100 Trying To : 'Terminal ST3" < satsip:ST3ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 326&commat;ST11D CSeq : 2 INVITE b21 :NCC ST3 INVITE satsip:ST3lD Sat-SIP/1.0 To : "Terminal ST3" < satsip:ST3ID > From : 'Terminal ST1" < satsip:ST1 ID > EMI19.2 CSeq : 2 INVITE PTP=false,UNI=true,FUF=100,FPDR=512 b23 : ST3 - NCC Sat-SIP/1.0 200 OK To : "Terminal ST3" < satsip:ST3ID > EMI19.3 CSeq : 2 INVITE b13: NCC STI Sat-SIP/1.0 200 OK To : 'Terminal ST3" < satsip:ST3ID > From:"Terminal ST1" < satsip:ST1 ID > Call-ID: 326&commat;ST1 ID CSeq : 2 INVITE b14: ST1 - NCC ACK satsip:NCCID Sat-SIP/1.0 To : 'Terminal ST3" < satsip:ST3ID > <Desc/Clms Page number 20> From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 326&commat;ST1 ID CSeq : 2 ACK b24 : NCC ST3 ACK satsip:ST3lD Sat-SIP/1.0 To : 'Terminal ST3" < satsip:ST3ID > From : 'Terminal ST1" " < satsip:ST1 ID > Call-ID: 326&commat;ST1 ID CSeq : 2 ACK Nachrichten der Fig. 7: m15 : ST1 NCC BYE satsip:NCCID Sat-SIP/1.0 To : 'Terminal ST2" < satsip:ST2ID > , 'Terminal ST3" < satsip:ST3ID > , 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 326&commat;ST1 ID CSeq : 1 BYE m25 : NCC ST2 BYE satsip:ST2lD Sat-SIP/1.0 To : 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1"satsip:ST1ID Call-ID: 326&commat;ST1 ID CSeq : 1 BYE m35 : NCC ST2 BYE satsip:ST3lD Sat-SIP/1.0 To : 'Terminal ST3" < satsip:ST3ID > From : 'Terminal ST1" < satsip:ST1 ID > Call-ID: 326&commat;ST1 ID CSeq : 1 BYE m45 : NCC - ST2 BYE satsip:ST4lD Sat-SIP/1.0 To:"Terminal ST4" < satsip:ST4ID > From: 'Terminal ST1"satsip:ST1ID Call-ID: 326&commat;ST11D CSeq : 1 BYE m26 : ST2 NCC Sat-SIP/1.0 200 OK To: 'Terminal ST2" < satsip:ST2ID > From : 'Terminal ST1" " < satsip:ST1 ID > Call-ID: 326&commat;ST1 ID CSeq : 1 BYE m36:ST3 - > NCC Sat-SIP/1.0 200 OK To : "Terminal ST3" < satsip:ST3ID > From : 'Terminal ST1"satsip:ST1ID EMI20.1 CSeq : 1 BYE <Desc/Clms Page number 21> m46 : ST2 NCC Sat-SIP/1.0 200 OK To : 'Terminal ST4" < satsip:ST4ID > From : 'Terminal ST1" < satsip:ST1ID > Call-ID: 326&commat;ST1 ID CSeq : 1 BYE m16 :NCC ST1 Sat-SIP/1.0 200 OK To : "Terminal ST2" < satsip:ST2ID > , 'Terminal ST3" < satsip:ST3ID > , 'Terminal ST4" < satsip:ST4ID > From:'Terminal ST1" < satsip:ST1ID > Call-ID: 326&commat;ST1ID CSeq : 1 BYE - @ @ PATENTANSPR CHE: 1. Verfahren zum Steuern von Verbindungen, insbesondere zum Verbindungsaufbau und/oder-abbau, zwischen Transitnetz-Terminals (ST1, ST2, ST3, ST4) eines Transitnet- zes (BSS) mit einer zentralen Steuereinrichtung (NCC), einer Anzahl von Transitnetz- Terminals sowie gegebenenfalls einer oder mehreren, dem Transitnetz internen Relaisstel- len (SAT), unter Verwendung von Transitnetz-Kommunikationsstrecken (seil, scl2), die jeweils zwischen zwei der Terminals und/oder Relaisstellen verlaufen, wobei die Steue- rung der Kommunikationsstrecken, insbesondere das Belegen und Freigeben derselben fÜr Verbindungen zwischen Terminals, von der Steuereinrichtung (NCC) aufgrund von Sig- nalisierungsinformation (ssg) durchgefÜhrt wird, die zwischen der Steuerstation (NCC) und den Terminals ausgetauscht wird, dadurch gekennzeichnet, dass fÜr den Austausch der Signalisierungsinformation (ssg) ein Signalisierungsprotokoll ver- wendet wird, mit zumindest folgenden, dem SIP-Standard entsprechenden Request- Nachrichtentypen: - ein Nachrichtentyp (INVITE; p11, m11, b11) zum Einleiten eines Verbindungsaufbaus, - ein Nachrichtentyp (BYE; p15, m15) zum Einleiten eines Verbindungsabbaus, und - ein Nachrichtentyp (ACK; p14, m14, b14) zum Best tigen eines vorangegangenen Austauschs von Signalisierungsinformation, sowie zumindest einem dem SIP-Standard entsprechenden Response-Nachrichtentyp (100,200, 4xx ; p12, m12, p13, p16, m13, b13, m16, m37) fÜr Best tigungsmeldungen und/oder Fehlermeldungen, wobei ein Verbindungswunsch (q1),der von einem bei einem Transitnetz-Terminal (ST1) angebundenen Telekommunikationsnetz (TN1) an dieses Terminal (ST1) gesendet wird, von einer seitens des Terminals (ST1) vorgesehenen Interworking-Funktion (IF1 ) empfan- gen wird und erst nach erfolgtem Aufbau einer Transitnetz-Verbindung (s12) der Verbin- dungswunsch (q1) an ein zweites Transitnetz-Terminal (ST2), das die Gegenstelle der Transitnetz-Verbindung darstellt, transparent weitergeleitet wird. 2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass aufgrund des von der Inter- working-Funktion empfangenen Verbindungswunsches seitens des Terminals (ST1) eine Nachricht (p11) gemäss dem Nachrichtentyp zum Einleiten eines Transitnetz- Verbindungsaufbaus erzeugt und an die zentrale Steuereinrichtung (NCC) gesendet wird.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Interworking-Funktion (IF1) aufgrund des empfangenen Verbindungswunsches (q1) einen Setup-Request (ip1) erzeugt, aufgrund dessen die Nachricht zum Einleiten eines Transitnetz- Verbindungsaufbaus erzeugt wird.

4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass in zumin- dest einem Teil der nach dem Signalisierungsprotokoll ausgetauschten Nachrichten, <Desc/Clms Page number 22> insbesondere Nachrichten (m11) nach dem Nachrichtentyp zum Einleiten eines Verbin- dungsaufbaus, mehrere gerufene Transitnetz-Terminals (ST2, ST3, ST4) genannt werden, wobei solche Nachrichten für die Steuerung von Punkt-zu-Mehrpunkt-Verbindungen ver- wendet werden.

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass ein zusätzlicher Response- Nachrichtentyp (499) verwendet wird, mit dem eine Fehlermeldung in Bezug auf sämtliche gerufenen Transitnetz-Terminals einer Punkt-zu-Mehrpunkt-Verbindung signalisiert wird.

6. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass in den Bestätigungs- meldungen (m13') für Punkt-zu-Mehrpunkt-Verbindungen, zumindest jedoch in einem Teil von diesen, Rumpffelder nach einem zusätzlichen Rumpffeld-Typ (4FIN) verwendet wer- den, wobei mittels jedes solchen Rumpffelds eine Fehlermeldung in Bezug auf ein gerufe- nes Transitnetz-Terminal der betreffenden Punkt-zu-Mehrpunkt-Verbindung signalisiert wird.

7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass das Signa- lisierungsprotokoll als auf dem IP-Protokoll und/oder einem diesen übergeordneten Proto- koll, wie TCP oder UDP, aufsetzendes Signalisierungsprotokoll realisiert ist.

8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass im Rumpf einer von einem Transitnetz-Terminal an die Steuereinrichtung gesendeten Request- Nachricht erwünschte bzw. benötigte Verbindungsparameter angegeben werden.

9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass zumindest ein Teil der so übersendeten Verbindungsparameter einen oder mehrere der folgenden Kenngrössen betreffen : Verbindungstyp, Service-Kategorie, maximale Datenrate, Verwendungsfaktor, maximale Burst-Grösse, gewünschte Priorität der Verbindung, Cell-Delay-Variation, maxi- maler Cell-Transfer-Delay.

10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass es zum Steuern von Verbindungen zwischen Satellitenterminals (ST1, ST2, ST3, ST4) eines Satel- liten-Telekommunikationssystems (BSS) mit einer zentralen Steuereinrichtung (NCC), einer Anzahl von Satellitenterminals und zumindest einem Satelliten (SAT) verwendet wird, unter Verwendung von Kommunikationsstrecken (seit, scl2), die jeweils zwischen zwei der Satellitenterminals und/oder Satelliten verlaufen, wobei die Steuerung der Kommunikati- onsstrecken, insbesondere das Belegen und Freigeben derselben für Verbindungen zwi- schen Satellitenterminals, von der Steuereinrichtung (NCC) aufgrund von Signalisierungs- information (ssg) durchgeführt wird, die zwischen der Steuerstation (NCC) und den Satelli- tenterminals ausgetauscht wird.

11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass die Zuteilung von Bandbrei- ten zur Datenübertragung seitens des bzw. der Satelliten (SAT) durch eine dynamische Ressourcenverwaltung in Abhängigkeit von den angeforderten Verbindungsqualitäten gesteuert wird.

12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass die einem Satelliten (SAT) zugeordnete Ressourcenverwaltung im Rahmen eines On-Board-Systems auf diesem Satelliten abläuft.

13. Terminal-Einrichtung (ST1, ST2, ST3, ST4) für ein Transitnetz (BSS) mit einer zentralen Steuereinrichtung (NCC), für den Verbindungsauf- und-abbau in dem Transitnetz (BSS) in Zusammenwirken mit anderen Transitnetz-Terminals sowie gegebenenfalls einer oder mehreren, dem Transitnetz internen Relaisstellen (SAT) unter Verwendung von Kommuni- kationsstrecken (seil, scl2) die jeweils zwischen der Terminal-Einrichtung und einem anderen Terminal oder einer Relaisstelle verlaufen, wobei die Terminal-Einrichtung zum Austausch von Signalisierungsinformation (ssg) mit der Steuereinrichtung (NCC) zur Steu- erung der Kommunikationsstrecken, insbesondere das Belegen und Freigeben derselben für Verbindungen, eingerichtet ist, dadurch gekennzeichnet, dass sie zur Verwendung eines Signalisierungsprotokolls für den Austausch der Signalisie- rungsinformation (ssg) eingerichtet ist,

mit zumindest folgenden, dem SIP-Standard ent- sprechenden Request-Nachrichtentypen: - ein Nachrichtentyp (INVITE; p11, m11, b11) zum Einleiten eines Verbindungsaufbaus, <Desc/Clms Page number 23> ein Nachrichtentyp (BYE; p15, m15) zum Einleiten eines Verbindungsabbaus, und ein Nachrichtentyp (ACK; p14, m14, b14) zum Bestätigen eines vorangegangenen Austauschs von Signalisierungsinformation, sowie zumindest einem dem SIP-Standard entsprechenden Response-Nachrichtentyp (100,200, 4xx ;

p12, m12, p13, p16, m13, b13, m16, m37) für Bestätigungsmeldungen und/oder Fehlermeldungen, und eine Interworking-Funktion (IF1) vorgesehen ist, welche dazu eingerichtet ist, Verbin- dungswünsche (q1 ), die jeweils von einem bei der Einrichtung (ST1) angebundenen Tele- kommunikationsnetz (TN1) an die Einrichtung (ST1) gesendet werden, zu empfangen und jeweils erst nach erfolgtem Aufbau einer Transitnetz-Verbindung (s12) an ein Transitnetz- Terminal (ST2), das die Gegenstelle der Transitnetz-Verbindung darstellt, transparent wei- terzuleiten.

14. Einrichtung nach Anspruch 13, dadurch gekennzeichnet, dass sie dazu eingerichtet ist, aufgrund des von der Interworking-Funktion empfangenen Verbindungswunsches eine Nachricht (p11) gemäss dem Nachrichtentyp zum Einleiten eines Transitnetz- Verbindungsaufbaus zu erzeugen und an die zentrale Steuereinrichtung (NCC) zu senden.

15. Einrichtung nach Anspruch-14, dadurch gekennzeichnet, dass die Interworking-Funktion (IF1) zum Erzeugen eines Setup-Request (ip1) aufgrund des empfangenen Verbindungs- wunsches (q1) eingerichtet ist, aufgrund dessen die Nachricht zum Einleiten eines Transit- netz-Verbindungsaufbaus erzeugt wird.

16. Einrichtung nach einem der Ansprüche 13 bis 15, dadurch gekennzeichnet, dass sie als Satellitenterminal-Einrichtung {ST1, ST2, ST3, ST4) für ein Satelliten-Telekommunikations- system (BSS) mit einer Anzahl Satellitenterminals und zumindest einem Satelliten, einge- richtet ist, nämlich für den Verbindungsauf- und-abbau in einem Satelliten-Telekommuni- kationssystem (BSS) in Zusammenwirken mit zumindest einem Satelliten {SAT) unter Verwendung von Satelliten-Kommunikationsstrecken (seil , scl2), die jeweils zwischen dem Satellitenterminal und dem zumindest einen Satelliten verlaufen.

17. Einrichtung nach einem der Ansprüche 13 bis 16, dadurch gekennzeichnet, dass in den nach dem Signalisierungsprotokoll ausgetauschten Nachrichten, insbesondere Nachrich- ten (m11) nach dem Nachrichtentyp zum Einleiten eines Verbindungsaufbaus, die Nen- nung mehrerer gerufenen Terminals (ST2, ST3, ST4) zulässig ist, wobei solche Nachrich- ten für die Steuerung von Punkt-zu-Mehrpunkt-Verbindungen verwendet werden.

18. Einrichtung nach Anspruch 17, dadurch gekennzeichnet, dass ein zusätzlicher Respon- se-Nachrichtentyp (499) zum Signalisieren einer Fehlermeldung in Bezug auf sämtliche gerufenen Terminals einer Punkt-zu-Mehrpunkt-Verbindung vorgesehen ist.

19. Einrichtung nach Anspruch 17 oder 18, dadurch gekennzeichnet, dass in den Bestäti- gungsmeldungen (m13') für Punkt-zu-Mehrpunkt-Verbindungen Rumpffelder nach einem zusätzlichen Rumpffeld-Typ (4FIN) zulässig sind, wobei mittels jedes solchen Rumpffelds eine Fehlermeldung in Bezug auf ein gerufenes Terminal der betreffenden Punkt-zu- Mehrpunkt-Verbindung signalisiert wird.

20. Einrichtung nach einem der Ansprüche 13 bis 19, dadurch gekennzeichnet, dass das Signalisierungsprotokoll als auf dem IP-Protokoll und/oder einem diesen übergeordneten Protokoll, wie TCP oder UDP, aufsetzendes Signalisierungsprotokoll realisiert ist.

21. Einrichtung nach einem der Ansprüche 13 bis 20, dadurch gekennzeichnet, dass im Rumpf einer von einem Terminal an die Steuereinrichtung gesendeten Request-Nachricht die Angabe erwünschter bzw. benötigter Verbindungsparameter zulässig ist.

22. Einrichtung nach Anspruch 21, dadurch gekennzeichnet, dass zumindest ein Teil der so übersendeten Verbindungsparameter einen oder mehrere der folgenden Kenngrössen betreffen : Verbindungstyp, Service-Kategorie, maximale Datenrate, Verwendungsfaktor, maximale Burst-Grösse, gewünschte Priorität der Verbindung, Cell-Delay-Variation, maxi- maler Cell-Transfer-Delay.

HIEZU 3 BLATT ZEICHNUNGEN