Jump to content

IP Multimedia Subsystem: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
controll -> control
Line 307: Line 307:
* http://www.bcr.com/bcrmag/2005/06/p18.php Article - IMS 101: What You Need To Know Now
* http://www.bcr.com/bcrmag/2005/06/p18.php Article - IMS 101: What You Need To Know Now
* http://www.tech-invite.com/ SIP/IMS Technical Portal
* http://www.tech-invite.com/ SIP/IMS Technical Portal
* http://www.linkbit.com/support-decoder.html Online SIP/IMS Protocol decoder




Revision as of 20:28, 3 August 2006

The IP Multimedia Subsystem (IMS) is a standardised Next Generation Networking (NGN) architecture for telecom operators that want to provide mobile and fixed multimedia services. It uses a Voice-over-IP (VoIP) implementation based on a 3GPP standardised implementation of SIP, and runs over the standard Internet Protocol (IP). Existing phone systems (both packet-switched and circuit-switched) are supported.

The aim of IMS is not only to provide new services but all the services, current and future, that the Internet provides. In this way, IMS will give network operators and service providers the ability to control and charge for each service. In addition, users have to be able to execute all their services when roaming as well as from their home networks. To achieve these goals, IMS uses open standard IP protocols, defined by the IETF. So, a multimedia session between two IMS users, between an IMS user and a user on the Internet, and between two users on the Internet is established using exactly the same protocol. Moreover, the interfaces for service developers are also based on IP protocols. This is why IMS truly merges the Internet with the cellular world; it uses cellular technologies to provide ubiquitous access and Internet technologies to provide appealing services.

History

  • IMS was originally defined by an industry forum called 3G.IP, formed in 1999. 3G.IP developed the initial IMS architecture, which was brought to the 3rd Generation Partnership Project (3GPP), as part of their standardization work for 3G mobile phone systems in UMTS networks. It first appeared in release 5 (evolution from 2G to 3G networks), when SIP-based multimedia was added. Support for the older GSM and GPRS networks was also provided.
  • Early IMS was defined to allow for IMS implementations that do not yet support all "Full IMS" requirements.
  • 3GPP2 (a different organisation) based their CDMA2000 Multimedia Domain (MMD) on 3GPP IMS, adding support for CDMA2000.
  • 3GPP release 6 added interworking with WLAN.
  • 3GPP release 7 added support for fixed networks, by working together with TISPAN R1.

Basic Principles

  • Different network architectures: IMS allows operators and service providers to use different underlying network architectures.
  • Terminal and user mobility: The mobile network provides terminal mobility (roaming), while user mobility is provided by IMS and SIP.

Fixed/Mobile Convergence

IMS was originally designed for mobile networks, but with the addition of TISPAN in release 7, fixed networks are supported too. This is called Fixed/Mobile Convergence (FMC), which became one of the key trends of the telecommunications industry in 2005.

The vision is for people to use one phone with one number, address book and voicemail bank, taking advantage of cheap, high-speed connectivity in their fixed-line home or office setting, while enjoying mobility outside in the wide-area mobile phone network. It also includes a seamless handover of calls between fixed-line and mobile networks.

Telecommunications operators can provide services to users irrespective of their location, access technology, and terminal. IMS guarantees interworking with existing phone systems, while providing an upgrade path for modern multimedia sessions (like a videophone).

Critics say that fixed operators are mainly interested in expanding their services in the area of mobile operators (and vice versa), while lowering their operational costs at the same time by using Voice over IP technology.

3GPP / TISPAN IMS Architectural Overview

Architecture

The IP Multimedia Core Network Subsystem is a collection of different functions, linked by standardized interfaces. A function is not a node (hardware box) : an implementer is free to combine 2 functions in 1 node, or to split a single function into 2 or more nodes. Each node can also be present multiple times in a network, for load balancing or organizational issues.

Access Network

The user can connect to an IMS network using various methods, all of which are using the standard Internet Protocol (IP). Direct IMS terminals (mobile phones, PDAs, computers, ...), can register directly into an IMS network, even when they're roaming in another network or country (the visited network). The only requirement is that they can use IPv6 (also IPv4 in 'Early IMS') and are running SIP User Agents. Fixed access (e.g., DSL, cable modems, Ethernet, ...), mobile access (W-CDMA, CDMA2000, GSM, GPRS, ...) and wireless access (WLAN, WiMAX, ...) are all supported. Other phone systems like the POTS (the old analogue telephones), H.323 and non IMS-compatible VoIP systems are supported through gateways.

Core Network

User Database

The HSS (Home Subscriber Server) is the master user database that supports the IMS network entities that are actually handling the calls/sessions. It contains the subscription-related information (user profiles), performs authentication and authorization of the user, and can provide information about the physical location of user. It's similar to the GSM HLR and AUC.

An SLF (Subscriber Location Function) is needed when multiple HSSs are used. Both the HSS and the SLF implement the DIAMETER protocol (Cx, Dx and Sh interfaces).

User identities

In normal 3GPP networks, the following identities are used;

  • International Mobile Subscriber Identity (IMSI)
  • Temporal Mobile Subscriber Identity (TMSI)
  • International Mobile Equipment Identity (IMEI)
  • Mobile Subscriber ISDN Number (MSISDN)

IMSI is a unique user identity that is stored in the SIM. To improve privacy, a TMSI is generated per geographical location. While IMSI/TMSI are used for user identification, the IMEI is a unique device identity and is phone specific. The MSISDN is the telephone number of a user.

With IMS, the following additional identities are implemented:

  • IP Multimedia Private Identity (IMPI)
  • IP Multimedia Public Identity (IMPU)

Both are not phone numbers or other series of digits, but URIs, that can be digits (a tel-uri, like tel:+1-555-123-4567) or alphanumeric identifiers (a sip-uri, like sip:john.doe@example.com).

The IMPI is unique to the phone, and you can have multiple IMPU per IMPI (often a tel-uri and a sip-uri). The IMPU can also be shared with another phone, so both can be reached with the same identity (for example, a single phone-number for an entire family).

The HSS user database contains, but is not limited to, the IMPU, IMPI, IMSI, and MSISDN.

Call/Session Control

Several roles of SIP servers or proxies, collectively called CSCF (Call Session Control Function), are used to process SIP signalling packets in the IMS.

  • A P-CSCF (Proxy-CSCF) is a SIP proxy that is the first point of contact for the IMS terminal. It can be located either in the visited network (in full IMS networks) or in the home network (when the visited network isn't IMS compliant yet). Some networks might use a Session Border Controller for this function. The terminal will discover its P-CSCF with either DHCP, or it's assigned in the PDP Context (in GPRS).
    • it's assigned to an IMS terminal during registration, and does not change for the duration of the registration
    • it sits on the path of all signalling messages, and can inspect every message
    • it authenticates the user and establishes an IPsec security association with the IMS terminal. This prevents spoofing attacks and replay attacks and protects the privacy of the user. Other nodes trust the P-CSCF, and do not have to authenticate the user again.
    • it can also compress and decompress SIP messages using SigComp, which reduces the round-trip over slow radio links
    • it may include a PDF (Policy Decision Function), which authorizes media plane resources e.g. quality of service (QoS) over the media plane. It's used for policy control, bandwidth management, etc ... The PDF can also be a separate function.
    • it also generates charging records
  • An I-CSCF (Interrogating-CSCF) is a SIP proxy located at the edge of an administrative domain. Its IP address is published in the DNS of the domain (using NAPTR and SRV type of DNS records), so that remote servers (e.g., a P-CSCF in a visited domain, or a S-CSCF in a foreign domain) can find it, and use it as an entry point for all SIP packets to this domain. The I-CSCF queries the HSS using the DIAMETER Cx and Dx interfaces to retrieve the user location, and then route the SIP request to its assigned S-CSCF. Up to Release 6 it can also be used to hide the internal network from the outside world (encrypting part of the SIP message), in which case it's called a THIG (Topology Hiding Interface Gateway). From Release 7 onwards this function is removed from the I-CSCF and is now part of the IBCF (Interconnection Border Control Function). The IBCF is used as gateway to external networks, and provides NAT and Firewall functions (pinholing).
  • An S-CSCF (Serving-CSCF) is the central node of the signalling plane. It's a SIP server, but performs session control as well. It's always located in the home network. The S-CSCF uses DIAMETER Cx and Dx interfaces to the HSS to download and upload user profiles - it has no local storage of the user.
    • it handles SIP registrations, which allows it to bind the user location (e.g. the IP address of the terminal) and the SIP address
    • it sits on the path of all signalling messages, and can inspect every message
    • it decides to which application server(s) the SIP message will be forwarded to, in order to provide their services
    • it provides routing services, typically using ENUM lookups
    • it enforces the policy of the network operator

Application Servers

Application servers (AS) host and execute services, and interfaces with the S-CSCF using SIP. This allows third party providers an easy integration and deployment of their value added services to the IMS infrastructure. Examples of services are:

Depending on the actual service, the AS can operate in SIP proxy mode, SIP US (user agent) mode or SIP B2BUA (back-to-back user agent) mode. An AS can be located in the home network or in an external third-party network. If located in the home network, it can query the HSS with the DIAMETER Sh interface (for SIP-AS and OSA-SCS) or the MAP interface (for IM-SSF).

  • SIP AS : native IMS application server
  • OSA-SCS : an Open Service Access - Service Capability Server interfaces with OSA Application Servers using Parlay
  • IM-SSF : an IP Multimedia Service Switching Function interfaces with CAMEL Application Servers using CAP

Media Servers

An MRF (Media Resource Function) provides a source of media in the home network. It's used for :

Each MRF is further divided into :

  • An MRFC (Media Resource Function Controller) is a signalling plane node that acts as a SIP User Agent to the S-CSCF, and which controls the MRFP with a H.248 interface
  • An MRFP (Media Resource Function Processor) is a media plane node that implements all media-related functions.

Breakout Gateway

A BGCF (Breakout Gateway Control Function) is a SIP server that includes routing functionality based on telephone numbers. It's only used when calling from the IMS to a phone in a circuit switched network, such as the PSTN or the PLMN.

PSTN Gateways

A PSTN/CS gateway interfaces with PSTN circuit switched (CS) networks. For signalling, CS networks use ISUP (or BICC) over MTP, while IMS uses SIP over IP. For media, CS networks use PCM, while IMS uses RTP.

  • An SGW (Signalling Gateway) interfaces with the signalling plane of the CS. It transforms lower layer protocols as SCTP (which is an IP protocol) into MTP (which is a SS7 protocol), to pass ISUP from the MGCF to the CS network.
  • An MGCF (Media Gateway Controller Function) does call control protocol conversion between SIP and ISUP, and interfaces with the SGW over SCTP. It also controls the resources in an MGW with a H.248 interface.
  • An MGW (Media Gateway) interfaces with the media plane of the CS network, by converting between RTP and PCM. It can also transcode when the codecs don't match (e.g. IMS might use AMR, PSTN might use G.711).

Charging

Offline charging is applied to users who pay for their services periodically (e.g., at the end of the month). Online charging, also known as credit-based charging, is used for prepaid services. Both may be applied to the same session.

  • Offline Charging : All the SIP network entities (P-CSCF, I-CSCF, S-CSCF, BGCF, MRFC, MGCF, AS) involved in the session use the DIAMETER Rf interface to send accounting information to a CCF (Charging Collector Function) located in the same domain. The CCF will collect all this information, and build a CDR (Charging Data Record), which is sent to the billing system (BS) of the domain.
    Each session carries an ICID (IMS Charging Identifier) as an unique identifier. IOI (Inter Operator Identifier) parameters define the originating and terminating networks.
    Each domain has its own charging network. Billing systems in different domains will also exchange information, so that roaming charges can be applied.
  • Online charging : The S-CSCF talks to an SCF (Session Charging Function), which looks like a regular SIP application server. The SCF can signal the S-CSCF to terminate the session when the user runs out of credits during a session. The AS and MRFC use the DIAMETER Ro interface towards an ECF (Event Charging Function), that also communicates with the SCF.
    • When IEC (Immediate Event Charging) is used, a number of credit units is immediately deducted from the user's account by the ECF and the MRFC or AS is then authorized to provide the service. The service is not authorized when not enough credit units are available.
    • When ECUR (Event Charging with Unit Reservation) is used, the ECF first reserves a number of credit units in the user's account and then authorizes the MRFC or the AS. After the service is over, the number of spent credit units is reported and deducted from the account ; the reserved credit units are then cleared.

Early IMS

There is a need for an IMS version that offers similar features but doesn't require the investments necessary for full IMS. This version has been defined as Early IMS, and has the following advantages:

  • The user entity does not have to support IPv6
  • The user entity does not require an USIM/ISIM
  • The user entity does not have to support IPsec

However, as some of the IMS security mechanisms rely on the presence of a USIM/ISIM, such as user identification, the use of Early IMS has security implications that should be acknowledged.

Advantages & Issues

Advantages over existing systems

  • The core network is independent of a particular access technology
  • Integrated mobility for all network applications
  • Easier migration of applications from fixed to mobile users
  • Faster deployment of new services based on standardized architecture
  • An end to unique or customized applications, leading to lower CAPEX and OPEX
  • New applications such as presence information, videoconferencing, Push to talk over cellular (POC), multiparty gaming, community services and content sharing.
  • Evolution to combinational services, for example by combining instant messaging and voice
  • User profiles are stored in a central location
  • The architecture is designed for easy scalability and redundancy

Differences with free VoIP

It's possible to run free VoIP applications over the regular Internet. Then why do we need IMS, if all the power of the Internet is already available for 3G users?

  • Quality of Service : The network offers no guarantees about the amount of bandwidth a user gets for a particular connection or about the delay the packets experience. Consequently, the quality of a VoIP conversation can vary dramatically throughout its duration.
    • Contrasting view: The underlying routing structure of the Internet can effectively eliminate bandwidth and latency issues for the vast majority of VoIP calls. And what the Internet itself doesn't handle can be handled by sophisticated audio processing at the terminal endpoints of calls.
      • Re-Contrasting view: The Internet Core network may handle bandwidth and latency issues, mainly due to statistical reasons. The problem with free VoIP is that the Internet Access Provider can not easily differentiate free VoIP service from any further bandwidth consuming application in the access network. Especially the last mile is the bottleneck and with IMS the ISP/operator can guarantee QoS since he "knows" which service (e.g. VoIP) has been requested by the user.
  • Charging of multimedia services : Videoconferences can transfer a large amount of information, but the telecom operator can't charge separately for this data. Some business models might be more beneficial for the user (for instance: a fixed price per message, not per byte); others might charge extra for better QoS.
    • Contrasting view: Complex charging structures are a legacy of the telephone industry and are not needed on Internet connections which are typically flat-rate. The cost of monitoring traffic to distinguish between different types of bytes greatly adds to the cost of delivering those bytes.
      • Re-Contrasting view: IMS charging is very simple and built-in. An unlimited flat-rate for all users would penalize the majority of users who are not interested in downloading several GBytes of movies per week. A flexible (volume, session - time & service, event based) charging architecture creates new opportunities and can be much more attractive for the end-user.
  • Integration of different services : an operator can use services developed by third parties, combine them, integrate them with services they already have, and provide the user with a completely new service. For example: if voicemail and text-to-speech is combined, a voice version of incoming text messages can be provided for blind users.
    • Contrasting view: IMS requires that all services be integrated into, and delivered by the operator's network. Therefore only those services that "pass muster" with the operator will be supplied to their customers. Operators must incur integration costs, and both the network operator and the third-party service offeror must reach a business agreement on the revenue model for offering the service. Third-party services that network operators don't - for whatever arbitrary reason - want to offer will never be seen by consumers. This is a dramatic difference from the Internet, where anyone can offer any website service to anyone with an Internet connection.
      • Re-Contrasting view: Any operator controlled service needs to be integrated to guarantee stability, quality, security and ease-of-use. With IMS the integration is just easier (e.g. due to centralized User database) and reduces costs (OPEX and CAPEX - e.g. due to service independent Call Session Controller). With IMS the end-user can expect Internet like services - just without more or less complicated log-in procedures or security concerns. For sure, the Internet community will always be faster in developing potential new applications.

Issues

  • Benefits need to be further articulated in terms of actual savings.
  • IMS is "operator friendly" which means that it provides the operator with comprehensive control of content at the expense of the consumer.
  • IMS uses the 3GPP variant of SIP, which needs to interoperate with the IETF SIP.
  • IMS is an optimization of the network, and investments for such optimization are questionable.
  • Some IMS proponents are trying to push it as the total solution for IP-based systems such as IPTV, which is causing push-back from companies wanting a much richer experience in land-line environments that dont have mobile constraints;
  • There are no products available other than paper machine;
  • The new services are the same of ISDN services, i.e, voice calls, video calls, etc. All the supposed new services already exists;
  • QoS is not a problem for voice calls. Skype revenues shows that;
  • Susbscribers won't accept that service providers controls what application they are running;
  • It's a useless control-layer.

Specifications

3GPP Specs

They can be downloaded from http://www.3gpp.org/specs/numbering.htm . The list below is a small selection.

  • TS 21.905 Vocabulary for 3GPP Specifications
  • TS 22.066 Support of Mobile Number Portability (MNP); Stage 1
  • TS 22.101 Service Aspects; Service Principles
  • TS 22.141 Presence Service; Stage 1
  • TS 22.228 Service requirements for the IP multimedia core network subsystem; Stage 1
  • TS 22.250 IMS Group Management; Stage 1
  • TS 22.340 IMS Messaging; Stage 1
  • TS 22.800 IMS Subscription and access scenarios
  • TS 23.002 Network Architecture
  • TS 23.003 Numbering, Addressing and Identification
  • TS 23.008 Organisation of Subscriber Data
  • TS 23.107 Quality of Service (QoS) principles
  • TS 23.125 Overall high level functionality and architecture impacts of flow based charging; Stage 2
  • TS 23.141 Presence Service; Architecture and functional description; Stage 2
  • TS 23.167 IMS emergency sessions
  • TS 23.207 End-to-end QoS concept and architecture
  • TS 23.218 IMS session handling; IM call model; Stage 2
  • TS 23.221 Architectural Requirements
  • TS 23.228 IMS stage 2
  • TS 23.234 WLAN interworking
  • TS 23.271 Location Services (LCS); Functional description; Stage 2
  • TS 23.278 Customized Applications for Mobile network Enhanced Logic (CAMEL) - IMS interworking; Stage 2
  • TS 23.864 Commonality and interoperability between IMS core networks
  • TR 23.867 IMS emergency sessions
  • TS 23.917 Dynamic policy control enhancements for end-to-end QoS, Feasibility study
  • TS 23.979 3GPP enablers for Push-to-Talk over Cellular (PoC) services; Stage 2
  • TR 23.981 Interworking aspects and migration scenarios for IPv4-based IMS implementations (early IMS)
  • TS 24.141 Presence Service using the IMS Core Network subsystem; Stage 3
  • TS 24.147 Conferencing using the IMS Core Network subsystem
  • TS 24.228 Signalling flows for the IMS call control based on SIP and SDP; Stage 3
  • TS 24.229 IMS call control protocol based on SIP and SDP; Stage 3
  • TS 24.247 Messaging using the IMS Core Network subsystem; Stage 3
  • TS 26.235 Packet switched conversational multimedia applications; Default codecs
  • TS 26.236 Packet switched conversational multimedia applications; Transport protocols
  • TS 29.162 Interworking between the IMS and IP networks
  • TS 29.163 Interworking between the IMS and Circuit Switched (CS) networks
  • TS 29.198 Open Service Architecture (OSA)
  • TS 29.207 Policy control over Go interface
  • TS 29.208 End-to-end QoS signalling flows
  • TS 29.209 Policy control over Gq interface
  • TS 29.228 IMS Cx and Dx interfaces : signalling flows and message contents
  • TS 29.229 IMS Cx and Dx interfaces based on the Diameter protocol; Protocol details
  • TS 29.278 CAMEL Application Part (CAP) specification for IMS
  • TS 29.328 IMS Sh interface : signalling flows and message content
  • TS 29.329 IMS Sh interface based on the Diameter protocol; Protocol details
  • TS 29.962 Signalling interworking between the 3GPP SIP profile and non-3GPP SIP usage
  • TS 31.103 Characteristics of the IMS Identity Module (ISIM) application
  • TS 32.240 Telecommunication management; Charging management; Charging architecture and Principles
  • TS 32.260 Telecommunication management; Charging management; IMS charging
  • TS 32.299 Telecommunication management; Charging management; Diameter charging applications
  • TS 32.421 Telecommunication management; Subscriber and equipment trace: Trace concepts and requirements
  • TS 33.102 3G security; Security architecture
  • TS 33.108 3G security; Handover interface for Lawful Interception (LI)
  • TS 33.141 Presence service; security
  • TS 33.203 3G security; Access security for IP-based services
  • TS 33.210 3G security; Network Domain Security (NDS); IP network layer security
  • TS 33.978 Security aspects of early IP Multimedia Subsystem (IMS)

IETF Specs

  • RFC 2327 Session Description Protocol (SDP)
  • RFC 2748 Common Open Policy Server protocol (COPS)
  • RFC 2782 a DNS RR for specifying the location of services (SRV)
  • RFC 2806 URLs for telephone calls (TEL)
  • RFC 2915 the naming authority pointer DNS resource record (NAPTR)
  • RFC 2916 E.164 number and DNS
  • RFC 3087 Control of Service Context using SIP Request-URI
  • RFC 3261 Session Initiation Protocol (SIP)
  • RFC 3262 reliability of provisional responses (PRACK)
  • RFC 3263 locating SIP servers
  • RFC 3264 an offer/answer model with the Session Description Protocol
  • RFC 3265 SIP-Specific Event Notification
  • RFC 3310 HTTP Digest Authentication using Authentication and Key Agreement (AKA)
  • RFC 3311 update method
  • RFC 3312 integration of resource management and SIP
  • RFC 3319 DHCPv6 options for SIP servers
  • RFC 3320 signalling compression (SIGCOMP)
  • RFC 3323 a privacy mechanism for SIP
  • RFC 3324 short term requirements for network asserted identity
  • RFC 3325 private extensions to SIP for asserted identity within trusted networks
  • RFC 3326 the reason header field
  • RFC 3327 extension header field for registering non-adjacent contacts (path header)
  • RFC 3329 security mechanism agreement
  • RFC 3420 Internet Media Type message/sipfrag
  • RFC 3428 SIP Extension for Instant Messaging
  • RFC 3455 private header extensions for SIP
  • RFC 3485 SIP and SDP static dictionary for signaling compression
  • RFC 3515 the SIP REFER method
  • RFC 3550 Real-time Transport Protocol (RTP)
  • RFC 3574 Transition Scenarios for 3GPP Networks
  • RFC 3588 DIAMETER base protocol
  • RFC 3589 DIAMETER command codes for 3GPP release 5 (informational)
  • RFC 3608 extension header field for service route discovery during registration
  • RFC 3665 SIP Basic Call Flow Examples
  • RFC 3680 SIP event package for registrations
  • RFC 3725 best current practices for Third Party Call Control (3pcc) in SIP
  • RFC 3824 using E164 numbers with SIP
  • RFC 3840 indicating user Agent Capabilities in SIP
  • RFC 3841 caller preferences for SIP
  • RFC 3842 SIP event package for message waiting indication and summary
  • RFC 3856 SIP event package for presence
  • RFC 3857 SIP event template-package for watcher info
  • RFC 3858 XML based format for watcher information
  • RFC 3891 the SIP Replaces Header
  • RFC 3903 SIP Extension for Event State Publication
  • RFC 3911 the SIP Join Header
  • RFC 4028 session timers in SIP
  • RFC 4235 an INVITE-Initiated dialog event package for SIP
  • RFC 4475 Session Initiation Protocol (SIP) Torture Test Messages

See also

External links

Retrieved from "https://en.wikipedia.org/w/index.php?title=IP_Multimedia_Subsystem&oldid=67505344"