IMS Public Service Identities (PSIs)

After IMS Public User Identities (IMPUs), here is a first post on the second type of identity specified in 3GPP IMS specifications. I will start with the basics.

The concept of IMS Public Service Identity (PSI) was introduced in 3GPP R6. Like an IMPU, a PSI might be defined as a SIP URI (e.g. sip:service@operator) or a TEL URI (e.g. tel:1-234-567890).

To read about PSIs as defined in 3GPP, check chapters 4.3.6 and 5.4.12 of TS 23.228.

Definition (Sort of)

According to TS 23.228, PSIs identify "services which are hosted by application servers". The specification then states that PSIs are used to identify user groups (i.e. sets of users). Is a "user group" a "service"? I do not think so, and this makes the definition of a PSI in 3GPP specifications a little bit ambiguous or short to say the least.

For me, a PSI identifies an IMS service related resource. This might be the service itself (e.g. PSI to change session from 2-party to multiparty, PSI used to retrieve service configuration information), a service feature (e.g. PSI used for starting an ad-hoc push to talk session), a service instance (e.g. PSI identifying a pre-defined conference, PSI identifying a specific content, PSI identifying a specific chat room), a user group (e.g. request to PSI should be exploded to every user in the group identified by the PSI). A PSI could also identify a specific service parameter, a bundling of individual services...

My terminology might not be very accurate, and my own definition is certainly not complete, but basically a PSI identifies anything you might want to identify as the initiator or recipient of a SIP request, which is not an IMS user (for which an IMPU will be used instead). The definition for PSI is therefore directly linked to how SIP and IMS will be used for the delivery of future services. The more IMS and SIP are used to deliver innovative services in an innovative manner, the more the definition for a PSI might be extended.

Prior to its introduction in 3GPP specifications, the concept was not formalized but already existed in practice. For instance, 3GPP already mentioned in R5 the possibility to name a conference through a specific SIP or TEL URI. Similarly, pre-OMA specifications of Push To Talk Over Cellular also made use of a specific SIP URI to start an ad-hoc push to talk session. Concerning the IETF, though it has not been conceptualized as in 3GPP, the possibility to use a SIP URI for something else than a user is common practice (as I once read in an IETF SIP-related RFC: "In the Internet nobody knows you're a dog").

"Private" or "Restricted Access" PSIs

The terms "Private PSI" and "Restricted Access PSI" do not exist in 3GPP specifications, so do not look for them elsewhere than on this blog! Note that the association of the term "private" to an acronym whose first letter means "public" might be a hint for one of two things 1) the author of this blog writes nonsense, 2) 3GPP might not have selected the best name for the concept. You chose.

Private and Restricted Access PSIs are only usable by subscribers of the operator that owns the PSIs. As you will see below (*spoiler*) this is because their routing is based on service profiles associated to the users initiating SIP requests to them.

A Restricted Access PSI can be used by users who are explicitly authorized to access the resource identified by the PSI, i.e. their subscription permits access to the resource. For instance, a specific video streaming content is accessible to a set of users who have paid for it.

A Private PSI has a specific meaning to a limited set of users, possibly a single one. For instance, a user group consisting of John's family members and identified by a PSI like sip:MyFamily@operator, may be accessible by John alone, or John and the members of his family. Other IMS users (e.g. Mary) might have a user group with the same name, but for them this name will point at another group definition (e.g. another family).

Routing of SIP requests addressed to a Private or Restricted Access PSI is determined by the service profiles associated to the users who are authorized to use this PSI. More precisely, their service profile stored in the HSS includes one or several initial filter criteria(s) which determine(s) how a SIP request originating from this user and addressed to this PSI must be routed.

"Really Public" PSIs

"Really Public" PSIs are usable by anybody, including subscribers of other operators than the one that owns the PSI.

As they must be globally routable across various IMS domains (e.g. the request addressed to the PSI may originate from another IMS nettork or from the Internet), 3GPP had to define specific means to route SIP requests addressed to these PSIs. This is actually the reason why the concept was introduced in 3GPP specifications, and the reason for the name of the "public" in PSI.

3GPP was very generous with Really Public PSIs, as it standardized no less than 3 alternative ways to route them (4 if you count 2 sub-variants for subdomain based routing). Considering the complexity and cost induced by the standardization of options and alternative solutions (that need to be implemented and operated afterwards), I never understood why 3GPP (more especially operators) permitted this to happen. But who am I to complain?

Two of these alternatives lead to a very similar result as they route all SIP requests addressed to one PSI to a single application server (i.e. the PSI is the only criterion used to route the SIP request).

The first alternative is subdomain based routing. The PSI will look like sip:anything@service.operator. The "service.operator" subdomain will be resolved through DNS to the application server serving all the PSIs constructed with this subdomain. Sub-variants include the case where the subdomain is resolved to the AS in the network originating the request, and the one where this is the network serving the PSI that resolves the subdomain into the AS address.

The second alternative relies on an address stored in the HSS. When the request addressed to the PSI reaches a signalling entry point to the network serving the PSI (which is an I-CSCF), this I-CSCF matches the PSI with the address of an AS retrieved from the HSS.

The third mechanism is for me by far the most powerful from a service perspective. It consists in treating the PSI as an IMPU (IMS Public User Identity). This is, a service profile is associated to the "PSI user" (this term is used in the specifications) as it would be to an IMPU.

When a request addressed to the PSI is received by the I-CSCF, this one routes the request as if it was addressed to an IMPU (i.e. the HSS provides the I-CSCF with the address of an S-CSCF serving the PSI user). Routing of the PSI by the S-CSCF is then based on a set of initial filter criteria forming the service profile of the PSI.

This approach is interesting as it permits to make PSIs benefit from the service architecture defined for IMS users. More especially, it permits:
- To discriminate service routing of requests addressed to the PSI according to details of the SIP request. For instance, an INVITE for a voice session and an INVITE for a video session addressed to the same PSI may be routed to different specialized media servers. As another example, a subscription to presence (SUBSCRIBE for presence event package) and an instant message (MESSAGE) addressed to the same PSI could be routed either to a presence server or a messaging server.
- To chain several ASs on the signalling path of the SIP request, instead of routing it to a unique AS. For instance, a SIP MESSAGE addressed to the sip:The_IMS_Lantern_ChatRoom@operator PSI, a chat forum for this blog, could be routed through an archiving server, an anti-virus server, and an anti-spam server, prior to reaching its final destination: the chat room server that will dispatch it to all the users currently in the chat room.

Distinct vs. Wildcarded PSIs

Distinct PSIs are PSIs that are fully defined by the operator and provisionned as such in the HSS (e.g. sip:This_Service@operator, provisionned in the HSS with a matching application server address or a service profile).

Wildcarded PSIs permit an operator to provision PSI routing information in the HSS according to a naming pattern. All the PSIs sharing the same naming pattern will be routed the same way. For instance, sip:*_ChatRoom@operator is a wildcarded PSI that corresponds to the IMS Lantern chat room PSI introduced above.

Wildcarded PSIs permit to factorize service routing information between multiple PSIs. They also permit PSIs to be (partly) created by end users, and to be managed fully by an application server without involvement of the operator's provisioning system. For instance, I could create myself the name of the IMS Lantern chat room in the chat room server. No need to change any routing information in the HSS. Every request to the IMS Lantern chat room would be routed to the chat room server according to the wilcarded PSI it is based on.

Activation / De-activation of PSIs

An application server may activate or de-activate a PSI in the HSS through the Sh reference point (interface between an AS and the HSS based on Diameter).

This permits to have a greater application control on PSI routing information. You could imagine the case where a service is available only during certain hours of the day, or days of the week. A PSI could also be usable during a limited period (e.g. a sports event). There are certainly many other usages for the dynamic activation/de-activation of PSIs.

SIP Requests May Originate From a PSI

The IMS service architecture permits application servers to generate SIP requests towards users or other application servers.

It is possible for an AS to use a PSI as the originating address of a SIP request. This permits a service to identify itself as the originator of a service interaction towards a user or another application.

Future post(s) will show potential service patterns making use of PSIs (i.e. ideas on how to use the PSI ingredient to cook some IMS services).

Christophe

IMS Public User Identities (IMPUs)

There might be a few interesting things to say about IMS user identities.

As you certainly know, there can be two sorts of IMS Public User Identities (also known as IMPUs): tel URIs (e.g. tel:+1-234-456789) and sip URIs (e.g. sip:user@operator).

(Note that a SIP URI with an E.164 number in the user part and a parameter "user=phone" is the equivalent to a tel URI and will be treated as such by the IMS core network)

Tel URIs: Smooth Migration From Legacy Telephony

In IMS, tel URIs may be used to address an IMS user or a user in the legacy circuit-switched network.

When the tel URI corresponds to an IMS user, the core network entity called S-CSCF (Serving Call Session Control Function) will be able to resolve it into a SIP URI, thanks to a DNS extension called ENUM,. It will then proceed with the routing of the SIP request within the IMS.

When the tel URI corresponds to a circuit-switched user, the S-CSCF's query to ENUM will fail to resolve the tel URI into a SIP URI. The S-CSCF will then route the call to the circuit-switched network through an appropriate gateway.

Consequently, using a tel URI an IMS user can set up a call with another IMS user or with a legacy telephony user.

Tel URIs also permit IMS users to be called from the circuit-switched network. The CS network routes the call to a voice gateway, which sets up a voice session in the IMS using the original B-party number to form a tel URI. The IMS core then resolves the tel URI into a SIP URI of the IMS user.

In order to support interoperability with the circuit-switched network, IMS users will need to keep legacy phone numbers for years, even if they use SIP URIs in parallel.

SIP URIs: The Future of User Addressing

SIP URIs should eventually dominate and replace phone numbers as the way to address other users in some years from now.

This steady migration from telephone numbers to alphanumerical SIP addresses will be a fundamental element for different types of convergence:

- Convergence between fixed and mobile communication, as mobile and fixed -segregated phone numbers will be replaced by access-agnostic SIP URIs.

- Convergence between telecom and Internet communication, as both can use SIP and SIP URIs.

- Convergence between SIP-based communication (e.g. multimedia sessions, voice, instant messaging) and email through the possibility to use the same address between SIP and the email protocol (e.g. sip:John@service_provider vs. smtp:John@service_provider).

IMPUs Identify Users, Not a Specific Line or Device!

There is a major difference between IMS and pre-IMS addresses. While pre-IMS phone numbers are usually associated to a unique line or device, IMS IMPUs relate to end-users.

In a pre-IMS world, mapping a legacy phone number to multiple devices is an added-value feature requiring a specific implementation in existing fixed and mobile networks.

In contrast, the possibility to concurrently assign an IMPU to multiple devices is a basic IMS feature, supported by the IMS core network (i.e. S-CSCF), without the need for a specific support in the application layer. The dynamic allocation of an IMPU to one or several devices is performed through the IMS registration procedure.

In addition, the possibility for IMS to support multiple access technologies (e.g. cable, xDSL, cellular wireless, non-cellular wireless) makes that an IMPU can concurrently be shared between multiple fixed and mobile devices (e.g. fixed phone, PC, set top box, mp3 player, mobile phone). This is fixed mobile convergence at the user and network level.

Multiple IMPUs for One User

IMS specifications permit a user to have several IMPUs. It is up to the operator to decide how many IMPUs a user will be allowed to have.

Different IMPUs may serve as aliases. These IMPUs are totally inter-changeable, as they are associated to the same set of services and are transparently associated to the same devices. The user may use them to differentiate between different groups of contacts (e.g. friends vs. strangers). A user will typically have a tel URI as alias to a SIP URI (see above).

Different IMPUs may also permit the user to endorse several persona (e.g. member of an association, owner of a private business). In this case, the IMPUs may be associated to different service profiles, and possibly to different devices (but they can also be associated to the same).

One IMPU for All Services, Across All Devices

A feature that may seem to conflict with the previous, and might actually be more essential, is the possibility to associate a single IMPU to virtually all the services of a user.

IMS and SIP can unify all real time 2-party and multi-party person to person communication (e.g. voice, video, instant messaging, deferred messaging), blend communication, content and data together, and support access to user data and information (e.g. presence, user profile, various event packages permitting to access and monitor user-related data and events).

All these communication/content/data services can be accessed through a single user IMPU, which is independent from the devices and access technologies being used. Moreover, if this IMPU corresponds to the user's email address, you can then finally have a unique address on your visit or business cards, and this address may provides access to more services than all the old ones put together.

More Enablers for Services

The possibility to access a plethora of services through a single IMPU can also be extremely beneficial to services themselves.

Consider the following example (which may not be that interesting from a service perspective, but this is not the point).

John sends an electronic birthday card to Mary through IMS deferred messaging (i.e. the message will be delivered to Mary as soon as she is able to receive it). A service associated to John intercepts the SIP service request, extracts Mary's IMPU from it and generates a presence request on behalf of John and addressed to Mary's IMPU. Mary's presence server answers with a set of information related to Mary, according to John's authorization to access it. This information may be very rich about Mary, the means and addresses to communicate with her, her devices, the applications she uses, and various availability and preference information about them. John's service may use this information to suggest additional or alternative ways to deliver the electronic birthday card (e.g. email). It may also suggest to store elements of this information in various repositories, such as John's address book.

This example shows that even if a an IMS subscriber still makes use multiple identities and addresses (for instance addresses related to Internet services), one of them may be used as the key to dynamically discover all others.

It also shows that a service which had never heard about a user can discover a whole lot of information about this user and use it for the delivery of sophisticated services. In the example, I used presence, which by itself can be a very rich set of information, but this could be extended to much more than this.

Christophe