DE102005046171A1 - Verfahren zum Aufrufen von Applikationsservern mit unterschiedlicher Betriebsart durch ein IP Multimedia Subsystem - Google Patents

Verfahren zum Aufrufen von Applikationsservern mit unterschiedlicher Betriebsart durch ein IP Multimedia Subsystem Download PDF

Info

Publication number
DE102005046171A1
DE102005046171A1 DE200510046171 DE102005046171A DE102005046171A1 DE 102005046171 A1 DE102005046171 A1 DE 102005046171A1 DE 200510046171 DE200510046171 DE 200510046171 DE 102005046171 A DE102005046171 A DE 102005046171A DE 102005046171 A1 DE102005046171 A1 DE 102005046171A1
Authority
DE
Germany
Prior art keywords
application server
multimedia subsystem
message
application servers
ims
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.)
Withdrawn
Application number
DE200510046171
Other languages
English (en)
Inventor
Richard Obermaier
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 Solutions and Networks GmbH and Co KG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Priority to DE200510046171 priority Critical patent/DE102005046171A1/de
Priority to PCT/EP2006/065495 priority patent/WO2007036398A1/de
Publication of DE102005046171A1 publication Critical patent/DE102005046171A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1063Application servers providing network services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1016IP multimedia subsystem [IMS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Aufruf komplexer Dienste eines Telekommunikationsnetzes durch ein IP Multimedia Subsystem (IMS), bei dem jeder Dienst Anwendungen von Applikationsservern (AP1, AP2, AP3, AP4, AP5) unterschiedlicher Betriebsart des Telekommunikationsnetzes umfasst. Diese Applikationsserver (AP1, AP2, AP3, AP4, AP5) müssen für den Aufruf des Dienstes in einer bestimmten Reihenfolge (RF) durchlaufen werden und dabei werden Nachrichten von den Applikationsservern (AP1, AP2, AP3, AP4, AP5) entsprechend der jeweiligen Betriebsart bearbeitet. Vom IP Multimedia Subsystem (IMS) wird dann eine von einem Applikationsserver (AP1, AP2, AP3, AP4, AP5) an das IP Multimedia Subsystem (IMS) gesendete Nachricht entsprechend am IP Multimedia Subsystem (IMS) gespeicherter Aufrufkriterien (LS) ausgewertet. Dabei wird anhand eines Kopfteiles der gesendeten Nachricht vom IP Multimedia Subsystem (IMS) die Betriebsart des Applikationsservers (AP1, AP2, AP3, AP4, AP5), von dem diese Nachricht gesendet worden ist, erkannt und dann werden entsprechend dieser Betriebsart Aufrufe weiterer Applikationesserver (AP1, AP2, AP3, AP4, AP5) gesteuert. DOLLAR A Die mit dem erfindungegemäßen Verfahren erzielbaren Vorteile bestehen insbesondere darin, dass für die Dienste in einem Telekommunikationsnetz, die durch ein IP Multimedia Subsystem (IMS) aufgerufen werden, Applikationsserver (AP1, AP2, AP3, AP4, AP5) mit unterschiedlicher Betriebsart ohne Einschränkung zum Hinterlegen von ...

Description

  • Die Erfindung betrifft ein Verfahren zum Aufruf komplexer Dienste eines Telekommunikationsnetzes durch ein IP Multimedia Subsystem, bei dem jeder Dienst Anwendungen von Applikationsservern mit unterschiedlicher Betriebsart umfasst. Diese Applikationsserver müssen für den Aufruf des Dienstes in einer bestimmten Reihenfolge durchlaufen werden und dabei werden Nachrichten von den Applikationsserver entsprechend der jeweiligen Betriebsart bearbeitet.
  • In den letzten Jahren haben sich Telekommunikationsnetze zu bedeutenden Kommunikationsmedien entwickelt, um wechselseitig Daten bzw. Informationen in Form von Sprache, Schrift, Bild, etc. auszutauschen. Zu den Telekommunikationsnetzen werden beispielsweise Telefonnetze wie z.B. klassische, vermittelte Telefonnetze, Mobilfunknetze, etc. und Computernetze, in denen meist verschiedene, primär selbständige elektronische Systeme zusammengeschlossen werden und von denen Daten meist in Form von Paketen – also paketorientiert – übertragen werden.
  • Von Computernetzen, über welche eine Vielzahl an Diensten wie z.B. Bereitstellung und Übertragung von Daten und Informationen, etc. angeboten werden, werden für den Austausch von Daten zwischen Rechnern innerhalb des Netzes oder auch verschiedener Netze Protokolle eingesetzt. Wird für die Weitervermittlung von Daten in Paketform das so genannte Internet Protokoll IP eingesetzt, so werden diese Computernetze auch als IP-basierte Computernetze bezeichnet. Diese IP-basierten Computernetze sind heute weit verbreitet. Ein Computernetzwerk, von welchem das Internet Protokoll IP verwendet wird, ist das weltweit bekannte Internet, wie die Gesamtheit aller miteinander verbundenen Computernetze genannt wird, die ebenfalls auf dem Internet Protokoll IP basieren.
  • Bei den Telefonnetzen ist seit den neunziger Jahren vor allem die Bedeutung von Mobilfunknetzen, bei denen die Endgeräte für Telefonie nicht über ortfeste Übergabepunkt an das Telefonsnetz angebunden, sondern mobil sind, durch die Entwicklung neuer Mobilfunkstandards wie z.B. Global System for Mobile Communications GSM besonders stark gestiegen. Von diesen Standards wird die Basis für die Mobilfunknetze der so genannten zweiten Generation gebildet, von denen durch den Einsatz digitaler Technik für die Sprach- und Datenübertragung erstmals Netzkapazitäten für einen Massenmarkt zur Verfügung gestellt wurden. Mittlerweile sind die Mobilfunknetze durch neue Standards wie z.B. Universal Mobile Telecommunications System UMTS für höhere Datenübertragungsraten optimiert worden und ermöglichen z.B. Dienst wie beispielsweise Videotelefonie, die Übertragung von Musik- oder Videodateien auf ein mobiles Endgerät, Audio-/Video-Nachrichten, etc. Die auf diesen neuen Standards basierenden Mobilfunknetze werden auch als Netz der dritten Generation bezeichnet.
  • Durch die große Bedeutung von IP-basierten Computernetzen einerseits und Telefonsnetzen, insbesondere Mobilfunknetzen andererseits gibt es mittlerweile Bestrebungen, diese beiden Netztypen durch Konvergenz in so genannten Netzen der nächsten Generation oder Next Generation Networks NGN aufzulösen. Von Next Generation Networks NGN werden dann die Aufgaben beider Netztypen (des Telefon- und des IP-basierten Computernetzes) übernommen, d.h. durch sie wird einerseits Telefonie (Übertragung von Sprache) und andererseits I-basierte Datenübertragung ermöglicht.
  • Die Konvergenz kann z.B. bei der Telefonie beobachtet werden, wo zunehmend klassische Telefonnetze in Next Generation Networks, von denen das Telefonieren über ein IP-basiertes Netz ermöglicht wird, aufgelöst werden oder beispielsweise bei den Mobilfunknetzen, über die neben den herkömmlichen Diensten wie z.B. Telefonie, Anrufbeantworterfunktion, Multimedia- oder Short Message Service mittlerweile auch ein Großteil der von IP-basierten Netzen wie z.B dem Internet zur Verfügung gestellten, meist auf dem Internet Protokoll IP basierenden Dienste wie z.B. E-mail, Zugriff auf das World Wide Web, Austausch von Multimedia-Daten, Laden von Audio- oder Video-Dateien auf das Endgerät, sofortige Nachrichtenübermittlung (Instant Messaging), etc. am mobilen Endgeräte genutzt werden können.
  • Um diese IP-basierten Dienste in einem Telefonnetz, insbesondere einem Mobilfunknetz verfügbar zu machen, wird in den Next Generation Networks eine spezielle Architektur-Struktur eingesetzt – das so genannte IP Multimedia Subsystem IMS. Das IP Multimedia Subsystem ist vom 3rd Generation Partnership Project 3GPP in einer Vielzahl technischer Spezifikationen TS standardisiert worden und stellt eine offene, für Netzbetreiber leicht in ihre Telekommunikationsnetzstruktur integrierbare und standardisierte Architektur-Struktur dar.
  • Der Zugang zum IP Multimedia Subsystem ist von jedem Telefon- bzw. Computernetzwerk mit paketorientierter Datenübertragung möglich. Für die Anbindung von klassischen Telefonnetzen wie z.B. dem Public Switched Telephone Network PSTN werden eigene Schnittstellensysteme eingesetzt. Von einem Benutzer kann daher mittels verschiedener Methoden je nach dem verwendeten Netz (z.B. vermitteltes Telefonnetz, Mobilfunknetz, Wireless LAN, etc.) auf das IP Multimedia Subsystem zugegriffen werden, wobei für den Zugang üblicherweise das Internet Protokoll IP eingesetzt wird.
  • Für die Nutzung IP-basierter Dienste durch die Benutzer wird vom IP Multimedia Subsystem eine Vermittlungsfunktion – die so genannte Call Session Control-Funktion CSCF – zur Verfügung gestellt. Durch die Call Session Control-Funktion, die von so genannten Vermittlungsrechnern des IP Multimedia Subsystems ausgeführt wird, wird der Aufbau und Ablauf einer multimedialen Verbindung zwischen Benutzern oder zur Nutzung eines IP-basierten Dienstes kontrolliert und gesteuert. Als Protokoll für das Management dieser multimedialen Verbindungen wird das so genannte Session Initiation Protocol SIP verwendet, das von der IETF (Internet Engineering Task Force) entwickelt wurde und durch eine Anzahl an Request for Comments RFC wie z.B. den RFC 3261, den RFC 3265, etc. definiert wird.
  • Die Dienste, die mittels IP Multimedia Subsystem genutzt werden können, werden in der Regel von so genannten Applikationsservern bereitgestellt. Auf diesen sind üblicherweise die zu den Diensten gehörenden Anwendungen und Daten hinterlegt bzw. werden auf ihnen die Dienste auch ausgeführt. Bei der Nutzung des Dienstes wird mit Hilfe des SIP-Protokolls von der Call Session Control-Funktion auf die entsprechenden Applikationsserver zugegriffen. Ein Aufruf eines Applikationsservers wird beispielsweise mittels logischer Adressierung mittels einer so genannten Adresse durchgeführt und dabei eine Nachricht – üblicherweise eine SIP-Nachricht – an die Adresse des Applikationsservers gesendet. Diese Nachricht wird in der Regel aus einem so genannten Kopfteil und aus einem so genannten Body gebildet, wobei im Kopfteil keine Nutzdaten, sondern diverse Verwaltungsdaten wie z.B. Absenderadresse, Empfängeradresse, etc. übertragen werden und im Body die eigentlichen Nutzdaten enthalten sind.
  • Ein Dienst kann allerdings auch aus mehreren Anwendungen zusammengesetzt sein, welche von verschiedenen Applikationsservern bereitgestellt werden. In einem solchen Fall müssen die für den Dienst notwendigen Applikationsserver in einer vorgegebenen Reihenfolge aufgerufen und von den Nachrichten durchlaufen werden. Hierzu ist im IP Multimedia Subsystem üblicherweise für jeden Dienstbenutzer eine Liste gespeichert, in welcher die für die Dienste notwendigen Applikationsserver gemeinsam mit entsprechenden Aufruf kriterien – so genannten Filter-Ausdrücken – geordnet hinterlegt sind. Durch diese Filter-Ausdrücke, die für jeden Applikationsserver-Aufruf von der Call Session Control-Funktion ausgewertet werden, wird neben der Reihenfolge der Applikationsserver-Aufrufe auch festgelegt, ob ein Applikationsserver aufgerufen wird oder nicht.
  • Die Applikationsserver, auf denen Anwendungen und Daten der Dienste gespeichert sind, können entweder innerhalb des Telekommunikationsnetzes des Betreibers, von dem auch das IP Multimedia System betrieben wird, oder in einem anderen – so genannten externen Telekommunikationsnetz installiert sein. In Abhängigkeit von den bereitgestellten Diensten und Anwendungen können die Applikationsserver von den Betreibern in unterschiedlichen Betriebsarten – wie z.B. als Proxy-Applikationsserver oder als Back-to-Back-User-Agent-Applikationsserver – betrieben werden.
  • Als Proxy-Applikationsserver wird ein Applikationsserver dann bezeichnet, wenn von diesem Applikationsserver im Datenverkehr zwischen Rechnern von Telekommunikationsnetzen vermittelt wird. Ein Proxy-Server ist ein Server (d.h. eine Einrichtung, von der zentral für die Rechner mehrerer Benutzer, den so genannten Clients, z.B. Dienste, Anwendungen oder Daten angeboten werden), von dem eingehende Nachrichten im Wesentlichen unverändert weiterleitet.
  • Bei einem Aufruf eines Proxy-Applikationsservers durch die Call Session Control-Funktion des IP Multimedia Subsystems wird daher die empfangene Nachricht vom Proxy-Applikationsserver gegebenenfalls bearbeitet und dann die im Wesentlichen unveränderte Nachricht wieder an die Call Session Control-Funktion bzw. an den Vermittlungsrechner, von dem sie ausgeführt wird, zurückgesendet. Auf diese zurückgesendete Nachricht können dann im IP Multimedia Subsystem die Filter-Ausdrücke angewendet und die Nachricht an einen weiteren Applikationsserver weitergesendet werden, so dass mehrere Anwendungen für einen Dienst von mehreren unabhängigen Applikationsserver zur Verfügung gestellt werden können.
  • Als Back-to-Back-User-Agent-Applikationsserver werden logische Einheiten bezeichnet, welche als so genannte User-Agent-Server Nachrichten vom IP Multimedia Subsystem empfangen und verarbeiten.
  • Im Gegensatz zum Proxy-Applikationsserver, der eine vom IP Multimedia Subsystem empfangene Nachricht in bearbeiteter oder unveränderter Form zurückschickt, wird vom Back-to-Back-User Agent Applikationsserver die empfangene Nachricht beantwortet. Für die Call Session Control-Funktion des IP Multimedia Subsystems bedeutet der Empfang einer derartigen Antwortnachricht nun, dass die Verarbeitung der gesendeten Nachricht abgeschlossen ist, und keine weiteren Applikationsserver mehr aufgerufen werden.
  • Vom Back-to-Back-User-Agent-Applikationsserver wird aber in seiner Rolle als User-Agent-Client eine (technisch gesehen) neue Nachricht erzeugt, die anstelle der ursprünglich empfangenen Nachricht weitergeleitet wird. In den Kopfteil wird vom Back-to-Back-User-Agent-Applikationsserver eine Identifikation z.B sein Name eingetragen.
  • Die Weise, wie eine Nachricht von einem Applikationsserver bearbeitet wird, ist damit von der Betriebsart des Applikationsservers abhängig. Daher werden auch die Aufrufe der Applikationsserver durch das IP Multimedia Subsystem während der Nutzung eines Dienstes von der Betriebsart des Applikationsserver beeinflusst. Umfasst ein Dienst mehrere Anwendungen, die von mehreren Applikationsserver bereitgestellt werden, so werden die Applikationsserver entsprechend der in der am IP Multimedia Subsystem gespeicherten Liste aufgerufen und von Nachrichten durchlaufen. Wird allerdings einer der Applikationsserver in der von Nachrichten zu durchlaufenden Kette von Applikationsservern als Back-to-Back User Agent- Applikationsserver betrieben, so wird der Durchlauf von Nachrichten unterbrochen. Denn vom Back-to-Back User-Agent-Appkationsserver wird die vom IP Multimedia Subsystem gesendete Nachricht beantwortet, wodurch für das IP Multimedia Subsystem die Kette an Aufrufen von Applikationsservern abgeschlossen ist.
  • Daraus ergeben sich für den Betreiber des IP Multimedia Subsystems beim Einrichten von Diensten, die Anwendungen auf mehreren Applikationsservern umfassen, große Einschränkungen. Es darf nur maximal ein Applikationsserver in der Kette an Aufrufen für den Dienst als Back-to-Back User Agent-Applikationsserver betrieben werden. Außerdem muss dieser Applikationsserver noch dazu als letzter Applikationsserver in der Kette für den Dienst vom IP Multimedia Subsystem aufgerufen werden. Da aber die Applikationsserver oft von anderen Betreibern als dem Betreiber des IP Multimedia Subsystems zur Verfügung gestellt werden, hat der letztere meist nur geringen Einfluss auf die Betriebsart der Applikationsserver.
  • Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren anzugeben, durch dass es ermöglicht wird, für in einem Telekommunikationsnetz zur Verfügung gestellte Dienste, die Anwendungen von mehreren Applikationsservern umfassen und wobei die Applikationsserver in einer bestimmten Reihenfolge von einem IP Multimedia Subsystem aufgerufen werden müssen, Applikationsserver mit unterschiedlicher Betriebsart ohne zusätzliche Einschränkungen zu verwenden.
  • Die Lösung dieser Aufgabe erfolgt erfindungsgemäß durch ein Verfahren zum Aufruf komplexer Dienste eines Telekommunikationsnetzes durch ein IP Multimedia Subsystem, bei dem jeder Dienst Anwendungen von Applikationsservern mit unterschiedlicher Betriebsart umfasst, welche für den Aufruf des Dienstes in einer bestimmten Reihenfolge durchlaufen werden müssen, und wobei vom Applikationsserver Nachrichten entsprechend der jeweiligen Betriebsart bearbeitet werden, wobei eine von einem Applikationsserver an das IP Multimedia Subsystem gesendete Antwortnachricht entsprechend am IP Multimedia Subsystem gespeicherter Aufrufkriterien ausgewertet wird, dann anhand eines Kopfteil der Antwortnachricht vom IP Multimedia Subsystem die Betriebsart des Applikationsservers, von dem die Antwortnachricht gesendet worden ist, erkannt wird, und dann entsprechend dieser Betriebsart Aufrufe weiterer Applikationsserver gesteuert werden.
  • Die mit dem erfindungsgemäßen Verfahren erzielbaren Vorteile bestehen insbesondere darin, dass für Dienste Applikationsserver mit unterschiedlicher Betriebsart ohne Einschränkung zum Hinterlegen von Anwendungen oder Daten genutzt werden können. Außerdem sind keine Einschränkungen bezüglich der Positionen der Applikationsserver mit unterschiedlicher Betriebsart notwendig. Dies insbesondere deswegen, weil die Kette an Aufrufen durch das IP Multimedia Subsystem, welche für die Ausführung eines Dienstes notwendig ist, aufgrund des erfindungsgemäßen Verfahrens nicht unterbrochen wird, da vom IP Multimedia Subsystem anhand des Kopfteils der Antwortnachricht des Applikationsservers erkannt wird, wie die weiteren Aufrufe von Applikationsservern zu steuern sind.
  • Es ist günstig, wenn die durch das IP Multimedia Subsystem aufgerufenen Applikationsserver nach dem Prinzip eines Proxy-Servers betrieben werden, da von einem Proxy-Applikationsserver die vom IP Multimedia Subsystem gesendeten Nachrichten üblicherweise im Wesentlichen unverändert bzw. nur in leicht bearbeiteter Form zurückgesendet werden.
  • Es ist vorteilhaft, wenn die durch das IP Multimedia Subsystem aufgerufenen Applikationsserver nach dem Prinzip eines Back-to-Back User Agent-Applikationsserver betrieben werden, weil eine von einem Applikationsservers nach dem Back-to-Back User Agent-Prinzip gesendete Nachricht leicht vom IP Multimedia Subsystem erkannt werden kann, da von einem Back-to-Back User Agent-Applikationsserver beispielsweise sein Name in den Kopfteil der gesendeten Nachricht eingetragen wird.
  • Es empfiehlt sich, Adressen für die Applikationsserver zusammen mit den entsprechenden Aufrufkriterien benutzerspezifisch in geordneten Listen am IP Multimedia Subsystem zu hinterlegen, wobei dieser Aufrufkriterien gesteuert werden kann, welcher Applikationsserver aufgerufen werden soll. Durch diese Listen können damit die Reihenfolge der Aufrufe der Applikationsserver für die Dienste festgelegt und die zugehörigen Aufrufkriterien bzw. Filterausdrücke für die Applikationsserver definiert werden. Außerdem können durch benutzerspezifische Zuordnung die Listen auf einfache Weise mit den Daten des Benutzers wie z.B. Berechtigungen administriert werden.
  • Es ist zweckmäßig, wenn für das Versenden der Nachrichten zwischen dem IP Multimedia Subsystem und den Applikationsservern das Session Initiation Protocol SIP, welches auf dem Internet Protocol IP basiert, eingesetzt wird, da SIP ein von der Internet Engineering Task Force IETF mit Blick auf das Internet spezifiziertes Netzprotokoll für den Aufbau von Kommunikationsverbindungen ist, welche zur Übertragung von Sprache in paketorientierten Telekommunikationsnetzen wie z.B. bei der IP-Telefonie verwendet werden kann.
  • Die Erfindung wird nachfolgend in beispielhafter Weise unter Bezugnahme auf die beigefügten Figuren näher erläutert. Es zeigen:
  • 1 den Ablauf eines Aufrufs eines komplexen Dienstes durch ein IP Multimedia Subsystem, bei dem der Dienst Anwendungen von mehreren Applikationsservern mit unterschiedlicher Betriebsart umfasst
  • 2 den schematischen Aufbau einer beispielhaften, auf dem IP Multimedia Subsystem gespeicherten Liste mit Aufrufkriterien für mehrerer Applikationsserver mit unterschiedlicher Betriebsart
  • In 1 sind erster, zweiter, dritter, vierter und fünfter Applikationsserver AP1, AP2, AP3, AP4, AP5, dargestellt, welche für den Ablauf eines komplexen Dienstes benötigt werden, da Anwendungen für diesen Dienst auf den Applikationsservern AP1, AP2, AP3, AP4, AP5 hinterlegt sind. Von diesen Applikationsservern AP1, AP2, AP3, AP4, AP5 wird der erste, dritte und fünfte Applikationsserver AP1, AP3 und AP5 als Proxy-Applikationsserver betrieben. Daher werden vom ersten, dritten und fünften Applikationsservern AP1, AP3 und AP5 entsprechend der Betriebsart eines Proxy-Applikationsservers empfangene Nachrichten in gegebenenfalls bearbeiteter Form weitergeleitet.
  • Beim zweiten und vierten Applikationsserver AP2 und AP4 wird die Betriebsart eines Back-to-Back User Agent-Applikationsservers eingesetzt. Entsprechend der Betriebsart als Back-to-Back User Agent-Applikationsserver wird vom zweiten und vierten Applikationsserver AP2 und AP4 eine empfangene Nachricht beantwortet und sodann eine neue Nachricht generiert und weitergeleitet, wobei in den Kopfteil neuen Nachricht Daten zur Identifizierung wie z.B. ein Name des Back-to-Back User Agent-Applikationsservers eingetragen werden, die als zweiter und vierter Identifier ID2, ID4 für Filter-Ausdrücke genutzt werden können.
  • In 1 ist weiters ein IP Multimedia Subsystem IMS dargestellt, das eine Vermittlungsrechner CSCF und eine benutzerspezifische Liste LS für den Aufruf eines Dienstes umfasst. Weitere Komponenten des IP Multimedia Subsystem IMS, welche für die beispielhaft erläuterten Abläufe unerheblich sind, sind aus Gründen einer einfacheren Darstellung in 1 nicht eingetragen.
  • Vom Vermittlungsrechner CSCF wird die Call Session Control-Funktion durchgeführt, die für Aufbau, Steuerung und Kontrolle einer multimedialen Verbindung bei Nutzung eines Dienstes durch einen Benutzer verantwortlich ist. Durch die Call Session Control-Funktion des Vermittlungsrechners CSCF werden ebenfalls der für eine Ausführung des Dienstes notwendige erste, zweite, dritte, vierte und fünfte Applikationsserver AP1, AP2, AP3, AP4, AP5 aufgerufen. Zur Durchführung der Verbindungssteuerung und -kontrolle sowie für den Zugriff auf diese Applikationsserver AP1, AP2, AP3, AP4, AP5 wird vom Vermittlungsrechner CSCF als Protokoll das Session Initiation Protocol SIP verwendet.
  • Von der auf dem IP Multimedia Subsystem benutzerspezifisch gespeicherten Liste LS wird die Reihenfolge für die Aufrufe der Applikationsserver AP1, AP2, AP3, AP4, AP5 festgelegt, wobei für jeden Applikationsserver AP1, AP2, AP3, AP4, AP5 zusätzlich entsprechende Aufrufkriterien in der Liste LS abgelegt sind.
  • In 2 ist der Aufbau der Liste LS in beispielhafter Weise schematisch dargestellt. Die Liste LS umfasst in einer ersten Spalte RF die Reihenfolge für die Aufrufe der Applikationsserver AP1, AP2, AP3, AP4, AP5 für die Ausführung des Dienstes. Durch eine zweite Spalte FD werden dann jedem Applikationsserver AP1, AP2, AP3, AP4, AP5 die entsprechenden Filter-Ausdrücke für den Aufruf durch den Vermittlungsrechner CSCF des IP Multimedia Subsystems IMS zugeordnet. So wird beispielsweise dem ersten Applikationsserver AP1 ein Filter-Ausdruck zugewiesen, von dem festgelegt wird, dass der erste Applikationsserver AP1 nur aufgerufen wird, wenn in Kopfteil einer Nachricht kein zweiter und kein vierter Identifier ID2, ID4 eines zweiten bzw. eines vierten Applikationsservers AP2, AP4, die als Back-to-Back User Agent-Applikationsserver betrieben werden, enthalten ist, und ein erstes Aufrufkriterium AK1 für den ersten Applikationsserver erfüllt wird.
  • Wird nun von einem Benutzer ein komplexer Dienst, dessen Anwendungen auf mehreren Applikationsservern AP1, AP2, AP3, AP4, AP5 hinterlegt sind, mittels des IP Multimedia Subsystem aufgerufen, so wird in einem ersten Schritt 1 eine SIP-Nachricht zum Vermittlungsrechner CSCF des IP Multimedia Subsystems IMS gesendet. In einem zweiten Schritt 2 wird vom Vermittlungsrechner CSCF der Kopfteil der SIP-Nachricht analysiert und die in der Liste LS gespeicherten Filter-Ausdrücke abgefragt. Trifft nun der Filter-Ausdruck für den Aufruf des ersten Applikationsservers AP1 zu, da kein zweiter und kein vierter Identifier ID2, ID4, die dem zweiten bzw. vierten Applikationsserver AP2, AP4 zugeordnet sind, im Kopfteil der Nachricht vorhanden und das erste Aufrufkriterium AK1 erfüllt ist, so wird in einem dritten Schritt 3 der erste Applikationsserver AP1 vom Vermittlungsrechner CSCF aufgerufen und die SIP-Nachricht dorthin weitergeleitet. In einem vierten Schritt 4 wird die SIP-Nachricht vom ersten Applikationsserver AP1 entsprechend seiner Betriebsweise als Proxy-Applikationsserver in unveränderter oder gegebenenfalls bearbeiteter Form an den Vermittlungsrechner CSCF zurückgesendet.
  • In einem fünften Schritt 5 wird vom Vermittlungsrechner CSCF wieder der Kopfteil der SIP-Nachricht ausgewertet und die in der Liste LS gespeicherten Filter-Ausdrücke abgefragt. Da kein zweiter und vierter Identifier ID2, ID4 für den zweiten bzw. den vierten Applikationsserver AP2, AP4 im Kopfteil der Nachricht vorhanden sind und ein zweites Aufrufkriterium AK2 zutrifft, wird in einem sechsten Schritt 6 der zweite Applikationsserver AP2 vom Vermittlungsrechner CSCF mittels der SIP-Nachricht aufgerufen. Da der zweite Applikationsserver AP2 als Back-to-Back User Agent-Applikationsserver ausgeführt ist, wird von ihm für die SIP-Nachricht eine entsprechende, neue SIP-Nachricht erstellt, in deren Kopfteil vom zweiten Applikationsserver AP2 der zweite, diesem zugeordnete Identifier ID2 eingetragen wird. Diese neue SIP-Nachricht wird dann in einem siebenten Schritt 7 vom zweiten Applikationsserver AP2 an den Vermittlungsrechner CSCF gesendet.
  • In einem achten Schritt 8 wird vom Vermittlungsrechner CSCF der Kopfteil der neuen SIP-Nachricht ausgewertet und die in der Liste LS gespeicherten Filter-Ausdrücke abgefragt. Dabei wird vom Vermittlungsrechner CSCF erkannt, dass im Kopfteil der neuen SIP-Nachricht der zweite Identifier ID2 eingetragen ist, wodurch nur mehr der Filter-Ausdruck für den Aufruf eines dritten Applikationsservers AP3, in dem kein vierter Identifier ID4 und ein drittes Aufrufkriterium AK3 eingetragen ist, zutreffen kann. Daher wird in einem neunten Schritt 9 der dritte Applikationsserver AP3, der als Proxy-Applikationsserver betrieben wird, aufgerufen. In einem zehnten Schritt 10 wird analog zum vierten Schritt 4 die vom Vermittlungsrechner CSCF gesendete SIP-Nachricht in gegebenenfalls bearbeiteter Form an den Vermittlungsrechner CSCF zurückgesendet.
  • Im einem elfen Schritt 11 wird vom Vermittlungsrechner CSCF wieder die Liste LS abgefragt und der Kopfteil der SIP-Nachricht untersucht. Da im Kopfteil immer noch der zweite, dem zweiten Applikationsserver AP2 zugeordnete Identifier ID2, aber kein vierter Identifier ID4 vorhanden ist, wird der Filter-Ausdruck für den Aufruf des vierten Applikationsservers AP4 als zutreffend erkannt, sofern auch ein viertes Aufrufkriterium AK4 erfüllt ist. Daher wird in einem zwölften Schritt 12 der vierte Applikationsserver AP4, der als Back-to-Back User Agent-Applikationsserver ausgeführt ist, vom Vermittlungsrechner CSCF mittels der SIP-Nachricht aufgerufen. Vom vierten Applikationsserver AP4 wird dann entsprechend seiner Betriebsart als Back-to-Back User Agent-Applikationsserver die SIP-Nachricht mit einer entsprechenden, neuen SIP-Nachricht beantwortet, wobei in den Kopfteil der neuen SIP-Nachricht der vierte, dem vierten Applikationsserver AP4 zugeordnete Identifier ID4 eingetragen ist. In einem dreizehnten Schritt 13 wird diese neue SIP-Nachricht vom vierten Applikationsserver AP4 an den Vermittlungsrechner CSCF übertragen.
  • In einem vierzehnten Schritt 14 wird vom Vermittlungsrechner CSCF der Kopfteil der neuen SIP-Nachricht analog dem achten Schritt 8 ausgewertet und die in der Liste LS gespeicherten Filter-Ausdrücke abgefragt. Dabei wird vom Vermittlungsrechner CSCF erkannt, dass im Kopfteil der neuen SIP-Nachricht der vierte Identifier ID4 eingetragen ist, wodurch nur mehr der Filter-Ausdruck für den Aufruf eines fünften Applikationsservers AP5, in dem ein fünftes Aufrufkriterium AK5 eingetragen ist, zutreffen kann. Daher wird in einem fünfzehnten Schritt 15 der fünfte Applikationsserver AP5, der als Proxy-Applikationsserver betrieben wird, aufgerufen. In einem sechzehnten Schritt 16 wird wieder analog zum vierten Schritt 4 bzw. zum siebenten Schritt 7 die vom Vermittlungsrechner CSCF gesendete SIP-Nachricht in gegebenenfalls bearbeiteter Form an den Vermittlungsrechner CSCF zurückgesendet. In einem siebzehnten Schritt 17 wird vom Vermittlungsrechner CSCF festgestellt, dass alle für den Dienst notwendigen Applikationsserver AP1, AP2, AP3, AP4, AP5 durchlaufen worden sind und die SIP-Nachricht an beispielsweise einen Benutzerrechner weitergeleitet.
  • Im IP Multimedia Subsystem IMS muss noch zusätzlich zwischen Diensten für die Seite des anrufenden Benutzers – der so genannte originating Seite – und Diensten für die Seite des angerufenen Benutzers – der so genannten terminating Seite – unterschieden werden. Denn es ist für den Ablauf des erfindungsgemäßen Verfahrens für Dienste, die auf der originating Seite ausgeführt werden, erforderlich, dass vom zweiten bzw. vierten Applikationsserver AP2, AP4 mit Betriebsart als Back-to-Back User Agent-Applikationsserver auf der originating Seite explizit angefordert wird, dass auch Dienste auf dieser Seite ausgeführt werden sollen. Entsprechend der technischen Spezifikation 3GPP TS 24.229 V6.6.0 Kapitel 5.7.3 der 3GPP wird dies vom zweiten bzw. vierten Applikationsserver AP2, AP4 durch Versorgen des Teils P-Asserted Identity im Kopfteil der SIP-Nachricht und durch Setzen eines Parameters für den Ursprung im Route-Kopfteil der SIP-Nachricht erreicht.

Claims (5)

  1. Verfahren zum Aufruf komplexer Dienste eines Telekommunikationsnetzes durch ein IP Multimedia Subsystem (IMS), bei dem jeder Dienst Anwendungen von Applikationsserver (AP1, AP2, AP3, AP4, AP5) mit unterschiedlicher Betriebsart umfasst, welche für den Aufruf des Dienstes in einer bestimmten Reihenfolge (RF) durchlaufen werden müssen, und wobei von Applikationsserver (AP1, AP2, AP3, AP4, AP5) Nachrichten entsprechend der jeweiligen Betriebsart bearbeitet werden, dadurch gekennzeichnet, dass eine von einem Applikationsserver (AP1, AP2, AP3, AP4, AP5) an das IP Multimedia Subsystem (IMS) gesendete Nachricht entsprechend am IP Multimedia Subsystem (IMS) gespeicherter Aufrufkriterien (LS) ausgewertet wird, dass anhand eines Kopfteil der gesendeten Nachricht vom IP Multimedia Subsystem (IMS) die Betriebsart des Applikationsservers (AP1, AP2, AP3, AP4, AP5), von dem die Nachricht gesendet worden ist, erkannt wird, und dass entsprechend dieser Betriebsart Aufrufe weiterer Applikationsserver (AP1, AP2, AP3, AP4, AP5) gesteuert werden.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die durch das IP Multimedia Subsystem (IMS) aufgerufenen Applikationsserver (AP1, AP2, AP3, AP4, AP5) nach dem Prinzip eines Proxy-Servers betrieben werden.
  3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die durch das IP Multimedia Subsystem (IMS) aufgerufenen Applikationsserver (AP1, AP2, AP3, AP4, AP5) nach dem Prinzip eines Back-to-Back User Agent-Applikationsserver betrieben werden.
  4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass Adressen für die Applikationsserver (AP1, AP2, AP3, AP4, AP5) zusammen mit den entsprechenden Aufrufkriterien (AK1, AK2, AK3, AK4, AK5) benutzerspezifisch in geordneten Listen (LS) am IP Multimedia Subsystem (IMS) hinterlegt sind, und dass mittels dieser Aufrufkriterien gesteuert werden kann, welcher Applikationsserver aufgerufen werden soll.
  5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass für das Versenden der Nachrichten zwischen dem IP Multimedia Subsystem (IMS) und den Applikationsservern (AP1, AP2, AP3, AP4, AP5) das Session Initiation Protocol SIP, welches auf dem Internet Protocol IP basiert, eingesetzt wird.
DE200510046171 2005-09-27 2005-09-27 Verfahren zum Aufrufen von Applikationsservern mit unterschiedlicher Betriebsart durch ein IP Multimedia Subsystem Withdrawn DE102005046171A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE200510046171 DE102005046171A1 (de) 2005-09-27 2005-09-27 Verfahren zum Aufrufen von Applikationsservern mit unterschiedlicher Betriebsart durch ein IP Multimedia Subsystem
PCT/EP2006/065495 WO2007036398A1 (de) 2005-09-27 2006-08-21 Verfahren zum aufrufen von applikationsservern mit unterschiedlicher betriebsart durch ein ip multimedia subsystem

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE200510046171 DE102005046171A1 (de) 2005-09-27 2005-09-27 Verfahren zum Aufrufen von Applikationsservern mit unterschiedlicher Betriebsart durch ein IP Multimedia Subsystem

Publications (1)

Publication Number Publication Date
DE102005046171A1 true DE102005046171A1 (de) 2007-04-05

Family

ID=37633610

Family Applications (1)

Application Number Title Priority Date Filing Date
DE200510046171 Withdrawn DE102005046171A1 (de) 2005-09-27 2005-09-27 Verfahren zum Aufrufen von Applikationsservern mit unterschiedlicher Betriebsart durch ein IP Multimedia Subsystem

Country Status (2)

Country Link
DE (1) DE102005046171A1 (de)
WO (1) WO2007036398A1 (de)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003058913A1 (en) * 2002-01-10 2003-07-17 Nokia Corporation Method and system for proxying a message
DE602004017998D1 (de) * 2003-07-02 2009-01-08 Nokia Corp Funktionsmodus-routing

Also Published As

Publication number Publication date
WO2007036398A1 (de) 2007-04-05

Similar Documents

Publication Publication Date Title
DE60132387T2 (de) Richtlinien-Koordination in einem Kommunikationsnetz
DE60303004T2 (de) Kommunikationsknoten-architektur
DE10353925B4 (de) Verfahren zum Austausch von Daten zwischen zwei Hosts
EP2057832A1 (de) Verfahren zum anbieten eines call center-dienstes in einem peer-to-peer netzwerk
DE102004026785B4 (de) Kommunikationssystem, Kommunikationsendgerät, Konferenzsteuereinheit, Verfahren zum Steuern eines Kommunikationssystems, Verfahren zum Steuern eines Kommunikationsendgeräts und Verfahren zum Steuern einer Konferenzsteuereinheit
DE60304100T2 (de) Erzwingung eines Zeitpunktes zur Trennung einer Kommmunikationsverbindung mit schnurlosen Endgeräten mit transienten Netzwerkadressen
EP1761081A1 (de) Kommunikationssystem, Vermittlungsknoten-Rechner und Verfahren zur Bestimmung eines Kontrollknotens
DE10348207A1 (de) Behandlung von Early Media-Daten II
DE102006001503A1 (de) Verfahren und System zum Übermitteln von Zusatzdaten und Kommunikationsendgerät
DE102005043239B4 (de) Verfahren zum Aufbau und Verwalten einer Verbindung
EP2875626B1 (de) Verfahren und anordnung zum aufbau einer telekommunikationsverbindung
EP1282280A1 (de) Verfahren, Steuereinrichtung und Programmmodul zur Steuerung und Lenkung von Datenströmen einer Kommunikationsverbindung zwischen Teilnehmern eines Paketdatennetzes
WO2003032156A2 (de) Verfahren zum aktuellhalten von software auf verschiedenen endgeräten
DE102004030290A1 (de) Aufbau einer Verbindung für den Austausch von Daten eines IP-basierten Dienstes
EP1771993B1 (de) Verfahren zur überwachung eines nachrichtenverkehrs, sowie eine erste und zweite netzwerkeinheit zu dessen durchführung
DE102005046171A1 (de) Verfahren zum Aufrufen von Applikationsservern mit unterschiedlicher Betriebsart durch ein IP Multimedia Subsystem
DE102005043040B4 (de) Verfahren zum gezielten Blockieren von Diensten in einem IP Multimedia Subsystem
EP1777980A1 (de) Austausch von Informationen in einem Kommunikationssystem
WO2004102921A1 (de) Verfahren zum aufbau einer kommunikationsverbindung und kommunikationssystem
EP3959850B1 (de) Verfahren zum bereitstellen von verbindungsherstellungsdaten sowie anordnung mit einer mehrzahl von kommunikationsservern und einem vermittler
WO2006034948A1 (de) Nutzung von presence-informationen (statusinformationen) zur erweiterung einer bestehenden kommunikationsverbindung
DE102005052263A1 (de) Verfahren zur dynamischen Zuteilung eines Zugangsnetzes innerhalb eines mobilen Kommunikationssystems
EP1833192B1 (de) Verfahren zur Übergabe des Zugriffs auf eine serverbasierte Anwendungssitzung an ein Kommunikationsendgerät
DE102006043233B4 (de) Verfahren zum Anbieten von Centrex-Leistungsmerkmalen in einem Peer-to-Peer-Netzwerk
WO2008022613A2 (de) Verfahren zum erzeugen einer kommunikationssitzung - steuernachricht unter verwendung von sip

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8127 New person/name/address of the applicant

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO.KG, 81541 MUE, DE

8139 Disposal/non-payment of the annual fee