360 likes | 547 Views
Presents 2005 IMTC Forum. Video Telephony and IMS. Alex Afshar Dilithium Networks. Overview. What is IMS? IMS Architecture IMS Building Blocks IMS Services IMS QoS IMS Limitations & Obstacles Summary. 3G UMTS Network Architecture. Public Land Mobile Network (PLMN). Core Network.
E N D
Presents 2005 IMTC Forum
Video Telephony and IMS Alex Afshar Dilithium Networks
Overview • What is IMS? • IMS Architecture • IMS Building Blocks • IMS Services • IMS QoS • IMS Limitations & Obstacles • Summary IMTC Forum – May 2005 – Eibsee, Germany
3G UMTS Network Architecture Public Land Mobile Network (PLMN) Core Network Radio NetworkSystem (RNS) Circuit Switched (CS) GMSC MSC RNC NodeB CS Packet Switched (PS) SGSN GGSN IMS Core PS • Radio Network Controller (RNC) transmits separately CS data and PS data to MSC and SGSN respectively. • 3G-324M Videotelephony today is purely in the CS domain (the PS is NOT involved) • The PS domain is where IP Multimedia Subsystem (IMS) traffic is. IMTC Forum – May 2005 – Eibsee, Germany
Conversational Multimedia and 3G • Video telephony and video conferencing are essential to 3G carriers to differentiate their 3G services from 2/2.5G services • Essential to recover high cost of entry in certain markets • With the rapid growth of videotelephony and conferencing over fixed packet networks (cable, DSL) mobile videotelephony is getting an extra pull. • Technology advances and handset evolution are both minimizing differential costs of videotelephony mobile handsets versus voice/data only handsets.
Internet Protocol (IP) Multimedia Subsystem (IMS) • Convergence of Cellular/Mobile with the Internet – Two $$$huge$$$ markets • Provide mobile users to access all internet services from their turn-key cell phone: voice, video, data • Create new revenue opportunities through the availability of enabling technologies and services such as Presence, Instant Messaging, Push-to-Talk, etc… IMTC Forum – May 2005 – Eibsee, Germany
Internet is already in 2.5G (GPRS) so why IMS? • 3G Provides native packet access, so performance is significantly better • 3G IMS is designed with Quality of Service in mind (almost), so new services and better user experience • 3G IMS uses SIP and SIP extensions, so provides more integrated services. • 3G IMS defines a number of traffic models so it’s easier to bill services based on classes of traffic. IMTC Forum – May 2005 – Eibsee, Germany
IMS Development Requirements (by 3GPP) • Support for Establishing IP Multimedia Sessions • Support for QoS Negotiation • Support for interworking with Internet and Circuit Switched networks • Support for roaming • Support for strong control by operators on services to users • Support for rapid service creation w/o requiring standardisation • Support for access independence (independent from GPRS) IMTC Forum – May 2005 – Eibsee, Germany
IMS Services • Presence (enabling technology and service) • Instant Messaging & Document sharing • Push to Talk • Push to Show/See • Voice over IP • Voice & Video over IP – Videotelephony & conferencing • and many other applications that build-on and combine above… IMTC Forum – May 2005 – Eibsee, Germany
IMS Network Architecture IMTC Forum – May 2005 – Eibsee, Germany
Presence – The foundation of services • Presence allows people to know the address and state of their bodies (communication address, capabilities of terminal, availability to establish a communication) • But also they allow SERVICES to take advantage of the information, e.g.: • Voice/Videomail server detects a user gets on-line and hence pings them with a mail notification. • A streaming server/conferencing system detects the capabilities of the terminal and adjusts according to the network/bandwidth. • Combination of location-based information to provide localized information. IMTC Forum – May 2005 – Eibsee, Germany
The Presence Service • Service that allows users to be informed (if authorised) about the reachability, availability and willingness of communication of another user. • Also allow users to give detail terminal-specific capabilities (e.g. audio, video, IM, etc…) SUBSCRIBE/NOTIFY PUBLISH BobPresentity Alice Presentity Presence Agent (PA) LeePresentity Presence User Agents (PUAs) IMTC Forum – May 2005 – Eibsee, Germany
IMS Presence • Presence Agent (PA) – Receives and store the presentity information. • A “watcher” SUBSCRIBEs to this information through a SIP request to the PA. • The PA NOTIFYs the watcher when a change in the presentity has occurred. • The watcher terminal can displays the changes information. • Further “presence richness” is introduced by the Rich Presence Information Data Format. IMTC Forum – May 2005 – Eibsee, Germany
IMS Presence Architecture • Introduced in 3GPP Release 6 (TS 23.141) • A Presentity PUBLISHes its presence information by the means of Presence Information Data Format (PDIF) document encoded using XML. <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" entity="pres:someone@example.com"> <tuple id="sg89ae"> <status> <basic>open</basic> </status> <contact priority="0.8"> tel:+09012345678 </contact> </tuple> </presence> IMTC Forum – May 2005 – Eibsee, Germany
Push to Talk Service • Walkie-Talkie type service – similar to what Nextel in US and others now offer in many countries • Expected to be the first IMS service to build on presence and to combine with data (HTTP browser access) • Voice can be carried over packet with “minimal” QoS issues (as compared to issues faced in conversational services). • Attractive as it can combine voice and data to offer with presence a richer multimedia experience • Provides one-to-one and group sessions (ad-hoc or pre-arranged). • Groups can have lists which are managed and maintained on the network. IMTC Forum – May 2005 – Eibsee, Germany
Push to Talk over Cellular Architecture & Protocols XCAP XCAP SIP XCAP SIP SIP RTP/RTCP RTP/RTCP IMTC Forum – May 2005 – Eibsee, Germany
PoC Architecture Simplified • OMA PoC Needs: • GPRS – The Radio Network to get to the IP Services • IMS – The IP Facilitator • The OMA Services • Aggregation Proxy • PoC Application Server • Shared XDMS (XML Document Management Server) • Presence Application Server • Handsets with PoC Clients PRS RNC Agg Proxy Shared XDMS IMS PoC IMTC Forum – May 2005 – Eibsee, Germany
PoC Client • The PoC Client resides on the mobile terminal and is used to access the PoC service. • The PoC Client is expected to perform the following as a minimum: • Allow PoC Session initiation, (e.g. codec negotiation), participation (e.g., talk or listen), and release. • Perform registration with the SIP/IP Core. • Authentication of the PoC User to the SIP/IP Core. • Support Talk Burst Control procedures and Talk Burst Control Protocol negotiation. • Incorporate PoC configuration data provided by the DM Client. • Support the capability of a PoC User to set the Answer Mode Indication (Manual Answer, Automatic Answer) the Incoming PoC Session Barring and Incoming Instant Personal Alert Barring. • Support User Plane adaptation procedures if initiated by the PoC Server. • Support receiving of Instant Personal Alert IMTC Forum – May 2005 – Eibsee, Germany
How Does PoC Work? (1) • Aggregation Proxy • Maintains IP connection with UE • Performs Authorization Function • Routes XML Requests to other Services • Allows the UE to have 1 IP Address for all Services PRS RNC Agg Proxy Shared XDMS IMS PoC UE IMTC Forum – May 2005 – Eibsee, Germany
How Does PoC Work? (2) • Shared XDM Server • XML Document Management Server • Stores any XML document • Supports XCAP • A document manipulation protocol for XML • All Contact Lists and Groups are provided in XML • UE downloads Lists and Groups from S-XDMS PRS RNC Agg Proxy Shared XDMS IMS PoC UE PoC IMTC Forum – May 2005 – Eibsee, Germany
How Does PoC Work? (3) • PoC Application Server • Responsible for Call Setup/Teardown • Includes the App Logic and Media Gateway • All subscribers are provisioned on it • May perform Controlling or Participating Function PRS RNC Agg Proxy Shared XDMS IMS PoC PoC IMTC Forum – May 2005 – Eibsee, Germany
PoC Server (Controlling Function) • A PoC Server Controlling Function is expected to perform the following functions: • Provides centralized PoC Session handling • Provides the centralized media distribution • Provides the centralized Talk Burst Control functionality including Talker Identification • Provides SIP Session handling, such as SIP Session origination, release, etc. • Collects and provides centralized media quality information • Provides centralized charging reports • Supports User Plane adaptation procedures • Support Talk Burst Control Protocol negotiation • and more… • Provide transcoding between different codecs when needed and when on Media path. IMTC Forum – May 2005 – Eibsee, Germany
PoC Codecs • AMR-NB is mandated by 3GPP • AMR-WB is mandated by 3GPP if available on UE. • EVRC is mandated by 3GPP2 IMTC Forum – May 2005 – Eibsee, Germany
IMS Quality of Service • Support for several models: • Link-Layer resource reservation, e.g. Policy Decision Point context activation in GPRS • RSVP (Resource ReSerVation Protocol) • DiffServ (Differentiated Services) • P-CSCF can modify SDP to instruct terminals to perform resource reservation for media using the Single Reservation Flow semantics (RFC 3524) of the SDP grouping framework (RFC 3388). • SDP grouping framework allows to group media streams and describe semantics of the group, e.g. lip-synch • For example, “a=group” SDP line carries semantic of a group (e.g. LS for lip-sync) and “a=mid” carries identifier of a media id. • SRF semantic indicate that all media streams in the group should use the same resource reservation flow. IMTC Forum – May 2005 – Eibsee, Germany
IMS Quality of Service (Cont.) • IMS Terminals needs to reserve resources (e.g. by creating a secondary PDP Context in GPRS) once being instructed by P-CSCF. • Four traffic classes are defined: Best Effort, Interactive, Streaming and Conversational. Note PDP context used for SIP signalling is always Conversation. • The GGSN receives traffic from a terminal over a PDP context, assigns appropriate DSCP (Differentiated Services Codepoints) and send to network (expected to support DiffServ). IMTC Forum – May 2005 – Eibsee, Germany
IMS Limitations & Obstacles • Most deployments will build on GPRS, and hence will inherit GPRS’s limitations • Co-location of GGSN and P-CSCF in Home Network (Media Traffic) • Deployments will be patchy, meaning signalling traffic will be all over the place. • QoS will be a challenge • IOT – Expect many challenges because many new standards are being drafted as products are being built. • BUT IT IS GOING TO BE BIG!!! IMTC Forum – May 2005 – Eibsee, Germany
QoS Barrier to Conversational VT Public Land Mobile Network (PLMN) Core Network Radio NetworkSystem (RNS) Circuit Switched (CS) QoS Barrier GMSC MSC RNC NodeB CS Packet Switched (PS) SGSN GGSN IMS Core PS • Radio Network Controller (RNC) transmits separately CS data and PS data to MSC and SGSN respectively. • 3G Videotelephony today is purely in the CS domain (the PS is NOT involved what-so-ever) • The PS domain is IP Multimedia Subsystem (IMS) traffic is. IMTC Forum – May 2005 – Eibsee, Germany
Characteristics of Conversational Multimedia • Real-time communication of audio, video and data. • End-to-end delay preferably under 400ms • Audio/Video synchronized to within 100ms. • Video frame rate as high as possible (~15 fps) • As good quality of audio and video as possible IMTC Forum – May 2005 – Eibsee, Germany
RTP/UDP/IPv4 headers RTP payload vs. headers overhead RTP payload 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 14 32 61 100 200 500 750 1000 1250 RTP payload size (bytes) Packetization & Encapsulation Overheads • Overheads of RTP/UDP/IPv6 compared to 3G-324M. • Transport overheads (IPv6) Source: 3GPP TS 26937 Packet based VT incurs about 25% additional overheads compared to 3G-324M, in typical conditions. IMTC Forum – May 2005 – Eibsee, Germany
Summary • IMS will bring another revolution into personal mobile communication • It introduces a number of enabling technologies that will find applications in many services across many economies – So market is huge • Most initial deployments will rely on presence, voice, images, video-clips and data (document sharing) • Conversational video will come next. • Pave the way towards an all-packet transport IMTC Forum – May 2005 – Eibsee, Germany
IMS Architecture, Protocols & Interfaces IMTC Forum – May 2005 – Eibsee, Germany
IMS Building Blocks • Most building blocks are SIP proxies or servers: • P-CSCF: Proxy Call/Session Control Function. First contact point between UE and IMS network. Verify and routes all SIP traffic. Depending on access technology (e.g. GPRS) may have to be located in Home Network (with GGSN). • I-CSCF: Interrogating CSCF is a SIP proxy who’s address is listed in the DNS records of the domain. Access to HSS (Home Subscriber Server – new HLR) through Diameter (AAA protocol) and may encrypt parts of SIP messages that contain sensitive info. Typically first hop in a destination domain. Typically located in Home network. • S-CSCF: Serving CSCF. Plays a central role in the signalling. SIP server that performs session control and is a registrar. Also access HSS • SIP Application Servers (AS) – Typically either a SIP User Agent, SIP Proxy, SIP Server or SIP B2BUA. • Other gateways providing access to legacy services (i.e. PSTN, OSA, CAMEL, …) which have SIP interfaces on IMS side and native legacy interfaces on external sides. IMTC Forum – May 2005 – Eibsee, Germany
IMS UE Registration Procedure • UE registers with access network (e.g. GPRS) – IP-CAN (IP Connectivity Access Network) • P-CSCF Discovery, either: • Part of IP-CAN. In GPRS part of PDP activation, or • Separate standalone procedure (using DHCPv6). Now UE has IP address, domain-name, and IP address of P-CSCF. • IMS Level Registration: The UE issues a REGISTER SIP request which goes through P-CSCF → I-CSCF → S-CSCF at end of which (after authorization from HSS) it gets an OK and the Public User Identity is bound to a contact address. IMTC Forum – May 2005 – Eibsee, Germany
IMS Presence Architecture • Introduced in 3GPP Release 6 (TS 23.141) Watcher (AS) PA (AS) PUA (AS) RLS (AS) IMTC Forum – May 2005 – Eibsee, Germany