Who reads The IMS Lantern?

As a complement to my latest post on IMS deployments, I think that an analysis of the audience of The IMS Lantern can provide interesting insights about the IMS community all over the world.

Since June 2007, this blog generated over 41,000 visits from 132 countries.

Worldwide audience

From a continental perspective, Europe accounts for half of the traffic and generated more than twice as many visits as the Americas and Asia, which are head to head.

However, the USA are, by a large margin, the country which tops the others in terms of traffic.

Here are the top 20 countries:

1.	United States
2.	France
3.	India
4.	Germany
5.	United Kingdom
6.	Sweden
7.	Canada
8.	Spain
9.	South Korea
10.	Switzerland
11.	Italy
12.	Netherlands
13.	Japan
14.	Slovenia
15.	Israel
16.	China
17.	Singapore
18.	Taiwan
19.	Austria

Companies

Visits come from three main types of companies:

- Big network equipment vendors including those leading on the IMS market, but not only.

- Operators, mainly from the USA, Canada, France, Spain, Germany, South Korea, Japan and Australia.

- Application service suppliers, with a huge domination from India.

However, a significant part of the traffic is also generated by smaller vendors providing equipments, services or OSS/BSS systems, by suppliers of service platforms, and by research centers, engineering schools and universities.

Subjects of interest

Visitors are mainly interested in posts describing technical details about the IMS service architecture, IMS identities, the SCIM, and IMS data management. This may hint at a deficiency in the way the literature, courses and IMS specifications address these topics.

Just behind come posts dedicated to the innovative features of SIP and the IMS service architecture, like the User Oriented Architecture (UOA), fixed mobile convergence, multimedia SIP sessions and CPM, and the various service patterns I had the opportunity to describe. I am personally very happy to see that CPM, which is by far the most ambitious IMS standardization initiative, attracts a lot of curiosity and is often entered as a keyword in search engines. Moreover, the post dedicated to it is the one visitors spend the most time on. Another source of more personal satisfaction is to see that the concept of User Oriented Architecture that I associated to the IMS has started to spread outside of the blog, even if it is far from having reached mainstream acceptance yet.

The IMS Lantern therefore seems to be accessed as both an educational and thought-provoking resource on the IMS.

Sources of traffic

Visits mainly come from search engines with IMS-related queries and from people who regularly visit the blog or get notified about new posts.

A smaller portion of the traffic comes from links on other sites (mainly blogs addressing telecom or technological topics). I have done very little to advertise The IMS Lantern on the Internet, but do not hesitate to link to it if you have the opportunity to do so.

Influence

Does The IMS Lantern have an influence on the work of some people or companies in the industry?

I know from direct contacts and some references visible on the Internet that The IMS Lantern has influenced research activities, the writing of theses, articles and even a book that will be published in the coming months.

It is a great source of motivation for me to learn that others can benefit from what I am writing and I have no problem with the reuse of ideas and information I am providing through this blog. So don't be shy: if this blog has a direct or indirect influence on what you are doing, just let me know.

Moving the Frontier between IT and Telco (part 2)

There has been an irresistible trend in the recent years for state-of-the-art IT technologies to find a room in telecommunications network, but so far this has still been relatively contained. I think that IMS can change all this and totally redefine the frontier between the IT and more classical Telco domains.

The IMS architecture clearly distinguishes between two types of SIP servers: core network ones (the CSCFs, the media gateways) which support basic IMS access, control and SIP connectivity, and application servers, which can basically support any SIP-related logic which is not standardized as a core functionality of the network.

I think this definition of an IMS application server by default (i.e. an AS is not a core network entity) might be the most accurate you can find at the moment. For instance, I believe that the 3GPP R7 Voice Call Continuity feature, which permits a voice call to be handed over between IMS and the circuit-switched network, should be considered as a core network feature, even if 3GPP decided to host it on a SIP Application Server.

Though the decision from 3GPP to locate a feature on a SIP application server rather than in the core network might not be considered as the ultimate criterion to draw the line between the IMS core network and application layer, I think that these two layers have fundamental differences, resulting into important implementation alternatives.

Stable vs. Dynamic Servers

An IMS core network entity is heavily standardized, both in terms of behavior and supported interfaces. There is very little room for non-standard extensions of these entities, both due to their role in the architecture, and the need to permit interoperability in a multivendor environment.

On the other hand, the standardization of the application layer is very limited. Some enablers like presence or IMS messaging are standardized (in 3GPP, the IETF, OMA), but this standardization should be seen as a minimal required set of features, that can be extended at will for differentiation. Moreover, the application layer should permit the deployment of applications that are not standardized at all.

If you believe in an IMS that supports innovative services for end-users, you need an application layer made of service platforms supporting applications with very short development cycles, that can be co-located (how many services will you deploy if you need one box for each of them?), and that can evolve very rapidly according to the wishes of end-users. Does this ring an Internet-related bell?

Show me the upper part of the IMS application layer!

The network-centric nature of 3GPP standardization makes that the IMS application layer is essentially specified according to its relationship to the SIP-centric IMS core network. This may give the impression that a "SIP Application Server" is only defined according to its support of SIP. This perception may have been reinforced by the SIP-centric nature of early IMS service platforms. This does not have to be.

For me, the IMS service architecture figure from the 3GPP specifications, which places the S-CSCF at the center, and the application servers at the margin, is like the photograph of a person that would only show the legs. In the context of the IMS application layer, the upper part of the body missing on the picture is SOA and Web Services oriented. It integrates IMS applications in the IT and Web 2.0 domains. To this respect, the Parlay X type of approach, which concentrates on the exposure of telecom services to 3rd parties is only one side of the coin, as IMS applications may as much consume 3rd party services as they can expose some.

I can send my version of the complete IMS application layer photograph to those of the readers interested. Just send an email to me (see my profile). It is in color...

Different SIP Traffic Patterns for Core Network and Application Layer Entities

All IMS SIP signalling for all IMS users goes through the IMS core network entities called CSCFs (more especially the S-CSCF).

If you consider John, the proportion of SIP messages that may originate from his devices or are addressed to him and are processed by an S-CSCF serving him is simple to calculate: 100 %. Similarly, all SIP messages originated or received by IMS application servers have to transit through CSCFs. The IMS core network is the SIP connectivity network, the IMS motorway, without which there is no IMS and no accessible IMS application or IMS client. This motorway is agnostic of the services it enables, and will treat in a similar way SIP messages used to establish a voice session, a gaming session, to access or update presence, to send instant messages, or to program your VCR for tonight's TV program.

This is not the same situation for the application layer. An application server hosts a set of services that may only apply to a subset of IMS users, and to a subset of the SIP signalling associated to these users. Typically, a presence server is only interested in presence-related signalling for the users it supports (the user centric nature of IMS permits to distribute users on several server instances).

You may imagine servers hosting very popular services, inducing a lot of SIP traffic, and others serving more niche services, or which use SIP more marginally than other protocols in their service delivery.

Finally, not all IMS services will have stringent latency requirements, as not all of them will be related to real time person to person communication.

Bottomline, there might be very different requirements in terms of scalability, reliability, and latency between IMS core network and application layer entities.

IT Invasion in the IMS Application Layer!

The way I see it, the IMS core network consisting of CSCFs, the HSS, border and voice gateways, is still a very telco-centric system, being highly standardized, essentially processing signalling, processing this signalling in a very systematic, service independent manner, having to be very scalable, reliable and highly responsive.

On the other hand, the IMS application layer is where innovation has to be introduced, it has to be very dynamic, with advanced interfaces towards end-users, and a deep integration with advanced IT and Internet systems. Requirements on capacity, reliability, latency, may be (slightly or significantly) more relaxed than for core network entities.

My opinion is that the whole IMS application layer should belong to the IT domain, with eventually most if not all applications being implemented on advanced, open, standardized service platforms provided by major IT vendors (e.g. J2EE). Application themselves will be implemented by software companies, including some located in garages.

This is a big difference with the current situation, in which most of the telco application layer is still implemented on closed, telco-specific platforms, and supplied by big telco vendors.

An essential point for me is that the IT domain will start on top of SIP (whether ISC or when the AS acts as a normal SIP enpoint) and not only on top of a web services gateway. IMS applications may equally use Web Services, SIP and other relevant protocols to deliver their goodies to end users, and if IMS can bring something to the Internet and IT communities, this is by introducing SIP as a another generic service control protocol, extending SOA into a User Oriented Architecture (UOA).

Christophe

Three Axes for IMS: #3 User Oriented Architecture

The Service Oriented Architecture (SOA) is an IT architecture that enables the creation of applications via the combination of loosely coupled and interoperable services. While there may be different implementations, typical SOA makes use of WSDL, BPEL and web services. Web 2.0 and Mashups are also linked to SOA.

SOA concepts and ideas are spreading very fast in the Telco industry. However, at the moment, few see a relationship between IMS and SOA, other than the fact that IMS (like the pre-IMS network(s)) can exhibit web services to an application layer implemented around SOA. In this vision, there are two clearly separated worlds: an IMS/SIP core network and a SOA/WS service network, the former integrating with the latter according to the latter's terms, i.e. by exposing its capabilities through web services.

My belief is that such a vision is very partial and totally ignores the capabilities of SIP and IMS for the delivery of services. SIP as a protocol, and IMS as a service architecture, can optimally integrate with and complement a SOA, by bringing a dimension that is currently missing to it and is fundamental: user orientation.

To understand how SIP and IMS can support a User Oriented Architecture (UOA), it is first important to realize that SIP is not only a very generic session control protocol, that can support application-level sessions (see previous entry). SIP also features an important set of non session-related extensions, which make it a very generic service control protocol. The most important of these extensions is certainly the concept of "event package", which is based on the methods SUBSCRIBE, NOTIFY, and PUBLISH. SIP-based Presence relies on event packages, which permit a user (or application) to access, monitor or modify presence information. However, presence is only the tip of the event package iceberg. There already exist numerous event packages, which permit, e.g. to monitor the activity of a user on a keyboard or the changes made to a user profile, or for a server to receive and interpret stimuli from a graphical user interface (e.g. the user touched this area, then entered this and that key). Event packages permit to create, update and distribute any type of event, data, and commands into a SIP network.

The user orientation of IMS is based on characteristics that are specific to the SIP protocol, and on others that belong specifically to the IMS service architecture.

In short, SIP addresses can relate to services, but are more usually associated to users. The IMS service architecture permits to route SIP requests to devices and to application servers based on the identity of the user. The routing of SIP requests to devices associated to the user is based on normal SIP routing procedures, while the routing of SIP requests to specific application servers is based on "service profiles" associated to each user and stored in the IMS user database, the HSS.

In practice, while SOA would permit an application to access the presence of user X by using a presence service with the identity of a user as parameter, SIP and IMS permit to access the presence of a user via the generation of a SUBSCRIBE which is addressed to the user identity. Instead of being routed to a unique presence service applicable to all users, the SIP request can be routed to an instance of the presence service which is specific to this particular user.

Such a reversal of the addressing and routing approach (service for SOA, user for SIP) is very important, as a request addressed to a SIP user address in IMS can reach a user, but also the devices associated to this user, and applications or application instances associated to this user, whether these applications reside in the network (e.g. presence) or in the device(s) of the user (e.g. a game).

Imagine a health monitoring device installed on the body of the user. A very convenient way for a centralized entity to access health indicators of the user and to monitor their changes over time would be to issue a SUBSCRIBE for a specific event package, and to address this SUBSCRIBE to the user itself. The same SUBSCRIBE addressed to different users will reach the health monitoring devices associated to each of them.

Now, think of all the potential applications of SIP event packages, add to it all the potential applications of the generic session control mechanisms of SIP. Think that there exist other SIP extensions of interest to add to the pack. Then, imagine the potential of a service architecture that combines both SOA and SIP/IMS principles...

Christophe