Public Service Identity (PSI) : Role defined

PSI identifies a service (presence, messaging, conferencing etc.), or a specific resource created for a service on an application server and is based on local configuration policy, so PSI can be routed over Inter Operator Network to Network Interface.

These PSI are created on the fly i.e. they may be created by the user on an as -needed basis in the AS and are not registered prior to usage.

Usage: 

Public service identities take the form of  SIP URI or are tel URL format.

In messaging services there is a public service identity for the messaging list service (e.g., sip:sms@irns.example.com) to which the users send messages and messaging list server. 

The same applies to conferencing services (i.e., audio/video and then the messages are distributed to other members on the messaging list by the messaging sessions), where a URI for the conferencing service is created.

Initial Filter Criteria : IFC

Initial Filter Criteria (IFC) :

Service-triggering information is presented in the form of initial filter criteria. Initial

filter criteria describe when an incoming SIP message is further routed to a specific AS. Service-specific data are represented as initial filter criteria.

The main components for understanding the IFC are trigger point and application server.

Trigger point :

The trigger point describes conditions that should be checked to discover whether the

indicated AS should be contacted. The absence of a trigger point will indicate unconditional

triggering to an AS. Each trigger point contains one to multiple instances of the

Service Point Trigger. Service Point Triggers may be linked by means of logical expressions

(AND, OR, NOT).
Service point triggers have following components.

• Request-URI class defines SPT for the Request-URI. Request-URI contains attribute RequestURI.
• SIP Method class defines SPT for the SIP method. SIP Method contains attribute Method which holds the name of any SIP method.
• SIP Header class defines SPT for the presence or absence of any SIP header or for the content of any SIP header. SIP Header contains attribute Header which identifies the SIP Header, which is the SPT, and the Content attribute defines the value of the SIP Header if required.The absence of the Content attribute and ConditionNegated = TRUE indicates that the SPT is the absence of a determined SIP header.
• Session Case class represents an enumerated type, with possible values "Originating", "Terminating_Registered", "Terminating_Unregistered", "Originating_Unregistered", "Originating_CDIV" indicating whether the filter should be used by the S-CSCF handling the Originating, Terminating for a registered end user, Terminating for an unregistered end user, Originating for an unregistered end user, or Originating after Call Diversion services. An originating case refers to when the S-CSCF is serving the calling user. A terminating case refers to when the S-CSCF is serving the called user.
• Session Description Information class defines SPT for the content of any SDP field within the body of a SIP Method. The Line attribute identifies the line inside the session description. Content is a string defining the content of the line identified by Line.

Application Server (AS) :

The Application Server (AS) defines the AS that is contacted if the trigger points are met. The AS may contain information about the default handling of the session if contact with the AS fails. Default handling will either terminate the session or let the session continue based on the information in the initial filter criteria.
Use case : If the contacted AS does not respond, then the S-CSCF follows the default-handling procedure associated with initial filter criteria: that is, either terminate the session or let the session continue based on the information in the filter criteria. If the initial filter criteria do not contain instructions to the S-CSCF regarding the failure to contact the AS, then the S-CSCF will let the call continue as the default behaviour. 

Sharing single user identity among multiple devices : single IMPU to multiple IMPI

In IMS between IMPU and IMPI many to many relationship is possible. so lets see how this is possible and what are the use cases.

Lets have an example in which we have 3 UE.
UE1 : only audio call capable.
UE2 : Video call capable.
UE3 : Gaming console.

so having same IMPU shared among these three IMPIs we how we can come to know to which IMPI call will be terminated.

This decision making can be done by S-CSCF by knowing the type of service and capability of devices.
And same can be achieved by forking as well.
There are two types of forking:
1. Sequential forking :
    Sequential forking means that different items of UE are contacted one by one.  Timeout has been maintained for contacting devices.
2. Parallel forking
    Parallel forking means that different items of UE are contacted at the same time. Only one session will be established.

ISIM : IP Multimedia Services Identity Module

ISIM has following six modules stored.


Security keys :
Security keys consist of integrity keys, ciphering keys and key set identifiers. Integrity keys are used to prove integrity protection of SIP signalling. Ciphering keys are used to provide confidential protection of SIP signalling.

Private User Identity :
The private user identity simply contains the private user identity of the user. It is used in a registration request to identify the user’s subscription.

Public User Identity :
The public user identity contains one or more public user identities of the user. It is used in a registration request to identify an identity to be registered and is used to request communication with other users.

Home NW Domain Name :
The home network domain name consists of the name of the entry point of the home network name (address of the Interrogating-CSCF, or I-CSCF).

Administrative data:
Administrative data include various data, which could be used, say, by IMS subscribers for IMS operations or by manufacturers to execute proprietary auto-tests.

Access Rule Reference:
Access rule reference is used to store information about which personal identification number needs to be verified in order to get access to the application.

NASS Bundled IMS Authentication : Detailed

The Network Attachment Subsystem (NASS) provides registration at access level and initialization of User Equipment (UE) for accessing to the TISPAN NGN services. The NASS provides network level identification and authentication, manages the IP address space of the Access Network and authenticates access sessions. The NASS also announces the contact point of the TISPAN NGN Service/Applications Subsystems to the UE. Network attachment through NASS is based on implicit or explicit user identity and authentication credentials stored in the NASS. 

 

Subsystem Discovery :

The contact information provided by the NASS should either be in the form of the IP address of the contact point or in the form of the FQDN of the contact point (in which case the NASS provides the IP address of the DNS server that is able to resolve this FQDN into the IP address of the contact point). Alternatively, the contact point to the TISPAN NGN Service/Applications Subsystems may be statically configured in the UE e.g. using Fully Qualified Domain Names (FQDN) and DNS resolution to retrieve the contact points IP addresses. This option applies in the non-roaming case. 

NASS Bundled IMS Authentication

NASS based models do not implement any authentication mechanism at all, to reduce authentication delay. The IMS users are authenticated by underlying access network authentication and their identity and their IP address are sent to IMS network as the proof of authentication. Both solutions assume anti-spoofing mechanisms in access networks while forging of IP address would lead to forged identity in IMS network. The security level of IMS network corresponds to the security level of underlying access network.

Initial registration using NASS-IMS bundled authentication

@I-CSCF

Different UEs, each with its own private user identity, can register the same shared public user identity. Registrations of all public user identities belonging to these UEs are directed to the same S-CSCF.

If the REGISTER request does not include an Authorization header field and private user identity, the I-CSCF shall derive the private user identity from the public user identity being registered, contained in the To header field, by removing URI scheme and the following parts of the URI if present: port number, URI parameters, and To header field parameters.

@ S-CSCF- HSS

Upon receipt of a REGISTER request without the "integrity-protected" header field parameter in the Authorization header field or without an Authorization header field, which is not for an already registered public user identity linked to the same private user identity, the S-CSCF shall:

1)   identify the user by the public user identity as received in the To header field of the REGISTER request and if the Authorization header field is present, the private user identity as received in the Authorization header field of the REGISTER request. If the Authorization header field is not present, the S-CSCF shall derive the private user identity from the public user identity being registered by removing SIP URI scheme and the following parts of the SIP URI if present: port number, URI parameters, and To header field parameters;

2)   check whether one or more Line-Identifiers previously received over the Cx interface, and stored as a result of a Authentication procedure with the HSS, are available for the user. If not, the S-CSCF performs the Authentication procedure with the HSS, in order to obtain these Line-Identifiers;

3)   in the particular case where the S-CSCF received via the Cx interface one or more Line-Identifiers, compare each of Line-Identifiers with the "dsl-location", "eth-location" or "fiber-location" parameter of the P-Access-Network-Info header field (if present and if it includes the "network-provided" parameter):

-     if one of these match, the user is considered authenticated.

-     otherwise i.e. if these do not match, return a 403 (Forbidden) response to the REGISTER request; and

4)   if no Line-Identifier is received over the Cx interface, send a 500 (Server Internal Error) response to the REGISTER request.