Here follows an index by themes of the posts on this blog. I will update it as new posts are published.
In bold are the posts that are important to me.
The Potential of IMS
Three Axes for IMS: #1 Fixed Mobile Convergence
Three Axes for IMS: #2 Multimedia Communication
Three Axes for IMS: #3 User Oriented Architecture
Does IMS Create a New Walled Garden?
IMS Service Features
IMS Service Logic Distribution
Conservative & Progressive Application Layers
Co-existence of Conservative & Progressive Application Layers
What is an IMS Service?
3GPP Multimedia Telephony & OMA CPM
Service Anthropomorphism
Fixed Mobile Convergence
Three Axes for IMS: #1 Fixed Mobile Convergence
IMS Public User Identities (IMPUs)
3GPP Multimedia Telephony & OMA CPM
Multimedia Communication
Three Axes for IMS: #2 Multimedia Communication
Status of Multimedia Communication
Enabling Multimedia Communication
Use Case: Multimedia Service Delivery
Conservative & Progressive Application Layers
3GPP Multimedia Telephony & OMA CPM
User Oriented Architecture (UOA) and Service Oriented Architecture (SOA)
SOA & IMS: Same Fight?
Three Axes for IMS: #3 User Oriented Architecture
Service Pattern: Automatic Service Discovery & Configuration
The Beatles & The Stones
An IMS Application Server in Context
A Contribution from the Fraunhofer Institute FOKUS
What is an IMS Service?
Service Anthropomorphism
The IMS Service Architecture
Beware of IMS Service Architecture Prejudices!
An IMS Application Server in Context
Conflicting Views on the IMS Service Architecture
IMS Service Routing: Big Picture
IMS Service Logic Distribution
IMS Service Features
Conservative & Progressive Application Layers
Co-existence of Conservative & Progressive Application Layers
IMS Service Interaction Use Cases: Part 1
IMS Service Interaction Use Cases: Part 2
IMS Service Interaction Use Cases: Part 3
What is an IMS Service?
3GPP Communication Services
The SCIM
Standardization: SCIM & Service Broker
Review of Typical SCIM Features
Here is my SCIM
More on the SCIM!
SIP
SIP Everywhere but NOT for Everything
Service Pattern: IMS Content Indirection
Use Case: Multimedia Service Delivery
Does IMS Create a New Walled Garden?
Moving the Frontier between IT and Telco (part 2)
What is an IMS Service?
A Building Block Approach to Standardization
An Article from Microsoft
3GPP Communication Services
IMS as Integration Framework
Service Pattern: Automatic Service Discovery & Configuration
Service Pattern: IMS Content Indirection
Use Case: Multimedia Service Delivery
What is an IMS Service?
A Building Block Approach to Standardization
IMS and the Internet
Does IMS Create a New Walled Garden?
IMS Service Interaction Use Cases: Part 1
Use Case: Multimedia Service Delivery
Conflicting Views on the IMS Service Architecture
An IMS Application Server in Context
IMS Communication Services: Uncut Version
A Building Block Approach to Standardization
Different Strategies for IMS
3GPP Communication Services
IMS Service Examples and Service Patterns
Service Pattern: Automatic Service Discovery & Configuration
Service Pattern: IMS Content Indirection
Public Service Identity Service Patterns
Use Case: Multimedia Service Delivery
IMS Communication Services: Uncut Version
IMS Service Interaction Use Cases: Part 1
IMS Service Interaction Use Cases: Part 2
IMS Service Interaction Use Cases: Part 3
What is an IMS Service?
Service Anthropomorphism
IMS Application Servers & Service Platforms
An IMS Application Server in Context
Moving the Frontier between IT and Telco (part 2)
IMS Service Routing: ISC for IMS Application Servers
Different Strategies for IMS
User Data
User Application Data: a Panorama
User Application Data: Opinions
A Building Block Approach to Standardization
Perception Issues with IMS
Why dedicating a blog to IMS?
A Classification of IMS Critics, Part 1
A Classification of IMS Critics, Part 2
IMS: Core Network or Service Framework?
Does IMS Create a New Walled Garden?
SOA & IMS: Same Fight?
Conflicting Views on the IMS Service Architecture
Danger! IMS Communication Services
IMS Communication Services: Uncut Version
IMS Communication Services: Latest News
The Beatles & The Stones
Conservative & Progressive Application Layers
What is an IMS Service?
3GPP Multimedia Telephony & OMA CPM
Different Strategies for IMS
3GPP Communication Services
Details on IMS Specifications
Finding Your Way on the 3GPP Web Site
IMS Public User Identities (IMPUs)
IMS Public Service Identities (PSIs)
IMS Service Routing: Big Picture
IMS Service Routing: Service Profile
IMS Service Routing: ISC for S-CSCF
IMS Service Routing: ISC for IMS Application Servers
Standardization: SCIM & Service Broker
User Application Data: a Panorama
Danger! IMS Communication Services
IMS Communication Services: Uncut Version
IMS Communication Services: Latest News
3GPP Multimedia Telephony & OMA CPM
IMS Standardization Tracking Report
3GPP Communication Services
General Views on the Industry
IMS for Mobile Operators
IMS for Fixed Operators
IMS for Operators with Mobile & Fixed Units
Moving the Frontier between IT and Telco (part 1)
Moving the Frontier between IT and Telco (part 2)
SOA & IMS: Same Fight?
A Building Block Approach to Standardization
Different Strategies for IMS
Defining an IMS Strategy
A List of IMS Deployments (regular updates to be expected)
External Contributions to the IMS Lantern
Call For Contributions
A Contribution from the Fraunhofer Institute FOKUS
An Article from Microsoft
IMS Standardization Tracking Report
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, December 11, 2007
Conflicting Views on the IMS Service Architecture
The two figures above both depict the IMS Service Architecture.
The first one is taken from the 3GPP specifications and is therefore the primary basis for anyone to understand the IMS Service Architecture.
The second one is my own representation of the IMS service architecture, based on the exact same specifications, and is therefore only accessible by the readers of this blog. As I have not seen so far a similar representation anywhere else, you can assume that this is not at the moment the mainstream perception of the IMS service architecture in the telco community.
IMS as a New Intelligent Network (IN)
The 3GPP representation of the IMS service architecture is network centric. It represents the IMS application layer solely according to its interface to the IMS core network, placed at the center of the figure with the S-CSCF.
This representation is potentially misleading as technicians with a classical telecom background can perceive the IMS service architecture as an IP replica of the Intelligent Networks that can be found in all existing fixed and mobile circuit-switched networks. Actually, I have seen this view supported numerous times, both by these people who know everything about telecommunications and by alleged IMS experts.
This IN perception of the IMS service architecture is re-inforced by the fact that two of the IMS application server types represented in the figure are tightly linked to IN: the IM SSF is a gateway between IMS and an IN application server, and the OSA gateway is usually (and rightly) perceived as being essentially an API on top of IN. Adding to the confusion, the terminology used for the IMS service architecture (e.g. trigger points) heavily borrows from IN (to be frank, some companies participating to IMS standardization did see this architecture as an IN one).
In an IN network, the (fixed or mobile) switch interfaces with the application server through a dedicated control interface (e.g. INAP, CAP, an IS.41 subset), which permits the application server to control the switch by issuing instructions to it. These instructions essentially serve the purpose to control voice calls, as the circuit-switched network is voice centric.
In such an architecture, the basic voice services are supported by the core network, which is complemented by application servers for the delivery of "supplementary" or "value-added" services.
With this kind of background, it is easy to perceive ISC as the IMS equivalent to INAP/CAP and the IMS application servers as an extension to the core network. Some might even argue that the IMS application layer is not needed, if you can implement all the required supplementary services within the S-CSCF.
IMS as a Totally New Service Architecture
However, the IN-oriented interpretation of the IMS service architecture does not resist a thorough analysis of the specifications that I tried to describe in past posts (here, there, there and there).
First, with the exception of the user registration part of the ISC reference point (which permits the S-CSCF to notify application servers about registration events, but does not permit the AS to block registrations), ISC cannot be seen as a logical interface between the S-CSCF and the application server.
On the contrary, ISC is only one branch in an end-to-end SIP interaction between the application server and other application-related entities. In such an interaction, the S-CSCF and the whole IMS core network only act as intermediaries and service-related routing functions between application-related entities. This is why I tend to represent the whole IMS core network as a SIP-oriented service bus supporting the IMS application layer (I will come back on this in a future post). This bus is essential for the IMS application layer, but its significance is close to zero from a service perspective. Suffice to say that it duly supports its service bus role, and that the best additional value it can offer to applications is to be totally transparent to them.
The second essential characteristic of IMS that dismisses the claims of an IN replica is that SIP is not the equivalent of SS7 over IP:
- SIP sessions are not voice calls. They are much more generic service sessions, which may even not include any voice or person-to-person communication component.
- SIP is not only about SIP sessions. Other SIP methods make SIP a very generic service control protocol.
With such a knowledge in mind, it is irrelevant to represent the IMS service architecture without representing what is on the other side of ISC (and other SIP-relate reference points supported in the IMS core network). My figure tries to represent all the possibilities.
However, this figure is still incomplete, as it focuses on the SIP dimension of the IMS service architecture. For a more complete view, look at this previous post.
The End-To-End IMS Service Architecture (SIP Dimension)
Many possibilities exist, that I already described in the past (here, there and there), but I will summarize below (note that the examples are very basic).
An IMS endpoint (terminal, endpoint application server) in the operator's domain initiates a SIP service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence.
An IMS endpoint (terminal, endpoint application server) in another operator's domain initiates a SIP service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence.
An endpoint (terminal, endpoint application server) in a non-IMS domain (e.g. enterprise network, the Internet) initiates a service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence. Note that the non-IMS endpoint may either use SIP or another protocol to initiate the interaction. In the latter case, a protocol converter (e.g. Jabber to SIP) will translate the initial request into SIP.
Specific case: the non-IMS endpoint is an application server (e.g. Internet application requiring user's presence).
The application server initiates a SIP service interaction with an IMS endpoint (terminal, endpoint application server) in the same operator's domain. ISC is the first branch used in this interaction. Example: application server sends instant message to user.
The application server initiates a SIP service interaction with an IMS endpoint (terminal, endpoint application server) in another operator's domain. ISC is the first branch used in this interaction. Example: application server sends instant message to user of another operator.
The application server initiates a SIP service interaction with an endpoint (terminal, endpoint application server) in a non-IMS domain (e.g. in an enterprise network or in the Internet). ISC is the first branch used in this interaction. Example: application server sends instant message to user in the Internet. Note that the non-IMS endpoint may either accept SIP requests or not. In the latter case, a protocol converter (e.g. SIP to Jabber) will translate the initial request to the required protocol.
Specific case: the non-IMS endpoint is an application server (e.g. presence server).
The application server initiates a SIP service interaction with another IMS application server in the same operator's domain. ISC is both the first and last branch used in this interaction. Example: presence-based application accesses user's presence.
The application server initiates a SIP service interaction with another IMS application server in another operator's IMS domain. ISC is both the first and last branch used in this interaction. Example: presence-based application accesses user's presence.
An IMS application server acts as an intermediary in any of the interactions listed above, plus the essential case where none of the service interaction endpoint is an IMS application server (e.g. two IMS devices, an IMS device and a non-IMS device, an IMS device and a non-IMS endpoint application server). The idea is for the intermediary AS to either control or add-value to the end-to-end interaction. ISC is a branch somewhere in the middle of the SIP signalling path. Note that several IMS ASs can be inserted as intermediaries in the signalling path, forming a chain of combined services. Examples: IMS AS authorizes and/or charges for access to service, IMS application server inserts media plane intermediary to improve user experience (e.g. media mixing, media transcoding).
User Oriented Service Routing
The SIP dimension of the IMS service architecture relies on two SIP routing mechanims:
1) Standard SIP routing (labelled in the figure as IETF SIP routing) based on the resolution of the target SIP address towards an endpoint.
2) IMS User Oriented and Service Profile based routing (labelled in the figure as user profile based routing), which permits to dynamically alter SIP routing on a user-per-user basis towards IMS application servers. The service profiles stored in the HSS can be seen as service routing routing under the control of the operator and modifiable over time. This permits to incrementally modify SIP routing as applications are added or removed from the network, and this without impacting endpoints.
This draws a service architecture which is very flexible in terms of service logic location (in service entities like application servers in the network, endpoint application servers, devices), very flexible in terms of location of service entities in different domains (the operator's domain, another operator's domain, an enterprise domain, the Internet) and very agile in its possibility to dynamically modify service logic at work in the network.
Christophe
Subscribe to:
Posts (Atom)
Stumble It!
