Through my company Arismore, I am offering a 2-day course on the IMS application layer. It can be delivered either in French or in English (all the material is in English). There are sessions regularly organized in my company's premises in Saint-Cloud, Paris, France, which are open to individuals. The course can also be delivered on site, within or outside Europe.
What makes this course unique is that, while others usually provide a litteral description of IMS specifications and essentially concentrate on the IMS core network, largely overlooking the IMS service architecture, sometimes even delivering misleading information, this one totally concentrates on this domain in which resides the true potential of IMS for differentiation and revenue generation (both for operators and suppliers). You can take this course after a regular IMS one, but my experience shows that even IMS novices can follow it without missing any core network background.
The course does not only describe IMS application-related specifications that span multiple standardization organizations (3GPP, the IETF, OMA, ETSI TISPAN). It also helps understanding what lies behind them, by providing revealing insights on how they were produced (e.g. historical timeline, assumptions, mistakes, conflicts between companies, need to address specific issues), shows in details how they effectively work, explains how they can optimally be exploited to deliver innovative services or innovatively deliver existing ones, and finally addresses the main opportunities and challenges that IMS brings to the industry. After this course, the student can understand what IMS can deliver, why there exist so many conflicting perceptions of IMS, and why IMS is as much a challenge as a promise.
Several on site sessions have been given or are planned in the near future, and the response has been so positive that these sessions usually lead to discussions about further collaboration between the customer company and Arismore.
Contact me at cgourraud@yahoo.ca if you are interested in either an on site session or in a session organized in our offices in Paris (planned dates can be found in the side bar of the blog).
Here follows a description of the course. You can also request from me a slightly more detailed powerpoint content description.
Part 1: The IMS Service Architecture
This is the most comprehensive part of the course. It addresses several objectives: understanding how the IMS service architecture works (dynamic view), getting an overview of the specifications (static view), understanding the drivers behind standardization decisions (motivations, design by accident, pending issues), understanding how the architecture can be used (application layer architecture, service patterns).
Standardized topics include:
- Overview of the architecture
- IMPUs & PSIs
- ISC usage scenarios & examples
- Details of ISC
- Service profiles and initial filter criterias (iFCs)
- OSA SCS / IM SSF / SIP AS
- MRFC/MRFP
- SCIM & Service Broker
- IMS Communication Services
- User Data Management (Sh, OMA XDM, GUP)
The service features of SIP are treated as a specific topic. It highlights the potential of the protocol when used in IMS or in other networks:
- Multimedia sessions
- Event packages
- Routing alternatives (SIP forking, callee capabilities/caller preferences), GRUUs)
- Support of Group Services
- Combination with other protocols (content indirection, SIP REFER, SIP session, body in SIP message)
- Interoperability aspects (between SIP profiles, between SIP and other protocols)
Service oriented features specific to the IMS service architecture, and complementing the intrinsic SIP ones are also detailed. This part permits to understand the value IMS adds on other SIP-based networks:
- Service composition
- Logic mutualization
- Personalization / Differentiation of user experience
- Simple access to services
- Service flexibility / agility
- Authorization to services
- Unlimited service scalability
- Multi-vendorship / Differentiation for each service
- Service anthropomorphism
- Usage of a single identity for multiple services
Part 2: IMS standardized services and enablers
This part covers IMS services and enablers standardized or under standardization in 3GPP, OMA and ETSI TISPAN. As for Part 1, background information about the standardization process is given.
User data services & enablers:
- Presence (IETF, 3GPP, OMA specifications)
- Group Management / Group Services
Voice oriented services & enablers:
OMA Push To Talk Over Cellular (Poc) V1 and V2
3GPP Combining circuit-switched and IMS services (CSI)
3GPP Voice Call Continuity (VCC)
3GPP/TISPAN Multimedia Telephony (MMTel)
3GPP IMS Centralized Services (ICS)
3GPP Conferencing
Messaging services & enablers:
OMA SIP Push
Messaging (IETF IM, 3GPP IMS Messaging, OMA SIMPLE IM)
3GPP SMS over generic IP access
OMA Converged IP Messaging (CPM) - Messaging part
Multimedia services & enablers:
OMA Converged IP Messaging (CPM) - Multimedia part
TISPAN IPTV
This part ends with a description of the Rich Communication Suite (RCS) initiative
Part 3: Opportunities & Challenges
This final part addresses essential topics which go beyond IMS specifications.
It is structured around the following topics:
- Fixed Mobile Convergence (from technical to user oriented convergence: opportunities and challenges)
- Which role(s) for the operators (e.g. bitpipe provider, intelligent pipe/channel provider, service provider with more or less control)
- Exploiting IMS Capabilities (e.g. User Oriented Architecture, Distributed Service Architecture, need for optimizing the IMS service architecture)
- Service Platforms (e.g. black boxes vs. open platforms, JAIN SLEE, J2EE)
- IMS as a service integration framework (different types of IMS services, how to integrate non-IMS services into IMS, relationship to 3rd party service providers)
Christophe
Showing posts with label Public Service Identity. Show all posts
Showing posts with label Public Service Identity. Show all posts
Tuesday, April 15, 2008
Monday, December 17, 2007
Use Case: Multimedia Service Delivery
This post presents an example which makes use of these multimedia capabilities.
IMS Service Features Illustrated with the Example
The example I present today shows, among other things...
How IMS can be used by an operator to deliver a multimedia service which includes content and application components, but not a single person-to-person communication one.
How IMS can be used to share a multimedia content and application experience between several users (not shown on the figure).
How IMS can be used to mix person-to-person communication with content and application sharing.
How non IMS and even non SIP-aware services can be integrated with IMS (i.e. a service delivered over IMS does not have to be specifically developed for it and does not necessarily require SIP-related application components).
How IMS can be used for an operator to offer to its subscribers services actually delivered by 3rd party service providers located in other domains, possibly including the Internet, without requiring a prohibitively strong technical coupling with them.
How IMS can permit an operator to add-value to multimedia content delivered to its subscribers by third party service providers.
That IMS Services might be highly distributed, with application logic running in devices and in a variety of application and content servers. The SIP logic itself might be confined to only a subset of these service entities.
Why the existing conferencing solutions available on the market are too limited, and why a more generic multimedia conferencing architecture is needed.
Description of the Service
In order to experience the multimedia service, the user starts a session addressed to a Public Service Identity (PSI) identifying the service. The PSI may be specific to the user and routed to the SIP AS according to the user's service profile (originating trigger). Alternatively, the PSI may be a shared, public one. In this case, the routing to the SIP AS may also be based on the user's service profile (i.e. users need to be authorized to access the service so that their service profile allows routing to the SIP AS), unless it is based on the normal resolution of the PSI to the SIP AS (i.e. all users can access the SIP AS when they issue a request addressed to it). I already described these routing alternatives here and also with another service use case.
The user negotiates (and possibly re-negotiates during the session) the content of the service through any appropriate interface. For instance by accessing a web page supported by the SIP AS. Alternatively, this could be through a client downloaded on the terminal and communicating with the SIP AS via an application to application interface, like the exchange of XML documents describing the desired content of the multimedia session.
The SIP AS then performs the required actions to deliver the content (e.g. files, streaming media, web pages, applications) within the session. Depending on the type of content, the desired control of the operator over the delivery, and the technical means available for each component, the SIP AS uses the appropriate mechanism for each of the components (which do not have to be co-located with the service control logic hosted by the SIP AS). This may include some of the following:
- Establishing a SIP session with the component endpoint and bridging this new session with the user to SIP AS one (typical B2BUA behavior).
- Controlling the delivery of the component via an appropriate non-SIP interface (e.g. web services, H.248) towards the component source and negotiating/re-negotiating the SIP session accordingly towards the user.
- Providing the user's terminal and/or the component source with appropriate information to establish an end-to-end connection. In an example, the SIP AS would provide within the session a URI (e.g. HTTP URI, FTP URI, RTSP URI) via SIP content indirection or a referral, permitting the user's terminal to directly connect with the component source. In another instance that I used when I was the architect of an IMS demo for an equipment supplier, the SIP AS retrieves from the source the information required to connect to a whiteboard server, and transmits it to the user's terminal, so that a whiteboard client connects to the server and interfaces with it through the relevant whiteboard protocol. In yet another instance, the SIP AS provides the component source with the information relevant to push the content to the user's terminal. In any of these instances, the SIP AS may keep a control interface towards the component source in order to terminate the delivery of the component when the service session is completed (the idea is to ensure that the component is not delivered anymore after the service session is ended).
During session establishment or session renegotiation for a specific component, the SIP AS may decide to insert a number of media-level intermediaries (typically media servers) between the user's terminal and the component source(s). In such a case there is no peer to peer connection between the user's terminal and the component source, as both connect to the intermediary which is under the control of the SIP AS. The potential control interface between the SIP AS and the intermediary in the network might be an alternative way for the SIP AS to synchronize the delivery of the service component with the service session (start/stop delivery). However, the usage of a media intermediary may serve other more added-value objectives, like combining/mixing different components together (e.g. inserting text information in a video stream), caching media for better delivery quality, transcoding media to fit the capabilities of the user's terminal, or inserting localized advertizement in the media stream (possibly to decrease the service fee to be paid by the user).
It should be noted that the component sources may be provided by the operator or by 3rd party service providers located in other domains, and possibly in the Internet. In this case, the operator acts as a service broker, adding value to individual components by integrating them in a single multimedia session, acting on the media plane, and providing the level of access (no need for the user to authenticate to each individual service component provider), the QoS and the security that can be expected by the user from its telecommunications operator.
The service session, which takes place between the user's terminal and the SIP AS (usage of SIP for the service may be confined to these two entities), may terminate when either the user or the SIP AS decides that it is time to. As for individual components in the session, their delivery may be terminated through either the user's terminal, the component source, or the SIP AS if it has the control means to do it.
Some of the Benefits of Using IMS to Deliver the Service
As I already described in an earlier post, using SIP has a prerequisite to access a service has numerous advantages for both the operator and the user, and using a SIP session to deliver the service even adds on top of this:
- The SIP signalling generated by the user's terminal and reaching the SIP AS transports meaningful service information, such as the authenticated identity of the user, information relevant to charging like the address of the charging nodes and correlation identifiers which will permit the billing system to correlate charging information generated at the media plane level (e.g. type and volume of media), at the IMS core network level (duration of the session), and at the SIP AS level (any additional application-level event), information about the location of the terminal (e.g. cell ID), and information about the access technology used by the terminal, which can be exploited by the SIP AS to optimize the delivery of the components.
- Routing of the SIP signalling between the user's terminal and the SIP AS may be directly linked to the authorization of the user to access the service (see above).
- The establishment and re-negotiation of the session permits the user's terminal and the SIP AS to re-use core network support to set the relevant QoS and security associations just like for a person-to-person voice or multimedia session.
- The SIP session determines a well defined context for the delivery of the service, with a clear begining and end.
- The session permits the coherent combination and aggregation of individual components within a multimedia service.
- The session offers the possibility for the operator to insert media-level intermediaries for both control and added-value purposes. This example thus illustrates how an operator can both use multimedia sessions to deliver its own services, and add value to peer-to-peer multimedia exchanges.
Some Possible Extensions to the Use Case
Though not supported by the standards today, the service could be extended with session continuity, permitting the terminal to switch from one access to another (e.g. WiFi to UMTS) without stopping the service session and the delivery of its components.
Currently under work in the IETF, session mobility would permit the user to transfer the ongoing session from a terminal to another (e.g. mobile phone to TV set) without stopping it. Such a transfer could be necessary from a convenience perspective (e.g. the user started the service on the run and is now at home, benefiting from terminal alternatives), or depending on the renegotiation of the service session (e.g. the user would like to add a component like an application, which is not available on the terminal he or she is using). It would also be possible for the user to receive the content or run applications on several terminals, each optimized for a subset of the components or applications.
While the example concentrated on the delivery of a mutimedia service to a single user, it would be possible to share the experience between multiple ones. This could be done by providing a conferencing entity to the architecture. As this conferencing support would not be limited to person-to-person communication (e.g. voice, messaging), this would require a more generic conferencing architecture than those proposed today by suppliers. I tried to describe a potential architecture in a past post. Sharing the same experience could imply the synchronization of applications on each of the users' terminals, permitting for instance shared browsing, a shared whiteboard, or multi-player gaming.
As soon as multiple users are involved in the service session, person-to-person communication would be an appreciated plus and would be enabled by the conferencing support permitting to add bi-directional communication components between the participants. Such a possibility would make the use case come back to the core concern of the operator: delivering person-to-person telecommunication.
A service supporting both the delivery of content/application and person-to-person communication may experience different modes. In addition to this example in which a service session is extended to communication, an alternative use case would see a communication session between two or more users extended to shared multimedia service delivery.
Everything is Possible, Nothing is Given
Obviously, such a service would require an adequate support in terminals (application architecture, application components and an intuitive user interface), a relevant architecture in the IMS application layer, the right agreements and technical settings between the operator, its SIP AS, and the 3rd parties and their servers, and an attractive business model for all the parties (the operator would need to find the right charging policy for its subscribers).
It would require that ongoing standardization efforts in 3GPP do not prevent, through artificial barriers, the delivery of such a service or similarly out-of-the-mainstream others. I will come back on this topic in a future post.
Christophe
Tuesday, June 26, 2007
Public Service Identity Service Patterns
In this post, I will try to present some potential usage of Public Service Identities (PSIs) for the delivery of IMS services.
Services to the World
PSIs were standardized for this, but it might be useful to highlight it: PSIs permit an operator to provide services that are accessible from any SIP network.
This means that the IMS Lantern chat room from the previous post, or any content identified through a PSI, is potentially accessible to all IMS subscribers of the world, whether their subscription is a fixed, mobile, cable, or converged one.
This also means that the same service is accessible from non-IMS networks with SIP connectivity like the Internet.
Combination of Private/Restricted and Public Access to a PSI
The previous post might have given the impression that a PSI can either be accessed by a happy few or by everybody.
Actually, this does not have to be. A PSI can be accessed in one way by a happy few, and in another way by all the others, and the way a PSI is accessed can determine the logic that is executed to process the corresponding SIP request in the IMS application layer.
Private/Restricted access to a PSI is determined by the service profile associated to the originator of the SIP request addressed to the PSI (i.e. the service profile of the user includes one or several initial filter criteria that relate to the PSI and permit to route the request to an application server).
What happens for users who initiate a SIP request to the PSI and do not have a PSI-aware service profile?
The IMS core network will try to route the SIP request anyway, and then there are two cases:
1) There is no way to match the PSI to a physical address, i.e. there is no service profile associated to the PSI, and it is not defined in any DNS (or ENUM) server or in the HSS. In that case, the PSI is really accessible by a happy few.
2) There is a "public" PSI routing mechanism, i.e. one of the three mechanisms described in the previous post. In that case, the PSI is also accessible to everybody. The public access mechanism may route the request to another application server or to the same one as the private/restricted access procedure. In any case, it is possible for an application server to determine how the SIP request was routed to the application server (i.e. either as an originating or a terminating request), and consequently to apply a different logic for each case.
Automatic Service Discovery and Configuration
I already gave an example of this mechanism with the automatic service discovery and configuration service pattern. In this example, John is subscribed to Service X, and consequently benefits from the restricted access configuration information associated to the service. His girlfriend Mary is not subscribed to Service X. If she issues a request addressed to sip:ServiceX@operator.com in order to retrieve service X's configuration information, the request will be routed to an alternative service logic, which will deny access to the information.
Restricted Access for Management of Public User Groups
Restricted Access for Management of Public User Groups
Another example would correspond to a user group identified by the PSI sip:Friends_of_IMS@operator.
Anybody can use this PSI to send an instant message to members of the group, access their presence information, or start a multimedia session with them (public access to the PSI). All these services are accessed through the initiation of an adequate SIP request addressed to the PSI (i.e. MESSAGE, SUBSCRIBE for presence event package, INVITE). Routing to the relevant application server is based on the service profile associated the PSI (i.e. MESSAGEs go to messaging server, SUBSCRIBEs for presence event package go to the resource list server, INVITEs go to the multimedia conferencing server).
On the other hand, only a few users can manage the user group, i.e. add/remove users to it. This implies that SIP requests that permit to access and modify the definition of the user group (SUBSCRIBE, PUBLISH for a group management event package) are restricted to a limited set of people. These people will have their service profile defined in such a way that their management requests to the sip:Friends_of_IMS@operator PSI will be routed to the application server managing the user group. The same management requests issued by a non authorized user will not be routed to any application server and will be rejected by the IMS core network (the service profile associated to the PSI does not define any routing for PUBLISH and SUBSCRIBE requests related to the group management event package).
Differentiated Access to Content (see figure, click to enlarge)
Anybody can use this PSI to send an instant message to members of the group, access their presence information, or start a multimedia session with them (public access to the PSI). All these services are accessed through the initiation of an adequate SIP request addressed to the PSI (i.e. MESSAGE, SUBSCRIBE for presence event package, INVITE). Routing to the relevant application server is based on the service profile associated the PSI (i.e. MESSAGEs go to messaging server, SUBSCRIBEs for presence event package go to the resource list server, INVITEs go to the multimedia conferencing server).
On the other hand, only a few users can manage the user group, i.e. add/remove users to it. This implies that SIP requests that permit to access and modify the definition of the user group (SUBSCRIBE, PUBLISH for a group management event package) are restricted to a limited set of people. These people will have their service profile defined in such a way that their management requests to the sip:Friends_of_IMS@operator PSI will be routed to the application server managing the user group. The same management requests issued by a non authorized user will not be routed to any application server and will be rejected by the IMS core network (the service profile associated to the PSI does not define any routing for PUBLISH and SUBSCRIBE requests related to the group management event package).
Differentiated Access to Content (see figure, click to enlarge)
The third example is illustrated by the picture at the top. The PSI sip:This_Content@operator identifies a specific content (e.g. a video) that can be accessed through a SIP session initiated by the user.
Four application servers serve the same PSI.
A and B serve the subscribers of the operator who are authorized to access the content. Access to these application servers is based on the service profiles associated to each subscriber. The service profiles associated to subscribers in the partition #1 route the service request to A, while service profiles associated to subscribers in the partition #2 route the service request to B. Service logic on A and B delivers the content.
A and B serve the subscribers of the operator who are authorized to access the content. Access to these application servers is based on the service profiles associated to each subscriber. The service profiles associated to subscribers in the partition #1 route the service request to A, while service profiles associated to subscribers in the partition #2 route the service request to B. Service logic on A and B delivers the content.
C serves the subscribers of the operator who are not authorized to access the content. The service profile associated to the PSI determines that all requests originating from users whose IMPU's domain is the one of the operator shall be routed to C. The service logic on C may show a preview of the content and propose the user to subscribe to the content.
D serves subscribers of other operators and users from the Internet. The service profile associated to the PSI determines that all requests originating from users whose IMPU's domain is not the one of the operator shall be routed to D. The service logic on D may propose the user to pay for viewing the content.
It would be possible to further discriminate between users trying to access the content. For instance, the service profile associated to the PSI could determine that SIP requests which do not include a P-Asserted-Identity header (i.e. requests originated from a non-IMS network) should be routed to an application server E.
Christophe
Friday, June 22, 2007
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
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
Subscribe to:
Posts (Atom)
Stumble It!
