Kỹ thuật IMS part 56

Identification Identities of the user Public User Identities sip:marek@mydomain.com tel:+48 22 8259820 ms@mobile.com Abonent IMS Private User Identity sip:ms@pw.com tel:+48 602 210799 Identities of the user and user’s service profiles sip:marek@mydomain.com Service Profile tel:+48 22 8259820 ms@mobile.com Public User Identities IMS subscriber Private User Identity User’s Profile related with Private User Identity and with a set Public User Identities sip:ms@pw.com Service Profile tel:+48 602 210799 User’s Profile Identification in IMS    A need for a unique identification Private and Public ids Public User Identity     More than one PUI (Public User Identity) SIP URI or TEL URI sip:+48-8323546@telekom.pl; user=phone tel:+48-22-8323546 TEL URI required for IMS-PSTN calls At least one TEL URI and one SIP URI per user IMS User Identity (1/2)   Each IMS User has at least one private and one or more public User Identities IMS Private User Identity:    belongs to the IMS operator not used for routing of SIP messages uses the format defined in RFC 2486   Example: user-X@ims.operator.com“ stored on the ISIM card (in the mobile phone) and in the HSS (in the IMS User Profile) IMS User Identity (2/2)  IMS Public User Identity:    public and may be subject to Number Portability used for routing of SIP messages may use the SIP-URI format defined in RFC 3261 and/or the TEL-URI format defined in RFC 2806     Example SIP-URI: “sip:user-X@company-X.com“ Example TEL-URI: “tel:+491231234567” At least one Public User Identity is stored on the ISIM card All Public User Identities are stored in the HSS Public Service Identities (PSI)    Similar to public user identities, but allocated to services (ASs) rather than users Used to identify specific applications Servers (enablers), such as presence or group list servers Typically take the form of a SIP URI or TEL URI     sip: songdownload@t-online.de, presence@t-online.de, chat@partner.de tel: +49-900-123-456 PSIs are treated as PUIs, i.e easy routing of SIP requests to ASs (as end user systems  also called “service routing”) Public Service Identities are not authenticated  i.e., there is no corresponding private user (service) identity SIM, USIM and ISIM in 3GPP     UMTS terminals feature Universal Integrated Circuit Card (UICC) Stores subscription information, authenticaion keys, address book, message store Without UICC – only emergency calls Logical applications:    Subscriber Identity Module (SIM), Universal Subscriber Identity Module (USIM) IP Multimedia Service Identity Module (ISIM) ISIM   UICC application – 3GPP TS 31.103 Stores IMS data for    User authorization and authentication Terminal configuration ISIM might coexist with SIM and USIM ISIM  Private User Identity   Public User Identity   One or more SIP URIs assigned to a user Home Network Domain URI     Only one SIP URI containing the name of the home domain Used for resolving home network address during registration procedure Only one home network domain Long term secret   Authorization and computing of CK and IK keys IMS terminal uses IK and CK respectively for security and ciphering of SIP messages to/from P-CSCF 10 An example of a service 24 Several Application Servers providing services 25 Filter Criteria Triggering Example User initiates a SIP session by sending a SIP INVITE with header=A to its S-CSCF S-CSCF evaluates the SPTs and finds a match with the filter criteria X S-CSCF forwards request to AS1 AS1 performs any needed service logic and sends the SIP request back to the S-CSCF with a service related modification, i.e change header=A to header=B S-CSCF evaluates the SPTs and finds a match with the filter criteria Y S-CSCF forwards the request to AS2 AS2 performs any needed service logic and sends SIP request back to the SCSCF No more filter criteria, S-CSCF forwards this request to the next hop based on the route decision If in step 3, the header was not changed by AS1, then S-CSCF evaluates the SPTs and does not find a match and routes the request to the next hop Application Application Server Server SIP message now with header=B ISC Interface Incoming SIP Leg SIP message possibly modified INVITE Match Initial Filter Criteria Out-Going SIP Leg S-CSCF INVITE Filter Criteria X to AS1 SPT HeaderA priority Header = A Filter criteria Y to AS2 SPT HeaderB priority SIP message forwarded by S-CSCF Same logic for Mobile origination and Mobile termination On registration, the S-CSCF also checks filter criteria If there is a match, S-CSCF performs 3rd party registration to the AS which may execute services Models of AS operation AS functional model AS HSS Sh/Si Application Logic AS-ILCM AS-OLCM ISC S-CSCF AS terminating UA or Redirect server AS From: X To: Y Call -ID: Z SIP dialog #1 From: X To: Y Call -ID: Z SIP dialog #1 S -CSCF AS as initiating UA AS SIP dialog #1 S -CSCF From: X To: Y Call -ID: Z SIP dialog #1 From: X To: Y Call -ID: Z AS acting in SIP proxy mode AS From: X To: Y Call -ID: Z SIP dialog #1 From: X To: Y Call -ID: Z SIP dialog #1 SIP dialog #1 S -CSCF From: X To: Y Call -ID: Z SIP dialog #1 From: X To: Y Call -ID: Z AS acting in 3PCC / B2BUA mode AS From: X To: Y Call -ID: Z SIP dialog #1 From: X To: Y Call -ID: Z SIP dialog #2 SIP dialog #1 S -CSCF From: P To: Q Call -ID: R SIP dialog #2 From: P To: Q Call -ID: R AS „call” model AS SIP request SIP answer AS-ILCM AS-Logic SIP request AS-OLCM SIP answer Termination of a session by AS AS SIP BYE SIP 200 OK AS-ILCM AS-Logic AS-OLCM Session termination request forwarded by AS From: A To: B Call-ID:Y Cseq:Z SIP BYE AS AS-ILCM AS-Logic AS-OLCM SIP BYE From: A To: B Call-ID:Y Cseq:Z Session termination request initiated by AS AS AS-ILCM AS-Logic SIP BYE From: A To: B Call-ID:Y Cseq:Z AS-OLCM SIP BYE From: C To: D Call-ID:W Cseq:X Delivery of services by the AS – wrap up  S-CSCF determines that a call requires enhanced service processing   Based on filtering criteria, the S-CSCF determines the address of the Application server and relays the call to the AS function The Application Server receives the call and invokes the appropriate service logic taking one of the following actions:    Filtering may be based on calling / called party or other mechanism (defined by filtering criteria) eg SIP message type, header fields, etc Redirects the call to a new destination Send the call back through the S-CSCF in order to monitor subsequent call events (ie act as a SIP Proxy) The Application Server (based on some other input) can also set-up calls between other entities in the network (ie act as a B2BUA) 37 IMS service platform interfaces Source: T Magedanz (TU Berlin / Fraunhofer FOKUS) 38