in Leipzig, Germany ¡ In Slovakia since 2006 ¡ Working for Slovak Telekom since 2007 ¡ Post-grad studies at Slovak University of Technology since 2007 ¡ Worked and implemented SIP and IMS software as well as carrier platforms
agenda: Understand IMS services ¡ Besides that: ¡ Ask questions (how is it done in real-world, how did Slovak Telekom do that) ¡ Interrupt (I don’t understand, can you provide samples, can we skip that) ¡ Contribute (I’ve heard/read that…, I’m interested in…) ¡ Discuss…
Transport & Switching Networks Wireless Access Wireline Access IP Backbone Existing and newly emerging services Service & Network Control (QoS, Security, IP Mobility) Too costly, per-service network archit ecture Single/simple/cost-effective network infr astructure for existing & new services
Control Plane Service Architecture Applications/Services Plane HSS CSCF Access Network Other Networks Web Portal Application Servers Session Control Centralized Databases Media Control & Gateways Media Server
services ¡ The core and its services are independent from the access ¡ Layered architecture ¡ Transport, session control, applications ¡ Transparency through standard interfaces ¡ Session Control Layer ¡ End point registration, authentication ¡ Session establishment, routing, interconnect ¡ Application Layer ¡ Service Logic
AS) ¡ DIAMETER: HSS, (RACS/NASS, PCRF) ¡ Application Layer ¡ SIP/DIAMETER interface towards service control layer ¡ SIP/XCAP interface (based on HTTP) towards UE ¡ Call related application logic ¡ IMS service (e.g. Presence, PoC) ¡ Service Creation Environment ¡ Northbound integration through service APIs
the IM CN ¡ SIP compression, IPSec association, PDF interaction ¡ Interrogating-CSCF – Subscriber contact point ¡ Next-hop lookup from HSS, S-CSCF assignment and routing, THIG functionality ¡ Serving-CSCF – Service profile internal procedures ¡ Handling registration, challenging UE, routing decisions ¡ Responsible for Registration and Session Establishment, Charging Data Generation, Media content check
various protocols possible, e.g., HTTP REST, Parlay X ¡ Open Service Access (OSA) gateway ¡ Connect northbound to OSA Parlay based AS ¡ IM Service Switching Function (SSF) ¡ Connect northbound the AS layer to legacy services using IN protocols (e.g. INAP, CAMEL)
¡ Public Identification (assigned subscribers) ¡ Initial Filter Criteria (triggering AS interaction) ¡ Initial Filter Criteria (iFC) ¡ Trigger points with service point triggers (conditions when to interact) ¡ Application server (SIP URI for interaction)
from HSS during registration ¡ Subsequent filter criteria (sFC) provided by application server (beyond 3GPP R8) ¡ Allows dynamic definition of trigger points during application runtime
¡ I-CSCF for public service identities (PSI) à explicit access ¡ S-CSCF for services (of served users) à implicit access ¡ Applications have interface towards HSS ¡ User profile information ¡ Location information, service information ¡ Complexity of security, authorization, access interaction etc. all handled by the core
¡ Terminating AS (e.g., acting as user agent) ¡ Originating AS (e.g., wake up service, click to dial) ¡ SIP Proxy server (e.g., for SIP header manipulation) ¡ Back-to-back user agent (e.g., for deeper modifications in SIP dialog as supplementary service enabler)
to define a clear set of available communication services that are interoperable ¡ Stakeholders in RCS are all key players in the telecom market (operators, vendors) ¡ Develop concrete value propositions for different stakeholders in the ecosystem ¡ Initial focus was on enriched mobile communication services, now RCS is extending the same services to the fixed environment ¡ Collaborative effort to facilitate the introduction of commercial IMS based rich communication services over mobile and fixed networks ¡ Several releases available (Rel. 1-5, RCS-e aka Joyn) ¡ Focus on residential user segment ¡ Not “defined”, but PBX integration/support not defined ¡ Focus NOT on end device applications (iPhone, Android)
that can be launched from a capability enhanced address book (EAB) à EAB enriched call and enhanced messaging ¡ Rel. 1 ¡ EAB with capability exchange enables content sharing during a call and enhanced messaging (conversational view, chat). Backup/restore in network ¡ Mobile users only, direct relation with mobile operator ¡ Rel. 2 ¡ Introduction of broadband access, multiple clients, mobile phone required ¡ Network address book (NAB) allows synchronization (sharing btw. devices possible) ¡ Rel. 3 ¡ Enhanced services (presence states, messaging, network value added services) ¡ Content sharing outside voice call ¡ Single broadband access possible (w/o mobile phone) ¡ Rel. 4 ¡ LTE and fixed access enhancements, service enhancements ¡ Rel. 5 ¡ IP voice/video call, location sharing, service improvements
evolution to voice and text, which enables customers to send instant messages, video chat and exchange files in real time. All functions are built into the address book of mobile devices and based on the IMS. ¡ Enhanced Rel. 2 for faster time-to-market ¡ Powered by the five leading European mobile operators, incl. Deutsche Telekom ¡ Focused communication services (core services only) ¡ IM/Chat, file transfer, image/video share ¡ Social presence/profile information not mandatory ¡ Standard: “RCS-e provides a simple interoperable extension to voice and text today“
messaging (as in RCS R2) ¡ One-to-one chat ¡ Group chat ¡ Add. Features to Rel. 2 ¡ Store &forward for chat ¡ Typing/delivery notify ¡ File Transfer (as in RCS R2) ¡ Image/Video Share during CS phone call (as in RCS R2)
S-CSCF BGCF IBCF I-BGF RCS-e AS (Service) RCS-e AS (Config) ENUM A-BGF IPX Other MNO Mw Mi ISC Gm Mb Mb Ici Izi Mx SIP DNS Media Mw Ma I-CSCF HSS Cx Cx Diameter HTTP Sh Mb Mx
transfer +g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.ft" Image share +g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.gsma-is" Video share +g.3gpp.cs-voice Social presence information +g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.sp" Capability discovery via presence +g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.dp" Table 1: Complete SIP OPTIONS tag proposal for RCS-e
establishment ¡ SIP MESSAGE for notifications ¡ MSRP for one-to-one/group chat and file transfer ¡ RTP for video share ¡ AS functions (samples) ¡ Group chat ¡ Aggregation ¡ Accounting, policy
Addressing (URIs for send/recv, lists for relays) ¡ Scheme: msrp/msrps for TLS. TCP transport. ¡ Methods (e.g. SEND) and response codes (e.g. 200 OK) ¡ MSRP relays in the path ¡ More in RFC 4975 (protocol), RFC 4976 (relays)
in locating SIP servers ¡ NAPTR lookup ¡ SRV lookup ¡ A/AAAA lookup ¡ NAPTR resolves the preferred protocol and the DNS string to locate the service ¡ ngnlab.eu. 7200 IN NAPTR 10 50 "s“ "SIP+D2T“ _sip._udp.ngnlab.eu. ¡ SRV look-up for a NAPTR given address indicates the domain and port the service listens on ¡ _sip._udp.ngnlab.eu. 7200 IN SRV 0 0 5060 icscf.ngnlab.eu. ¡ A/AAAA to find the IP address of the domain name ¡ icscf.ngnlab.eu. 7200 IN A 147.175.103.213
users that want to use presence ¡ IFC ¡ AS: Presence Server ¡ TP: CNF (&) ¡ Method and ¡ PUBLISH or ¡ SUBSCRIBE ¡ Event ¡ Header: Event ¡ Content: .*presence.* P-CSCF Presence Server S-CSCF SUBSCRIBE 200 OK 200 OK NOTIFY SUBSCRIBE 200 OK 200 OK NOTIFY SUBSCRIBE 200 OK 200 OK NOTIFY UE
write and modify data stored in XML format on server ¡ Hard state presence information ¡ Watcher authorization ¡ Resource Lists ¡ XML document sub-trees and element attributes are mapped into HTTP URIs à direct access via XPath ¡ Various selections (e.g., one or more elements, children, attributes, content)
¡ XDMS is located on application layer ¡ Direct communication between UE and XDMS ¡ Use cases ¡ Store resource list ¡ Authorize buddies XDMS UE XCAP
other applications/enablers or with non- IMS clients ¡ Various protocols possible ¡ XCAP ¡ Parlay X ¡ HTTP REST ¡ Standardization approaches exist, e.g., GSMA OneAPI, RCS-e API
of services by using various enablers ¡ Standardization approaches (e.g. SCIM) ¡ Approach ¡ SIP AS towards the IMS using ISC ¡ Connecting to multiple AS via ISC, optionally also to other AS w/ different protocols
¡ Why is the IMS needed for some communications services? Is it? ¡ But I have heard of service X, why don’t they use the IMS? ¡ Will we build all future services on top of IMS? ¡ Are IMS services only those inherited from the Telco past? ¡ Will Telco’s deploy multiple IMS? IMS in the cloud? Share an IMS? ¡ Will IMS bring in new revenues? Is it cheaper to deploy services on the IMS compared to stand-alone deployments?
the IMS ¡ Sample services, incl. protocols and principles ¡ Other means of integrating IMS services /with IMS services ¡ Hopefully covered all open questions (last chance J)
1.2.2 Spec If you feel content where you hold the copyright is displayed within these slides and you do not like it, miss a link/reference, or want me to remove it altogether please let me know. Thanks to Eugen Mikoczy and Stephan Massner for contributing to the slides.
schumann
karlov
naradai
asial_edu
hugaomarques
cbtlibrary
gmoriki
signer
takashi_toyosaki
utokyoissr2360
stephaniewalter
malarkey
akmur
zenorocha
lauravandoore
bermonpainter
holman
thekraken
afnizarnur
aleyda
scottboms
matthewcrist
![Sebastian Schumann [email protected] @s_schumann sschumann Thank you!](https://files.speakerdeck.com/presentations/365c6d70899b01303e3812313d06f1ad/slide_54.jpg){kind=link}
