IP Multimedia Subsystem - aot.tu-berlin.de · Agententechnologien in betrieblichen Anwendungen und der Telekommunikation A O T IP Multimedia Subsystem Agententechnologien in der Telekommunikation

Agententechnologien inbetrieblichen Anwendungenund der Telekommunikation

A O T

IP Multimedia Subsystem

Agententechnologien in der Telekommunikation Sommersemester 2009

Stefan [email protected]

Lecture

3 –

13.05.2009

2A O T TU Berlin

Agenda

• IMS Einleitung (Überblick, Motivation) • Session Initiation Protocol

•Einleitung•Überblick SIP Session Aufbau und Registrierung•SIP im Detail:

•Session Aufbau, Protokoll Nachrichten, Komponenten•Session Aufbau/Kontrolle - Kombination mit SDP•Security

•SIP Protokoll Erweiterungen (Presence & IM)• IMS

•Überblick•SIP Signalisierung im IMS•Komponenten: CSCF, HSS•Registration / Session Aufbau im Detail•Service Ausführung / SIP AS / Integration mit Parlay, OMA•Weitere Komponenten: MRF, BGCF, Charging•Security•IMS Integration NGN, IPTV

• Zusammenfassung• Referenzen

3A O T TU Berlin

Einleitung

Quelle: http://www.ikr.uni-stuttgart.de/Content/VFF_IKR_Workshop_2006/FMC_Network_Evolution.pdf

4A O T TU Berlin

Quelle: Business Communications Review, May 2006

Einleitung – IP Multimedia Subsystem – Motivation (1)

Horizontal layered architecture and service integration

Not reusable

http://webtorials.com/main/resource/papers/BCR/paper102/05-fried.pdf

5A O T TU Berlin

Einleitung – IP Multimedia Subsystem – Motivation (2) -> New network operators business model

Quelle: http://www.deutsche-telekom-laboratories.de/~vidales/pubs/commag-ieee_acuevas-final.pdf

Neue „bessere“ Dienste:

•z.B. bessere Video Qualität

•zugeschnitten auf den Benutzer (user context & location)

IMS als Teil der network operator Architektur

User profiles & charging, AAA

Single-sign-on

6A O T TU Berlin

Einleitung – IP Multimedia Subsystem (1)

IMS

kontrollierte und personalisierte Person-zu-Person und Person-zu- content Kommunikation

Service Integration

AAA, QoS, Roaming

Single Sign On

Open-Standard Schnittstellen

Charging

New multimedia realtime applications

Converged networks

Connectivity network independence

Voice

Video

Data

7A O T TU Berlin

Einleitung – IP Multimedia Subsystem

Spezifiziert vom Third Generation Partnership Project (3GPP/3GPP2)Ursprünglich als Teilspezifikation in Release 5 (2002) für 3G Mobilfunknetze / UMTS Ab Release 6 (2004) WLAN Integration, ab Release 7 unabh. von Zugangstechnologie

IMS ist Industriestandard für Netze der nächsten Generation für Dienste wie VoIP, Telefonie und Multimedia

definiert generische Architektur mit Open-Standard SchnittstellenIMS-Standard beschreibt Funktionen der Netzelemente und Schnittstellen zwischen ihnen (Reference Points)Definiert Mechanismen für: Sicherung der Dienstqualität (QoS), Roaming, Abrechung der Multimedia Sitzung (charging), Integration von Diensten

IMS Dienste bieten kontrollierte und personalisierte Person-zu-Person und Person-zu-content Kommunikation (Sprache, Text, Video,…)

8A O T TU Berlin

Einleitung – IMS – Motivation Zusammenfassung

Eine Service-orientierte Umgebung - Nutzung einer Vielzahl von Anwendungen unabhängig vom darunter liegenden Zugriffsnetzwerk und dem verwendeten Endgerät

„layered“, horizontale Netzwerk ArchitekturWiederverwendung der Funktionalitäten in verschiedenen Anwendungenermöglicht Service Providern schnelle, einfache und kostengünstige Entwicklung/Einführung neuer VoIP- und Multimedia-Dienste basierend auf einer standarisierten Architektur

Gemischte Multimedia-Anwendung - einfache Kombination; keine Trennung zwischen Daten-, Video-, und Audio-Applikationen

Securityauthentication, authorization, privacysingle-sign-on; nach Registrierung Nutzung aller für den Benutzer freigeschalteten Dienste

Quality of Service – garantierte Qualität der Kommunikation

Charging, Billing

Neue Anwendungen - Videokonferenz, Push-to-Talk (Push-to-X), multiparty gaming, communityservices, content sharing, Presence-Management (kombiniert mit location based services)

Roaming – Nutzung der Dienste aus fremden Netzwerken

9A O T TU Berlin

IMS / NGN History

(UMTS)

10A O T TU Berlin

Migration zu IMS

IMSMobile networks (GSM)

Quelle: Alcatel

11A O T TU Berlin

IMS - Architektur Überblick (1)

Quelle: „White Paper IMS - IP Multimedia Subsystem“, Ericsson

IMS

3 Layer Architecture

Service Layer :telephony & multimendia appsIMS Enablers: specific genericASs; e.g. presence, group mgt.value-added services (push-to-talk, …)

Control Layer: End point registrationSession setupMedia Servers (MRF)Signaling/Media Gateways(SG/MGCF)

Connectivity LayerVerbindung unterschiedlicher Zugangsnetze zu IMS (über Gateways)

12A O T TU Berlin

IMS - Architektur Überblick (2)

“Reference points describe all the traffic between two resources, including multiple protocols for the different types of traffic. IMS reference points not only specify how to interact with a resource but also which endpoints are allowed to interact with a specific resource.”

Quelle: http://www.bcr.com/carriers/public_networks/ims_101_w hat_need_know_now_2005061514.htm Quelle: http://www.3gpp.org/specs/specs.htm

13A O T TU Berlin

IMS – verwendete IP Protokolle

Quelle: „White Paper IMS - IP Multimedia Subsystem“, EricssonUser Equipment (UE)

IMS

Schlüsselprotokoll: Session Initiation Protocol (SIP)

Signalisierungs-Protokoll zum Aufbau, Abbau und Modifikation von Multimedia Sitzungen im Internet

Diameter basierte AAA (Authentication, Authorisation, Accounting)

und andere: SDP, RTP, RTCP, MGCP, Megaco(H.248), COPS, …

User Equipment (UE)

14A O T TU Berlin

Session Initiation Protocol

15A O T TU Berlin

Session Initiation Protocol - Einleitung

Signalisierungs-Protokoll zum Aufbau, Abbau und Modifikation von multimediaSitzungen im Internet

Audio/Video IP Telephonie / KonferenzenInstant Messaging, User Presence, gaming, distributed media, …

einfach strukturiert, leicht erweiterbar und offenrequest-response protocol, text-basiert ähnlich HTTP auf der Applikationsebenesetzt auf Transport Protokollen wie UDP und TCP auf

Standardisiert von der IETF in mehreren RFCsKernprotokoll: erstmals im RFC 2543 (1999); aktuelle Spezifikation im RFC 3261 (2002); dazu zahlreiche RFCs zu Erweiterungen

breite Unterstützung der führenden Telekommunikationshersteller, Standard der 3GPP/3GPP2 für multimediale Kommunikation

16A O T TU Berlin

SIP Session Setup (1)

Quelle: http://www.iaria.org/conferences2007/filesICDT07/tutorial-ims-6.pdf

17A O T TU Berlin



18A O T TU Berlin



19A O T TU Berlin

SIP - Registering


20A O T TU Berlin

SIP – Session Setup using SIP Proxies (1)


21A O T TU Berlin

SIP – Session Setup using SIP Proxies (2)

22A O T TU Berlin

Überblick SIP Funktionalitäten

Kombinierter Einsatz mit Session Description Protocol (SDP) zum Beschreiben der Media AttributeRealtime Transport Protocol (RTP) zum Übertragen der eigentlichen media stream Daten

Funktionalitäten :Ermitteln Ort bzw. Endgerät des Anzurufenden und Bereitwilligkeit zur Teilnahme an Kommunikation Verbindungsaufbau und -Verwaltung (Aushandeln und Modifizieren der Verbindungsparameter) Feststellen der Endgerät FähigkeitenErweiterungen ermöglichen u.a. user presence awareness und InstantMessaging

23A O T TU Berlin

SIP - Basic requests (RFC 3261)

REGISTER: Registrieren der gegenwärtige location eines Clients

INVITE: Initiieren eines Anrufes, Media (Neu-)AushandlungACK: Client bestätigt Eintreffen einer INVITE - 200 OK Antwort vom ServerBYE: Teilnehmer beendet AnrufCANCEL: bricht vorhergehend gesendeten request ab

OPTIONS: UAC erfragt die Fähigkeiten eines UAS; der UAS reagiert wie bei einem INVITE ohne einen Anruf zu initialisieren

24A O T TU Berlin

SIP - Protokoll (1) – Messages - Requests

SIP request Aufbau :request-line (mit requestMethode und Ziel URI), mehrere header lines,leere Zeile, optionaler message body(message payload)

INVITE sip:alice@domain2 SIP/2.0Call-ID: [email protected]: 4 INVITEFrom: „Bob" <sip:bob@domain1>;tag=6043To: „Alice" <sip:alice@domain2>Via: SIP/2.0/UDP 192.168.1.2:15890;branch=z9hG4bK71d20bccbea3e3c145dc60466c44fbMax-Forwards: 70Route: <sip:130.149.159.218:5060>Content-Type: application/sdpContact: <sip:192.168.1.2:15890;transport=udp>Content-Length: 87

v=0o=- 3326598528 3326598528 IN IP4 192.168.1.2s=-c=IN IP4 192.168.1.2...

25A O T TU Berlin

SIP - Protokoll (2) - Messages - Responses

status-line enthält status code und Kurzbeschreibung der Antwort,

Status code geteilt in 6 Klassen :1xx : informelle Antwort, „Session in Progress“ o. „Ringing“2xx : success, request ist akzeptiert 3xx : redirection des requests, der Sender hat den request an neue(n) Empfänger zu richten 4xx : client error – syntaktischer Fehler im request oder request kann vom server nicht bearbeitet werden5xx : server error – Fehler im server beim Abarbeiten des requests6xx : global error – Fehler in allen servern (vom proxy gesetzt)

man unterscheidet „provisional“ (1xx) und „final“ (alle anderen) Antworten

einem request sind mehrere provisional (nur bei INVITE) und eine final response von einer remote Instanz einer SIP Entität zugeordnet

sind mehrere (remote) Instanzen registriert, können auch mehrere final Antworten eintreffen (oder werden vom SIP proxy server absorbiert)

200 OK SIP/2.0Call-ID: …CSeq: 4 INVITEFrom: To: …Contact: ……

v=0o=- 3326598528...s=-c=IN IP4 192.168.1.2...

26A O T TU Berlin

SIP - Session Signalling Flow (1)

(audio/video media stream)

Anruf Initialisierung, Media Strom Aushandlung

Modifikation der Medienströme

(re-INVITE)

Anruf Beendigung

27A O T TU Berlin

SIP - Session Signalling Flow (2)

Quelle: „Understanding SIP“, D. Sisalem and J. Kuthan

28A O T TU Berlin

SIP - Session Stream Negotiation & Description

Session Description Protocol (SDP) (RFC 2327) : session stream Attribute werden vom beschrieben (als body in SIP messages)

U.a. Empfänger IP Addresse und Port, media type, Protokoll, Codecs, Name und Zweck der Session, Startzeit

Aushandlung erfolgt per offer-answer mechanism(RFC 3264)

Herausfinden der codecs die von beiden Teilnehmern unterstützt werdenSIP messages enthalten offer/answer als SDP body, wenn kein body offerrequirement (nur INVITE) Gebräuchlich im INVITE / 200 OK messagePaar (aber auch : 200 OK / ACK, 183 / PRACK)Neuaushandlung der streams durch Senden eines neuen offers (re-INVITE oder UPDATE), Beenden/Verwerfen und Hinzufügen von streams

Offer :v=0 o=- 25678 753849 IN IP4

128.96.41.10s= c=IN IP4 128.96.41.10t=0 0 m=audio 3456 RTP/AVP 0 8m=video 75464 RTP/AVP 32

Answer :v=0 o=- 25678 753849 IN IP4

128.96.41.5s= c=IN IP4 128.96.41.5 t=0 0 m=audio 54377 RTP/AVP 8m=video 0 RTP/AVP 32

29A O T TU Berlin

SIP Registrar Server

Erreichbarkeit für andere Benutzer : gewährleistet durch Registrierung am registrar server

SIP Entitäten sind eindeutig identifiziert durch eine SIP URI (Uniform ResourceIdentifier), sip:username@domain

User Agent registriert seine derzeitige location (IP address + port) mit SIP URI(address-of-record) des Benutzers durch REGISTER request

Benutzer kann über mehrere Endgeräte gleichzeitig erreichbar sein

In Kombination HTTP Digest Authentication(RFC 2617) zur Benutzer Authentifizierung

Location Database Eintrag

„Benutzer sip:name@domain ist

erreichbar unter IP + port“

30A O T TU Berlin

SIP Proxy Server

Routet die SIP messages vom UAC zum UAS, und zurück

Proxy Server muß nächsten Hop bestimmen, möglich durch :DNS, registrar (location database), Benutzerskript, fest konfiguriertIst meist co-located mit einem registrar

Verändert bestimmte Teile der requests vor dem Weitersenden; ermöglicht u.a.:routen der Responses (Proxy Adresse in Via-header) zurück zum UAC Record-Routing: Proxy bleibt im SIP signaling path einer session

Man unterscheidet stateless und stateful proxyStateful : hält Transaction (Zuordenen von responses zu requests), forkingmöglich, Absorbieren von retransmissionsStateless : schneller, skalierbar, produziert mehr traffic

31A O T TU Berlin

SIP Proxy Forking

Der Angerufene ist an mehreren Endgeräten gleichzeitig registriert

Proxy kann request an mehrere Engeräte des Angerufenen weiterleiten

Bei Rufannahme : Zurückreichen der ersten „OK“ Antwort (von (2)), Abrechen (CANCEL Methode) der anderen Einladung (1)

CANCEL

Callee instance (2)

Callee instance (1)

Caller

32A O T TU Berlin

SIP Komponenten

SIP Trapezoid mit UA und proxy server

+ Registrar

…

SIP proxies

User Agent (UA) : Benutzerendgerät (Softphone, Hardphone, auch Application Server u. PSTN GW)UA Client (UAC): initiiert Anrufe, sendet SIP AnfragenUA Server (UAS): hört auf eingehende Anrufe, sendet SIP Antworten

Proxy Server : routet SIP Nachrichten zw. SIP Entitäten

Registrar Server : registriert Bindung zw. Benutzer und Endgerät

Redirect Server :leitet SIP requests zu neuer(/n) location(s) (per 3xx response mit neuem contact(s))

Back-to-Back User Agent (B2BUA)terminiert SIP Anfragen (UAS) und generiert neue (UAC)Manipulation von SIP messages

SIP AS

(optional)

33A O T TU Berlin

SIP - Sicherheitsmechanismen

Authentifizierung des request-SendersHTTP Digest authentication scheme benutzt im SIP ProtokollNach Erhalt von 401/407 response wird request nochmal mit Benutzer credentials(Name, realm und Passwort) versendet

Integrität und VertrauenswürdigkeitS/MIME Standard (RFC 3851) für digitale Signaturen und Verschlüsselung des SIP message bodies

Verschlüsselter Transport SIPS URI (“sips:” Schema anstatt von “sip:”) als request-URITLS Protokoll zum Senden des requests hop-by-hop bis zum proxy server der Ziel-Domain

UA

407 Proxy AuthorizationRequired

REQUEST

Proxy Server / Registrar

200 OK

REQUESTAuthentication-headerwith user credentials

34A O T TU Berlin

SIP Erweiterungen – Presence and Instant Messaging

Spezifikationen von der IETF SIMPLE Working Group

Konform zu generischen IM und presence Spezifikationen der IETF (CPP, CPIM, IMPP WG) -> Interoperabilität zw. versch. IM Protokollen (z.B. SIP zu XMPP über Gateways)

Presence services definiert im „presence event package“Basiert auf generellem Event Notification Framework –SUBSCRIBE / NOTIFY Methoden (RFC 3265) undEvent State Publishing, PUBLISH Methode, RFC 3903, Event State Compositor und Event Publishing AgentUser presence beschrieben durch das Presence Information Data Format (PIDF)

Instant Messaging, two approaches :pager mode: MESSAGE Methode, RFC 3428, stand-aloneInstant Messages über den SIP Signalisierungswegsession mode : per INVITE ausgehandelt, Daten per MSRP(Message Session Relay Protocol) peer-to-peer

200 OK (un)SUBSCRIBE

Watcher

NOTIFY (event state)

200 OK SUBSCRIBE

Presentity

200 OK

Sender

200 OK MESSAGE

Instant Inbox

(SIP UA) (SIP UA)

35A O T TU Berlin

SIP Erweiterungen – Presence and Instant Messaging - Presence Information Data Format (PIDF)

Request : Body:

NOTIFY sip:10.0.4.62:43313;transport=udp SIP/2.0

Event: presenceSubscription-State:

active;expires=3600Record-Route:

<sip:130.149.154.198:5080;lr>Content-Type: application/pidf+xmlContent-Length: 1047…

…<presence xmlns="urn:ietf:params:xml:ns:pidf"

… entity="pres:[email protected]"><dm:tuple id="eadcddf7"><contact>sip:10.0.4.177:65093</contact><status><basic>open</basic></status><timestamp>2008-04-27T05:31:56Z</timestamp>

</dm:tuple><dm:tuple id="eadcddf8">

<contact>mail:[email protected]</contact><status><basic>open</basic></status>

</dm:tuple><dm:person id="eabfccd3"><status><basic>open</basic></status><dm:timestamp>…</dm:timestamp><rpid:activities><rpid:busy/>

</rpid:activities></dm:person>

</presence>

Benutzer sip:[email protected] ist (mit seinem SIP Endgerät) unter der IP Adresse 10.0.4.177:65093 bereit zur Kommunikation (tuple Status der SIP Kontaktes ist „open“), er ist aber zur Zeit beschäftigt (Status person = „busy“). Weiterhin ist er per email erreichbar (tuple Status ist „open“).

36A O T TU Berlin

SIP Erweiterungen – Presence and Instant Messaging - SIP Presence Server

Quelle: http://download.oracle.com/docs/cd/E10301_01/doc.1013/e10292/about_sdp.htm

Presence Server

SUBSCRIBE

37A O T TU Berlin

SIP Erweiterungen – Event Notification

Event Notification Framework (SUBSCRIBE/NOTIFY/PUBLISH) ist generisch, beliebig erweiterbar

weitere definierte event packages : registration event package : Informationen über registrierte SIP Entitätenreference event package : „kontaktiere third-party und teile Erbgebnis mit !“ (session mobility, session hand-off)conference event package : Informationen über Konferenz Teilnehmer/Statuswatcher info event template-package : Informationen über subscriber für einen bestimmten event und notifier

38A O T TU Berlin

IP Multimedia Subsystem

39A O T TU Berlin

IMS - Architektur Überblick

Service Layer (Application Layer)Application Server (AS)IMS Enablers (specific genericASs; e.g. Presence, Group Management.)

Service Control Layer (IMS Core)Call Session Control Function(S-, I-, P- CSCF)Home Subscriber ServerMedia Resource Function(MRF)Media Gateway (SG/MGCF)Policy Decision Function (PDF)Charging FunctionBreakout Gateway

IMS

User Equipment (UE)

40A O T TU Berlin

IMS – User Identity

User Equipment = 3GPP IMS konformer SIP User Agent

UE enthält ISIM / USIM (IP Multimedia / Universal Subscriber Identity Module) mit : Security key (für Benutzer Authentifizierung und Integrität/Verschlüsselung der SIP Nachrichten)Öffentliche und private Benutzer IDs sind dort gespeichertHome Network Domain URIUSIM : temporäre private identity und public identity werden zugewiesen (berechnet aus IMSI (International Mobile Subscriber Identitfication)

IP Multimedia Private Identity (IMPI)Genau eine pro IMS subscriber, benutzt für AAA

IP Multimedia Public Identity (IMPU)Normale SIP URI oder TEL URIBenutzt zum Routen der SIP messagesIdentifiziert den Benutzer öffentlichMehrere public identities per IMS subscription möglich -> Benutzer agiert unterverschiedenen Rollen -> Nutzung unterschiedlicher Dienste über zugewiesene Benutzer Profile

41A O T TU Berlin

IMS – SIP Signalling - Ohne Roaming


42A O T TU Berlin

IMS – SIP Signalling - Mit Roaming


43A O T TU Berlin

IMS – SIP Signalling - QoS

PDF – Policy Decision Function : Durchsetzen der auf Applikationsebene geforderten Media Qualitäten auf Netzwerk Ebene (PDP context activation)


44A O T TU Berlin

IMS – SIP Signalling – Charging

CCF - Charging Collection Function / SCF - Session Charging Function

Quelle: http://www.deutsche-telekom-laboratories.de/~vidales/pubs/commag-ieee_acuevas-final.

/ SCF

45A O T TU Berlin

IMS - Call Session Control Function (CSCF)

Quelle : http://www.newport-networks.com/downloads/DaveGladwinSBCsAndIMS.pdf

46A O T TU Berlin

IMS - Proxy CSCF (P-CSCF)

Erster Kontaktpunkt (outbound proxy) im lokalen oder besuchten Netzwerk vom UE ausfindig gemacht über DHCP oder GPRS PDP

Agiert als proxy : Weiterleiten der SIP registration vom UE zum I-CSCF des Home NetzwerksWeiterleiten der SIP requests vom UE zum S-CSCF (oder I-CSCF) des Home NetzwerksWeiterleiten der eintreffenden SIP Nachrichten zum UA

Enthält PDP(Policy Decision Point) / PDF (Policy Control Function) : ermittelt der QoS Klasse und TrägerquellenPrüft Media Parameter (SDP) gegen lokale policies

Komprimieren und Dekomprimieren (SigComp) von SIP Nachrichten zwischen UE und P-CSCF

Aufbau Security Association zwischen UE und P-CSCF (SIP über IPSec)

Weitere Funktionen : Protokollierung, Aufruf Services in der lokalen Infrastruktur: Notrufunterstützung

47A O T TU Berlin

IMS - Serving CSCF (S-CSCF)

Agiert als Registrar; während Registrierung :Authentifizieren des Benutzers (), holt dazu „authentication vector“ vom HSS über Diameter MAR requestHolt user profil (zum späteren routen weiterer requests) vom HSS über Diameter SAR request

Agiert als SIP Proxy

Ist immer im SIP Signalisierungs Pfad (Record-Routing + Service-Route)

Interagiert mit den Dienstplattformen, routet SIP request zu SIP ASFilterinformation (im Benutzer Profil, vom HSS) bestimmen, ob und welcher AS einen Dienst ausführen soll

Notifiziert SIP Entitäten über Eintreten eines Registrierungsereignisses (De-Registrierung, Re-Authentifikation)

Führt netzwerkinitiierte De-Registrierung und Anruf Beendigung aus

48A O T TU Berlin

IMS - Interogating CSCF (I-CSCF)

Zentraler Kontaktpunkt für alle SIP requests zum subscriber eines Operator Netzwerks

Registrierung: Zuweisung eines S-CSCF zum Benutzer (über HSS Diameter Anfrage)

Routed SIP requests zu diesem S-CSCF

Versteckt interne Struktur eines Operators - THIG (Topology Hiding Inter-Network Gateway)

Immer im SIP Signallisierugspfad Pfad durch Record-Routing und Service-Route; Verschlüsselung der Einträge des zu schützenden Netzwerks in SIP messages

49A O T TU Berlin

IMS – Home Subscriber Server (HSS)

Verwaltet die Benutzer Subscription / Profil InformationenAuthentifizierungsinformationenPrivate und Public Identitäten der BenutzerFilter Kritierien -> welche services werden aufgerufen ?Über welche Medien darf Benutzer kommunizieren

Cx (Diameter) Schnittstelle zu S-CSCF, I-CSCFLiefert Authentifizierungs Daten und Benutzer Profil an S-CSCFLiefert zugewiesenen S-CSCF an I-CSCF

Sh (Diameter) Schnittstelle zu Application ServerLiefert Benutzer Datenan AS (public IDs, welcher S-CSCF ?, registration state, location information, charginginformation, …)Notifiziert AS über dis Änderung von Benutzer DatenAS kann Benutzer Profil setzen

Mehrere HSS Instanzen erlaubt, verwaltet von SLF

(Subscription Location Function)

50A O T TU Berlin

IMS - Registrierung und Session Aufbau

51A O T TU Berlin

IMS - Session Initiierung mit Service Aufruf

SGSN GGSN GGSN SGSN

UEBUEA

Access Network A

SIP/SDPinviting

P-CSCFC

SIP / SDP

S-CSCFAP-CSCFD

Service Platform A(ASA)

S-CSCFB

Go SIP/SDP

IP Backbone Network

Data- Path

PDP ContextSessionlevel(SIP/SDP signalling)Bearer level(PDP context activation / modification / Release)Interactionbetweensession andbearer level(COPS)

PDF

Gm Gm

PDP Context

SIP / SDP

SIP / SDP

Service Platform B(ASB)

PDF

I-CSCF (between P-CSCF and S-CSCF) not shown for simplicity

[email protected]

Go

Serving Network AServing Network B

Access Network B

Quelle: http://europe.eu.int/information_society/policy/ecomm/doc/info_centre/public_consult/ngn/comments/coureau.ppt

I -CSCFB-CSCFA

I

52A O T TU Berlin

IMS – Application Server / Service Trigger Points (1)

Initial Filter CriteriaFilter Regeln im Benutzer Profil; genau einer öffentlichen Benutzer ID zugeordnetEnthält Trigger Point + AS Indentifier (SIP URI format e.g. sip:[email protected])

Trigger Point = boolean expression -> unter welchen Bedingungen wird zum ApplicationServer geroutet?

Trigger Point = Konjunktion/Disjunktion von 1..n Service Point Trigger

Service Point Trigger (SPT) : Request URI, SIP Methode, SIP Header, Session Description, session case(orginating or terminating)

Quelle: http://www.fokus.gmd.de/testbeds/ims_playground/Paper/FOKUS-IMS-Tutorial-public.pdf

53A O T TU Berlin

<InitialFilterCriteria><Priority>0</Priority><TriggerPoint>

<ConditionTypeCNF>1</ConditionTypeCNF><SPT>

<ConditionNegated>0</ConditionNegated><Method>INVITE</Method>

</SPT><SPT>

<ConditionNegated>0</ConditionNegated><SIPHeader>

<Header>P-Asserted-Identity</Header><Content>sip:boss@domain</Content>

</SIPHeader></SPT>

</TriggerPoint><ApplicationServer>

<ServerName>sip:[email protected]:5100</ServerName><DefaultHandling>0</DefaultHandling>

</ApplicationServer></InitialFilterCriteria>

IMS – Application Server / Service Trigger Points Example

(method=INVITE) AND(P-Asserted-Identity = sip:boss@domain) AND

all calls from boss have to goto an answering machine (SIP AS)

54A O T TU Berlin

IMS – Application Server - Modes

AS Dienste angeboten von home, visited oder third party provider

S-CSCF forwards requests to AS, results of AS sent back to S-CSCF

AS kann in 4 verschiedenen Modi agieren:terminating UA or redirect server originating UA SIP proxy B2BUA

Public Service Identities (PSIs) zum Identifizieren bestimmten Application ServerForm einer SIP URI oder TEL URI, z.b: sip:[email protected]


55A O T TU Berlin

IMS – Application Server - Types

SIP Application Server

OSA / Parlay Services

CAMEL Services

56A O T TU Berlin


IMS – SIP Application Server – SIP Servlets

- Eine Realisierungsmöglichkeit für SIP AS sind SIP Servlets - Definiert in Java Specification Request 289 (früher JSR 116)

57A O T TU Berlin

IMS – Application Server – OSA/Parlay


Services: Third Party Call, Conferencing, Terminal Status/Location, Messaging, Presence, Audio Call, Streaming, Call Handling, Address Lists, …

58A O T TU Berlin

IMS im Kontext von OSA/Parlay, Parlay X, OMA

Quelle: http://www-128.ibm.com/developerworks/webservices/library/ws-soa-ipmultisub1/

•Open Mobile Alliance (OMA)

•Zusammenschluss Mobilfunk- Dienstleistungs- und Produktanbieter

•Standardisierung von Diensten, z.B. Presence und Group List Enabler (XDMS)

•Parlay Group

•Abstraktion von Diensten

•Zusammenarbeit 3GPP

•Parlay - IDL für CORBA

•Parlay X - SOAP Web Services

IMS Core

59A O T TU Berlin

IMS – Media Resource Function

Media Server Funktionalität, bietet Dienste wieconferencing, streaming, announcement, recording

Media Resource Function is geteilt in zwei FunktionalitätenMedia Resource Control Function (MRFC)Media Resource Processor Function (MRPF)

MRFCInterpretiert die SIP/SDP Signalisierungs Informationenvom S-CSCF / ASAgiert als SIP User Agent zum S-CSCF hinKontrolliert MRPF über H.248 Protokoll; Alternative: (aber nicht standarisiert) SIP oder Integration MRFP und MRFC in eine Komponente (da weniger komplex)

MRPFMixing, streaming, transcoding

60A O T TU Berlin

Media Gateway Control Function (MGCF) - Gateway to PSTN networksÜbersetzt SIP Nachrichten in entsprechende PSTN Signale und zurückTranscodiert codecs der MedienströmeAgiert als SIP UA

Breakout Gateway Control Function (BGCF)für Anrufweiterleitung vom IMS zum circuit switched network zuständig (Anruf Telefonnummer, PSTN / Public Land Mobile Network (GSM)) lokale MGCF (Anrufer im selben Netz) oder BGCF des fremden Netzes

IMS – Media Gateway

61A O T TU Berlin

IMS – Charging

Two approaches : Offline charging Online charging

Offline Charging : users pay for their services periodically (e.g. at the end of month)

Charging Collection Function (CCF)collecting of Session charging information from the IMS nodes (by using Rfinterface (Diameter))intermediate data storage buffering; call detail records (CDR)transfer of the charging data to the (operator’s chosen) billing systems (BS)

Online Charging: Prepaid Service, credit based charging

Session Charging Function (SCF) = AS, erhält “blind” SIP requests über User Profil Filterregeln

/ SCF


62A O T TU Berlin

IMS – Sicherheitsaspekte

Security Associations (IPSec, ESP Verschlüsselung und Integrität)

2: zw. UE und P-CSCF; aufgebaut bei SIP Registrierung3: Cx Interface zw. HSS und x-CSCF4: inter domain über SecurityGateways (SEGs)5: intra domain zw. x-CSCFs

Quelle : ETSI TS 33.203-710

1: Beidseitige Authentifizierung zw. UE und Heimatnetzwerk über geheimen Schlüssel in ISIM und HSS (assoziiert zu privaten Benutzer Identität (IMPI)) bei der SIP Registrierung (3GPP Authentication and Key Agreement (AKA) Mechanismus)

63A O T TU Berlin

IMS – NGN Integration

Quelle: Introduction to TISPAN NGN, [email protected]

ETSI TISPAN aims to enableNext Generation Networks

3GPP IMS as core of NGN

A multi-service, multi-protocol, multi-access, IP based network

+ Connectivity ControlLayer

Network AttachmentSubsystemResource AdmissionControl Subsystem

64A O T TU Berlin

IMS – NGN Integration am Bsp. von IPTV

Transport ControlFunctions

SSF

Core IMS

Transport ProcessingFunctions

IPTV Media Functions

CoD-MCF

CoD-MDF

BC-MCF

BC-MDF

N-PVR-MCF

N-PVR-MDF

IPTV Service Control Functions

CoD-SCF

BC-SCF

N-PVR-SCF

Xc

Xd

Gm

Gq'

Xa

ISC

e2

UPSFCx

e4RACSNASS

UE

IPTV Media Control Functions

IPTV Media Delivery Functions

Sh

Ut

y2

SDFSh

ISC

Xp

Media Delivery, Distribution & StorageTransport Functions

Application and IPTV Service Functions

NGN / IMS based IPTV architecture, TISPAN TS 182 027

Quelle folgende Seiten : http://isoc.nl/activ/2008-SIPSIG-standards-OskarVanDeventer-IMS-basedIPTV.ppt

65A O T TU Berlin

IMS – NGN Integration am Bsp. von IPTV (2)


SSF

Core IMS



CoD-MCF

CoD-MDF

BC-MCF

BC-MDF

N-PVR-MCF

N-PVR-MDF


CoD-SCF

BC-SCF

N-PVR-SCF

Xc

Xd

Gm

Gq'

Xa

ISC

e2

UPSFCx

e4RACSNASS

UE



Sh

Ut

y2

SDFSh

ISC

Xp



UE: User EquipmentSet-top box, Residential Gateway,

Home-Theater PC, …

Core IMS:Bunch of SIP

servers and User Profile Server

“HSS”

SCF and SDF: dedicated SIP

application servers for

IPTV

66A O T TU Berlin



SSF

Core IMS



CoD-MCF

CoD-MDF

BC-MCF

BC-MDF

N-PVR-MCF

N-PVR-MDF


CoD-SCF

BC-SCF

N-PVR-SCF

Xc

Xd

Gm

Gq'

Xa

ISC

e2

UPSFCx

e4RACSNASS

UE



Sh

Ut

y2

SDFSh

ISC

Xp



Media control and delivery, e.g. video-on-demand

jukebox

Transport, network attachment, resource reservation

67A O T TU Berlin



SSF

Core IMS



CoD-MCF

CoD-MDF

BC-MCF

BC-MDF

N-PVR-MCF

N-PVR-MDF


CoD-SCF

BC-SCF

N-PVR-SCF

Xc

Xd

Gm

Gq'

Xa

ISC

e2

UPSFCx

e4RACSNASS

UE



Sh

Ut

y2

SDFSh

ISC

Xp



SDF: Service Discovery Function, “what are my IPTV services”, “where can I change my user

profile”, “where can I select my service”, address of service portal

68A O T TU Berlin



SSF

Core IMS



CoD-MCF

CoD-MDF

BC-MCF

BC-MDF

N-PVR-MCF

N-PVR-MDF


CoD-SCF

BC-SCF

N-PVR-SCF

Xc

Xd

Gm

Gq'

Xa

ISC

e2

UPSFCx

e4RACSNASS

UE



Sh

Ut

y2

SDFSh

ISC

Xp



SSF: Service Selection Function, getting an Electronic Programme

Guide, “what programs are available”

69A O T TU Berlin



SSF

Core IMS



CoD-MCF

CoD-MDF

BC-MCF

BC-MDF

N-PVR-MCF

N-PVR-MDF


CoD-SCF

BC-SCF

N-PVR-SCF

Xc

Xd

Gm

Gq'

Xa

ISC

e2

UPSFCx

e4RACSNASS

UE



Sh

Ut

y2

SDFSh

ISC

Xp



SCF: Service Control Function, Set up an IPTV

session using SIP- based session control, select

Media Function

RACS: Resource & Admission Control

Subsystem

70A O T TU Berlin



SSF

Core IMS



CoD-MCF

CoD-MDF

BC-MCF

BC-MDF

N-PVR-MCF

N-PVR-MDF


CoD-SCF

BC-SCF

N-PVR-SCF

Xc

Xd

Gm

Gq'

Xa

ISC

e2

UPSFCx

e4RACSNASS

UE



Sh

Ut

y2

SDFSh

ISC

Xp



RTSP protocol for media control: Broadcast trick

modes, Content on Demand and Network PVR

RTP protocol for media

transport

IGMP protocol for control of plain

Broadcast Television

71A O T TU Berlin

IMS - Zusammenfassung

SIP als Standardsignalisierungsprotokoll im IMS

IMS bietet : neue IP basierte Diensteschnelle Dienstentwicklung („Layered“ Architektur)Interoperabilität der DiensteZugriffsnetzwerkunabhängigkeit (UMTS, WLAN, DSL) AAA: Charging, single-sign-on, SicherheitRoamingNeues Geschäftsmodel für den Netzwerk Betreiber

Aber:„IMS is complex and costly …“„little (if any) in the way of new applications“ ?„there are performance concerns“

(„IMS 101: What You Need To Know Now”, John Waclawsky)

IMS Erfolg ist abhängig von der Akzeptanz der BenutzerRisiko: network operator als reine “bit pipe”, wenn Benutzer unabhängigie Kommunkaitons-Anwendungen nutzt (z.B. P2P)

72A O T TU Berlin

Referenzen

The Internet Engineering Task Force (IETF): http://www.ietf.org/RFCs SIP, Diameter

The 3rd Generation Partnership Project (3GPP): http://www.3gpp.org/

The Third Generation Partnership Project 2 (3GPP2): http://www.3ggp2.org/

Parlay Group: http://www.parlay.org/en/index.aspOSA/Parlay, Parlay X

Tech-Invite : http://www.tech-invite.com/ : Collection of SIP, ETSI, 3GPP, TISPAN, … standards

The IMS Lantern Blog : http://theimslantern.blogspot.com/Overview current IMS deployments, IMS resources linksMany IMS details & aspects

http://www.ietf.org/

http://www.parlay.org/en/index.asp

http://www.tech-invite.com/

http://theimslantern.blogspot.com/

73A O T TU Berlin

Ende

74A O T TU Berlin

Backup

75A O T TU Berlin

IMS

76A O T TU Berlin

IMS – Beispiel Service

Presence server

INVITE User B

INVITE

User B online?

„Away“!

RTP audio stream

INVITE „play announcment of user B“

User A

Trigger service for user B

Charging information

Service für subscriber B : spiele Ansage ab, wenn ich bei eingehenden Anruf nicht erreichbar bin !

77A O T TU Berlin

IMS Main Features

IMS Phase 2 - 3GPP Rel6Inter-working with non-IMS IP networks (e.g. Internet)Inter-working with CS networks (e.g. PSTN, CS PLMN)IMS Services combining CS (rt) & PS (nrt) : CSI Phase 1Access agnostic IMS specificationsUTRAN QoS optimisation for PS conversational servicesWLAN/3GPP inter-working for using PS/IMS services Presence/Instant Messaging (SIMPLE) → OMAGroup management & Conferencing (SIP)Immediate and Session based messagingService enablers for IMS : PoC → OMADynamic QoS policy (including Gq (P-CSCF/PDF))Lawful interceptionSIP forkingFull charging framework (incl. Online and Flow based) IPv4 option & IPv6 evolution guidelines still applicable

IMS Phase 1 - 3GPP Rel5SIP Session Control for IMS SignallingSecurity & IMS Authentication :

SIP signalling integrity (IPSec : UE / P-CSCF)IMS User/Service authentication (IMS-AKA)

QoS : SBLP (Go : P-CSCF-PDF / GGSN-PEF)SIP Compression (Sigcomp, UE/P-CSCF)Header compression in RAN (UE / RNC, re-use

of RoHC)Charging (mainly Offline) and OAM&PMultimedia codecs

OSA supportCAMEL (Phase 4) for IM-SSFIPv6 use for SIP signalling and IMS user traffic

IPv4 optional (guidelines & IPv6 evolution)

Emergency servicesIMS local servicesEnhanced QoS (extension for IP Inter-working)MRFP / MRFC (Mp) & ALG/Tr-GW (Ix) interfacesGERAN optimisation for PS conversational services

IMS ‘Phase 3’ - 3GPP Rel7 (Draft contents, depends on Rel6 and company proposals)IMS enhancements for Fixed Broadband accessInterim Security (IP based authentication)Merging of Go and Gx (TPF/FBC) interfaces

Quelle: http://europe.eu.int/information_society/policy/ecomm/doc/info_centre/public_consult/ngn/comments/coureau.ppt

78A O T TU Berlin

79A O T TU Berlin

80A O T TU Berlin

SIP/IMS - Warum SIP ?

Simple. „SIP is based on a straightforward request-response interaction model, making life simple and comprehensible for developers. The messages are also text-based whichmakes them easy to parse, create, read, understand and debug.“

Extensible. „SIP can set up sessions for any media type, be it voice, video, application sharing orteleportation (once we invent it!)“

Flexible. „SIP allows developers to interact with the individual protocol messages (within limits) without breaking anything. This means that developers can perform a lot of neat tricks that make development much easier.“

Familiar: „In large part because SIP borrows heavily from HTTP and other internet standardsfrom the IETF, lots of web-like technologies can be used to build SIP applications. SIP development looks and feels a lot like web development, and there are a lot of web developers out there.“

http://www.sipcenter.com/sip.nsf/html/IMS+IP+Multimedia+Subsystem

81A O T TU Berlin

IMS – Registration - Signaling Flow (1/2) (3GPP AKA)

Quelle: Forschungszentrum Telekommunikation Wien, NGN Service Layer Security, Oliver Jung

Benutzer Authentification

+

Schlüsselaustausch für die Verschlüsselung aller weiteren SIP Nachrichten zw. UE und P-CSCF

82A O T TU Berlin

IMS – Registration - Signaling Flow (2/2) (3GPP AKA)

Quelle: Forschungszentrum Telekommunikation Wien, NGN Service Layer Security, Oliver Jung

83A O T TU Berlin

IMS – Session Initiation - Signaling Flow (1/3)

Quelle: http://www.fokus.gmd.de/testbeds/ims_playground/Paper/FOKUS-IMS-Tutorial-public.pdfQuelle: http://www.fokus.gmd.de/testbeds/ims_playground/Paper/FOKUS-IMS-Tutorial-public.pdf

84A O T TU Berlin



85A O T TU Berlin



86A O T TU Berlin

IMS – Session Initiation - Zusammenfassung

•Reservierung der Media Resourcen notwendig

•Policy Decision Function (PDF) authorisiert QoS Resourcen anhand policies

•(GPRS) Packet Data Protocol (PDP) Context activation

•vor der Reservierung muss session ausgehandelt sein (PRACK, SIP early media negotiation)

•das alles sollte vor dem Klingeln geschehen (SIP „180 Ringing“)

87A O T TU Berlin

Diameter Protocol

Diameter:Request - Response Protocol, binary encoded, over reliable transport (e.g. TCP)Base Protocol (RFC 3588): Diameter sessions = exchange of commands and attribute value pairs(AVPs) between authorized Diameter clients and serversextensible for other applications through addition of new commands and AVPs

3GPP specific Diameter application: Cx, Dx interfaces: TS 29.228, Sh interface: TS 29.329, Codecs, identifiers: TS 29.230

Quelle: http://www-128.ibm.com/developerworks/library/wi-diameter/index.html

Example commands : Server Assignment Request and Answer(SAR/SAA) bei SIP REGISTER

S-CSCF -> HSS: „user isregistered!“, request userprofil information

SAR AVPs: IMPI, IMPU, S-CSCF, …SAA AVPs: IMPI, IMPU, User Profil, ChargingInformation (address of charging function), …

88A O T TU Berlin

89A O T TU Berlin

IMS – Sicherheitsaspekte (2)

Problem „early IMS“„early IMS“ = IMS der ersten Phase: keine IP6 fähigen Geräte / keine USIM/ISIM in den Endgeräten3GPP definiert „early IMS“ SecurityAber: nur ausgelegt für GPRS, keine Lösung für WLAN / xDSL

Quelle : ETSI TS 33.203-710

90A O T TU Berlin

IMS – Charging Function - Offline Charging

Offline Charging : users pay for their services periodically (e.g. at the end of month)

Charging Collection Function (CCF)collecting of Session charging information from the IMS nodes (by using Rf interface (Diameter))intermediate data storage buffering; call detail records (CDR)transfer of the charging data to the (operator’s chosen) billing systems (BS)

SIP message extension headers: P-Charging-Vector, P-Charging-Function-AddressInserted by P-CSCF and S-CSCFIdentifies: session, PDP-context, orginating / terminating network, CCF address

Visited(A) Visited(B)

Home(B)

ASAS

MRFCMRFC

S-CSCFS-CSCF

I-CSCFI-CSCF

P-CSCFP-CSCF

BGCFBGCF

BS

Rf

Home(A)

ASAS

AAA

MRFCMRFC

S - CSCFS - CSCF

I - CSCFI - CSCF

P - CSCFP - CSCF

BGCFBGCF

BS

RfAAA

AAABS

P-CSCFP-CSCFRf

BS

P - CSCFP - CSCFAAARf

PDSN PDSN

CCF CCF

91A O T TU Berlin

IMS – Charging Function - Online Charging

CCF

Charging information

flow

ISC

ITSITS

Online Charging System

Home(A) + Visited(A)

Re

Rb

Ro

Ro

Re

Rc

MRFCMRFC

AS(s)AS(s)

ISC

ITSITS

Online Charging System

Home(B) + Visited(B)

Re

Rb

Ro

Ro

Re

Rc

Account

Correlation FunctionBearer

Charging FunctionAccount

Correlation Function Bearer

Charging Function

RatingFunction

RatingFunction

S-CSCFS-CSCF S-CSCFS-CSCF

AS(s)AS(s)

MRFCMRFC SCCF

CPCF

SCCF

CPCF

SessionCharging Function

SessionCharging Function

EventCharging Function

EventCharging Function

SCF meldet accounting Informationen an Correlation Function (CF) (über Rb Diameter interface)Wenn Benutzer Kreditabgelaufen, Meldung von CF an SCF, SCF beendet session durchSIP BYE an Teilnehmer(agiert als B2BUA)

AS und MRFC melden Ereignisse an Event Charing Function (ECF) (aus SIP P-Charging-Function-Address header), ECF an CF

Online Charging: Prepaid Service, credit based charging

Session Charging Function (SCF) = AS, erhält “blind” SIP requests überUser Profil Filterregeln

92A O T TU Berlin

DAI – Labor IMS Aktivitäten

93A O T TU Berlin

NGN

94A O T TU Berlin

The role of SBCs in IMS and TISPAN based networks

http://www.newport-networks.com/downloads/DaveGladwinSBCsAndIMS.pdf

95A O T TU Berlin

IMS – NGN IMS Residential Gateway

96A O T TU Berlin

IMS - NGN Integration

Quelle: Alcatel, „Quality of Service for IMS on Fixed Networks“

97A O T TU Berlin

IMS – NGN Integration (2)

Quelle: http://www.itu.int/ITU-T/worksem/h325/200605/presentations/s1p4-brennan.pdf

Network Attachment Subsystem (NASS): Location Management, provisioning of IP addresses, IP authentication, authorization of network access

Resource Admission Control Subsystem (RACS): controls QoS resources, policies, NAT traversal, IPv4/IPv6 Protocol Translation, Security

98A O T TU Berlin

99A O T TU Berlin

SIP

100A O T TU Berlin

SIP - Session establishment (4)

Proxy 1 und Proxy 2 sind im signaling path der session durch Record-Routing

redirect server (vs. proxy server):

kein Weiterleiten der requests, bestimmt UAS location aus database und sendet sie in 3xx class response zurück

101A O T TU Berlin

SIP Erweiterungen – Erweiterungen für Session Kontrolle

PRACK Methode : bestätigt Erhalt der 1xx responses zum INVITE request (werden nun wie das 200 OK retransmitted, bis PRACK eintrifft)Eingeführt zur PSTN KompatibilitätBenutzt zum Aushandeln von „earlymedia“, SDP offer/answer werden schon in INVITE / 1xx / PRACK ausgetauscht

UPDATE Methode : Neuaushandlung wie re-INVITE für „early media“

INFO Methode : Session relevanteInformationen (Applikations-Ebene), z.B. „the user is currently typing something“

102A O T TU Berlin

SIP - Transaction and Dialogs

RFC 3261 : Protokoll Realisierung in verschiedenen logischen Ebenen – encoding, transport, transaction, transaction user (TU)

Transaction: umfasst request und alle responsestransaction layer verarbeitet retransmissions, message Zuordnung und request timeoutsZuordnung durch transaction identifier = branch parameter im Via header

Via: SIP/2.0/UDP 192.168.1.2:15890;

branch=z9hG4bK71d20bccbea3e3c145dc60466c44fb42

Dialog: Sequenz von transactionsPeer-to-peer Verbindung zw. zwei UAs über eine bestimmte ZeitVereinfachung des Routens, direkte KommunikationUA location vermittelt im Contact Header in request und response

Quelle: „SIP Introduction“, J. Janak.

103A O T TU Berlin

SIP Erweiterungen – Event Notification (1)

End-to-end notification (links) vs. zentraler Ansatz (rechts) mit PUBLISH und Event State Compositor (ESC) / Event Publishing Agents (EPA):

Documents

IP Multimedia Subsystem - aot.tu-berlin.de · Agententechnologien in betrieblichen Anwendungen und der Telekommunikation A O T IP Multimedia Subsystem Agententechnologien in der Telekommunikation