A guide to the architecture that extends IMS to non-SIP applications * Why that's important * What's now standardized * Challenges to come

July 17, 2006

31 Min Read
Tispan: IMS Plus

In the past couple of years, IMS has become one of the biggest buzzwords in the telecom industry because of its promise of enabling operators to roll out a multiplicity of new services rapidly and inexpensively even while cutting costs by consolidating networks, back office systems, and staff.

Far less fuss has been made of IMS’s bigger brother, Tispan, which incorporates IMS (IP Multimedia Subsystem) but actually does a whole lot more by tackling many of the specific requirements of fixed networks.

In a nutshell, Tispan tackles non-SIP applications and IMS doesn't – and that's a very big deal. Why? Because non-SIP applications include not only legacy services but also HTTP applications and peer-to-peer file sharing. In other words, they represent a substantial proportion of traffic on current and future IP next-generation networks (NGNs).

This realization is now triggering growing interest in the European Telecommunications Standards Institute (ETSI) ’s Tispan NGN standard, particularly since the publication in December 2005 of Release 1. Many telcos and service providers are beginning to specify – or are planning to specify – Tispan in their NGN rollouts, so Tispan is by no means just another vendor-inspired bandwagon.

Indeed, a poll taken during the Webinar on which this report is based suggests that Tispan is hitting the right buttons on current concerns over NGN services. Nearly 45 percent of respondents believed that the first service deployed on a Tispan RACS/NASS subsystem would be PSTN emulation, followed by 33 percent who favored converged fixed/mobile multimedia SIP-based services.

NGNs are increasingly seen as important tools in the future profitability of network and service providers. They are about network convergence and a common service portfolio, regardless of access mechanism. For its proponents, Tispan delivers the architecture on which NGNs will be based, at least initially. And it’s not just about advanced services over a converged network – it’s crucial to service providers being able to scale their application delivery processes.

Today, the network is the service. Tomorrow, the service is an individual application, and the network is merely the transport that needs to be controlled to support the application. Supporting this potentially huge diversification of the service provider and telco product portfolio requires an architecture and framework above and beyond the basic network for accelerating the delivery and management of applications. Tispan is a step along the path to achieving this.

It is thus increasingly important to understand what Tispan is, what it isn’t, what it can do now, and what it is going to be able to do in the future should all the planned extensions materialize. Here’s a hyperlinked contents list into the Tispan maze:

  • Page 7: Tispan Now & in the Future

    Webinar

    This report is based on a Webinar, The Role of Tispan in Next-Generation Networks, moderated by Graham Finnie, Senior Analyst, Heavy Reading, and sponsored by Cisco Systems Inc. (Nasdaq: CSCO) and Tazz Networks Inc. An archive of the Webinar may be viewed free of charge by clicking here. About the Author

    — Tim Hills is a freelance telecommunications writer and journalist. He's a regular author of Light Reading reports.

    Next Page: The Point of Tispan

    Tispan is a bit of a mouthful, as it stands for Telecommunications and Internet Converged Services and Protocols for Advanced Networks. Strictly, it’s a standards group within the European Telecommunication Standards Institute (ETSI), but it also lends its name to the standards-based NGN architecture that the group is defining. There are eight subgroups defining all aspects of NGN – ranging from architecture, protocols, and security, right through to OSSs.

    Tispan is doing all this through the definition of subsystems that perform specific roles within an overall converged-services architecture. The subsystems are further broken down into functional blocks – components that provide specific functions – and sets of interfaces among these components. These interfaces are protocols and protocol specifications.

    Tispan is looking mainly at the fixed-line environment, but there is also a very close working relationship with the 3rd Generation Partnership Project (3GPP) to bring fixed/mobile convergence to NGNs. Essentially, Tispan adopts the 3GPP IMS architecture standard for SIP-based applications, but adds further functional blocks and subsystems to handle non-SIP applications and other requirements of fixed networks not addressed by IMS.

    There are two main points behind the Tispan effort. One is to improve the subscriber experience and deliver new services, such as IPTV, that don’t work well over today’s best-effort Internet, or that currently need separate networks. Ultimately, end users will be able to access these services from wherever they are and with whatever device they may be using to attach to the network.

    From the service provider perspective, the Tispan NGN is about consolidation and cost savings as much as it is about introducing new services. Table 1 shows why. Currently, when a subscriber uses an application, there is generally a vertically integrated silo of hardware and software, running from the terminal to the back office, that delivers the application to the user. This arrangement is known as a stove-pipe architecture, and is inherently inflexible and expensive to operate and manage overall – although each separate silo or pipe may be highly optimized for its particular application.

    Table 1: Comparison of Per-Service Provision Requirements in Traditional & NGN Architectures

    Stove-pipe architecture

    Tispan NGN architecture

    Back office

    Separate

    Common

    Application

    Separate

    Separate (but potential for shared application components)

    Service delivery and session control

    Separate

    Common

    Network

    Separate

    Common

    Terminal

    Separate

    Common (depending on capabilities)

    Source: Tazz Networks, 2006



    In contrast, the Tispan NGN avoids this multiple replication by introducing large-scale commonality into the hardware and software used for service and application delivery and operation.

    “NGN for service providers is about consolidating those services onto a converged IP core. It is about consolidating the service delivery infrastructure – the bits of middleware infrastructure that sit under the application code – so that those components can be reused to introduce new applications,” says Jared Rosoff, founder and chief technology officer of Tazz Networks. “And it is about reusing all the back-office and management systems, and increasing the cost efficiency of operating and running this network, as well as lowering the bar to introducing new applications.”

    Next Page: NGN Evolution & Requirements

    Although Tispan is a specific NGN architecture, it belongs to a broad stream of common industry thinking on NGNs. Figure 1 shows a very basic high-level view from one vendor, Cisco, of how an NGN architecture may be divided into different operational layers. Tispan formalizes this type of approach.

    95511_1.gifThe NGN consists of three layers – Application Layer, Service Layer, and Network Layer – and needs to support key requirements placed by different types of application and service:

    • Consumer: The evolution of fixed-line, best-effort data solutions to triple-play voice, video, and data solutions, including a wide range of additional capabilities, such as bandwidth flexing and turbo-button, application-aware QOS for supporting particular applications.

    • Business: QOS-enabled Layer 2 and Layer 3 VPN services supporting converged data, voice, and video solutions. Customers want increased network transparency, administrator-driven changes to branch bandwidth and QOS, on-road access, and access via disparate user equipment.

    • Evolved services: These mean evolving existing service infrastructures, such as the PSTN, onto the NGN environment so as to offer similar services but with lower opex. In the longer term, these evolved services will be more closely integrated with new consumer and business services.

    To offer flexible, mobile solutions requiring hard bandwidth and QOS guarantees requires a much closer level of cooperation between applications and the network. The Service Exchange framework provides this linkage in the Cisco NGN.

    “The Service Exchange framework has a number of key functions. The first is to provide a level of virtualization,” says Simon Spraggs, distinguished systems engineer at Cisco. "So the applications don’t need to understand the topology of the network, and the network does not need to understand the intricacies of the particular application. But it also needs to provide services such as identity services, directory services, the policy control elements, billing, and so on. So there is clearly a software element, but also in some cases a hardware element as well. Devices such as deep packet inspectors, session border controllers, and media gateways would also sit at this level of the network.”

    This layer sits above the Network Layer, which is an IP/MPLS infrastructure that can provide reliable packet forwarding and virtualized services across the network. It is also the enforcement point for the Service Layer – clearly, without such capabilities in the Network Layer, there is little point in having a lot of the described service capabilities.

    SIP and Non-SIP

    When it comes to looking at the more detailed requirements that applications put on an NGN, there are many application types, protocols, and procedures, but one important division will be between those applications that use SIP to do their session setup and those that don’t. Figure 2 illustrates this point and also gives more details of the Network Layer.

    95511_2.gifAlthough the vast bulk of existing wireline Internet-type applications do not use SIP, Spraggs points out that there is huge interest in the use of SIP signaling to find users, to set up calls, and to alter connections between applications. It’s also been heavily embraced by the mobile world, and IMS – developed initially by the 3GPP – is built entirely around the setup and control of SIP-based sessions.

    Subsequently, other standards groups have borrowed or adapted the work done by the 3GPP to build IMS solutions specific to their needs. As a consequence, the term IMS has quickly moved to become generically associated with an architectural framework for SIP-oriented applications.

    “Clearly, if we are going to get fixed/mobile convergence in the future, we need to pay a lot of attention to the actual SIP environment,” Spraggs says. “However, NGN is not only about SIP. We need to be able to deal with non-SIP applications.”

    The huge number of non-SIP-based applications fall largely into two types:

    • Legacy/Existing: These form an extensive list and include VOD and video systems that use protocols such as RTSP, or even HTTP, to access services; basic Internet access services, which often operate below the IP layer with protocols such as PPP or DHCP services for getting users onto the network; and email and the like.

    • Inappropriate/Non-SIP-Signaled: SIP’s basic raison d’être of session setup can be irrelevant to some services, or not work very well for them. Examples are what service providers term over-the-top applications. These are applications that are not hosted by the service provider – examples are a multiuser gaming application and a peer-to-peer file-trading application.

    “We think that it is key that the NGN be able to support both these legacy services as well as non-session-based services -- things like a turbo button that do not involve a real-time media streaming session between two points, but rather refer to a generic flex of bandwidth on an access line,” says Tazz Networks’ Rosoff.

    He points out that part of the benefit of the SIP environment is obviously that it ties the service provider into that SIP signaling, and allows the provider to react to SIP-based applications. However, even for over-the-top applications, the service provider often wishes to provide controls that can be leveraged, though SIP is not being used and the service provider is not directly involved in the signaling chain. So it is important to consider whether an NGN architecture can support both SIP- (or IMS) and non-SIP- (non-IMS) based solutions.

    Going Beyond 3GPP IMS

    It’s worth pointing out some further reasons why the Tispan NGN incorporates IMS but does not use it exclusively.

    3GPP is developing IMS (see Figure 3) as part of its work to create a globally applicable specification for a third-generation (3G) mobile phone system. 3GPP specifications are in turn based on the GSM (Global System for Mobile Communications) specifications, now generally known as the UMTS (Universal Mobile Telecommunications System). This has initially tended to orient 3GPP IMS more towards the characteristics and requirements of the mobile environment, although the intention is to make IMS access agnostic – and the specification’s sequential releases are moving further in that direction.

    95511_3.gifNevertheless, there are implicit assumptions in 3GPP IMS that do not necessarily match the wireline environment. According to Rosoff, these include:

    • Policy element part of the Proxy SIP server: Implicit assumption that only SIP applications need policy.

    • Wireless user entity and authentication: No account taken of 15 years of AAA deployment in wireline.

    • Wireless access network via GGSN: 3GPP has made a number of assumptions about the access network and the way it is structured that are largely incompatible with how much of the wireline network has been built out. For example, there is no account of CMTS for cable and B-RAS for xDSL.

    • Only SIP-signaled applications: No account taken of the majority of Internet applications and bandwidth. applications.

    • Business: No account of the regulatory and resulting commercial models seen in the wireline environment.

    From the service perspective, 3GPP IMS is very much based on session-based services, primarily looking at applications that involve real-time media streaming among multiple points on the network. Thus many of the service-control protocols do not include concepts of security policies and so forth that an application may wish to activate. Instead, these functionalities are designed into the underlying transport network, without the real service exposure that is demanded by many of the newer-generation applications.

    “Some of the assumptions about the wireless network also don’t carry over to the wireline network,” says Rosoff. “For example, security in a wireless environment is based on secure IDs and SIM cards sitting inside the wireless handset, and a lot of the encryption and authentication mechanisms built into the network are based on this capability. Unfortunately, you don’t have this concept in the wireline network. Rather, there is a DSL environment where users are identified by a line ID or MAC address. A lot of the assumptions that are made from a security and authentication standpoint don’t carry over to the wireline environment.”

    Next Page: ETSI Tispan Specifications

    According to Cisco's Spraggs, the ETSI Tispan work takes a very pragmatic approach, and the emphasis is very much on providing solutions that can be implemented.

    “Release 1 was published in December 2005 and contains the main standards directions,” he says. “So it contains the overall architecture, and I think it is fair to say that Release 1 has concentrated quite heavily on voice, xDSL, SIP-oriented solutions, and edge QOS solutions. It’s a useful feature and functionality set, but it certainly doesn’t cover the entire NGN-type applications that we are going to see. For instance, it doesn’t look at streaming media and those kinds of things to start with.”

    Release 2 will fill some of these gaps and is being defined now for publication during 2007; Release 3, which will treat generalized mobility, is planned to follow in 2009.

    Architectural highlights of Tispan Release 1 include:

    • Support for SIP-based and non-SIP-based applications

    • IMS for conversational SIP-based applications

    • Other subsystems for other application types

    • Access agnosticism

    • Support for complex commercial models

    • Roadmap to fixed/mobile convergence based on IMS

    • Reuse and collaboration with standards development organizations (specifically 3GPP, but others include the Broadband Forum and the MultiService Forum )

    The Tispan Release 1 architecture is based on the 3GPP IMS Release 6 architecture but is intended to address the wireline providers. The architecture uses cooperating subsystems sharing common components, which allows the addition of new subsystems over time, to cover new demands and service classes. It also ensures that the network resources, applications, and user equipment (mostly inherited from IMS) are common to all subsystems, thereby ensuring user, terminal, and service mobility to the fullest extent possible.

    Figure 4 shows a high-level view of the overall Tispan NGN architecture. Despite the apparent complexity, the basic NGN layering is visible. At the top is the applications domain, which is really a placeholder for the specific application services that a service provider wants to deliver to its customers, and which are not specified by Tispan.

    95511_4.gifUnderneath are a number of reusable service subsystems that underpin those applications and enable them to be delivered. These subsystems include RTSP-based streaming services, the IMS SIP-based services, and PSTN emulation services. A key feature is that all these services share a variety of other common components. In particular, they are linked to a common database, which means that they all share subscriber identity information and subscriber profile information, rather than having their own separate-silo versions of that data. All these services also share two of the most important functional blocks of Tispan: the NASS and the RACS.

    The Network Attachment Subsystem (NASS) provides registration at access level and initialization of user equipment for access to Tispan NGN services. NASS provides network-level identification and authentication, manages the IP address space of the access network, and authenticates access sessions. NASS also announces the contact point of the Tispan NGN service/applications subsystems to the user equipment. Network attachment via NASS is based on implicit or explicit user identity and authentication credentials stored in the NASS.

    The Resource and Admission Control Subsystem (RACS) provides applications with a mechanism to request and reserve resources from the access and aggregation networks. To achieve this, real-time multimedia services (VOIP, videoconferencing, VOD, and online gaming) must be able of trigger the QOS resource reservation, admission-control, and policy-control capabilities of the network. RACS provides the means for an operator to enforce admission control and set the respective bearer service policies. It provides the means for value-added services to obtain network resources that are needed to offer end-user services. RACS is session aware but service agnostic.

    Finally, Tispan specifies some things about the access network – such as the home network environment and how home terminals connect onto this network – as well as the core network transport, and how this whole architecture enables peering to neighboring providers and transit carriers that might be participating in the NGN.

    IMS entities can use the Interconnect Border Control Function (IBCF) to perform interconnect procedures at the boundary between to operator domains. There may be multiple IBCFs within an operator’s network. The use of the IBCF is optional in the architecture and depends on the operator's interconnect policy. IMS entities insert the IBCF along the SIP signaling path if required by local policy.

    Next Page: Details of Tispan Release 1

    Figure 5 gives a more detailed breakdown of the Release 1 architecture, showing the main functional blocks within the larger component subsystems. Although it appears complicated, it is logical and very similar to a layout in a DSL environment. Table 2 provides more information on the functional blocks within the architecture.

    95511_5.gifTable 2: Main Functional Blocks Within Tispan Release 1

    Transport Function

    RACS

    NASS

    Service Subsystems

    Application Function

    Functions

    Core, access and home transport capabilities. Deals with different owners of the network

    Policy implementation. Admission control

    Registration and initialisation of UE. Network Level ID and authentication

    General architecture defines: Core IMS subsystem. PSTN/ISDN emulation subsystem (PES). Streaming Subsystem. Content broadcast subsystem. Note that Release 1 looks only at IMS and PES

    Two types of application: AF-1 applications -- Don�t use Service Subsystems; Interface directly to RACS; defined but not really covered in Release 1. AF-2 applications -- Use Service Subsystems

    Interfaces

    RACS and NASS

    Application Function (via Gq'). NASS (AAA and conf)

    RACS, Service, Transport

    RACS, NASS, Application Function

    Service Subsystem. RACS (AF-1 applications)

    Blocks

    (1) User Equipment: TE = Terminal Equipment. CNG = Customer Network Gateway

    SPDF- Serving Policy Decision Function. A-RACF- Access Resource and admission Control Function

    AMF = Access Management Function (Radius client). NACF = Network Access Configuration Function (CPE IP address allocation, DHCP server). CLF = Connectivity Session Location and Repository Function (registers association between IP address and CPE network location information for location based services). UUAF = User Access Authorization Function (user authentication, authorization and collection of accounting, Radius server). PDBF = Profile Database Function (authentication and user network profile). CNCFG = CPE Configuration Function

    (1) IMS subsystem: Subset of 3GPP IMS. Service control functionality

    (2) Access network: ARF = Access Relay Function (DHCP relay, PPP to Radius Relay). L2TF = Layer 2 Terminal Function (terminates L2). RCEF = Resource Control Enforcement Function (Policing, packet marking, Open/close gates)

    (2) PES: Non-IMS PES. PES over IMS

    (3) Core: BGF = Border Gateway Function. Superset of RCEF. Plus NAPT traversal and metering

    Source: Cisco Systems, 2006



    In terms of practical operation, some points to note include:

    Transport Function: The access node within the access network is typically something like a DSLAM, so it will have Layer 2 functionality, but it may also have some basic Layer 3 functionality as well. The IP edge is where the end-user session is terminated, and provides the first policy enforcement point at the IP layer. This situation equates very well to the current use of a B-RAS in the DSL environment or to a CMTS in a cable environment.

    The last component in the transport network is the core. Tispan is not concerned with primary transport functions such as routing but with the control of gateway functions, such as the Core Border Gateway Function (C-BGF), which provides, among others, QOS control and NAT-type functionality between the access network and the core network. The Interconnect BGF (I-BGF), has similar functionality, but for interconnection to other providers and other networks.

    RACS: The RACS consists of two primary functional blocks: the Service Policy Decision Function (SPDF) and the Access Resource and Admission Control Function (A-RACF). The SPDF is generally responsible for interfacing to the service subsystems in the application layer and allowing those systems to request reserved network resources from the NGN access network.

    When the SPDF receives one of these requests, it applies policy rules that can be specified by each service provider so as to define how its network will work. The service policy, for example, may define the amount of resources available for various types of service, the mechanism by which admission control be done, NAT and firewall traversal rules, and so forth.

    The SPDF interfaces to the A-RACF to reserve access bandwidth resources. In a DSL environment this would be perhaps an ATM access network or an Ethernet access network. This model can, however, support multiple types of access networks by deploying multiple A-RACFs – one for each access network type.

    Generally, the RACS is the point where policy control is injected into the Tispan architecture, and is the mechanism whereby features such as oversubscription, guaranteed QOS, and similar network-level capabilities can be exposed to the various subsystems of the Tispan architecture.

    NASS: The NASS is essentially a repository of data associated with end users. So it holds the policy information and the user location information, and it also provides the address allocation to the actual terminal equipment out in the network. This is very similar to the use of RADIUS in current DSL environments, as RADIUS authenticates the user, provides the user’s IP address, and provides some policy components associated with the user.Service Subsystems: Tispan concedes that there will be multiple service subsystems to cater to the different sorts of service that will be delivered, and IMS is just one of those subsystems. Tispan takes the core of IMS – the SIP control plane – and reuses it within the Tispan architecture, but replaces the original IMS access network and policy and admission control capabilities that were defined specifically for the wireless network.

    A major driver for Tispan is obviously PSTN emulation, given the huge PSTN user base. PSTN/ISDN emulation mimics a PSTN/ISDN network from the point of view of legacy terminals (analog or ISDN) by an IP network accessed through a gateway. All PSTN/ISDN services remain available and identical (with the same ergonomics for the user), so that end users are unaware that they are not connected to a conventional TDM-based PSTN/ISDN. There are two different forms of PSTN Emulation Service documented in Tispan:

    • Non-IMS PSTN Emulation Service: This is a very simple architecture with a monolithic softswitch controlling an access gateway (for the line side) and trunking gateways (for the trunk side). The protocol used between the softswitches is SIP-I, which encapsulates the national variant of ISUP over SIP. Many vendors are developing this architecture.

    • PSTN Emulation Service Over IMS: This reuses the full IMS to emulate PSTN/ISDN services, and introduces a new functional entity for the line side – the Access Gateway Control Function (AGCF). The protocol used between the IMS functional entities is SIP, and it means mapping all PSTN/ISDN supplementary services into SIP.

    The PSTN Emulation Subsystem thus contains all the call routing and switching infrastructure, as well as gateway functions that bridge between that emulated IP-based environment and the legacy SS7 and circuit-switched environments that end stations are used to. The PSTN environment shares all the same resources as IMS-based services, and hence the PSTN services and IMS services can coexist on top of a shared IP network.

    Notice that PSTN Simulation Service is different. It provides PSTN/ISDN-like services to advanced terminals (IP-phones) or IP-interfaces, and there is no strict requirement to make all PSTN/ISDN services available or be replicated, although end users expect to have access to the most popular ones, possibly with different ergonomics. This approach does not require the mapping of every complex PSTN supplementary service into SIP. PSTN Simulation Service always uses the IMS, which is termed a PSTN Simulation Subsystem.

    Tispan is currently considering several other service subsystems. In particular, the Release 2 work is looking at video streaming services in the RTSP subsystem. This will enable both IPTV and on-demand TV services to be delivered over the converged access network.

    Application Function: Tispan defines two types of application. Those that don’t use the service subsystems can directly interact with the RACS, but Release 1 has little to say about these. The second type use the service subsystems’ capabilities. They interface to the subsystem and then use the services from the various subsystems to get their requirements pushed down into the network.

    Next Page: Tispan in Action

    Tispan may sound very theoretical, so here are a couple of examples of how a Tispan architecture can support real applications.

    VOIP

    One of the early uses considered by Tispan is essentially the IMS VOIP architecture. A key demand on the IP-based NGN in delivering voice is to ensure that the QOS is the same as for a typical legacy PSTN call.

    Figure 6 shows how an IMS-based voice application can be signaled across the network by using Tispan, while ensuring that that call is delivered with a differentiated QOS (that is, appropriate to a voice call and not just best effort – something that is very difficult to do on the public Internet today).

    95511_6.gifThe steps, in order, are:

    • User dials phone number, and initiates SIP signaling

    • P-CSCF (part of IMS that handles proxying SIP messages on the access network) requests authorization for call via Gq’ interface

    • SPDF requests authorization for access network resources via Rq interface

    • A-RACF (optionally) provisions policies using Re/Ra interfaces

    • SPDF (optionally) requests BGF authorization via Ia interface

    • Remote party SDP received

    • P-CSCF requests re-authorization for call given remote SDP via Gq’ interface

    • SDPF (optionally) re-authorizes access network resources via Rq interface

    • A-RACF (optionally) changes policies using Re/Ras

    • SPDF (optionally) requests BGF re-authorization

    • Ringing signal delivered to user

    This is a fairly complicated process. Roughly, what is going on is that, when the user picks up the phone and dials a number, this signals via SIP to the P-CSCF. The P-CSCF, before it forwards the SIP message on to the rest of the IMS, asks the RACS via the SPDF to ensure that sufficient network capacity exists to support the proposed call. The SPDF thus evaluates the carrier’s service policy rules for the service to check, for example, the firewall pinholing and NAT traversal that may be required to route the call. It also goes down to the A-RACF to reserve a portion of the access network bandwidth to ensure that congestion would not cause poor call quality.

    Assuming that the policies checked out OK, and that enough bandwidth is available, the P-CSCF goes on to route the SIP call setup message to the called number. When the called number answers or responds, the signaling flows back from the remote end to the P-CSCF, and the RACS is ordered to commit the resources that have been provisionally reserved. Again, should it be necessary, there is the opportunity to reserve access-network resources, change the policy configuration in the access network to support the call, and to commit any firewall pinholing that might be required.

    Assuming that everything is still OK, the P-CSCF will continue to route the SIP message back to the called end station, and will cause the ringing signal to be heard by the phone.

    Wholesale Telecom

    An interesting aspect of Tispan compared to the original 3GPP IMS architecture is the range of business relationships that are available in Tispan.

    In the wireline environment, every country has different regulatory environments, and often there is separation between the wholesale and retail sides of wireline service delivery. Separation means that a single entity cannot both own the transport network and provide service to the end user attached to the network. This naturally leads to the formation of separate business entities, such as network service providers, which own and operate the actual network, and service providers,which retain a relationship with the end user and essentially lease services from the access-network provider.

    Figure 7 divides the Tispan architecture into a number of different business entities. There are many ways of doing this – Figure 7 is just one example, but it shows the level of sophistication that can be achieved.

    95511_7.gifOn the right-hand side are a variety of users, such as a bill payer using different devices in the home, or a roaming user moving between a wireless hotspot and a wireless access network. Each of these users is connected to one of several access networks (which may be owned and operated by different network service providers), and that access network authenticates those users and manages network resources by using the A-RACF and NASS functions.

    Figure 7 shows the SPDF-to-A-RACF interconnect (the Rq interface) as a business-to-business (B2B) interface, and on the left-hand side of the slide is ISP Network 1 – the actual service provider network and the entity that provides service to the end user. This entity operates the service policy decision function, thus essentially controlling the NGN core network, while delegating the access capability to a wholesale provider.

    Also shown is a third business entity – the application service provider – which models a third-party entity such as an independent voice carrier that might provide the IMS (for example) that a user’s applications interface with. Here another B2B interface (the RACS Gq’ interface) allows the application service provider to request QOS treatment for their services from the ISP, and the ISP may then in turn request QOS treatment from the network service provider for those services.

    Next Page: Tispan Now & in the Future

    Despite Tispan’s highly abstract nature and apparent complexity, it’s worth pointing out that architectures with similar aims and capabilities to Tispan have been around for some time in wireline networks. For example, at the access level of the network, user control and policy have been used for many years. Traditionally these have been done by RADIUS, which has been generally a pull protocol, and simple policy has been implemented when the user authenticates. Over time, however, policy controllers have been integrated into this Radius environment, and enhancements to Radius have been added to support dynamic push/pull policy control. Further, policy control today is not about programming a single entity; rather it is about interacting with multiple entities to create a business behavior.

    “Today we see user portals whereby users can log on and change their characteristics – such as prepaid, turbo button, VOD profiles, telephony profile, and so on,” says Cisco Systems’ Spraggs. “In lab environments we are also seeing VOD and middleware talking directly to the policy controllers for the purposes of changing user bandwidth and QOS profiles – also used as a CAC-ing [Call Admissions Control] function. Additionally, the service control environment is quickly moving beyond access only. We are developing solutions that perform core admission control functions.”

    Figure 8 shows how current wireline networks are beginning to incorporate such enhanced control capabilities.

    95511_8.gif“We are also starting to see some pretty strong interest in policy control in the core of the network,” continues Spraggs, “although it is somewhat different in the core, and is probably not going to be about per-user configuration, but more about admission control. Today we see plenty of softswitches running over IP environments, and some can check the network availability and response times – for example, integrated ping and very simple call counting. But we are seeing an increased interest in taking that functionality out of the softswitch and using the policy control environment. This is often termed bandwidth management in the core.”

    In Tispan terms, then, the wireline environment is already fairly advanced towards the NGN direction, so the omens for Tispan look positive.

    “Release 1 is a great start,” says Spraggs. “It acknowledges the different access technologies; it acknowledges the commercial models; it acknowledges the fact that there are different application types out in the world. And it is going down a path where fixed/mobile convergence is going to be possible through the use of a common IMS.”

    Tispan Challenges

    Of course, there are always challenges with new architectures, and Tispan is no exception. Spraggs points out that Release 1 is pretty heavily voice and SIP oriented and doesn’t have much to say about some basic things.

    ”We need to think in the future about how to support the more basic network services. How do we get a user to flex their bandwidth? That’s a very simple application, something that is being used pretty widely today, yet perhaps doesn’t fit brilliantly in the Tispan architecture. We need to think also about how we are going to support existing non-SIP applications.”

    These include Web-type applications, gaming applications, and new emerging application types, such as IPTV. The Digital Video Broadcasting Project (DVB) has produce IPTV specifications, but these have yet to be incorporated into the Tispan architecture to ensure that they can utilize the policy control and the capabilities of the network and authentication system.

    Nor must the past be neglected. Although the traditional, stove-pipe, dedicated application/network combinations are unsuitable for the future converged environment, they tend to have become highly optimized for their respective applications. Tispan has to avoid losing the benefits of this optimization through the imposition of general-purpose, good-enough solutions – which the temptations of scale and convenience may encourage. As a trivial example, for an old hi-fi buff, it is depressing to witness a generation of children emerging today who believe that MP3 is good-quality audio.

    However, Tispan’s challenges are not only technical.

    “Probably one of the larger challenges is for Tispan to gain support from some of the content providers. Over-the-top services are being pushed by companies such as Google (Nasdaq: GOOG) and Yahoo Inc. (Nasdaq: YHOO), and for Tispan to be truly successful, we need to be able bring those in to the architecture and deal with those types of services as well,” says Spraggs.

    This takes Tispan right into the heart of one of the hottest and most fraught debates in telecom today.

    “One of the key aspects of the Tispan architecture is enabling B2B interface through which a remote entity such as Yahoo or Google can request services from the access network to deliver content to users,” says Tazz Networks’ Rosoff. “Obviously there is a heated debate over whether or not service providers should allow prioritization of traffic for the Yahoo site over the Google site, for example, but Tispan absolutely puts the technology in place to allow that – and it allows it to be controlled either by the service provider requesting these types of services, or by the end user.”

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like