WirelessMoves

IMS and TISPAN, a bit of a mystery combination. In part one I’ve taken a look at what TISPAN is and how it uses IMS in it’s architecture. This part focuses on the PSTN/ISDN Emulation Sub-System and how the IMS can be used to simulate an analogue telephony switching center.

Besides the IMS subsystem the PSTN/ISDN (Public Switched Telephone
Network / Integrated Services Digital Network) Emulation Sub-System
(PES) is another important element of TISPAN. Its aim is to enable
legacy analog and ISDN telephones to be connected to an IP based next
generation network (NGN) via a media gateway which is either part of
the access modem or a standalone device. An IMS independent
implementation for PES is described in ETSI ES 282 002 while ETSI TS
182 012 defines how a PES can be implemented with IMS. Both standards documents are available via ETSI’s web site for free but one must register first.

As legacy devices can not be
modified a gateway has to be deployed on the user’s location. On the
one side of the gateway the analog or digital telephone is connected to
a legacy connector. In case of a standalone device the other side of
the device usually features an Ethernet connector with which the device
can be connected to the DSL or cable modem. The PES specification in
ETSI TS 182 012 knows two types of devices. Voice Gateways (VGWs)
emulate a SIP User Agent on the behalf of the legacy device and
communicate with SIP commands with the P-CSCF of the IMS. The second
approach is to deploy a media gateway (GW) which communicates via the
H.248 (Media Gateway Protocol, MEGACO) to the Access Gateway Control
Function (AGCF). In this approach the SIP User Agent functionality is
included in the AGCF, i.e. not on the customer device but in the
network itself.  Additionally, the AGCF includes the P-CSCF
functionality. During call establishment, the P-CSCF or the AGCF then
communicate with the RACS to reserve the required transport resources
to ensure the quality of service for a call. In addition, PES requires
an IMS Application Server (AS) to emulate the PSTN or ISDN service
logic when the PES User Agent sends SIP messages with embedded ISUP
messages.

And a final note: The TISPAN standard also aims to standardize non IMS
sub-systems. While out of scope of the current version of the
specification it is likely that TISPAN will specify a standardized IPTV
and Video on Demand (VoD) system in the next version.

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!

Interesting to see that telecommunication equipment providers are showing up on YouTube. Here are some nice examples. Of course with no advertisement in mind from my side 🙂

• Nortel’s Hypreconnectivity Vision
• Alcatel Lucent’s Vision for IMS
• Nokia Siemens Networks: Bringing Networks to Life
• Ericsson on IMS (and sequels here, here and  here)

Have fun watching!