1 / 310

IMS Concepts

IMS Concepts. 3.1 Overview 3.2 Registration 3.3 Session initiation 3.4 Identification 3.5 Identity modules 3.6 Security services in the IMS 3.7 Discovering the IMS entry point 3.8 S-CSCF assignment 3.9 Mechanism for controlling bearer traffic. 3.10 Charging 3.11 User profile

espen
Télécharger la présentation

IMS Concepts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IMS Concepts

  2. 3.1 Overview 3.2 Registration 3.3 Session initiation 3.4 Identification 3.5 Identity modules 3.6 Security services in the IMS 3.7 Discovering the IMS entry point 3.8 S-CSCF assignment 3.9 Mechanism for controlling bearer traffic

  3. 3.10 Charging 3.11 User profile 3.12 Service provision 3.13 Connectivity between traditional Circuit-Switched users and IMS users 3.14 Mechanism to register multiple user identities at once 3.15 Sharing a single user identity between multiple terminals 3.16 SIP compression

  4. 3.1 Overview • Prior to IMS registration • P-CSCF discovery • UE discovers the IMS entity to which it will send a REGISTER request • Before a registration process • UE needs to fetch user identities from identity modules

  5. During the registration • a S-CSCF will be assigned • authentication will be performed • corresponding security associations will be established • a user profile will be downloaded to the assigned S-CSCF • SIP compression is initialized • implicitly registered public user identities will be delivered

  6. 3.2 Registration • Prior to IMS registration, which allows the UE to use IMS services • UE must obtain an IP connectivity bearer and discover an IMS entry point, P-CSCF for example • in the case of GPRS access • UE performs GPRS attach procedure • UE activates a Packet Data Protocol (PDP) context for SIP signalling

  7. IMS registration contains two phases (Figure 3.1) • 1st phase (the leftmost part) • how the network challenges the UE • 2nd phase (the rightmost part) • how the UE responds to the challenge and completes the registration

  8. First, the UE sends a SIP REGISTER request to the discovered P-CSCF (1) • this request would contain • an identity to be registered • a home domain name (address of the I-CSCF) • P-CSCF • processes the REGISTER request • uses the provided home domain name to resolve an IP address of the I-CSCF (2)

  9. I-CSCF • contacts the HSS to fetch the required capabilities for S-CSCF selection (3) • after S-CSCF selection • I-CSCF forwards the REGISTER request to the S-CSCF (4)

  10. S-CSCF • realizes that the user is not authorized • retrieves authentication data from the HSS (5) • challenges the user with a 401Unauthorized response(6-8)

  11. Second, the UE will calculate a response to the challenge and send another REGISTER request to the P-CSCF (9) • P-CSCF finds the I-CSCF (10) • I-CSCF finds the S-CSCF (11-12) • S-CSCF • checks the response • if it is correct, then downloads a user profile from the HSS (13) and accepts the registration with a 200OK response(14-16)

  12. Once the UE is successfully authorized • UE is able to initiate and receive sessions • During the registration procedure • both UE and P-CSCF learns which S-CSCF in the network will be serving the UE

  13. It is the UE's responsibility to keep its registrationactive by periodically refreshing its registration • otherwise, the S-CSCF will silently remove the registration when the registration timer lapses • When the UE wants to de-register from the IMS • it simply sends a REGISTER request including the registration timer (expire) value zero

  14. 3.3 Session initiation • When user A wants to have a session with user B (Figure 3.2) • UE A generates a SIP INVITE request • sends it via the Gm reference point to the P-CSCF (1) • P-CSCF processes the request • decompresses the request • verifies the originating user's identity before forwarding the request via the Mw reference point to the S-CSCF (2)

  15. S-CSCF processes the request • executes service control which may include interactions with application servers (ASs) • eventually determines an entry point of the home operator of user B based on user B'sidentity in the SIP INVITE request

  16. I-CSCF • receives the request via the Mw reference point (3) • contacts the HSS over the Cx reference point to find the S-CSCF that is serving user B (4) • the request is passed to the S-CSCF via the Mw reference point (5) • S-CSCF takes charge of processing the terminating session • includes interactions with application servers (ASs) • eventually delivers the request to P-CSCF over the Mw reference point (6)

  17. After further processing (e.g., compression and privacychecking) • P-CSCF uses the Gm reference point to deliver the SIP INVITE request to UE B (7) • UE Bgenerates a response, 183Session Progress(8), which traverses back to UE Afollowing the route that was created on the way from UE A(9-13) • UE B→ P-CSCF (B) → S-CSCF (B) → I-CSCF (B)→ S-CSCF (A) → P-CSCF (A) → UE A

  18. After a few more round trips • both sets of UE complete session establishment • can start the actual application (e.g., a game of chess)

  19. The high-level content of a SIP INVITE request is given in Table 3.2 • each column gives the information elements that are inserted, removed or modified

  20. 3.4 Identification 3.4.1 Identification of users 3.4.2 Identification of services (public service identities) 3.4.3 Identification of network entities

  21. 3.4.1 Identification of users 3.4.1.1 Private user identity 3.4.1.2 Public user identity 3.4.1.3 Derived public user identity and private user identity 3.4.1.4 Relationship between private and public user identities

  22. 3.4.1.1 Private user identity • A unique global identity defined by the home network operator • used within the home network to uniquely identifythe user from a network perspective [3GPP TS 23.228] • Mainly used for authentication purposes • Also used for accounting and administration purposes

  23. The IMS architecture imposes the following requirements for private user identity [3GPP TS 23.228, TS 23.003] • the private user identity will take the form of a network access identifier (NAI) [RFC2486] • the private user identity will be contained in all registration requests passed from the UE to the home network • the private user identity will be authenticated only during registration of the user (including re-registration and de-registration)

  24. the S-CSCF will need to obtain and store the private user identity on registration and on unregistered termination • the private user identity will not be used for routing of SIP messages • the private user identity will be permanently allocated to a user and securely stored in an IMS Identity Module (ISIM) application

  25. the private user identity will be valid for the duration of the user's subscription within the home network • it will not be possible for the UE to modify the private user identity • the HSS will need to store the private user identity • the private user identity will optionally be present in charging records based on operator policies

  26. 3.4.1.2 Public user identity • Public user identity • the user identity in IMS network • the identity used for requesting communication with other users • can be published (e.g., in phone books, Web pages, business cards)

  27. IMS users will be able to initiate sessions and receive sessions from many different networks, such as GSM networks and the Internet • to be reachable from the CS side • the public user identity must conform to telecomnumbering (e.g., +358 501234567) • to request communication with Internet clients • the public user identity must conform to Internetnaming (e.g., joe.doe@example.com)

  28. The IMS architecture imposes the following requirements for public user identity [3GPP TS 23.228, TS 23.003] • the public user identity/identities will take the form of either a SIP uniform resource identifier (URI) or a telephone uniform resource locator (tel URL) format • at least one public user identity will be securely stored in an ISIM application • it will not be possible for the UE to modify the public user identity

  29. a public user identity will be registered before the identity can be used to originate IMS sessions and IMS session-unrelated procedures (e.g., MESSAGE, SUBSCRIBE, NOTIFY) • a public user identity will be registered before terminating IMS sessions, and terminating IMS session-unrelated procedures will be delivered to the UE • the network will not authenticate public user identities during registration

  30. The tel URL scheme is used to express traditional E.164 numbers in URL syntax • The tel URL is described in [RFC2806], and the SIP URI is described in [RFC3261] and [RFC2396] • Examples of public user identities

  31. 3.4.1.3 Derived public user identity and private user identity • When the IMS is deployed there will be a lot of UE that does not support the ISIM application • a mechanism to access IMS without ISIM (IP Multimedia Services Identity Module) was developed • in this model, private user identity, public user identity and home domain name are derived from an International Mobile Subscriber Identifier (IMSI) • this mechanism is suitable for UE that has a Universal Subscriber Identity Module (USIM) application

  32. Private user identity • the private user identity derived from IMSI is built according to the following steps [3GPP TS 23.003] • the user part of the private user identity • replaced with the whole string of digits from IMSI • the domain part of the private user identity • composed of the MCC and MNC values of IMSI • a predefined domain name, IMSI.3gppnetwork.org

  33. these three parts are merged together and separated by dots in the following order • mobile country code (MCC, code uniquely identifying the country of domicile of the mobile subscriber) • mobile network code (MNC, a digit or a combination of digits uniquely identifying the public land mobile network) • predefined domain name

  34. Example：

  35. Temporary public user identity • if there is no ISIM application to host the public user identity, a temporary public user identity will be derived, based on the IMSI • the temporary public user identity will take the form of a SIP URI sip:user@domain

  36. the user and domain part are derived similarly to the method used for private user identity [3GPP TS 23.003] • example of a corresponding temporary public user identity would be sip:234150999999999@234.15.IMSI.3gppnetwork.org

  37. The IMS architecture imposes the following requirements for a temporary public user identity [3GPP TS 23.228] • it is strongly recommended that the temporary public user identity is set to "barred" for IMS non-registration procedures so that it cannot be used for IMS communication

  38. The following additional requirements apply if the temporary public user identity is "barred" • the temporary public user identity will not bedisplayed to the user and will not be used for public usage (e.g., displayed on a business card) • the temporary public user identity will only be used during the registration to obtain implicitlyregistered public user identities

  39. Implicitly registered public user identities will be used for session handling, in other SIP messages and at subsequent registration processes • After the initial registration only the UE will use the implicitly registered public user identity(s) • The temporary public user identity will only be available to CSCF and HSS nodes

  40. 3.4.1.4 Relationship between private and public user identities • An example shows how different identities are linked to each other • Joe is working for a car sales company and is using a single terminal for both his work life and his personal life • to handle work-related matters he has two public user identities • sip:joe.smith@brandnewcar.com • tel:+358 50 1234567

  41. when he is off-duty he uses two additional public user identities to manage his personal life • sip:joe.smith@ims.example.com • tel:+358503334444 • by having two sets of public user identities he could have totally different treatment for incoming sessions • for example, he is able to direct all incoming non-work-related sessions to a messaging system after 5p.m. and during weekends and holidays

  42. Joe's user and service-related data are maintained in two different service profiles • one service profile contains information about his work life identities and is downloaded to the S-CSCF from the HSS when needed, i.e. • when Joe registers a work life public user identity, or • when the S-CSCF needs to execute unregistered services for a work life public user identity

  43. another service profile contains information about his personal life identities and is downloaded to the S-CSCF from the HSS when needed • Figure 3.3 shows how Joe's private user identity, public user identities and service profiles are linked together

  44. 3.4.2 Identification of services (public service identities) • With the introduction of standardized presence, messaging, conferencing and group service capabilities • there must be identities to identify services and groups that are hosted by ASs • Identities may be created by the user on an as-needed basis in the AS and are not registered prior to usage • Release 6 introduced a new type of identity, the publicservice identity

More Related