Category: IMS

IMS and the TISPAN secrets

No this is not a Harry P. sequel but just about as mysterious. For a long time I was aware that besides IMS there is a group called TISPAN that deals with Next Generation Networks (NGNs) in the fixed line world. Lots of articles note that TISPAN is based on IMS but give no further details. Recently I did some research in this area and here is my summary of how TISPAN and IMS are related. A word of caution, though: For the text below I assume that you are familiar in general with how IMS works, i.e. what is a P-CSCF, S-CSCF, etc.

As the IMS mainly addresses the requirements of wireless operators, the European Standards Institute (ETSI) has decided to define a broader NGN architecture in their TISPAN (Telecommunications and Internet converged Services and Protocols for Advanced Networking) standards project. In the meantime 3GPP and TISPAN are working in close co-operation and it is expected that Release 8 of the 3GPP standard will contain a common architecture. In its core, a TISPAN Next Generation Network (NGN) consists of the following entities:

  • A subset of the IP Multimedia Subsystem (IMS) as defined by 3GPP;
  • A PSTN / ISDN Emulation Subsystem (PES);
  • Other non-SIP subsystems for IPTV, Video on Demand and other services.

As can be seen in the list the IMS is only one of several core subsystems of TISPAN. The reason for this is the fact that many services today are not based on SIP and sessions such as IPTV or Video on Demand (VoD). Many different approaches exist on the market today to deliver such services to the user. TISPAN aims to standardize the way such services are delivered, controlled and billed and how such applications can interact with the transport network to request a certain quality of service level for their data packets.

While the IMS has been defined to be access network agnostic, the 3GPP standards still make a number of assumptions on the kind of access network and subscriber databases to be used. To make IMS usable for DSL and cable operators it is required to fully generalize interaction with the access network and to have a generalized user database in the network. The figure on the left shows a simplified model of how the IMS is enhanced by TISPAN for this purpose as defined in ETSI ES 282 001 and ETSI ES TS 182 006 (available at the ETSI website for free but you have to register).

A main difference between fixed line and wireless networks is how devices connect to the network. In case of fixed line access networks, a DSL or cable modem at the customer’s premises is usually the gateway device that establishes the connection to the network. One or more devices behind this gateway device will then use the established connection to register with the IMS service. This is quite different compared to 3GPP where each device connects both to the transport network (PDP context activation) and to the IMS service (SIP register).

A number of different ways exist today how a DSL or cable modem can attach to the network.  TISPAN has made the step to standardize the functionality required in the network for user management at the network layer with the Network Attachment Subsystem (NASS). When a DSL or cable modem is powered on it first communicates with the NASS to authenticate and to obtain an IP address. Protocols used for this purpose are for example PPPoE (Point to Point Tunneling Protocol over Ethernet) and PPP over ATM.
The NASS is reached during the attachment process via the Resource Control Enforcement Function (RCEF) / Border Gateway Function (BGF) which sits between the access network and the core network of the operator. Their tasks are among others to route IP traffic between an external network and subscribers and to ensure that quality of service requests coming from the IMS or other core systems listed above are enforced on the transport layer.

The TISPAN Resource and Admission Control Subsystem (RACS) performs a similar task as the IMS Policy Decision Function (PDF). When an IMS session is established by a TISPAN device the P-CSCF contacts the RACS subsystem to reserve the required resources for the session and to allow IP packets to flow between the participants of the session. The RACS then communicates with the RCEF/BGF to see if enough resources are available for the session and configures them accordingly.

While in the 3GPP IMS model resources are reserved by the mobile devices and the P-CSCF once codecs have been agreed on, the TISPAN P-CSCF already contacts the RACS for the first time when receiving the INVITE message from the originator. If bandwidth requirements change during the session setup because a different codec has been selected by the devices the P-CSCF contacts the RACS again to modify the policy. This means that unlike a 3GPP IMS mobile device, which requests a certain bandwidth and QoS with a secondary PDP context activation, TISPAN IMS devices are not involved in QoS processes at all since the P-CSCF takes care of the whole process. This is necessary as TISPAN devices, unlike 3GPP mobile devices, are pure IP devices and thus can not influence the quality of service settings of the network themselves.

So much for this blog entry. Stay tuned for part two in which I will discuss the PSTN/ISDN Emulation Sub-System (PES).

As always, comments are welcome!

Will Fixed/Wireless Convergence Push IMS?

Despite its multimedia capabilities the IP Multimedia Subsystem (IMS) hasn’t yet gotten a lot of opportunities to show its capabilities in wireless networks. One of the reasons for this is that current circuit switched mobile voice telephony works well and meets user expectations. Things, however, are improving for IMS.

With the introduction of the iPhone, more and more people are getting aware of multimedia and Internet capabilities of mobile devices. Thus, it might well be possible that multimedia enriched voice calls might also soon appear on the radar screen of users. On the network side many operators are upgrading their current 3G networks to 3.5G and with the first WiMAX networks rolled out now and LTE on the horizon there is sufficient bandwidth for such services. Additionally, WiMAX and LTE networks no longer have a circuit switched part and operators need a solution such as the IMS to be able to offer conversational services over their next generation networks. It thus seems inevitable, that the IMS will have a bright future.

In practice, however, things will be a bit more difficult since third party VoIP service providers such as Skype, Vonage and others could try to take a piece of the wireless market in a similar way as in fixed line networks today. After all, the application layer does not care whether IP packets traverse a DSL line or the air interface of a wireless network as long as there is enough bandwidth. From my own experience, SIP and proprietary VoIP services such as Skype work well over 3.5G wireless networks and even Skype video calls have excellent video quality in both directions.

Network operator based IMS systems, however, have a number of advantages over voice services provided by third parties if the play their cards right:

Network operators today sell both a mobile device and voice service. This means that the service works out of the box, no configuration required by the user. With pre-installed and pre-configured IMS applications such as voice, video calling, presence, etc. they have a head start over third party services for which applications have to be installed on mobile devices.

The IMS is also able to request a certain bandwidth for a session from the transport layer. In case there is congestion anywhere in the network, it will be made sure that multimedia sessions are not impacted.

The third advantage, which I think is a major one, is that IMS gives network operators with both fixed line (think DSL, cable) and wireless assets (think HSPA, WiMAX and LTE) the opportunity to converge their voice + multimedia service offerings both in the network and from the users point of view.

In the fixed line world the transition from analog telephony to VoIP over DSL or cable is already in full swing. The incentive for the user to switch to VoIP is usually a lower price for a combined voice service and Internet access over DSL or cable. When combined with mobile voice + Internet access, network operators can offer their clients Internet access + voice (and multimedia) telephony both at home, in the office or while roaming outside with a single device and a single telephone number.

The IMS also allows to have many devices registered to the same telephone number. This is great since at home it might be more convenient to use a dedicated phone, a notebook or even an IMS capable and connected television set to make a voice or video call.

With Voice Call Continuity (VCC) there is even the possibility that a mobile device automatically switches to Wifi when the user returns home or to his office thus reducing the load on the cellular network. Switching to Wifi at home also solves the issue of 3G/4G in-house coverage which in many regions of the world is inferior to 2G coverage due to the use of higher frequency bands.

And finally, the IMS has the capabilities to transfer a voice call from one device to the other. This is quite interesting in scenarios in which the user returns home and then transfers an ongoing voice call from his mobile phone to a television set and adding a live video stream to the call in the process.

It’s clear that getting all of this right is not a trivial task. But if network operators want to retain their role as a service provider they have to go beyond what third party service providers could offer over a bit pipe.

As always, thoughts and comments are welcome!

I-WLAN for IMS access over Wifi

I’ve taken a look at IMS lately and ways to access the IMS from non 3GPP networks such as Wifi hotspots and Wifi at home. Looks like 3GPP TS 23.234 and TS 33.234 contains everything required for the purpose. The first major building block of I-WLAN (Wireless Local Area Network interworking) is how the subscriber database of a 2G/3G network can be used to authenticate Wifi users that have a device with built in GSM/UMTS SIM card. For this purpose EAP/AKA or EAP/SIM is used. For EAP-SIM I’ve written a blog entry some time ago. The standard also foresees methods for the access point to deliver billing information to the 3GPP network.

What I didn’t realize at that time was that the second building block in those two documents is a method to establish an IPSec encryption tunnel between a mobile device and a gateway between an external network (e.g. the Internet) and the 3GPP core network which hosts an IMS. This gateway is called the Packet Data Gateway (PDG). The standard even says that the IPsec tunnel setup can be used without the above mentioned EAP-SIM authentication step. That’s good news as the EAP-SIM authentication requires support of the Wifi Access point while the tunnel establishment is transparent to the Wifi access point.

So let’s see maybe we’ll see 3G+/Wifi IMS devices with the ability to establish an IPSec tunnel over Wifi to the IMS of their wireless operator. Great stuff for mobile operators with DSL assets.

IMS Applications

In my previous IMS post I’ve taken a look at the difference between SIP telephony networks and the IP Multimedia Subsystem (IMS). With that list it is quite obvious that the IMS is a centralized session management system that gives lots of control to the network operator and makes it quite difficult for third parties to integrate their services on a global scale. So while in theory the IMS is capable to be a platform for many web 2.0 services I think that in practice it will manly be used in the future for voice and instant messaging based services. Here’s a list of services which I think we will see in the IMS in the mid-term. If you have other examples, please leave a comment!

  • Voice telephony as the main application. This includes handing over voice calls between networks as the user roams out of coverage of a network. Furthermore, advanced IMS solutions will enable handovers of voice calls to a 2G network if no high speed B3G network is available anymore.
    The IMS enables video calls with the advantage over current 3G circuit switched mobile video calls that the video stream can be added or dropped at any time during the session.
    Presence and instant messaging.
  • Voice and video session conferencing with three or more parties
    Push message & video services such as sending subscribers messages when their favorite football team has scored a goal, when something exciting has happened during a Formula-1 race, and so on.
  • Calendar synchronization among all IMS devices.
  • Notification of important events (birthdays, etc.).
  • Wakeup service with auto answer and the users preferred music or news.
  • Live audio and videocasts of events. The difference to current solutions is the integrated adaptation to the capabilities of the device.
  • Peer to peer document push.
  • Unified voice and video mail because all devices used by a person are subscribed to the same IMS account.
  • One identity / telephone number for all devices of a user. A session is delivered to all or some devices based on their capability. A video call would only be delivered to registered devices of the user capable of receiving video. Sessions can also be automatically modified if devices do not support video.
  • A session can be moved from one device to another while it is ongoing. A video call for example might be accepted on a mobile device but transferred to the home entertainment system when the user arrives at home. Transferring the session also implies a modification of the session parameters. While a low resolution video stream is used for a mobile device the resolution can be increased for the big screen of the home entertainment system if this is supported by the device at the other end.
  • Use of several user identities per device. This allows only using a single device or a single set of devices to be reached friends and business partners alike. With user profiles in the network incoming session requests can be managed on a per user identity basis. This way, business calls could be automatically redirected to the voice mail system at certain times, to an announcement or to a colleague while the user is on vacation while private session requests are still connected.

IMS vs. Naked SIP

Everyday we get a bit closer to all IP wireless networks in which operators are hard pressed to present a voice over IP solution. Today two approaches are on the horizon: ‘Naked SIP’, already implemented in some 3G phones such as Nokia N-Series and E-Series S60 phones. And then there is the IP Multimedia Subsystem (IMS), based on SIP but with lots of additional specification put around it. So what does IMS do that SIP doesn’t? I came up with the following list of things which are laking in naked SIP today which are dealt with in IMS:

  • General SIP implementations are network agnostic and can not signal their quality of service requirements to a wireless access network. Thus, voice over IP data packets can not be preferred by the system in times of congestion.
  • Handling of transmission errors on the air interface can not be optimized for SIP calls. While web browsing and similar applications benefit from automatic retransmissions in case of transmission errors, VoIP connections would prefer erroneous packets to be dropped rather than be repeated at a later time since such packets are likely to come too late.
  • SIP VoIP calls can not be handed over to the 2G network in case the user roams out of the coverage area of B3G networks.
  • SIP does not work in 2G networks.
  • Most SIP implementations today use the 64 kbit/s PCM codec for VoIP calls. Compared to optimized GSM and UMTS codecs, which only require about 12 kbit/s, this significantly decreases the number of VoIP calls that can be delivered via a base station. Furthermore, mobile network optimized voice codecs have built in functionality to deal with missing or erroneous data packets. While this is not required for fixed networks due to the lower error rates it is very beneficial for connections over wireless networks.
  • Emergency Calls (112, 911) can not be routed to the correct emergency center since the subscriber could be anywhere in the world.
  • No billing flexibility. Since SIP implementations are mostly used for voice sessions, billing is usually built into the SIP proxy and no standardized interfaces exist to collect billing data for online and offline charging.
  • Additional applications such video calls, presence, instant messaging, etc. are usually not integrated in SIP clients and networks.
  • It is difficult to add new features and applications since no standardized interfaces exist to add these to a SIP implementation. Thus, adding new features to User Agents and the SIP network such as a video mailbox, picture sharing, adding a video session to an ongoing voice session, push to talk functionality, transferring a session to another device with different properties, etc. is proprietary on both the terminal and the network components. This is costly and the use of these functionalities between subscribers of different SIP networks is not assured.
  • Insufficient security: Voice data is usually sent unencrypted from end to end which makes it easy to eavesdrop on a connection. Signaling can be intercepted since it is not encrypted. Man in the middle attacks are possible. No standards exist of how to securely and confidentially store user data (e.g. username/password) on a mobile device.
  • Scalability: Mobile networks today can easily have 50 million subscribers or more. This is very challenging in terms of scalability since a single SIP proxy in a network can not handle such a high number of subscribers. A SIP network handling such a high number of subscribers must be distributed over many SIP proxies/registrars.
  • There is no standardized way to store user profiles in the network today. Also, no standardized means exist to distribute user data over several databases which is required in large networks (see scalability above).

The list is quite long I have to admit. But there is one thing the list does not say: While naked SIP is available today I have yet to see an IMS capable terminal in the wild. I wonder how long it will still take?

As always, comments are welcome.