SIP-basierte Dienstentwicklung für das IMS CN (UMTS Release 5)

SIP-basierte Dienstentwicklung für das IMS CN (UMTS Release 5) Axel Jusek, Fachhochschule Braunschweig/Wolfenbüttel, Wolfenbüttel Martin Hans, Comneon GmbH & Co. OHG, Salzgitter Frank Kowalewski, Comneon GmbH & Co. OHG, Salzgitter Diederich Wermser, Fachhochschule Braunschweig/Wolfenbüttel, Wolfenbüttel Einführung Nicht erst seit der Versteigerung der UMTS - Lizenzen stellt sich die Frage ob und wie sich der Aufbau eines weiteren Mobilfunknetzes rechtfertigen lässt. Für die Netzbetreiber stellt sich die Frage nach der Wirtschaftlichkeit und für die Regulierungsbehörde die Frage nach der Sinnhaltigkeit der Frequenzvergabe. Für beide lautet die Antwort: Mehrwertdienste. Tatsächlich wird sich ein neues Mobilfunknetz nicht mehr nur mit Sprachübertragung finanzieren lassen, sondern benötigt für einen wirtschaftlichen Betrieb eine Reihe zusätzlicher Dienste. Damit Dienste für den Endkunden attraktiv werden, müssen sie verschiedene Medien unterstützen bzw. den Zugriff darauf ermöglichen. Für den Verbraucher wird das Versprechen der Netzanbieter Information anywhere, anytime erst dann eingelöst sein, wenn die Information auch in jeder beliebigen Form abgerufen werden kann, also auch als Grafik, Musikstück, Animation, Videosequenz, etc.. Um diesem Ziel gerecht zu werden, müssen die Mobilfunknetze multimediafähig sein. Dieses wird durch die Einführung des IP based Multimedia Subsystem Core Network (IMS CN), welches auf dem Session Initiation Protocol (SIP) basiert, erreicht. Für die Wirtschaftlichkeit eines Dienstes ist auch die Entwicklungszeit und der Entwicklungsaufwand von Bedeutung. Dienste werden kurzfristig (Event driven) vom Kunden bestellt und sollen möglichst sofort verfügbar sein. Dies lässt sich nur durch die Verwendung von geeigneten Dienstentwicklungsumgebungen realisieren. Das Vorstellen eines Baukastens für den Entwurf der Dienste ist Gegenstand dieser Veröffentlichung. SIP Das Session Initiation Protocol (SIP) wurde von der Internet Engineering Task Force (IETF) [13] definiert und ist ein Ende-zu-Ende Signalisierungsprotokoll für den Verbindungsaufbau, die Änderung von Verbindungsparametern und den Abbau von Verbindungen [4,6,16,17]. SIP setzt auf dem UDP bzw. TCP - Protokoll auf und gehört zur Applikation Layer. Das Schichtenmodell ist in Abbildung 5 dargestellt. Das SIP ermöglicht aufgrund seiner positionsunabhängigen Adressierung und der Fähigkeit Verbindungen auszuhandeln, die einfache und effiziente Nutzung verschiedenster Multimedia-Dienste. SIP dient nicht dem Transport von Daten sondern ist ausschließlich für die Signalisierung konzipiert. Damit wird, wie im traditionellen Intelligenten Netz, eine Trennung des Transportweges von Nutzdaten und Signalisierungsinformationen ermöglicht. Zum Transport von Multimediadaten werden Protokolle wie das RealTime Protocol (RTP) und das RealTime Streaming Protocol (RTSP) eingesetzt. Zur Beschreibung der Verbindungen und zum Aushandeln der Transportprotokolle und Medienkodierung wird das Session Description Protocol (SDP [10]) verwendet. Das SDP wird in den SIP-Nachrichten transportiert. 1/12

Das IMS CN des UMTS Release 5 Das Kernnetz des UMTS in Release 99 und 4 besteht aus einer Circuit Switched Domain (CS), zur Vermittlung von Telefongesprächen und einer Packet Switched Domain (PS), die zur Übertragung von Datendiensten genutzt wird. GSM BSS IMS-Domain PS-Domain PDN UMTS RNS Home Domain CS-Domain Core Network PSTN Abbildung 1: Domain in UMTS Release 5 Weder die CS- noch die PS-Domain stellen Multimedia-spezifische Dienste zur Verfügung. Dieser Umstand führte zur Entwicklung des IP Multimedia Core Network Subsystems (IMS), das mit UMTS Release 5 eingeführt wird. Das IMS bildet innerhalb des UMTS Core Networks eine eigene Domain und basiert auf IPv6 und SIP. Die Ausrichtung auf Multimedia-Dienste und die Verwendung des Internetprotokolls machen die Speicherung von Verbindungszuständen notwendig, unter anderem weil ohne diese Maßnahme keine Dienstgüteparameter garantiert werden können. Die Call State Control Functions (CSCF) übernehmen diese Aufgabe und werden in Proxy-CSCF (P-CSCF), Interrogating-CSCF (I-CSCF) und Serving-CSCF (S-CSCF) unterschieden. Die Aufgaben des P-CSCF sind entsprechend [1]: Weiterleiten der SIP-REGISTER-Anfrage vom UA zum I-CSCF. Weiterleiten der SIP-Nachrichten zu demjenigen S-CSCF, der als Ergebnis der Registrierung als zuständig benannt wurde. Weiterleiten von SIP-Anfragen und Antworten an den UA. Entsprechend [1] sind die Aufgaben des I-CSCF die folgenden: Zuweisung eines S-CSCF bei der SIP-Registrierung. Weiterleiten von SIP-Anfrage aus einem anderen Netzwerk zum S-CSCF. Vom Home Subscriber Server (HSS) die Adresse des zuständigen S-CSCF abfragen. SIP-Anfragen oder Antworten entsprechend der Antwort des HSS an den jeweiligen S-CSCF weiterleiten. In [1] sind die Aufgaben des S-CSCF festgelegt: Entgegennehmen und verarbeiten von Register-Nachrichten. Sitzungskontrolle für registrierte Benutzer. Kann sich auch wie ein P-CSCF verhalten. Ist in der Lage SIP-Verbindungen eigenständig entgegenzunehmen oder aufzubauen. Interaktion mit Dienstplattformen zur Unterstützung der Dienste. Versorgt die Endgeräte mit ereignisbasierten Informationen. 2/12

HSS AS UA P-CSCF I-CSCF S-CSCF Abbildung 2: IMS Kernfunktionen Der Home Subscriber Server (HSS) ist vergleichbar dem HLR im GSM-Netz. Im HSS ist darüber hinaus die aktuelle IP-Adresse des Endgerätes (User Agent UA) gespeichert und es werden dort alle Informationen abgelegt, die einen Nutzer und seine Berechtigungen betreffen, z.b. von welchen anderen Nutzern die Presence-Information gelesen werden darf. Die Presence-Information, die Information darüber ob ein Nutzer zur Zeit kommunikationswillig ist oder nicht und auf welchem Wege er erreichbar ist, ist ebenfalls im HSS abgelegt. Das HSS enthält auch die Information welcher S-CSCF oder I-CSCF für eine Verbindungsaufnahme kontaktiert werden muss, bzw. kann diese Information von anderen HSS erfragen. Die Ausführung von serverbasierten Diensten geschieht auf dem Applikation Server (AS). Der AS ist in der Lage wie ein UA SIP-Verbindungen entgegenzunehmen und aufzubauen. Auf dem AS können alle bekannten Telekommunikationsdienste wie Konferenzen, Kurznachrichtendienst, Presence, Nachrichtendienst etc. realisiert werden. Dienstumgebung Für die Entwicklung und den Test der Dienste wird eine Nachbildung des IMS benötigt, welche hinreichend nahe am Original ist, so dass der Test der Dienste genaue Aussagen über den Einsatz in einem realen Kommunikationsnetz zulässt. Zu diesem Zweck muss die Testumgebung die folgenden Elemente des IMS nachbilden: P- CSCF, I-CSCF, S-CSCF, HSS, SIP-AS und UA. Diese sind in Abbildung 2 abgebildet und stellen die IMS Kernfunktionen und das Endgerät dar. Ein Bildschirmfoto des verwendeten Operations and Maintenance Servers des eingesetzten IMS Experimental Systems (IMS ES) ist Abbildung 8 mit den entsprechenden Elementen zu finden. Dienste Neben der klassischen Telephonie, für die die Mobilfunknetze ursprünglich erdacht wurden, sind heute zunehmend Mehrwertdienste wie Kurznachrichtendienste (Short Message Service SMS) und Informationsdienste (News) die Einnahmequelle der Netzbetreiber. Die Verbindung der Mobilfunknetze mit dem Internet ermöglicht eine neue Generation von Diensten, welche die Vorteile beider Kommunikationsnetze nutzen. Deutlich wird dies z.b. anhand der Evolution des SMS, von einem reinen textbasierten Dienst hat es sich über den Enhanced Message Service (mit eingeschränkter Multimedia Unterstützung) zum Multimedia Message Service (MMS) entwickelt, der heute die Übertragung von Text, Bildern, Tonaufzeichnungen und kleineren Videos erlaubt. Die Übertragung von Multimediainhalten 3/12

ist aber nur mit einem geeigneten Transportnetz sinnvoll, wie dies mit HSCSD bzw. GPRS (die 2,5te Generation der Mobilfunknetze) geschaffen wurde. Weitere Erwägungen, wie z.b. die Nutzung eines IP-basierten Backbone-Netzes, führten zum IMS. Das IMS erlaubt den Zugriff auf sämtliche im Internet befindliche Dienste von einem UMTS- oder GPRS-fähigen Mobilgerät. Der Schritt zum IP-Netz wird durch die Arbeiten verschiedener Organisationen, die im Internet Telephonie ermöglichen wollen, gefördert [12,15]. Durch die Wahl von SIP als Signalisierungsprotokoll im IMS wurde die Möglichkeit geschaffen, die Eigenschaften einer bestehenden Verbindung zu ändern. Herkömmliche Telekommunikationssysteme legen die Parameter während des Verbindungsaufbaus fest und müssen eine neue logische Verbindung erstellen, um alternative Parameter zu nutzen. SIP erlaubt nicht nur den flexiblen Auf- und Abbau von Telefon- bzw. Multimediakonferenzen, da zu jedem Zeitpunkt nicht nur weitere Teilnehmer hinzu genommen oder verabschiedet werden können, sondern auch den flexiblen Einsatz von Medien. Zur Zeit arbeiten mehrere Arbeitsgruppen des Third Generation Partnership Programms (3GPP) an der Weiterentwicklung des IMS und Gruppen der Internet Engineering Task Force (IETF) an der Weiterentwicklung des SIP. Dienstmodellierung Die Abbildung bzw. die Modellbildung des Dienstes lehnt sich üblicherweise an die Art der Ausführung des Dienstes an. Für alle Dienste, die mit einem vorgegebenen zeitlichen Ablauf ohne Wiederholungen bzw. Schleifen ausgeführt werden können (wie bisherige TK-Dienste), hat sich die Call Processing Language (CPL) als Darstellungsmittel bewährt [11]. Mit der Verwendung von SIP wird die Palette der Möglichkeiten jedoch drastisch erweitert, so dass die ablauforientierte Sicht auf Dienste nicht mehr genügt. Es wird vielmehr nach einer Betrachtungsweise gesucht, die auf Funktionalität und Ressourcennutzung ausgerichtet ist. PDN MRFP MGW Packet Data Subsystem MRFC BGCF MGCF PSTN/ PLMN Radio Access Network PDF CSCF OSA-SCS OSA-AS Home Subscriber Server SIP-AS Nutzdaten Abbildung 3: IMS Übersicht 4/12 Steuerung

Ansätze hierzu werden in [5] und in [19] vorgestellt. In Abbildung 3 ist die Übersicht des IMS dargestellt. Der SIP-AS ist direkt an den CSCF und den HSS angebunden und ermöglicht auf diese Weise sehr flexible Dienste. Anders als dargestellt, muss der SIP-AS nicht innerhalb des IMS eines einzelnen Providers liegen, sondern kann auch Provider unabhängig betrieben werden, da die gesamte Kommunikation des SIP-AS mit dem IMS ausschließlich über SIP abgewickelt wird. Wie in Abbildung 3 gezeigt, können auch OSA-AS angebunden werden. Die Parlay-API (3GPP verwendet den Ausdruck Open Service Architecture OSA) definiert einen Satz an Programmierschnittstellen mittels derer Anwendungsprogrammierer auf die Netzfunktionen zugreifen können. Für Internet-basierte Dienste hat Parlay die Parlay X Web Services Spezifikation [9] erstellt. Die Architektur ist in Abbildung 4 dargestellt. Parlay Web Services Gateway External Resources Parlay Web Service Logic Parlay Web Service Interface Application Resource Parlay/OSA Gateway Parlay X Application Logic Framework Logic Parlay X Application Interface Framework Interface Application Abbildung 4: Allgemeine Parlay-Dienste-Architektur Für die Realisierung von Anwendungen wurden im Parlay-API zwei Schnittstellen definiert: Eine Schnittstelle zur Realisierung von Basisfunktionen, wie Authentifizierung, und eine Schnittstelle zu den Netzdiensten, für die eigentlichen Mehrwertdienste [8]. Im IMS gibt es keine Einschränkung des Nutzdatenverkehrs, da nur die Signalisierung durch das Kernnetz erzwungen wird. Die Nutzdaten können Ende-zu-Ende über eine beliebige Verbindung transportiert werden. Darüber hinaus ist im SIP bereits der Einsatz von Erweiterungen des SIP geregelt (der Header darf um eigene Einträge erweitert werden), so dass auch hier anwendungsspezifische Erweiterungen eingesetzt werden können. Die Dienste werden sowohl in einer Parlay- als auch in einer SIP-Umgebung auf Servern betrieben. Damit nähert sich die Dienstverteilung, dem Modell des Internets an, dass ja auf dem klassischen Client-Server-Modell beruht. Neben den Netzen müssen für die Dienstmodelle auch die Geräte betrachtet werden, auf denen der jeweilige Dienst dargestellt wird. Die Palette der Endgeräte reicht dabei vom Mobiltelefon bis zum Laptop. Alle diese Geräte haben naturgemäß stark unterschiedliche Fähigkeiten hinsichtlich Kommunikation, Grafikdarstellung und Prozessorleistung, so dass für jede Zielgruppe von Endgeräten eine angepasste Nutzeroberfläche entworfen werden muss. Entsprechend muss auf dem AS eine Software existieren, die das Endgerät mit den für den jeweiligen Dienst notwendigen Daten versorgt und die Benutzereingaben bzw. Clientdaten entgegennimmt und verarbeitet. Das Kommunikationsnetz ist hierbei dumm, d.h. im Gegensatz zum Intelligenten Netz der zweiten Generation Mobilfunknetze wird durch die 5/12

Verwendung des Internet Protokolls (IP) die Intelligenz in die Endgeräte bzw. Server verlagert. Dies führt einerseits dazu, dass das Internet einfach angebunden und dort befindliche Ressourcen genutzt werden können, andererseits werden keine Verbindungsparameter (wie Laufzeit, Bandbreite, Fehlerfreiheit, Datensicherheit) garantiert. Unter diesen Voraussetzungen lassen sich alle denkbaren Dienste im IMS mit Elementen aus den folgenden Funktionsgruppen beschreiben: Verbindungsunterhaltung (Signalisierung) Datentransport Datenspeicherung Datenmanipulation (Verarbeitung, Umcodierung, Vervielfältigung, etc.) Datenerfassung (Eingabeschnittstellen) Datendarstellung (Ausgabeschnittstellen) Mit der Verwendung dieser sechs Funktionsgruppen als Baukasten für die Darstellung und Modellierung von Diensten im Internet und Mobilfunknetz lassen sich Dienste entwerfen und vor der Realisierung auf ihre Machbarkeit testen. Die Entwicklung einer Simulationsumgebung für Dienste ist auf dieser Basis ebenso denkbar. Abbildung 5: Protokollstruktur Die Dienste orientierte Zeichengabe mit SDP/SIP kann als Funktionsgruppe für die Verbindungsunterhaltung genutzt werden und ist in Abbildung 5 in der Kontroll-Ebene dargestellt, ebenso wird für den Datentransport TCP, UDP, etc. genutzt. Die übrigen Funktionsgruppen fallen in die Lücke von Funktionen und stellen damit einen wesentlichen Teil der Arbeit zur Umsetzung von mobilen Multimedia-Diensten (MMM- Dienste) dar. Zu den MMM-Diensten gehören zum Beispiel Mehrparteien Whiteboard und Videokonferenzen. Für die erste Umsetzung eines MMM-Dienstes wurde ein Mehrparteien Instant Messaging ausgewählt, da es sich mit geringem Aufwand realisieren lässt und bereits die wesentlichen Elemente des Modells enthält. 6/12

Dienstrealisierung Für die Realisierung der Dienste ist ihre Portierbarkeit ein wichtiges Kriterium. Die Berücksichtigung der Heterogenität der Systeme, die zur Nutzung eines Dienstes miteinander kommunizieren, führt zur Wahl einer Programmiersprache, welche auf allen Plattformen lauffähig ist, um die Einarbeitungs- und damit die Entwicklungszeit auf verschiedenen Systemen möglichst gering zuhalten. Die Wahl fiel auf Java, da in dieser Programmiersprache zusätzlich der objektorientierte Ansatz und die Unterstützung verteilter Systeme realisiert wurde. Für die Nutzung von Java auf mobilen Endgeräten wurde die Java 2 Micro Edition (J2ME) ausgewählt, da diese bereits optimal für den Einsatz auf Geräten mit limitierten Ressourcen zugeschnitten ist, und für die Umsetzung der Serverprogramme die Java 2 Standard Edition (J2SE), deren Funktionsumfang alle Anforderungen bisheriger Entwicklungen befriedigte. Für weitere Entwicklungen wird die Nutzung der Java 2 Enterprise Edition (J2EE) auf den Servern in Betracht gezogen. Die praktische Umsetzung der Dienste erfordert zudem die Durchführung eines Verteilungsentwurfs, da abhängig von den Fähigkeiten des Endgerätes einzelne Funktionen auf dem Server oder auf dem Endgerät realisiert werden müssen. Als Beispiel sei hier das Online-Banking genannt: Eine Eingabemaske kann die übergebenen Werte direkt, z.b. mittels eines Scripts wie Java-Script, oder es kann der empfangende Server die Werte auf Plausibilität überprüfen. Schneller, da mit geringerem Kommunikationsaufwand verbunden, ist die Lösung mittels Script, die aber einfache Endgeräte, wie normale Mobiltelefone, überfordert. Die Verwendung von Java zur Implementierung des Instant Messaging (IM) Dienstes auf einem mobilen Endgerät führt zur Verwendung von J2ME, während auf dem dienstunterstützenden Server J2SE verwendet wird. Für die Umsetzung des Dienstes muss die in [2] beschriebene Technische Spezifikation des 3GPP und die RFC 3428 [14] der IETF berücksichtigt werden. Das Funktionsmodell des IM-Clients auf dem Endgerät ist in Abbildung 6 dargestellt. Die Blockpfeile geben jeweils die Richtung des Datenaustauschs an. Da sowohl ein SIP-User Agent Server (UAS) als auch ein SIP User Agent Client (UAC) SIP- Nachrichten empfangen und versenden ist für beide die Kommunikation bidirektional. Die Funktionsweise des einfachen IM-Clients ist die folgende: Eine eingehende IM wird vom UAS entgegengenommen und in einem Zwischenspeicher abgelegt. Dort kann die IM vom Nutzer gelesen werden. Zum Versenden einer IM wechselt der Nutzer auf ein spezielles Formular zur Eingabe der IM. Mit dem Fertigstellen der IM wird diese an den User Agent Client (UAC) übergeben, der die IM an den Server zustellt. 7/12

IM-Client- Software IM-Anzeige IM-Eingabe SIP User Agent Server (SIP UAS) IM- Speicher SIP User Agent Client (SIP UAC) Mobilfunknetz Abbildung 6: Modell des IM-Clients Für den Server wird ein Entwurf benötigt der die Kommunikations- und Datenanforderungen des Clients bedienen kann. Dieser Entwurf wird in Abbildung 7 dargestellt und hat den folgenden funktionalen Ablauf. Der SIP-UAS nimmt die eingehenden SIP-Nachrichten an und leitet sie zur Verarbeitung weiter. Die Prozesseinheit wertet die Nachricht hinsichtlich der zu verwendenden Verteilerliste aus und lädt die Verteilerliste aus der Datenbank. Anhand der Liste werden nun neue Nachrichten erstellt und an den SIP-UAC zum Versenden geleitet.zur einfachen Erstellung und Veränderung der Verteilerlisten wurde der Server mit einer entsprechenden Java-Anwendung ausgestattet. Dieses Java-Servlet wird von einem Tomcat- Java-Container [20] ausgeführt und kommuniziert mittels dem HTTP über das Internet mit einem beliebigen Webbrowser. SIP ist ein reines Signalisierungsprotokoll, das durch die RFC 3428 [14] erweitert wurde, um Instant Messages direkt transportieren zukönnen. Der Transport der IM im IMS wird von dem 3GPP durch die TS 24.247 [2] spezifiziert. Für die Realisierung des Dienstes sind für die Java-Applikationen auf den mobilen Endgeräten unter J2ME die Ergebnisse des JSR 180 [7] relevant, in denen die SIP-Implementierung für mobile und embedded Geräte vereinbart wird. Die SIP-Implementierung unter Java für J2SE-fähige Geräte wird durch den JSR 32 [6] definiert. Alle Spezifikationen unterstützen den direkten Transport von IM von Endgerät zu Endgerät ohne den zusätzlichen Aufbau einer Nutzkanalverbindung. Der Versuchsaufbau besteht aus einem IMS Experimental System, dem Applikations-Server, einem Gateway und verschiedenen mobilen Endgeräten. Die Darstellung des Systems auf dem Operations- and Maintenance Server ist in Abbildung 8 gezeigt. 8/12

Obwohl die Laptops (Clients) durchaus in der Lage sind, J2SE-Programme auszuführen, wurde auf ihnen unter J2ME programmiert, um die spätere Portierbarkeit auf kleinere mobile Endgeräte wie Smartphones und PDAs zu ermöglichen. Für eine hinreichend gute Vergleichbarkeit zwischen dem Versuchsaufbau und realen Endgeräten werden die Applikationen nicht direkt auf den Laptops ausgeführt, sondern in einer Umgebung, die einen Treo 600 von der Firma PalmOne emuliert. Die Laptops wurden mit GPRS-fähigen PCMCIA-Karten ausgerüstet, so dass die Versuche über GPRS-Verbindungen durchgeführt wurden. Erprobungen mit realen Endgeräten und über UMTS-Verbindungen sind geplant. Verarbeitungs einheit Management DBMS Service Execution Service Management TOMCAT Java-Servlet- Container SIP- UAS Verarbeitungs einheit Service SIP- UAC IP-Netz Mobilfunknetz Abbildung 7: Modell des IM-Multiparty-Servers 9/12

Abbildung 8: OAM des IMS ES Ausblick Die hier vorgestellten Arbeiten sind Teil des Projektes IMMS (IP based Mobile Multimedia Services). Ziel des Projektes ist es einerseits Erfahrungen mit dem SIP-Protokoll in Hinblick auf die Realisierung mobiler Multimedia-Dienste zu gewinnen, und daraus Forderungen für die weitere Standardisierung abzuleiten. Zum anderen sollen konkrete Erfahrungen über die Wiedernutzbarkeit von Softwareschnittellen und komponenten aus leitungsgebundenen Diensten für die Entwicklung mobiler Multimedia-Dienste gewonnen werden. Anhand der hier vorgestellten prototypischen Realisierung eines Mehrparteien-Instant- Messaging wurde die Funktionsweise SIP basierter mobiler multimedia Kommunikation demonstriert. Für die weitere Entwicklung des Systems wurden bereits erste erfolgreiche Versuche mit einer Whiteboard-Applikation durchgeführt. Das System soll um zusätzliche Medien und Dienste, wie z.b. Telekonferenzdienste und Mehrparteien Textbearbeitung, erweitert werden, um die Wechselwirkung der gleichzeitigen Nutzung verschiedener Medien im Hinblick auf die SIP-Signalisierung zu untersuchen. Die vorgestellten Ergebnisse basieren auf dem Forschungsprojekt IMMS, das von der Firma Comneon GmbH & Co. OHG und dem Land Niedersachsen (im Rahmen des AGiP Programms) finanziell gefördert wird. 10/12

Abkürzungsverzeichnis 3GPP AGiP API AS CN CPL CS CSCF EMS GPRS HLR HSCSD HSS HTTP I-CSCF IETF IM IMS IMPP IP IPTEL J2EE J2ME J2SE JSR MMS MMUSIC P-CSCF PDN PS PSTN RFC RTP RTSP S-CSCF SDP SIP SIMPLE SMS TCP UA UAC UAS UDP UMTS Third Generation Partnership Program Arbeitsgemeinschaft innovative Projekte Advanced Programming Interface Application Server Core Network Call Processing Language Circuit Switched Domain Call State Control Function Enhanced Message Service General Packet Radio Service Home Location Register High Speed Circuit Switched Data Home Subscriber Server Hypertext Transport Protocol Interrogating Call State Control Function Internet Engineering Task Force Instant Message IP Multimedia Subsystem Instant Messaging and Presence Protocol Internet Protocol IP Telephony Java 2 Enterprise Edition Java 2 Micro Edition Java 2 Standard Edition Java Standardization Request Multimedia Message Service Multiparty Multimedia Session Control Proxy Call State Control Function Packet Data Network Packet Switched Domain Public Switched Telephone Network Request for Comment Real Time Protocol Real Time Streaming Protocol Serving Call State Control Function Session Description Protocol Session Initiation Protocol SIP for Instant Messaging and Presence Leveraging Extensions Short Message Service Transmission Control Protocol User Agent User Agent Client User Agent Server User Datagram Protocol Universal Mobile Telecommunication System 11/12

Literatur- und Quellenverzeichnis 1. 3GPP TS 23.228: IP Multimedia Subsystem (IMS); Stage 2 (Release 5). 3GPP; http://www.3gpp.org/ftp/specs/archive/23_series/23.228/. 2. 3GPP TS 24.247: Messaging using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3; 3GPP; http://www.3gpp.org/ftp/specs/archive/24_series/24.247/. 3. De Serres, Yves und Hegarty, Lawrence: Value-Added Services in the Converged Network; IEEE Communications Magazine, September 2001. 4. Dixit, Sudhir und Prasad, Ramjee: Wireless IP and building the mobile Internet; Artech House Boston London, 2002, ISBN 1-58053-354-X. 5. Gaedke, Martin, et al.: Object-oriented Web Engineering for Large-scale Web Service Management; Proceedings of the 32 nd Hawaii International Conference on System Sciences; 1999. 6. JSR 32: JAIN SIP Specification; Java Community Process; 2003; http://jcp.org/aboutjava/communityprocess/final/jsr032/index2.html. 7. JSR 180: SIP API for J2ME; Java Community Process; Dec 2003; http://jcp.org/aboutjava/communityprocess/final/jsr180/. 8. Mueller, Stephen M.: APIs and Protocols for convergent network services; McGraw- Hill, New York, 2002, ISBN 0-07-138880-X. 9. Parlay Group: Parlay X Web Services Specification, Version 1.0; 2003; http://www.parlay.org/specs/parlay_x_web_services_specification_v1_0.zip. 10. RFC 2327: SDP: Session Description Protocol; IETF; April 1998; http://www.ietf.org/rfc/rfc2327.txt?number=2327. 11. RFC 2824: Call Processing Language Framework and Requirements; IETF; May 2000; http://www.ietf.org/rfc/rfc2824.txt?number=2824. 12. RFC 2848: The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services; IETF; June 2000; http://www.ietf.org/rfc/rfc2848.txt?number=2848. 13. RFC 3261: SIP: Session Initiation Protocol; IETF; June 2002; http://www.ietf.org/rfc/rfc3261.txt?number=3261. 14. RFC 3428: Session Initiation Protocol (SIP) Extension for Instant Messaging, Dec. 2002; http://www.ietf.org/rfc/rfc3428.txt?number=3428. 15. Schulzrinne, Henning und Rosenberg, Jonathan: The IETF Internet Telephony Architecture and Protocols; IEEE Network, May/June 1999. 16. Schulzrinne, Henning und Rosenberg, Jonathan: The Session Initiation Protocol: Internet-Centric Signaling; IEEE Communications Magazine, October 2000. 17. Sinnreich, Henry und Johnston, Alan B.: Internet Communications Using SIP; Wiley New York, 2001; ISBN 0-471-41399-2 18. Trick, Ulrich: Next Generation Networks und UMTS; s. 81ff; Mobilfunk Stand der Technik und Zukunftsperspektiven, Informationstechnische Gesellschaft im VDE, VDE Verlag Berlin, ISBN 3-8007-2765-x, 2003. 19. Turner, Kenneth J.: Modelling SIP Services Using CRESS; FORTE 2002, LNCS 2529; pp 162-177; Springer-Verlag; Berlin, Heidelberg; 2002 20. Apache Jakarta Projekt: http://jakarta.apache.org/ 12/12