How IMS Enables Converged Services for Cable and 3G Technologies: A Survey

Abstract

The IP multimedia subsystem (IMS) is a service control overlay standardized by the 3GPP. The IMS is based on session initiation protocol (SIP) to establish, modify, and terminate the sessions. It provides a clean separation between services, signaling, and media with the potential to enable control and management of services over multiple transport technologies. In the scope of fixed-mobile convergence, this paper is dedicated to presenting a review of how cable networks can be integrated into IMS technology to achieve 3G-cable horizontal convergence. Cable networks, as one of the major fixed broadband access technologies with PacketCable architecture, are able to provide broadband internet access and VoIP in addition to cable TV. In this article, we review the evolution in PacketCable architecture to take up IMS. In this way, we consider the standardization and research activities to address this integration. We review some important challenges such as SIP protocol compatibility, defining unique user profile, required enhancement in authentication process, QoS and charging system.

1. Introduction

Fixed-mobile convergence (FMC) is an important area of research which brings in mutual advantages for both fixed broadband access providers and mobile operators. This convergence, in the initial phase, allows the users of each domain to benefit from services which are developed in the other domain. For instance, the mobile users may receive video streaming offered in cable technology on their cell phones, or the users can send and receive SMS/MMS on their fixed phones and PCs.

In the next phase, the goal is to create combined services by horizontal convergence of services provided in mobile and broadband access domains. Horizontal convergence is a concept in contrast with traditional vertical interconnection of service-specific network technologies. In vertical convergence, the integration is only at transport level and not at service level. The horizontal convergence of fixed-mobile domains creates innovative multimedia services such as unique numbering, common contact lists, and remote private video recorder (PVR) programming by cell phones. Moreover, new capabilities such as receiving the bandwidth consuming services on cell phones via broadband access or content sharing over fixed and mobile devices can be provided for the users.

To reach this goal, the need for a standardized service control overlay that provides a clean split between data transport and service level is indispensable. The role of this control overlay will be to make the services provided in a domain reachable to the users of other network technologies.

Based on session initiation protocol (SIP), IMS is the most complete IP-based service control plane that sets up an overlay on the underlying transport infrastructure and provides the possibility of end-to-end IP-based services.

All the services that are developed by service providers will be connected to IMS via a standard and SIP-based interface called IMS service control (ISC). With such architecture, the new services can be developed independently from underlying infrastructure technologies by different service operators and be connected to IMS via ISC. This reduces the time to market for emerging services and is more profitable for operators.

IMS is standardized by the 3GPP [1] for the 3G mobile technology, however, other wireless and wire-line network technologies such as Wimax, WiFi, xDSL, and broadband Cable accesses are also being integrated into IMS.

TISPAN [2] Project—Telecommunication and Internet converged Services and Protocols for Advanced Networking—in European Telecommunications Standards Institute (ETSI), in the field of Next-Generation Networks (NGN) Project [3], is considering part of the work on IMS done by 3GPP as their Service Layer Model [4].

In the USA, cable multiple systems operators (MSOs) are also involved in IMS standardization activity in 3GPP as part of the recent Cable Television Laboratory (CableLab) Project called PacketCable 2.0 [5].

PacketCable [6] is introduced and standardized by CableLab to provide IP multimedia services over HFC (Hybrid Fiber Coax) access networks. VoIP is the only major IP-based service considered in PacketCable 1.x [7, 8]. In contrast, CableLab in PacketCable 2.0 is seeking to develop such architecture to provide advanced SIP-based services in Cable networks by adopting IMS as the service control overlay. In this way, PacketCable 2.0 modifies different aspects of the PacketCable 1.x specifications.

Migrating from PacketCable 1.x toward PacketCable 2.0 with IMS is a promising strategy to achieve Cable-Wireless service convergence. In fact, the flexibility of IMS in adopting new services can answer future business needs by introducing new services for the customers of both technologies, such as: "One-Number phone service," "Unified Messaging," "Video on Demand (VoD) streaming to cell phone," "Content Sharing between Cell Phones, Personal Video Recorders (PVR), and other devices," "Remote PVR programming by cell phones," and "Buddy List spanning devices".

In this paper, we give an overview of important issues for this interconnection between Cable accesses and IMS. The organization of the paper is as follows.

In the second section, we introduce the overall IMS architecture and its basic functional elements. This section also discusses how IMS facilitates fixed-mobile convergence. In Section 3, we give a brief review of the PacketCable 1.x architecture and then present IMS-based architecture of PacketCable 2.0 in detail. Then in Sections 4–8, we review the important challenges such as SIP protocol extension, unique user profile and authentication, QoS control and resource reservation, and charging and billing system. Finally, the important points are summarized in Section 9.

2. IMS Architecture

IMS [1] was first standardized in 3GPP Release 5 to create an IP-based control plane between the underlying IP-based transport plane infrastructure and the Service Plane (see Figure 1). This overlay is set up based on SIP with new IMS functional entities in order to separate the path of IP media from signaling messages. SIP is a signaling protocol for IP telephony, multimedia conferencing, instant messaging, and presence which is standardized in IETF [9].

Figure 1

3GPP IMS architecture.

While IMS originates from the mobile market, it is access independent and various access technologies like WiFi, Wimax, DSL, and broadband cable access technology are integrated into it. In Release 5, IMS was specified based on IPv6.

In Release 6, the specification has evolved to allow a formal independence of the IMS from the access with the introduction of the IP-CAN (IP-Connectivity Access Network), as a generic access network.

IMS provides the possibility for providing end-to-end IP multimedia services, increased potential for service integration and easy adoption of different services such as instant messaging and presence and video conferencing.

Furthermore, IMS allows third-party service providers to connect their services to the IMS via standard interfaces (ISC/Sh) [1].

In Release 6 (frozen in March 2005), the required mechanisms and signaling flow for new services including IMS Messaging and Conferencing and Group Management were defined and some existing features were enhanced such as

• (i) interworking between IMS and non-IMS networks;

• (ii) lawful interception;

• (iii) option of IPv4-based IMS.

The work on IMS continued in Release 7 [1] on more enhancements such as (but not limited to) the following.

• (i) Voice call continuity (VCC) between CS and IMS [10]. With VCC, the user can switch a call between Circuit Switched and IMS domain. This is achieved by anchoring the calls which are registered for this service in a VCC server in the IMS domain.

• (ii) Support of Emergency Calls in the IMS. In Release 7, the IMS elements necessary to support IP Multimedia (IM) emergency services are defined [11]. This architecture allows emergency sessions to be prioritized over nonemergency sessions.

• (iii) IMS access via fixed broadband technologies. In this release PacketCable and TISPAN started collaborating in 3GPP specifications to integrate Cable and xDSL into IMS [12].

• (iv) IMS architecture and signaling flow for supporting conferencing [13] and messaging [14].

The work on IMS is being pursued in Release 8. In this release, the work on enhancement of IMS architecture for fixed-mobile convergence continues; and modification of corresponding specifications will be carried out with collaboration of TISPAN and PacketCable.

A general picture of IMS architecture with basic elements is presented in Figure 1. In the rest of this section, the role of each element will be explained.

2.1. IMS Functional Components

In this section, we introduce very basic IMS components which play key roles in session signaling process.

P-CSCF (Proxy-Call Session Control Function) is the entry point to IMS for User Equipment (UE). It is also the entity that should secure the link for the user to protect the privacy of its messages. P-CSCF may support SIP compression in order to reduce the load on the radio interfaces. The SIP-based Gm interface is specified between UE and P-CSCF.

UE discovers the corresponding P-CSCF after its attachment to the network and during successful activation of its PDP Context using either PDP Context Activation signaling or DHCP [15].

I-CSCF (Interrogating-CSCF) is the entry point of the operator's home domain for other operators' CSCFs. It acts as a SIP-proxy by routing SIP requests received from another network towards the S-CSCF. In addition, in the registration phase, it assigns the right S-CSCF to the UE. This assignment will be performed by interrogating the HSS to check the S-CSCF capabilities and user profile. The I-CSCF access to HSS is provided via Cx interface which is based on diameter [16]. Furthermore, the I-CSCF may hide topology, configuration, and capacity of the domain by adopting Topology Hiding Interworking Gateway (THIG) functionality.

S-CSCF (Serving-CSCF) acts as a SIP Registrar or home proxy as defined by IETF-RFC-3261[9] located in the user's home domain. It controls the session of registered users and invokes the requested services. The S-CSCF rejects communication when the media parameters are not in line with the user's service profile or with the local policy.

In addition to these call session control entities, other main IMS entities can be summarized as follows.

PDF (Policy Decision Function). This is logically a centralized entity that makes the policy decision according to the policy rules and the dynamic and static information of the network. This decision will be transferred to the access router (i.e., GGSN in 3G) which plays the role of Policy Enforcement Function (PEF). Consequently, according to the PDF decision, PEF allocates the resources for the session media. In Release 5, the PDF was enclosed in the P-CSCF. Moreover, the interface between PDF and GGSN which is called Go was based on COPS [17]. But Release 6 introduces a clear separation between the P-CSCF and the PDF function. With this extension, other non-SIP-based services will also benefit from the resource control mechanisms. Gq interface was defined between P-CSCF and PDF [1] as shown in Figure 1. Go and Gq are used for resource reservation and authorization and diameter replaced COPS in this release.

HSS- Home Subscriber Server holds location information, Initial Filter Criteria (iFC), and shared secrets of users. HSS stores the user identifications and the relations between the different public and private identifiers of users for Authentication, Authorization and Accounting (AAA).

AS (Application server) is a generic name for the entities in charge of services. An AS can be a SIP AS (the most common case), a third-Party Service AS, or a CAMEL server (CSE). CAMEL (Customized Application for Mobile Enhanced Logic) is the standard for mobile Intelligent Network [18]; this type of server can be used by the IMS through an interworking gateway (IM-SSF) for GSM legacy services such as prepaid. The AS is either localized in the user's home network or in a third-party domain.

BGCF (Breakout Gateway Control Function). BGCF determines the next hop for routing of a SIP message terminating in PSTN/CS. For PSTN/CS terminations, the BGCF selects the network in which PSTN/CS breakout is to occur. If the BGCF determines that the breakout is to occur in the same network in which the BGCF is located, then the BGCF selects a MGCF which is responsible for signaling interworking with the PSTN/CS Domain. If the break out is in another network, the BGCF will forward this session signaling to another BGCF in the selected network.

MGCF (Media Gateway Control Function) is considered a SIP endpoint. It translates ISUP/BICC messages from the PSTN side to SIP signaling in the IM CN subsystem side and Vice versa. The MGCF performs the signaling interworking to the PSTN and controls the Media Gateway (MGW) which is responsible for media format conversion.

2.2. Why IMS Facilitates Horizontal Fixed-Mobile Convergence

Traditionally, telco and mobile operators have created and deployed what is referred to as the vertical service platform architecture (see Figure 2) to handle voice/data services. However, these types of silo solutions mean allocating dedicated resources and components for each service. Each new service needs new signaling, a management system, network provisioning, and a service control protocol. All of these lead to the services which are highly dependent on the domain in which they are implemented. Moreover, the service of one domain is not accessible for other technologies except that a dedicated gateway is defined for each service domain to translate the signaling and protocol for other domains.

Figure 2

Traditional vertical service platform.

Such a model might just be tolerable while the number of services is limited. However, developing multimedia services to address miscellaneous user demands in this model is likely to be complex, unorganized, and expensive. This will be even more difficult and almost impossible for convergence of fixed and mobile services.

On the other hand, as shown in Figure 3, in the model proposed by IMS, services become independent of network infrastructure technology. IMS is another significant step (after Intelligent Network) to eliminate the cost and complexity of building a separate smokestack network for each new service. In IMS, each service will be connected to the network via standardized interfaces and become available to the users in any access technology. This is an architecture that makes it simpler and more cost effective for operators to roll out new and personalized services. IMS enables the development and deployment of converged IP infrastructure in which services are shared across multiple access technologies. IMS localizes the users in different domains and access technologies and triggers the required services for the users.

Figure 3

IMS Overlay architecture and blended multiple access.

Deploying IMS by operators of fixed and mobile means implementation of a uniform service control overlay which uses a unique IP-based signaling (SIP). In this model, CSCFs deployed in different domains are interconnected. This allows a domain access to services of other domains.

Uniform application service interface (ISC) and accessibility of services of other domains enable service convergence between different domains.

According to all of these features, IMS is considered as the dominant solution for providing fixed-mobile convergence.

Cable access providers, in addition to cable TV, today are able to provide broadband internet access and VoIP. However, by deploying IMS new service paradigms and capabilities will emerge.

In the next sections, we give a survey on research and standardization activities to deploy IMS in "Cable Technology" in order to achieve cable-wireless convergence.

3. Packetcable Architecture Overview

PacketCable is a project conducted by Cable Television Laboratories Inc. (CableLabs) and its cable operator members with the goal of enabling a wide variety of Internet-Protocol-based multimedia services over two-way hybrid fiber-coax (HFC) cable access systems [6]. PacketCable specifications have been released in four project phases: PacketCable 1.0 [7], PacketCable 1.5 [8], PacketCable Multimedia (PCMM) [19], and PacketCable 2.0 [5].

Before going through the architectural details of PacketCable, it is worth mentioning that in all of the cited developing phases, the architecture utilizes the services of three underlying networks: the HFC access network, the managed IP network, and the PSTN (see Figure 4).

Figure 4

PacketCable 1. x architecture.

PacketCable 1.0 [8] defines the subscriber environment and its interfaces to other network components including Cable Modem (CM), Multimedia Terminal Adapter (MTA), Cable Modem Termination System (CMTS), and Call Management Server (CMS).

CM connects user device to the cable access. MTA provides for the user codecs and all signaling and encapsulation functions required for media transport and call signaling on top of IP. It may be implemented as a standalone device or embedded in the Cable Modem.

The CMTS provides data connectivity and complimentary functionality to cable modems. The CMTS is located at the cable system head-end or distribution hub on the operator side of HFC access networks. The CMS provides call control and signaling related services for the MTA and CMTS. It is a trusted network element that resides on the managed IP part of the PacketCable network. The CMS consists of a Call Agent and a Gate Controller. Call Agent (CA) refers to the control component of the CMS that is responsible for providing signaling services.

To control a call, NCS (Network Call Signaling) protocol is used between CMS as the server and the MTA as the client [20]. NCS is a revision of Media Gateway Control Protocol (MGCP) [7]. The Gate Controller (GC) is a logical QoS management component within the CMS that coordinates all quality of service authorization and control.

Finally, the RKS (Record Keeper Server) collects all the charging information from CMS and CMTS to provide billing information.

PacketCable 1.5 extends the definition of two concepts introduced in the PacketCable 1.0: the Zone and the Domain [8]. A PacketCable Zone is defined as a single CMS and the endpoints it manages. A PacketCable Domain is the set of security realms managed by a single administrative and/or legal entity. The PacketCable 1.5 has introduced interconnection of different operator zones. The SIP is considered the signaling protocol between different CMSs.

In the next release, CableLab specified PCMM [19] to provide advanced IP-based services in Cable accesses. According to new requirements, the functional elements are enhanced. In this release, CableLab has defined the functional components and interfaces necessary to provide Quality-of-Service (QoS) and Resource Accounting to any multimedia-based application. The Policy-based admission control architecture defined in IETF RFC2753 [17] is adopted. CMS is divided into two separate components: an Application Manager (AM) and a Policy Server (PS). It can be said that the Application Manager is the advanced version of the CA and the Policy server is the advanced version of the Gate Controller. Policy Server acts as the Policy Decision Point (PDP) defined in RFC2753. According to the available application resources, user profiles, and network policy rules, a PDP decides to accept or deny a requested multimedia session.

The Policy Enforcement Point (PEP) function is also supposed to be inserted in CMTS. According to the authorization token issued by the PDP (Policy Server in this case), the PEP allocates the resources for the media transfer of the accepted session.

The Policy and QoS signaling protocols, event message generation for resource accounting, and security interfaces for multimedia architecture are defined in PCMM specifications [8].

3.1. Migrating Toward Packetcable-with-IMS

To reach a scalable and reliable architecture for horizontal Fixed/Mobile Convergence, CableLabs has decided to adopt IMS as the service control overlay in the PacketCable 2.0 project. In the frame of this project, CableLabs is collaborating with 3GPP in order to modify and reproduce some IMS aspects.

The target architecture in PacketCable 2.0 will have essential differences from the current architecture. With the existing architecture in PacketCable 1.x, horizontal fixed/mobile convergence is impossible. As shown in Figure 5(a), the IP services of one domain will not be accessible for other domains, since the connection of different IP domains is always via PSTN. Indeed, the cost of the call between different IP domains will be considerable because of signaling translation and media packet transformation in the borders.

Figure 5

Evolution phases of PacketCable architecture toward PacketCable-with-IMS. Signalling Architecture in PacketCable 1.xBy-passing PSTN for inter-CMSs sessionsSupporting SIP-based users by implementing P-CSCF functionalityFixed mobile convergence

To migrate to PacketCable 2.0 with IMS overlay, MSOs may choose a step by step and evolutionary strategy to reuse the existing infrastructure as much as possible [21].

Figure 5 shows these evolution phases in the PacketCable architecture. It is a reasonable strategy that (i) utilizes proven technology; (ii) generates new revenues and reduces the costs; (iii) incrementally adds applications and features.

In the first phase, as depicted in Figure 5(b), PSTN will be bypassed by adding the I-CSCF function in BGCF. Although in this phase SIP devices cannot be supported, some services that are more easily implemented on SIP, such as voice calling and click to dial, may be implemented for the conventional Cable user endpoints. These are the services which can make differentiation for MSOs from telephony provider competitors. In the second phase of migrating toward IMS, MSOs may support SIP clients by adding the P-CSCF functions and developing SIP MTAs (see Figure 5(c)). In addition, S-CSCF functions should be included in the CMS. Therefore, an IMS-like service control overlay will be set up with completion of this phase. Moreover, by expanding the customer space, MSOs are able to focus on their business goals and provide more advanced service features such as conference calling, call forwarding, and integrated voicemail and messaging.

Finally, in the last phase of architecture evolution, the fixed-mobile convergence will happen.

The IMS architecture is supposed to be implemented completely in this phase (see Figure 5(d)). Then different Application Servers of cable and 3G domains will be converged by using IMS standard interfaces. In this architecture, non-SIP-based end devices are supported as well as SIP-based devices (SIP endpoints or SIP-MTAs). Therefore, CMS is enhanced and is not replaced by S-CSCF [21]. The three main enhancements in CMS are firstly, interconnecting to HSS by deploying diameter interface; secondly, defining ISC interface to access to SIP-based ASs; and thirdly, setting up the SIP session on behalf of non-SIP-based end devices.

In [22], the details of the required architecture and signaling flow for a non-SIP-based device access to PacketCable IMS are introduced. If the user device does not support SIP (or the user does not own SIP-MTA), the description of his requested media in SDP will be negotiated by using NCS. The CMS receives this request and verifies if the user has the right to the requested media according to its profile residing in HSS. If the user is eligible for the requested service in IMS, CMS will act as the User Agent (UA) on behalf of the user and provide the required SIP messages for the next SIP Proxy.

When the user uses a SIP-based device, it sends the SIP messages to P-CSCF directly. Then P-CSCF forwards the SIP request to the proper CMS.

PacketCable 2.0, by IMS integration, specifies a revolutionary architecture at the service layer. Table 1 has compared PacketCable 1.x with PacketCable 2.0 architectures to summarize the advantages of IMS over existing service delivery system in Cable technology.

Table 1 Analysis of PacketCable 2.0 architectural evolution over PacketCable 1.x.

PacketCable 2.0 replaces NCS with SIP. NCS is a centralized signaling protocol to control nonintelligent legacy telephony end devices. With NCS, CMS monitors the end device status and issues the corresponding signaling to establish or terminate a session. The end device has no intelligence to provide the required call control signaling. In contrast, SIP proposes distributed signaling architecture with intelligent end devices. The end devices are able to provide call control signaling and react to the incoming requests. Consequently, the involvement of IMS components (including CMS) in session signaling is limited to AAA functions, session routing, and service triggering.

Hence, with elimination of responsibilities for end device control, supplementary services such as session forking/merging, caller ID presentation/restriction, and call forwarding may be implemented on board in CMS. Moreover, PacketCable 2.0 is able to support a variety of advanced end devices to satisfy end users demands for high quality experience of multimedia services.

On the other hand, Packetcable 2.0 introduces essential enhancement from the application and service point of view. Based on SIP, IMS facilitates the implementation of advanced telephony services like voice/video conferencing, messaging, push to talk, and so on.

Furthermore, the flexibility of IMS in the application level and its unified service triggering interface allow the service components to be combined and new advanced services to be defined. Therefore, with PacketCable 2.0, this service combination can happen between Cable and 3G domains and provide interesting services such as single fixed-mobile numbering, Unified Messaging, Video on Demand (VoD) streaming to cell phone, Content Sharing between Cell Phones, Personal Video Recorders (PVR) and other devices, Remote PVR programming by cell phones, and Buddy list spanning fixed/mobile devices.

Single fixed-mobile numbering means that a mobile/fixed user, using a multimode terminal, will be able to be roamed in a cable/3G technology network and have access to the local services. Figure 6 shows a scenario where a user of 3G domain is roamed in a Cable network domain.

Figure 6

(a) Registration path for a 3G User Roamed in Cable Domain. (b) Registration Signaling Flow for a 3G User Roamed in Cable Domain. (c) Originating Call establishment route/session-flow for a 3G User Roamed in Cable Domain.

The SIP signaling route and the session flow for registration are, respectively, shown in Figures 6(a) and 6(b).

In this scenario, a wireless cable modem from one side creates a 802.11 WLAN and from the other side is connected via HFC access to Cable IP domain. The 3G user is equipped with a multimode 3G/802.11 device. This device connects to the WLAN of the CM, obtains an IP address, and discovers the P-CSCF in the cable domain. After this stage, this user is ready to register in IMS level. To this end, it submits a register request.

Upon receipt of the register request, the P-CSCF examines the "home domain name" to discover the entry point to the home network (i.e., the I-CSCF) where the request should be transferred.

Then, I-CSCF interrogates HSS by submitting Cx-Query/Cx-Select-Pull. The HSS checks whether the user is allowed to register via that P-CSCF according to the user subscription and operator limitations/restrictions. Then if the user was authorized for this registration, HSS returns the S-CSCF name or capabilities corresponding to the user service profile by sending Cx-Query Resp/Cx-Select-Pull Resp to the I-CSCF.

The register request arrives at the S-CSCF. The S-CSCF demands HSS for information about the indicated user including service filter criteria (iFC). Based on the filter criteria, the S-CSCF sends register information to the service control platform and performs whatever service control procedures are appropriate. Finally, S-CSCF accepts the registration request of the user and replies with a 200-OK.

From this step on, the user is able to establish a call session. Figure 6(c) demonstrates a call session establishment route as well as session flow originated by a 3G user roamed in the cable domain.

Adoption of IMS in PacketCable is a big step toward the horizontal convergence of Cable access technologies and wireless mobile systems. However, to achieve this, there are important concerns in signaling compatibility, resource reservation, and security. In the following sections, these issues and corresponding solutions will be reviewed.

4. Differences in SIP Protocols

SIP (Session Initiation Protocol) is introduced by IETF in RFC 3261 [9]. It is a signaling protocol to establish, modify, and terminate the IP-based multimedia sessions. SIP messages which are called SIP methods consist of four main parts: User Identity, Method Type, Header Fields, and SIP body. A SIP client will be identified with a type of Uniform Resource Identifier, called SIP URI. It has a similar format to email addresses containing a user name and a host name. The method type shows the name of the SIP messages. The SIP methods are divided into two main categories of Requests and Responses. SIP header fields provide the message route information. RFC 3261 defines seven mandatory fields: To, From, Contact, CSeq, Call-ID, Max forwards, and Via. Finally, in the message body, there are the media parameters such as media type (video, voice, etc.), codec type and bit-rate that are described by employing the Session Description Protocol (SDP) [23].

There are differences between the standard SIP defined by IETF and the SIP recommended by the 3GPP. The 3GPP specifies extensions for SIP header fields and SIP messages.

In the case of SIP header fields, these extensions include.

• (i) supplementary header fields [24] which are defined in IETF as optional such as Path header and service-route header. Path header is completed during registration phase to identify the route between the UE and its S-CSCF. This header is inserted in the SIP register request and its corresponding 200-OK answer. On the other hand, an S-CSCF may use a Service-Route header field to inform UAs of the route that will end to that S-CSCF. The Service-Route header field is included by an S-CSCF in the response to a register request. Consequently, a registering UE learns of the route that may be used to request services from the system it just registered with.

• (ii) 3GPP specific header fields such as the subset of P-headers [25] (P-Access-Network-Info, P-media-authorization, P-Called-Party-ID, P-Visited-Network-ID, etc.)

Moreover, in the case of SIP messages, update which is a message defined as an extension to SIP by IETF for modifying a session characteristic [26] is mandatory in IMS to be used for starting the resource reservation process. In addition, implementation of Prack is mandatory in IMS. Prack is an SIP Provisional Response used as an acknowledgment.

These differences may not appear critical in a closed environment but may raise some concerns regarding interoperability with other domains SIP platform.

Fortunately, most of these extensions are also considered in PacketCable architecture. Indeed, update and Prack are both considered in PacketCable. Furthermore, regarding header extension, PacketCable has also defined 23 mandatory headers that CMS must support [20]. These extensions enable PacketCable systems to provide a robust multimedia service platform supporting basic telephony and custom calling features. Nevertheless, neither path header nor P-headers are supported in PacketCable 1.x architecture.

This incompatibility does not present a problem when a 3G-domain originating-session terminates in a PacketCable domain. This is because 3GPP in Release 6 has defined a new procedure allowing an IMS user to establish a session ending to a SIP user in a pure IETF SIP network [27]. However, those procedures are only for interworking with an external non-IMS SIP network and do not allow a non-IMS user to register and access an IMS network. This is the main reason that PacketCable 2.0 considers all of the mandatory headers defined by IMS 3GPP.

5. Unique User Profile and Enhanced Authentication

In converged networks, a key issue is how to define a unique subscriber profile to be authenticated and authorized through different access technologies for the shared services.

Furthermore, the user profile should be more complete and the access network information should be added. In 3G networks, the Cell ID (P-Access-Network-Info in SIP header) clarifies the current serving cell in the registration phase [27]. In fact, the end device is capable of obtaining this information and putting it in their registration messages directly (P-header in SIP register message). For Cable access, two important issues in location information provision must be considered.

Firstly, the legacy devices in Cable access networks are fixed devices. Hence, they are not designed to be capable of adding their location information to their signaling messages. To cope with this concern, in [22] we have proposed that new versions of MTAs should be able to obtain the location information and add it to signaling messages in the registration phase [22].

The second issue is defining which kinds of information can identify the attachment point of the user in Cable access. According to the fact that CMTS is the first attaching point in the operator domain, we consider that its MAC or IP address is the essential information for location identification. In addition, Cable Modem MAC/IP can be used as supplementary location information.

In addition to the required improvement in the user profile, there is necessity for reliable and secure authentication system. In the first releases of IMS (before Release 7), the only authentication and key agreement (AKA) system which was specified by the 3GPP was IMS-AKA. This is an authentication system based on USIM/ISIM approach. The UMTS Subscriber Identity Module (USIM) and IMS Subscriber Identity Module (ISIM) are found on the Universal Integrated Circuit Card (UICC) of 3G devices [28]. USIM-based IMS-AKA and ISIM-based IMS-AKA authentication require the phone to be equipped with the operator UICC card (i.e., a 3G SIM card) with USIM or ISIM capability. In the absence of UICC (because of hardware limitation), ISIM can be provided as a software module on end devices (PCs).

However, PacketCable 2.0 needs to support devices which do not contain or have access to any kind of ISIM. This limitation also exists for any other fixed access technologies. Therefore, to cope with this issue and extending IMS services for fixed legacy devices, SIP Digest [5] authentication approach is included in IMS [15].

5.1. SIP Digest Authentication Deployment in IMS

SIP Digest is a challenge/response approach defined in SIP for authentication of messages and access to services. In this approach, unlike that of IMS-AKA, the challenges are not precomputed (in UICC) but are computed in real time by S-CSCF. To have the minimum impact on the existing IMS architecture, PacketCable 2.0 adopts this approach by maintaining the existing headers of SIP messages (i.e., Authentication-Info header) used in the register phase.

Figure 7 shows the SIP Digest flow messages.

Figure 7

Authentication process based on SIP digest.

Adding support for SIP Digest has some impacts on some IMS elements as explained in the following.

• (a) S-CSCF should be able to compute the challenges/response required for authentication of the user. In addition, S-CSCF has to include an Authenticate-Info header in 2xx responses (e.g., 200 OK) following a successful authentication of UEs.

• (b) HSS: Cx interface should be enhanced. Indeed, digest authentication adds new parameters to be transmitted via Cx to S-CSCF. These parameters allow S-CSCF to compute the required challenge responses in the registration phase. In addition, HSS itself should store all the required parameters for challenge computation in each user profile.

6. Secure Attachment and Traffic Differentiation

Convergence of different access technologies will not be achieved unless they provide a secure and reliable connection for the clients. The privacy of users should be protected during the time of signaling exchange. On the UMTS access network, at the time of attachment, a primary PDP (Packet Data Protocol) [29] context is created for the signaling flows. PDP is the resource reservation protocol used in UTMS Accesses. By using PDP, on the path between a Mobile User Agent and GGSN through SGSN, a certain amount of resources will be allocated to the authenticated user to allow him to send and receive session signaling messages in a secure manner that protect the privacy of the exchanged information. In 3GPP Release 5 the primary PDP was also supposed to be used for media transfer. This is possible because in the access network (From UE to GGSN), before signaling messages arrive in the IMS domain (P-CSCF), they pass through the same route with media packets.

However, media QoS and security requirements are different from those of signaling messages; therefore it is not efficient to use the same PDP context for both signaling and media. Hence, in Release 6 of 3GPP, the notion of Secondary PDP Context was also considered [29]. With this possibility, according to the session QoS parameters that are negotiated between two call parties, another PDP context will be created to exchange the session media.

For the IP-based access technologies other than UTRAN (UMTS Radio Access Network), there is no PDP context. Consequently, there is a need for an IPSec [30] tunnel between the UE and the first reliable router in the access network (CMTS in the case of Cable Technology) to exchange signaling and media packets, including RTP, TCP/IP, Secure RTP, and SIP (see Figure 8). However, using the same tunnel, the IP address and the port number are inefficient without being able to distinguish flows with different QoS requirements.

Figure 8

Resource reservation for media and signaling.

On the other hand, it is definitely inefficient establishing a dedicated tunnel for each media flow since it involves a large amount of signaling exchange for each flow and implies a heavy process load on the network resources (routers and switches).

To achieve a tradeoff, we have proposed a solution based on two tunnel categories: one for conveying signaling flow and the other for media flow [22].

In an IPSec tunnel, all the traffic flows will have the same header (Source and Destination IP address, port no.) and then the five-tuple criteria will no longer be useful for traffic differentiation.

Our proposed solution is that different media flows in the same IPSec tunnel are distinguished by DiffServ Code Point (DSCP) marks.

The User end devices should support a DSCP [31] value to mark the media packets according to their authorized QoS class. Indeed, this function may be added to MTA on behalf of legacy devices in Cable access which do not support any resource reservation protocol like Diffserv.

IMS adopts the application-level policy-based resource reservation model defined by IETF in [17] for allocation of resource to traffic flows. This model is also considered in PacketCable 2.0 for resource reservation. Figure 9 displays the adopted QoS system in PacketCable 2.0.

Figure 9

Resource reservation model.

The PacketCable Application Manager (AM) is primarily responsible for determining the QoS resources needed for the session, based on the received session descriptors from P-CSCF, and managing the QoS resources allocated for a session.

Determining the QoS resources for a session involves interpreting the session information and calculating how much bandwidth is required, determining the correct PacketCable Multimedia traffic profile, and populating the traffic classifiers (DSCP Marks). This also involves determining the number of flows necessary for the session (e.g., voice only versus voice and video session) and managing the association of the flows to the session.

The Policy Server (PS) primarily acts as an intermediary between the Application Manager(s) and CMTS(s). It applies network policies to the Application Manager requests and proxies messages between the Application Manager and the CMTS. The AM resides in CMS and the PS may be deployed in CMS too. In the case that the PS is implemented as a stand alone component, diameter [16] is used to provide a secure interface between the AM and the PS. CMTS is the policy enforcement point. It allocates the authorized resources to the traffic flow according to the tokens assigned by Policy Server. The interface between PS and CMTS is based on COPS [19].

7. Charging and Billing System

Different operators need to exchange billing information for different reasons [32].

• (i) Service content (the user uses the service content created by home or visited domain);

• (ii) Roaming;

• (iii) Interconnection (the callee domain charges the caller domain);

• (iv) Conveyance (some part of the backbone used to convey the media/signaling is provided by another operator).

For these features, the operators need to define enhanced business models which can apply all types of charging (including volume, time, session, content, etc.) to create attractive plans for users and achieve interesting agreements with third parties that provide services contents.

IMS has set an advanced charging approach which achieves matching of traffic and service information [32, 33]. The IMS charging correlation information is encoded in the SIP P-Charging-Vector header. This header contains the following parameters: IMS Charging ID (ICID), access network charging identifier, and Inter Operator Identifier (IOI).

Two charging approaches (corresponding to real time and non-real time) have been specified in the IMS [32]: offline charging based on charging information and online charging based on charging events messages. In the offline approach, transport and IMS elements (SGSN, GGSN, P, I and S-CSCF) report their charging information to Charging Data Function (CDF) and then CDF creates a call detail record (CDR) and sends it via an interface to the billing domain [33].

Online charging is much harder to implement. The event information of bearer, IMS, and service layers should be sent to a correlation function. The correlation function has access to user credit and according to this information is capable of deciding if there is enough credit for the session during the call. Online charging is essential for services like prepaid.

As Figure 10 shows, PacketCable 2.0 also considers a similar approach [34]. CDF will be deployed to collect the charging information from IMS elements. Moreover, in the underlying network, event messages are sent to the Record Keeping Server (RKS) as they are generated (online) or alternatively, once generated, Event Messages may be stored on the CMS/CMTS/MGC and sent to the RKS in a single file (offline).

Figure 10

PacketCable 2. 0 charging and billing system.

Using the unique billing correlation ID (BCID) assigned to a given call, the RKS and CDF collect all the individual event messages for a call and send them to the Billing System. The Billing System assembles them into a single call detail record (CDR).

The charging information is included in the P-Charging Vector header. For the non-IMS devices mentioned in Section 4, it is the role of CMS to create the P-headers to enable mapping of charging information created in the PacketCable and 3G domains. For offline charging, for each session (unified by its Call-ID), RKS should be able to provide all charging information for service content, roaming, conveyance, and interoperation related to the P-Charging-Vector.

This unified charging architecture in 3G and broadband Cable facilitates users of one domain roaming in another. Moreover, by a federation of operators of fixed and mobile, the users may receive one unique billing for both their fixed and mobile access.

8. Related Work

The work on getting IMS integrated in broadband fixed technologies is also being pursued by a standardization body in ETSI, called Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) [2].

TISPAN is the ETSI core competence centre for all aspects of standardization for present and future converged networks including service aspects, architectural aspects, protocol aspects, QoS studies, security related studies, and mobility aspects within fixed networks, using existing and emerging technologies. TISPAN activity is within the scope of the ITU Next-Generation Network (NGN) Project. The first release of TISPAN architecture has been published and the work on its second release is being followed [4]. The specified architecture is structured according to a service layer and an IP-based transport layer.

The service layer includes four major subsystems as follows.

• (i) The core IP Multimedia Subsystem (IMS).

• (ii) The PSTN/ISDN Emulation Subsystem (PES).

• (iii) Other multimedia subsystems (e.g., IPTV Dedicated Subsystem) and applications.

• (iv) Common components (i.e., used by several subsystems) such as those required for accessing applications, charging functions, user profile management, security management, and routing data bases (e.g., ENUM).

The "Core IMS" [4] is a subset of the 3GPP IMS which is restricted to the session control functionalities. Application Servers (ASs) and transport/media related functions such as the Multimedia Resource Function Processors (MRFP) and the IMS Media Gateway function (IMS-MGW) are considered to be outside the "Core IMS".

The transport layer provides IP-connectivity to user equipment under the control of the network attachment subsystem (NASS) and the resource and admission control subsystem (RACS). These subsystems hide the transport technology used in access and core networks below the IP layer.

NASS provides the required functionalities for IP address provisioning, IP layer authentication and authorization of network access according to user profile and so on.

RACS is the TISPAN NGN subsystem responsible for the implementation of procedures and mechanisms handling policy-based resource reservation and admission control for both unicast and multicast traffic in access networks and core networks. TISPAN architecture is proposed for broadband access technologies like xDSL.

In addition to the standardization activities by PacketCable and TISPAN, there are also other research activities to integrate IMS in WLAN and WiMax Technologies [35–38].

In [39], 3GPP has proposed an architecture to allow WLAN access to 3G services. This is a general architecture to provide access to all services in the 3G domain including IMS services. With the proposed architecture, the roaming of 3G users in the WLAN domain is feasible. However, in this architecture convergence is obtained with a Master/Slave strategy. Indeed, in this 3GPP approach, it is 3G which controls the access to services and defines the corresponding policies.

In [35], a strategy for step by step deployment of IMS in WiFi technology is presented. The main idea of this work is to allow WiFi operators to deploy their own IMS services in their realm and provide an equivalent 3G/WLAN convergence strategy.

Finally, we should mention that there is also some research on Wimax integration in IMS. In [37], different levels of service integration between 3G and Wimax based on IMS are analysed.

9. Summary

This paper reviewed the evolutionary migration from PacketCable 1.x architecture toward Packetcable 2.0 with IMS to reach horizontal Fixed/Mobile Convergence. Some development of existing elements and functions in PacketCable and IMS required for that interconnection is discussed. New combined services and client capabilities which answer the future business requirements of cable technology operators were introduced. Moreover, four important challenges for this convergence were analyzed in particular: (i) difference in implemented SIP protocol in PacketCable and the 3GPP IMS, indicating the necessary SIP header extensions in PacketCable, (ii) possibility of defining a unique user identity and enhanced authentication process for users with no access to USIM, (iii) resource reservation and QoS control, and (iv) charging and billing issues. In all of these issues, the support of legacy devices is considered as well as IMS user agents.