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

Transcription

Mobilfunk - Stand der Technik und Zukunftsperspektiven, 9. VDE/ITG Fachtagung
VDE-Verlag, Berlin 2004, ISBN 3-8007-2839-7
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
UMTS
RNS
Home
Domain
PDN
PS-Domain
Core
Network
PSTN
CS-Domain
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
UA
P-CSCF
I-CSCF
AS
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: PCSCF, 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
Steuerung
Abbildung 3: IMS Übersicht
4/12
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/OSA
Gateway
Parlay Web
Service
Logic
Parlay Web
Service
Interface
Parlay X
Application
Logic
Parlay X
Application
Interface
Framework
Logic
Framework
Interface
Resource
Application
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 (MMMDienste) 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) SIPNachrichten 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-ClientSoftware
IM-Anzeige
SIP User Agent
Server (SIP UAS)
IMSpeicher
IM-Eingabe
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 TomcatJava-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
Service
Management
TOMCAT
Java-ServletContainer
DBMS
SIPUAS
IP-Netz
Verarbeitungs–
einheit
Service
Mobilfunknetz
Abbildung 7: Modell des IM-Multiparty-Servers
9/12
Service
Execution
SIPUAC
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-InstantMessaging 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 32nd 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; McGrawHill, 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;
13. RFC
3261:
SIP:
Session
Initiation
Protocol;
IETF;
June
2002;
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

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

Transcription

Similar documents

Diplomarbeit

Weiterentwicklung OS

- LocaNet

Netzwerkprotokolle

Kfz Karl Reitberger Trupolding 10 · 94508 Schöllnach

Weg - Institut für Kommunikationswissenschaft und Medienforschung

Modul Filmanalyse Französisch

Thecus N2200 Bedienungsanleitung