Session Control Manager Overview

This chapter contains general overview information about the Session Control Manager (SCM) including:

Product Description

The Session Control Manager (SCM) delivers and controls a robust multimedia environment today, while preparing for the networks of tomorrow. SCM provides an easy on-ramp to deploying Session Initiation Protocol (SIP)-based services and a future-proof migration path to the IP Multimedia Subsystem/Multimedia Domain (IMS/MMD) architectures.

The SCM performs the following functions:
  • SIP routing
  • Translation and mobility
  • Admission control
  • Authentication
  • Registration
  • Emergency Registration
  • Packet network access based on pre-established policies and procedures
  • Localized policy selection and enforcement
  • Multimedia Call Detail Records (CDRs)
  • Per-subscriber service facilitation
  • SIP Application-level Gateway (ALG)
  • Media relay
  • Mitigate SIP Denial of Service (DoS)
  • Prevent registration hijacking
  • Prevent theft of service
The SCM consists of multiple IMS components that can be integrated into a single ASR 5000 platform or distributed as standalone network elements:
  • IETF-compliant SIP Proxy/Registrar
  • 3GPP/3GPP2-compliant Proxy Call/Session Control Function (P-CSCF)
  • 3GPP/3GPP2-compliant Serving Call/Session Control Function (S-CSCF) 3GPP/3GPP2-compliant Interrogating Call/Session Control Function (I-CSCF) 3GPP/3GPP2 Breakout Gateway Control Function (BGCF)
  • 3GPP/3GPP2-compliant Emergency Call/Session Control Function (E-CSCF)
  • 3GPP/IETF-compliant Access Border Gateway (A-BG)

As standards-based network elements, SCM components can be integrated with each other or with third-party IMS components.

IMS Architecture

IP Multimedia Subsystem (IMS) specifies a standard architecture for providing combined IP services (voice, data, multimedia) over the existing public switched domain. IMS is an integral part of the 3GPP, 3GPP2, ETSI, and TISPAN network model standards that define circuit switched, packet switched, and IP multimedia domain environments. IMS also supports multiple access methods such as CDMA2000, DOCSIS, EPS, Ethernet, Fiber, GPRS, WCDMA, WLAN, XDSL, and wireless broadband access.

The call signaling protocol used in IMS is the Session Initiation Protocol (SIP). The primary component in the network for resolving and forwarding SIP messages is the Call/Session Control Function (CSCF). The CSCF provides the control and routing function for all IP sessions accessing the network. CSCFs are located in the control plane or layer of the Service Delivery Network as shown in the figure below.

When the SCM acts as an Access Border Gateway (A-BG), it uses the RFC3261/P-CSCF to provide a SIP/IMS control plane access border, as well as a bearer access border control function. Therefore, the A-BG provides all session border control functions for all SIP UEs attempting to access the mobile network from a network outside of the operator's control and operations.


Figure 1. IMS Service Delivery Networks Components
Collectively, CSCFs are responsible for managing an IMS session, including generating Call Detail Records (CDRs). Four functional behaviors are defined for the CSCF:
  • Proxy
  • Interrogating
  • Serving
  • Emergency

The following figure shows the general interaction between the CSCF components and the supporting servers.


Figure 2. IMS CSCF Components

In addition, the SCM may act as an Access Border Gateway (A-BG).

The following figure shows the general interaction between the A-BG and the supporting servers.


Figure 3. Access Border Gateway

Proxy-CSCF

The primary point of entry into the IMS network is the Proxy-CSCF (P-CSCF). The P-CSCF is responsible for:

  • providing message manipulation to allow for localized services (traffic/weather reports, news, directory services, etc.)
  • initiating the breakout of emergency service calls
  • Topology Hiding Inter-network Gateway (THIG)
  • Quality of Service (QoS) authorization
  • number conversions for local dialing plans
  • terminating IPSec tunnels
  • Transport Layer Security (TLS)
  • interworking
  • Signaling Compression/Decompression (SIGCOMP)
  • charging

The P-CSCF is the handset’s first point of entry into the IMS and is also the outbound proxy for SIP. Once the P-CSCF has completed all of the functions for which it is responsible, the call setup is handed off to the Interrogating-CSCF (I-CSCF).

Interrogating-CSCF

The I-CSCF performs mostly as a load distribution device. The I-CSCF queries the Home Subscriber Server (HSS) to identify the appropriate Serving-CSCF (S-CSCF) to which the call is sent. Since the HSS maintains user profile information (much like the Home Location Register (HLR) in the Public Land Mobile Network (PLMN)), the I-CSCF can identify the proper S-CSCF for the call. The I-CSCF may also query a AAA server to determine subscriber profile information using DIAMETER.

IMPORTANT:

The I-CSCF is incorporated into the S-CSCF.

I-CSCF Interfaces

The following diagram shows the interfaces/reference points associated with the I-CSCF:

Serving-CSCF

The Serving-CSCF (S-CSCF) is the access point to services provided to the subscriber. Service examples include session control services, such as call features.

Other services include:

  • VPN
  • Centralized speed dialing lists
  • Charging
The S-CSCF also interacts with the HSS for:
  • User authentication
  • Subscriber profile download and provisioning filter rules for services
  • Network authentication key
  • Emergency registration
  • Location management
  • User data handling

A Breakout Gateway Control Function is integrated into the SCM’s S-CSCF to support PSTN calls.

Telephony Application Server (TAS) Basic Supported

The following describe the local basic call features implemented on the S-CSCF:
  • Abbreviated Dialing (AD)
  • Call Forward Busy Line (CFBL)
  • Call Forward No Answer (CFNA)
  • Call Forward Not Registered (CFNR)
  • Call Forward Unconditional (CFU)
  • Call Transfer
  • Call Waiting
  • Caller ID Display (CID)
  • Caller ID Display Blocked (CIDB)
  • Feature Code Activation/De-activation
  • Follow Me/Find Me
  • Locally Allowed Abbreviated Dialing
  • Outbound Call Restrictions/Dialing Permissions
  • Short Code Dialing

Integrated S/I-CSCF

The following Interrogating-CSCF features are supported for the integrated S/I-CSCF:
  • Assign an S-CSCF to a User Performing SIP Registration - On a UE registration, the I-CSCF carries out a first step authorization and S-CSCF discovery. For this, the I-CSCF sends a Cx User-Authentication-Request (UAR) to the HSS by transferring the Public and Private User Identities and the visited network identifier (all extracted from the UE REGISTER message). The HSS answers with a Cx User-Authentication-Answer (UAA). The UAA includes the URI of the S-CSCF already allocated to the user. If there is no previously allocated S-CSCF, the HSS returns a set of S-CSCF capabilities that the I-CSCF uses to select the S-CSCF.
  • E.164 Address Translation - Translates the E.164 address contained in all Request-URIs having the SIP URI with user=phone parameter format into the Tel: URI format before performing the HSS Location Query. In the event the user does not exist, and if configured by operator policy, the I-CSCF may invoke the portion of the transit functionality that translates the E.164 address contained in the Request-URI of the Tel: URI format to a routable SIP URI.
  • Obtain the S-CSCF Address from the HSS - When the I-CSCF receives a SIP request from another network, it has to route the request to the called party. For this it obtains the S-CSCF address associated with the called party from the HSS by querying with a Cx Location-Information-Request (LIR) message. The Public-Identity AVP in the LIR is the Request-URI of the SIP request. The Location-Information-Answer (LIA) message contains the S-CSCF address in the Server-Name AVP. The request is then routed to the S-CSCF.
  • Route a SIP Request or Forward Response from Another Network - When the I-CSCF receives a request from another network, it obtains the address of the S-CSCF from the HSS using the procedure detailed above and routes the request to the S-CSCF. Responses are also routed to the S-CSCF.
  • Perform Transit Routing Functions - The I-CSCF may need to perform transit routing if, based on the HSS query, the destination of the session is not within the IMS. The IMS Transit Functions perform an analysis of the destination address and determine where to route the session. The session may be routed directly to an MGCF, BGCF, or to another IMS entity in the same network, to another IMS network, or to a CS domain or PSTN.
  • Generate CDRs - The I-CSCF generates CDRs for its interactions. Upon completing a Cx query, the I-CSCF sends an Accounting Request with the Accounting-Record-Type set to EVENT. The CDF acknowledges the data received and creates an I-CSCF CDR.

Emergency-CSCF

The Emergency-CSCF (E-CSCF) is a network element in IMS which is responsible for routing an emergency call to a Public Safety Answering Point (PSAP).

To identify the next hop PSAP, E-CSCF interacts with the Location Retrieval Function (LRF). LRF provides the necessary routing information so that E-CSCF can route the request to the appropriate PSAP.

E-CSCF Interfaces

The following diagram shows the interfaces/reference points associated with the E-CSCF:

A-BG

The A-BG is responsible for:

  • Border Control for both Signaling and Bearer
  • CALEA Support SIP and media taps
  • Call Admission and Access Control Access Control based on IP, URL, SIP Identity, and Session Limits
  • Intelligent Routing Least Cost, Congestion Based, Call Type, Domain Based As a SIP ALG, supports signaling and media routing with overlapping address ranges
  • SIP Application-level Gateway (SIP-ALG) SIP NAT Traversal SIP NAT (IPv4 <–> IPv6 translation) Media Relay (Header Manipulation): RTP, MSRP
  • SIP Security Prevent Theft of Service Prevent CSCF bypass Robust authentication procedures SIP message checking Prevent Registration Hijacking Authenticate Re-Register (S-CSCF) Early IMS Security: DoS attack prevention, impersonating a server UA authentication (prevent server impersonation) AKA authentication mechanism (further protection) Prevent Message Tampering (IPSec) Prevent Early Session Tear Down Early IMS Security prevents a different user releasing existing session Mitigate SIP Denial of Service (DoS) P-CSCF DoS Attack Prevention Blocking of user/IP address after repeated authentication and bad request failure in Register/INVITE Dropping of Register containing Contact header pointing to CSCF service ip:port Limited number of contacts on which Forking is allowed Dropping of Requests coming from source address other than the Register request's source address
  • Topology Hiding Inter-network Gateway (THIG)
  • Transport Layer Security (TLS)

Technical Specifications

The following table provides product specifications for the SCM.


Table 1. Session Control Manager Technical Specifications
. Description
Service Instances

Dual-mode proxy: simultaneously supports IETF & 3GPP/3GPP2 Proxies

SIP
  • IETF SIP Proxy/Registrar
  • 3GPP/3GPP2 Proxy Call Session Control Function (P-CSCF)
  • Stateful session and subscriber aware control
  • Signaling Compression/Decompression (SIGCOMP)
  • Auto discovery, subscriber privacy, network security, call fraud prevention, thwarting network overload conditions
SIP Message Handling

Forking, error handling and discard, header stripping and insertion, multiple public user identities

Logical Interfaces
  • IETF: SIP Proxy/Registrar
  • 3GPP: Mw, Gm, Rx, Rf, Cx, Sh, Dx, MI
  • 3GPP2: Mw, Gm, Tx, Rf, Cx, Sh, Dx, MI


Platform Requirements

The SCM service runs on a Cisco® ASR 5x00 chassis running StarOS. The chassis can be configured with a variety of components to meet specific network deployment requirements. For additional information, refer to the Installation Guide for the chassis and/or contact your Cisco account representative.

Licenses

The SCM is a licensed Cisco product. Separate session and feature licenses may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.

Network Deployments and Interfaces

SCM in a CDMA2000 Data Network Deployment

Integrated CSCF / A-BG / HA

The SCM is designed to function within a CDMA2000 PDSN network. By combining the SCM with a carrier-class Home Agent, a number of advantages emerge such as increased performance, distributed architecture, and high availability. As shown in the figure below, the SCM supports a number of interfaces used to communicate with other components in an IMS environment and supports the interface used to bridge the CDMA network.


Figure 4. CDMA2000 CSCF/A-BG/HA SCM Deployment Example

Logical Network Interfaces (Reference Points)

Interfaces, used to support IMS in a CDMA network, can be defined within two categories: SIP and DIAMETER. The SCM incorporates standards-based interfaces for both SIP and DIAMETER network architectures.

SIP Interfaces

The following table provides descriptions of SIP interfaces supported by the SCM in a CDMA2000 network deployment.


Table 2. SIP Interfaces in a CDMA Network
Interface Description
Gm The reference point between the P-CSCF and the User Equipment (UE).The Gm interface provides SIP signaling between the PDSN and the P-CSCF.
MI

The reference point between the E-CSCF and Location Retrieval Function (LRF).

The MI interface is used for routing an emergency call to a Public Safety Answering Point (PSAP). The E-CSCF interacts with the Location Retrieval Function (LRF) to identify the next hop PSAP.

Mw The reference point between the P/S-CSCF and other CSCFs.The Mw interface provides SIP signaling between two CSCFs.


DIAMETER Interfaces

The following table provides descriptions of DIAMETER interfaces supported by the SCM in a CDMA2000 network deployment.


Table 3. DIAMETER Interfaces in a CDMA Network
Interface Description
Cx

The reference point between the S/I-CSCF and the Home Subscriber Server (HSS).

The Cx interface is used to authenticate subscribers, provides server assignments, push user profile information from the HSS to the S-CSCF, and, when necessary, transmit a network initiated de-registration.

Dx

The reference point between the S/I-CSCF and Subscriber Location Function (SLF).

The Dx interface is used to proxy queries to a subscriber data server (such as an HSS) in which subscription data for a user can be found. The SLF receives a query for the subscriber data server, looks up the address of appropriate subscriber data server, and proxies the query to the appropriate subscriber data server.

Rf

The reference point between the P-CSCF and the Offline Charging System (OFCS).

The Rf interface is used to transfer charging information that will not affect, in real-time, the service being rendered.

For more information, refer to the 3GPP2 specification X.S0013-007-A v1.0.

Sh

The reference point between the S-CSCF and Home Subscriber Server (HSS).

The Sh interface is used for retrieval and update of call feature data parameters.

Tx

The reference point between the P-CSCF/A-BG and the Charging Rule Function (CRF)/Policy Decision Point (PDP) (PCRF) used for Service Based Bearer Control (SBBC). It identifies any P-CSCF/A-BG restrictions to be applied to the identified packet flows.



SCM in a GSM/UMTS Data Network Deployment

CSCF / A-BG / GGSN Deployment

The SCM is designed to function within a UMTS GGSN network. As shown in following figure, the SCM supports a number of interfaces used to communicate with other components in an IMS environment and supports the interface used to bridge the GGSN network.


Figure 5. GSM/UMTS CSCF/A-BG/GGSN SCM Deployment Example

Logical Network Interfaces (Reference Points)

Interfaces, used to support IMS in a UMTS network, can be defined within two categories: SIP and DIAMETER. The SCM incorporates standards-based interfaces for both SIP and DIAMETER network architectures.

SIP Interfaces

The following table provides descriptions of SIP interfaces supported by the SCM in a GSM/UMTS network deployment.


Table 4. SIP Interfaces in a GSM/UMTS Network
Interface Description
Gm

The reference point between the P-CSCF and the User Equipment (UE).

The Gm interface provides SIP signaling between the GGSN and the P-CSCF.

MI

The reference point between the E-CSCF and Location Retrieval Function (LRF).

The MI interface is used for routing an emergency call to a Public Safety Answering Point (PSAP). The E-CSCF interacts with the Location Retrieval Function (LRF) to identify the next hop PSAP.

Mw

The reference point between the P/S-CSCF and other CSCFs.

The Mw interface provides SIP signaling between two CSCFs.



DIAMETER Interfaces

The following table provides descriptions of DIAMETER interfaces supported by the SCM in a GSM/UMTS network deployment.


Table 5. DIAMETER Interfaces in a GSM/UMTS Network
Interface Description
Cx

The reference point between the S/I-CSCF and the Home Subscriber Server (HSS).

The Cx interface is used to authenticate subscribers, provides server assignments, push user profile information from the HSS to the S-CSCF, and, when necessary, transmit a network initiated de-registration.

Dx

The reference point between the S/I-CSCF and Subscriber Location Function (SLF).

The Dx interface is used to proxy queries to a subscriber data server (such as an HSS) in which subscription data for a user can be found. The SLF receives a query for the subscriber data server, looks up the address of appropriate subscriber data server, and proxies the query to the appropriate subscriber data server.

Rf

The reference point between the P-CSCF and the Offline Charging System (OFCS).

The Rf interface is used to transfer charging information that will not affect, in real-time, the service being rendered.

For more information, refer to the 3GPP2 specification X.S0013-007-A v1.0.

Rx

The reference point between the P-CSCF/A-BG and the Charging Rule Function (CRF)/Policy Decision Point (PDP) (PCRF).

The Rx interface (3GPP 29.211) is used to exchange Flow Based Charging (FBC) control information between the PCRF and the P-CSCF/A-BG. The CRF uses the information to make FBC decisions that are then exchanged with the Traffic Plane Function (TPF).

This interface is used in a 3GPP2 Release 7 implementation.

Sh

The reference point between the S-CSCF and Home Subscriber Server (HSS).

The Sh interface is used for retrieval and update of call feature data parameters.



Features and Functionality - Base Software

The following is a list containing a variety of features found in the SCM and the benefits they provide.

Bulk Statistics Support

The system's support for bulk statistics allows operators to choose to view not only statistics that are of importance to them, but also to configure the format in which it is presented. This simplifies the post-processing of statistical data since it can be formatted to be parsed by external, back-end processors.

When used in conjunction with the Web Element Manager, the data can be parsed, archived, and graphed.

The system can be configured to collect bulk statistics (performance data) and send them to a collection server (called a receiver). Bulk statistics are statistics that are collected in a group. The individual statistics are grouped by schema. Following is a list of supported schemas for SCM:
  • Card: Provides card-level statistics
  • Context: Provides context-level statistics
  • CSCF: Provides CSCF service statistics
  • CSCFINTF: Provides CSCF interface statistics
  • Diameter-acct: Provides Diameter Accounting statistics
  • Diameter-auth: Provides Diameter Authentication statistics
  • Map: Provides Map service statistics
  • Nat-realm: Provides NAT realm statistics
  • Port: Provides port-level statistics
  • System: Provides system-level statistics

The system supports the configuration of up to 4 sets (primary/secondary) of receivers. Each set can be configured with to collect specific sets of statistics from the various schemas. Statistics can be pulled manually from the system or sent at configured intervals. The bulk statistics are stored on the receiver(s) in files.

The format of the bulk statistic data files can be configured by the user. Users can specify the format of the file name, file headers, and/or footers to include information such as the date, system host name, system uptime, the IP address of the system generating the statistics (available for only for headers and footers), and/or the time that the file was generated.

When the Web Element Manager is used as the receiver, it is capable of further processing the statistics data through XML parsing, archiving, and graphing.

The Bulk Statistics Server component of the Web Element Manager parses collected statistics and stores the information in the PostgreSQL database. If XML file generation and transfer is required, this element generates the XML output and can send it to a Northbound NMS or an alternate bulk statistics server for further processing.

Additionally, if archiving of the collected statistics is desired, the Bulk Statistics server writes the files to an alternative directory on the server. A specific directory can be configured by the administrative user or the default directory can be used. Regardless, the directory can be on a local file system or on an NFS-mounted file system on the Web Element Manager server.

IMPORTANT:

For more information on bulk statistic configuration, refer to the Configuring and Maintaining Bulk Statistics chapter in the System Administration Guide.

Call Abort Handling

Call abort handling provides resource cleanup in error scenarios and makes sure resources that are not being used can be used for new calls. This feature is managed gracefully for a P-CSCF failure and CLI-initiated subscriber and session clean up.

Call Forking

Call forking allows subscribers to receive calls wherever they are by enabling multi-location UE registration.

Call Types Supported

In the IMS architecture, telephony features are normally provided by an external application server. Providing these features with the S-CSCF:

  • Reduces the need for an additional SIP AS
  • Simplifies the network architecture
  • Improves latency for call setup and feature invocation

The following call types are supported:

  • Directory service, toll-free, long distance, international, and operator-assisted calls - are supported through translation lists.
  • Emergency calls - are managed through the addition of an Emergency Call/Session Control Function (E-CSCF) that routes emergency calls to a Public Safety Answering Point (PSAP).
  • Mobile-to-Mobile SIP calls - supports SIP-based VoIP calls between mobile data users.
  • Public Switched Telephone Network (PSTN) calls - can be routed through a 3GPP/2 compliant BGCF located in the S-CSCF.

Congestion Control

The congestion control feature allows you to set policies and thresholds and specify how the system reacts when faced with a heavy load condition.

Congestion control monitors the system for conditions that could potentially degrade performance when the system is under heavy load. Typically, these conditions are temporary (for example, high CPU or memory utilization) and are quickly resolved. However, continuous or large numbers of these conditions within a specific time interval may have an impact the system’s ability to service subscriber sessions. Congestion control helps identify such conditions and invokes policies for addressing the situation.

Congestion control operation is based on configuring the following:

  • Congestion Condition Thresholds: Thresholds dictate the conditions for which congestion control is enabled and establishes limits for defining the state of the system (congested or clear). These thresholds function in a way similar to operation thresholds that are configured for the system as described in the Thresholding Configuration Guide. The primary difference is that when congestion thresholds are reached, a service congestion policy and an SNMP trap, starCongestion, are generated.A threshold tolerance dictates the percentage under the configured threshold that must be reached in order for the condition to be cleared. An SNMP trap, starCongestionClear, is then triggered. Port Utilization Thresholds: If you set a port utilization threshold, when the average utilization of all ports in the system reaches the specified threshold, congestion control is enabled. Port-specific Thresholds: If you set port-specific thresholds, when any individual port-specific threshold is reached, congestion control is enabled system-wide. Service Congestion Policies: Congestion policies are configurable for each service. These policies dictate how services respond when the system detects that a congestion condition threshold has been crossed.

CSCF performs congestion control based on the memory usage inside every sessmgr at two levels.

Level 1: For every new call/event received, the system checks if sessmgr memory-usage is above a threshold value (such as 95 percent). If it is, memory-congestion is triggered and new call messages are rejected with 500 SIP response. Memory congestion is disabled when memory usage drops by a tolerance value (default is 10 percent).

Level 2: If the sessmgr usage reaches 100 percent, all newly received SIP messages are dropped at the socket layer in that sessmgr except for the BYE message. The new SIP messages are not processed until the memory reaches the threshold value (95 percent).

A trap is also generated whenever sessmgr is in congestion state

IMPORTANT:

For more information on congestion control, refer to the Congestion Control chapter in the System Administration Guide.

DSCP Marking

Provides support for more granular configuration of DSCP marking.

For Interactive Traffic class, the P-CSCF/A-BG supports per-service configurable DSCP marking for Uplink and Downlink direction based on Allocation/Retention Priority in addition to the current priorities.

The following matrix may be used to determine the Diffserv markings used based on the configured traffic class and Allocation/Retention Priority:
Table 6. Default DSCP Value Matrix

Allocation Priority 1 2 3
Traffic Handling Priority . . .
1 ef ef ef
2 af21 af21 af21
3 af21 af21 af21



Early IMS Security

Early IMS security allows authenticating the UE without IMS protocols and clients. Based on the 3GPP TR 33.978 specification, the SCM supports security inter-operation with 2G and non-IPSec user devices.

Emergency Call Support

P-CSCF gives priority to emergency calls, especially in a congested network. In addition, P-CSCF rejects new calls to any user who is in an emergency call.

Error Handling

The SCM supports consistent management of errors in a framework that considers existing and future standards and specifications.

Future-proof Solution

The SCM eliminates the capital and operational barriers associated with deploying traditional, server-based SIP proxies that lack carrier-class characteristics, occupy valuable rack space, and require numerous network interfaces, while also introducing additional control hops in the network that add call setup latency.

When operators deploy IMS/MMD, profitability will improve because a seamless on-ramp will be provided by simultaneously supporting 3GPP/3GPP2-based standards, P-CSCF functionality, and IETF SIP standards.

Intelligent Integration

For deployed platforms, no new hardware is necessary to install or manage. Functionality is enabled with a simple software download.

Intelligent integration lowers operational expenditure and reduces the number of network elements, network interfaces, and call setup latency.

Interworking Function

The SCM allows non-IMS UEs (pre IMS or RFC3261-compliant UEs) to work with the IMS core. When UEs are not IMS compliant, having this protocol interworking function at the edge allows the IMS core to be IMS compliant. After the interworking function inserts all necessary IMS headers toward the IMs core, the call appears to the IMS core network elements as if it is coming from an IMS-compliant UE.

The feature allows simultaneous support of IETF SIP and 3GPP/3GPP2 IMS/MMD clients.

IPv6 Support

In addition to supporting IPv4, the SCM supports IPv6 addressing. A CSCF service can be configured with v6 addresses to support an all v6 network.

IMPORTANT:

For this feature, you may bind a CSCF service to either an IPv4 address or to an IPv6 address, but not both simultaneously.

The following diagram shows the implementation where CSCF supports only IPv4.


Figure 6. IPv4 Configuration

With IPv6 support, the configuration supported would look like the following diagram. The DNS server could be either IPv4 or IPv6.


Figure 7. IPv6 Configuration

IMPORTANT:

The policy interface to PCRF will be IPv6 based when DIAMETER supports IPv6.

Management System Overview

The system's management capabilities are designed around the Telecommunications Management Network (TMN) model for management - focusing on providing superior quality network element (NE) and element management system (Cisco Web Element Manager) functions. The system provides element management applications that can easily be integrated, using standards-based protocols (CORBA and SNMPv1, v2), into higher-level management systems - giving wireless operators the ability to integrate the system into their overall network, service, and business management systems. In addition, all management is performed out-of-band for security and to maintain system performance.

Cisco's O&M module offers comprehensive management capabilities to the operators and enables them to operate the system more efficiently. There are multiple ways to manage the system either locally or remotely using its out-of-band management interfaces.

These include:
  • Using the command line interface (CLI)
  • Remote login using Telnet, and Secure Shell (SSH) access to CLI through SPIO card's Ethernet management interfaces
  • Local login through the Console port on SPIO card using an RS-232 serial connection
  • Using the Web Element Manager application
  • Supports communications through 10 Base-T, 100 Base-TX, 1000 Base-TX, or 1000
  • Base-SX (optical gigabit Ethernet) Ethernet management interfaces on the SPIO
  • Client-Server model supports any browser (i.e. Microsoft Internet Explorer v5.0 and above or Netscape v4.7 or above, and others)
  • Supports Common Object Request Broker Architecture (CORBA) protocol and Simple Network Management Protocol version 1 (SNMPv1) for fault management
  • Provides complete Fault, Configuration, Accounting, Performance, and Security (FCAPS) capabilities
  • Can be easily integrated with higher-level network, service, and business layer applications using the Object Management Group's (OMG’s) Interface Definition Language (IDL)

The following figure demonstrates these various element management options and how they can be utilized within the wireless carrier network.


Figure 8. Element Management Methods

IMPORTANT:

SCM management functionality is enabled by default for console-based access. For GUI-based management support, refer to the Web Element Management System section in this chapter.

IMPORTANT:

For more information on command line interface based management, refer to the Command Line Interface Reference.

MSRP Support

The SCM supports Message Session Relay Protocol (MSRP) session and page modes.

PCRF Policy Control

P-CSCF can use the IMS Rx interface to communicate with the PCRF during call initiation and renegotiation to provide session information to the PCRF and ensure that a call conforms to policy. P-CSCF uses the IMS Rx interface during registration to subscribe to learn access network information and signaling path status.

PCRF policy control includes:

  • IP flow/media authorization
  • QoS resource reservation
  • Early media/bandwidth authorization
  • Notification of media path changes/states
  • Notification of signaling path changes/states

IMPORTANT:

For more information on PCRF policy control support, refer to the IMS Rx Interface chapter in this guide.

Presence Enabled

With its high transaction setup rate, this is an ideal solution to handle a large number of messages generated by presence signaling. CSCF supports all the presence RFC extensions and signaling and interoperates with several presence servers.

Redirection

The SCM supports response to 3xx redirect messages. In addition to supporting redirection as per 3GPP, it supports call redirection to other chassis in the network (based on configuration) in case of system overload.

Redundancy and Session Recovery

When enabled, provides automatic failover of existing CSCF sessions due to hardware or software faults.

The system recovers from a single hardware or software fault with minimal interruption to the subscriber’s service and maintains session information to rebuild sessions if multiple faults occur.

Registration Event Package

A set of event notifications used to inform SIP node of changes made to a registration.

Signaling Compression (SigComp)

SigComp compresses SIP call setup messages and is supported on the P-CSCF component. This reduces bandwidth demands on the RAN and reduces setup times.

SIP Denial of Service (DoS) Attack Prevention

The A-BG provides a scalable proxy network and a distributed Network Address Translation (NAT) network which effectively mitigates DoS attacks.

The SCM prevents a variety of DoS attacks specific to CSCF and SIP technology.

IMPORTANT:

For more information on SIP DoS attack prevention support, refer to the SIP DoS Attack Prevention chapter in this guide.

SIP Intelligence at the Core

The SCM provides operators with an easy on-ramp for deploying SIP-based subscriber services while supporting various network control operations that provide the necessary intelligent control to insure a robust, carrier-class subscriber experience is achieved in this always changing multimedia environment.

When integrated into Cisco's session-aware Home Agent or GGSN platform, the SCM becomes the first SIP hop in the network, allowing operators to monitor and control all SIP-based sessions and execute additional value-added functions.

As the logical anchor point within the packet core, the SCM improves the user experience with device and location independence, and enhances subscriber control and policy enforcement with faster, more intelligent decisions for multimedia services.

Furthermore, as Fixed Mobile Convergence takes hold, it will be especially important to incorporate the SCM in the packet core in order to achieve mobility and voice continuity between multiple access networks (3G, WiFi, WiMAX, etc.).


Figure 9. Cisco Integrated Session Control Manager

SIP Large Message Support

Large notify contains information about multiple users in one message, which reduces the number of SIP messages in the network. Large SIP messages can be sent on UDP if the endpoint can support fragmentation; otherwise, UDP to TCP switching can be used to transport large messages intact.

If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using TCP. This prevents fragmentation of messages over UDP and provides congestion control for larger messages. P-CSCF/A-BG is also able to handle messages up to the maximum datagram packet size. For UDP, this size is 65,535 bytes, including IP and UDP headers.

Large message support is needed for handling presence signaling traffic as the size of messages could be as large as 50K.

SIP Routing Engine

The SIP routing engine deploys SIP in a secure and controlled fashion.

Provides auto discovery of SIP elements, subscriber privacy, call fraud prevention, network security, and thwarting of network overload conditions.

Shared Initial Filter Criteria (SiFC)

If both the HSS and the S-CSCF support this feature, subsets of iFC may be shared by several service profiles. The HSS downloads the unique identifiers of the shared iFC sets to the S-CSCF. The S-CSCF uses a locally administered database to map the downloaded identifiers onto the shared iFC sets.

If the S-CSCF does not support this feature, the HSS will not download identifiers of shared iFC sets.

Telephony Application Server (TAS) Basic Supported

The following describe the local basic call features implemented on the S-CSCF:
  • Abbreviated Dialing (AD)
  • Call Forward Busy Line (CFBL)
  • Call Forward No Answer (CFNA)
  • Call Forward Not Registered (CFNR)
  • Call Forward Unconditional (CFU)
  • Call Transfer
  • Call Waiting
  • Caller ID Display (CID)
  • Caller ID Display Blocked (CIDB)
  • Feature Code Activation/De-activation
  • Follow Me/Find Me
  • Locally Allowed Abbreviated Dialing
  • Outbound Call Restrictions/Dialing Permissions
  • Short Code Dialing
TAS Basic provides basic voice call feature support in the SCM. In the IMS architecture, these telephony features are normally provided by an external application server. Providing these features with the S-CSCF:
  • Reduces the need for an additional SIP AS
  • Simplifies the network architecture
  • Improves latency for call setup and feature invocation
The following describe the local basic call features implemented on the S-CSCF:
  • Abbreviated Dialing (AD) - This feature allows the subscriber to call a Directory Number by entering less than the usual ten digits.Usually, the subscriber has four digit dialing to mimic PBX dialing privileges but these must be set up prior to use. When the SCM receives these numbers, it translates them and routes the call.
  • Call Forward Busy Line (CFBL) - This feature forwards the call if busy line indication is received from the UE. If CFBL is enabled on both the AS and the S-CSCF, the call is forwarded by the S-CSCF on Busy Line indication. The feature detects and eliminates call forward loops if the History-Info header is present. It also terminates forwarding if forwarding causes the forward attempts to be more than the number specified in the Max-Forwards header.
  • Call Forward No Answer (CFNA) - This feature forwards the call if no answer is received from the UE. If CFNA is enabled on both the AS and the S-CSCF, the call is forwarded by the S-CSCF on No Answer indication. The feature detects and eliminates call forward loops if the History-Info header is present. It also terminates forwarding if forwarding causes the forward attempts to be more than the number specified in the Max-Forwards header.
  • Call Forward Not Registered (CFNR) - This feature forwards the call if the subscriber is not registered. If CFNR is enabled on both the AS and the S-CSCF, the call is forwarded by the S-CSCF on Not Registered indication. The feature detects and eliminates call forward loops if the History-Info header is present. It also terminates forwarding if forwarding causes the forward attempts to be more than the number specified in the Max-Forwards header.
  • Call Forward Unconditional (CFU) - This feature unconditionally forwards the call. The check for local CFU is done prior to the filter criteria and before any AS interaction. Thus CFU is enabled on both the S-CSCF and the destination AS, the local CFU occurs and there is no AS interaction. The feature eliminates basic loop detection (A calls B which is forwarded to A) and if the History-Info header is present, enhanced loop detection is performed based on the contents of this header. It also terminates forwarding if forwarding causes the forward attempts to be more than the number specified in the Max-Forwards header.
  • Call Transfer - This feature allows the subscriber to transfer a call.
  • Call Waiting - This feature allows the subscriber to receive a second call while on the first call.
  • Caller ID Display (CID) - This feature inserts P-Preferred-Identity which communicates the identity of the user within the trust domain. If this header is already present, the feature may not do anything different.
  • Caller ID Display Blocked (CIDB) - This feature removes P-Preferred-Identity and P-Preferred-Asserted-Identity headers and inserts a Privacy header with the privacy value set to “id”.
  • Feature Code Activation/De-activation - This feature allows for activating and de-activating certain features using a star (*) - number sequence (star code). Registered subscribers have the option of activating or deactivated call features using specified star codes. The SCM translates these codes and routes the call.
  • Follow Me/Find Me - This feature invokes the incoming call to several configured destinations in parallel and connects the call to the first destination that responds, “tearing down” all the other calls. There are two possible implementations of this feature; one a sequential implementation in which each destination is attempted in sequence till a successful connection. The other is a parallel approach in which several destinations are tried simultaneously. The advantage of the parallel approach is a faster set up.
  • Locally Allowed Abbreviated Dialing - This feature allows the subscriber to dial a local-only, legacy, short code such as *CG or *POL. The SCM translates these codes to a ten-digit directory number and routes the call.
  • Outbound Call Restrictions/Dialing Permissions - This feature restricts subscribers from initiating certain outbound calls. For example, if a subscriber attempts to make an international call and is not permitted to, the S-CSCF rejects the call.
  • Short Code Dialing - This feature allows the subscriber to dial a short code such as #PAYor #MIN. The SCM translates these codes and routes the call.

Threshold Crossing Alerts (TCA) Support

Thresholding on the system is used to monitor the system for conditions that could potentially cause errors or outage. Typically, these conditions are temporary (i.e high CPU utilization, or packet collisions on a network) and are quickly resolved. However, continuous or large numbers of these error conditions within a specific time interval may be indicative of larger, more severe issues. The purpose of thresholding is to help identify potentially severe conditions so that immediate action can be taken to minimize and/or avoid system downtime.

The system supports Threshold Crossing Alerts for certain key resources such as CPU, memory, IP pool addresses, etc. With this capability, the operator can configure threshold on these resources whereby, should the resource depletion cross the configured threshold, a SNMP Trap would be sent.

The following thresholding models are supported by the system:

  • Alert: A value is monitored and an alert condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.
  • Alarm: Both high and low threshold are defined for a value. An alarm condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.
Thresholding reports conditions using one of the following mechanisms:
  • SNMP traps: SNMP traps have been created that indicate the condition (high threshold crossing and/or clear) of each of the monitored values.Generation of specific traps can be enabled or disabled on the chassis. Ensuring that only important faults get displayed. SNMP traps are supported in both Alert and Alarm modes.
  • Logs: The system provides a facility called threshold for which active and event logs can be generated. As with other system facilities, logs are generated Log messages pertaining to the condition of a monitored value are generated with a severity level of WARNING.Logs are supported in both the Alert and the Alarm models.
  • Alarm System: High threshold alarms generated within the specified polling interval are considered “outstanding” until a the condition no longer exists or a condition clear alarm is generated. “Outstanding” alarms are reported to the system's alarm subsystem and are viewable through the Alarm Management menu in the Web Element Manager.The Alarm System is used only in conjunction with the Alarm model.

IMPORTANT:

For more information on threshold crossing alert configuration, refer to the Thresholding Configuration Guide.

Trust Domain

Enables the identification of trusted network entities. This keeps subscriber information confidential when it is received.

Features and Functionality - External Application Support

This section describes the features and functions of external applications supported on the SCM. These services require additional licenses to implement the functionality.

Web Element Management System

Provides a graphical user interface (GUI) for performing fault, configuration, accounting, performance, and security (FCAPS) management of the ASR 5000.

The Web Element Manager is a Common Object Request Broker Architecture (CORBA)-based application that provides complete fault, configuration, accounting, performance, and security (FCAPS) management capability for the system.

For maximum flexibility and scalability, the Web Element Manager application implements a client-server architecture. This architecture allows remote clients with Java-enabled web browsers to manage one or more systems via the server component which implements the CORBA interfaces. The server component is fully compatible with the fault-tolerant Sun® Solaris® operating system.

The following figure demonstrates various interfaces between the Cisco Web Element Manager and other network components.


Figure 10. Web Element Manager Network Interfaces

IMPORTANT:

For more information on WEM support, refer to the WEM Installation and Administration Guide.

Features and Functionality - Licensed Enhanced Feature Support

This section describes optional enhanced features and functions.

Each of the following optional enhanced features require the purchase of an additional license to implement the functionality with the SCM.

Interchassis Session Recovery

Use of Interchassis Session Recovery requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.

The ASR 5000 provides industry leading carrier class redundancy. The systems protects against all single points of failure (hardware and software) and attempts to recover to an operational state when multiple simultaneous failures occur.

The system provides several levels of system redundancy:
  • Under normal N+1 PSC/PSC2/PSC3 hardware redundancy, if a catastrophic packet processing card failure occurs all affected calls are migrated to the standby packet processing card if possible. Calls which cannot be migrated are gracefully terminated with proper call-termination signaling and accounting records are generated with statistics accurate to the last internal checkpoint
  • If the Session Recovery feature is enabled, any total packet processing card failure will cause a packet processing card switchover and all established sessions for supported call-types are recovered without any loss of session.

Even though Cisco Systems provides excellent intra-chassis redundancy with these two schemes, certain catastrophic failures which can cause total chassis outages, such as IP routing failures, line-cuts, loss of power, or physical destruction of the chassis, cannot be protected by this scheme. In such cases, the Interchassis Session Recovery feature provides geographic redundancy between sites. This has the benefit of not only providing enhanced subscriber experience even during catastrophic outages, but can also protect other systems such as the RAN from subscriber re-activation storms.

The Interchassis Session Recovery feature allows for continuous call processing without interrupting subscriber services. This is accomplished through the use of redundant chassis. The chassis are configured as primary and backup with one being active and one in recovery mode. A checkpoint duration timer is used to control when subscriber data is sent from the active chassis to the inactive chassis. If the active chassis handling the call traffic goes out of service, the inactive chassis transitions to the active state and continues processing the call traffic without interrupting the subscriber session. The chassis determines which is active through a propriety TCP-based connection called a redundancy link. This link is used to exchange Hello messages between the primary and backup chassis and must be maintained for proper system operation.

  • Interchassis CommunicationChassis configured to support Interchassis Session Recovery communicate using periodic Hello messages. These messages are sent by each chassis to notify the peer of its current state. The Hello message contains information about the chassis such as its configuration and priority. A dead interval is used to set a time limit for a Hello message to be received from the chassis' peer. If the standby chassis does not receive a Hello message from the active chassis within the dead interval, the standby chassis transitions to the active state. In situations where the redundancy link goes out of service, a priority scheme is used to determine which chassis processes the session. The following priority scheme is used: router identifier chassis priority SPIO MAC address
  • Checkpoint MessagesCheckpoint messages are sent from the active chassis to the inactive chassis. Checkpoint messages are sent at specific intervals and contain all the information needed to recreate the sessions on the standby chassis, if that chassis were to become active. Once a session exceeds the checkpoint duration, checkpoint data is collected on the session. The checkpoint parameter determines the amount of time a session must be active before it is included in the checkpoint message.

IMPORTANT:

For more information on interchassis session recovery support, refer to the Interchassis Session Recovery chapter in the System Administration Guide.

IPSec Support

Use of IPSec requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.

Encrypted IPSec tunnels are terminated and decrypted so that traffic coming from untrusted networks are secured before entering the secure operator network. This prevents eavesdropping, hijacking, and other intrusive behavior from occurring.

IP Security (IPSec) is a suite of protocols that interact with one another to provide secure private communications across IP networks. These protocols allow the system to establish and maintain secure tunnels with peer security gateways.

IMPORTANT:

IPSec implementation is a mandatory part of IPv6, but it is optional to secure IPv4 traffic.

IMPORTANT:

For more information on IPSec support, refer to the IP Security chapter in this guide.

IPv4-IPv6 Interworking

Use of IPv4-IPv6 interworking requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.

This feature allows the P-CSCF to provide IPv4-IPv6 interworking in the following scenarios:

  • When UEs are IPv6-only and the IMS core network is IPv4-only
  • When UEs are IPv4-only and the IMS core network is IPv6-only

In addition, IPv4-IPv6 interworking helps an IPv4 IMS network transition to an all-IPv6 IMS network.

The following interworking requirements are currently supported:
  • MSRP support when IPv4-IPv6 interworking is enabled
  • IPv4 TCP and IPv6 TCP
  • Transport switching allowed based on size for both v4 and v6 network
  • UDP fragmentation allowed for both v4 and v6 networks
  • P-CSCF supports Mw and Gm interfaces on both v4 and v6
  • KPIs for Mw and Gm interfaces are supported on both v4 and v6
  • DNS supported for v4 and v6 networks
  • Interworking supported for IM and presence
  • Both v4 and v6 handsets are supported simultaneously on the same P-CSCF node

P-CSCF will provide IPv4-IPv6 interworking functionality between IPv6-only UEs and IPv4-only core network elements (I/S-CSCF) by acting as a dual stack. To achieve the dual-stack behavior, P-CSCF will be configured in two services with the first service (V6-SVC) listening on an IPv6 address and the second service (V4-SVC) listening on an IPv4 address. SIP messages coming from IPv6 UEs will come to V6-SVC and will be forwarded to the IPv4 core network through V4-SVC. Similarly, messages from the IPv4 core network come to V4-SVC and will be forwarded to IPv6 UEs via V6-SVC. P-CSCF also provides interworking functionality between IPV4-only UEs and IPv6-only core network elements.

P-CSCF handling different v4-v6 interworking scenarios is shown below.


Figure 11. Interworking Between IPv6 UE and IPv4 IMS Core Network

Figure 12. Interworking Between IPv4 UE and IPv6 IMS Core Network

To identify the need for IPv4-IPv6 interworking for a new incoming IPv6 REGISTER arriving at V6-SVC, a route lookup is performed based on the request-uri, first in V4-SVC context and then in V6-SVC context if the first lookup does not return any matching route entry. If a matching IPv4 next-hop route entry is found, then this indicates that interworking needs to be done. If no route entry is found, then a DNS query on request-uri domain is done for both A and AAAA type records. If DNS response yields only an IPv4 address, then this is also the case for performing IPv4-IPv6 interworking.

Headers (such as Via, Path, etc.) are automatically set to IPv4 bind address of P-CSCF V4-SVC. Remaining headers will be not be altered and sent as is toward the S-CSCF. The IPv4 address in a Path header received from S-CSCF in 200Ok of REGISTER will be replaced with V6-SVC’s IPv6 address before forwarding to UE.

Lawful Intercept

Use of Lawful Intercept requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.

The Cisco Lawful Intercept feature is supported on the SCM. Lawful Intercept is a licensed-enabled, standards-based feature that provides telecommunications service providers with a mechanism to assist law enforcement agencies in monitoring suspicious individuals for potential illegal activity. For additional information and documentation on the Lawful Intercept feature, contact your Cisco account representative.

Session Recovery Support

Use of Session Recovery requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.

The Session Recovery feature provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault within the system preventing a fully connected user session from being disconnected.

Session recovery is performed by mirroring key software processes (e.g. session manager and AAA manager) within the system. These mirrored processes remain in an idle state (in standby-mode), wherein they perform no processing, until they may be needed in the case of a software failure (e.g. a session manager task aborts). The system spawns new instances of “standby mode” session and AAA managers for each active Control Processor (CP) being used.

Additionally, other key system-level software tasks, such as VPN manager, are performed on a physically separate Packet Services Card (PSC/PSC2/PSC3) to ensure that a double software fault (e.g. session manager and VPN manager fails at same time on same card) cannot occur. The PSC/PSC2/PSC3 used to host the VPN manager process is in active mode and is reserved by the operating system for this sole use when session recovery is enabled.

The additional hardware resources required for session recovery include a standby System Management Card (SMC) and a standby PSC/PSC2/PSC3.

There are two modes for Session Recovery.
  • Task recovery mode: Wherein one or more session manager failures occur and are recovered without the need to use resources on a standby PSC. In this mode, recovery is performed by using the mirrored “standby-mode” session manager task(s) running on active PSCs. The “standby-mode” task is renamed, made active, and is then populated using information from other tasks such as AAA manager.
  • Full PSC/PSC2/PSC3 recovery mode: Used when a PSC hardware failure occurs, or when a PSC migration failure happens. In this mode, the standby PSC is made active and the “standby-mode” session manager and AAA manager tasks on the newly activated PSC perform session recovery.

Session/Call state information is saved in the peer AAA manager task because each AAA manager and session manager task is paired together. These pairs are started on physically different PSCs/PSC2s/PSC3s to ensure task recovery.

IMPORTANT:

Session Recovery is supported for either IPv4 or IPv6 traffic.

IMPORTANT:

For more information on session recovery support, refer to the Session Recovery chapter in the System Administration Guide.

TLS Support in P-CSCF

Use of SSL requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.

Transport Layer Security (TLS) provides confidentiality and integrity protection for SIP signaling messages between the UE and P-CSCF/A-BG. TLS is a layered protocol that runs upon reliable transport protocols like TCP and SCTP.

The SCM supports the following two scenarios:
  • TLS as a transport between UE and P-CSCF/A-BG, as per RFC 3261
  • Use of TLS by Security Mechanism agreement between UE and P-CSCF/A-BG, as per RC 3329 and TS 33.203

The following figure shows the TLS protocol layers.

IMPORTANT:

For more information on TLS support, refer to the TLS Support chapter in this guide.

How the SCM Works

This section provides information on the function of the SCM in a CDMA2000 PDSN or UMTS GGSN network and presents call procedure flows for different stages of session setup.

Admission and Routing

Admission and routing of subscriber URIs is performed through a number of configurable lists in the SCM.

The following sections describe the main admission and routing techniques used in the SCM. The following figure presents the method and order for admitting and routing sessions within the SCM.


Figure 13. Admission and Routing Method

CSCF Access Control Lists

Access Control Lists (ACLs) are a set of rules that are applied during CSCF session establishment. A typical use of these rules is to accept or deny registration or session establishment requests. ACLs may be tied to subscribers and/or the whole service. Subscriber based ACLs can also be imported from an external ACL/policy server. In that event, the external policy server address would be configured with the service.

A complete explanation of the ACL configuration method is located in Access Control Lists appendix in this guide.

Translation Lists

Translation lists help modify request-uri (i.e. addressing of a CSCF session). One example is that E.164 numbers could be altered by adding prefixes and suffixes or the request-uri could be modified based on the registration database.

Route Lists

Route lists are service level lists that assist in finding the next CSCF/UA hop. These are static routes and will override any dynamic routes (based on DNS queries for FQDNs).

Signaling Compression

The Session Initiation Protocol (SIP) is a text-based protocol designed for higher bandwidth networks. As such, it is inherently less suited for lower bandwidth environments such as wireless networks. If a wireless handset uses SIP to set up a call, the setup time is significantly increased due to the high overhead of text-based signaling messages.

Signaling Compression (SigComp) is a solution for compressing/decompressing messages generated by application protocols such as SIP. The P-CSCF component of the SCM uses SigComp to reduce call setup times on the access network, typically between the P-CSCF and the UE. The following features are supported:
  • SigComp Detection - P-CSCF detects if the UE supports SigComp and compresses messages it sends to the UE. The P-CSCF also detects if messages it receives are compressed and decompresses them.
  • SigComp Parameter Configuration - P-CSCF allows the configuration of Decompression Memory Size (DMS), State Memory Size (SMS), and Cycles Per Bit (CPB).
  • Failure Acknowledgement - P-CSCF replies with NACK on decompression failure.
  • SIP/SDP Static Dictionaries - P-CSCF supports the Session Initiation Protocol/Session Description Protocol Static Dictionary for Signaling Compression.

Supported Standards

The SCM service complies with the following standards for CDMA2000 PDSN, UMTS GGSN, and LTE network wireless data services.

Release 9 3GPP References

IMPORTANT:

The SCM currently supports the following Release 9 3GPP specifications. Most 3GPP specifications are also used for 3GPP2 support; any specifications that are unique to 3GPP2 would be listed under 3GPP2 References.

  • TS 23.167 IP Multimedia Subsystem (IMS) emergency sessions
  • TS 23.204 Support of Short Message Service (SMS) over generic 3GPP Internet Protocol (IP) access; Stage 2
  • TS 23.207 End-to-end Quality of Service (QoS) concept and architecture
  • TS 23.228 IP Multimedia Subsystem (IMS); Stage 2
  • TS 23.981 Interworking aspects and migration scenarios for IPv4-based IP Multimedia Subsystem (IMS) implementations
  • TS 24.229 Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
  • TS 24.341 Support of SMS over IP networks; Stage 3
  • TS 29.208 End-to-end Quality of Service (QoS) signalling flows
  • TS 29.214 Policy and charging control over Rx reference point
  • TS 29.228 IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents
  • TS 29.229 Cx and Dx interfaces based on the Diameter protocol; Protocol details
  • TS 32.240 Telecommunication management; Charging management; Charging architecture and principles
  • TS 32.260 Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging
  • TS 33.203 3G security; Access security for IP-based services
  • TS 33.978 Security aspects of early IP Multimedia Subsystem (IMS)

Release 8 3GPP References

IMPORTANT:

The SCM currently supports the following Release 8 3GPP specifications. Most 3GPP specifications are also used for 3GPP2 support; any specifications that are unique to 3GPP2 are listed under 3GPP2 References.

  • TR 23.806 Voice call continuity between Circuit Switched (CS) and IP Multimedia Subsystem (IMS) Study
  • TR 23.808 Supporting Globally Routable User Agent URI (GRUU) in IMS; Report and conclusions
  • TR 23.816 Identification of Communication Services in IMS
  • TS 24.229 IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
  • TR 24.930 IP Multimedia core network Subsystem (IMS) based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
  • TR 29.847 Conferencing based on SIP, SDP, and other protocols; Functional models, information flows and protocol details
  • TR 33.978 Security aspects of early IP Multimedia Subsystem (IMS)
  • TS 22.101 Service principles
  • TS 23.003 Numbering, addressing and identification
  • TS 23.107 Quality of Service (QoS) concept and architecture
  • TS 23.125 Overall high level functionality and architecture impacts of flow based charging; Stage 2
  • TS 23.141 Presence service; Architecture and functional description; Stage 2
  • TS 23.167 IP Multimedia Subsystem (IMS) emergency sessions
  • TS 23.203 Policy and charging control architecture
  • TS 23.204 Support of Short Message Service (SMS) over generic 3GPP Internet Protocol (IP) access; Stage 2
  • TS 23.207 End-to-end Quality of Service (QoS) concept and architecture
  • TS 23.218 IP Multimedia (IM) session handling; IM call model; Stage 2
  • TS 23.221 Architectural Requirements
  • TS 23.228 IP Multimedia Subsystem (IMS); Stage 2
  • TS 23.271 Functional description of Location Services (LCS)
  • TS 23.981 Interworking aspects and migration scenarios for IPv4-based IP Multimedia Subsystem (IMS) implementations
  • TS 24.141 Presence service using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3
  • TS 24.228 Signalling flows for the IP multimedia call control based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
  • TS 24.229 Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
  • TS 24.341 Support of SMS over IP networks; Stage 3
  • TS 26.114 IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction
  • TS 26.141 IP Multimedia System (IMS) Messaging and Presence; Media formats and codecs
  • TS 26.234 Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs
  • TS 26.235 Packet switched conversational multimedia applications; Default codecs
  • TS 26.236 Packet switched conversational multimedia applications; Transport protocols
  • TS 29.207 Policy control over Go interface
  • TS 29.208 End-to-end Quality of Service (QoS) signalling flows
  • TS 29.209 Policy control over Gq interface
  • TS 29.213 Policy and charging control signalling flows and Quality of Service (QoS) parameter mapping
  • TS 29.214 Policy and charging control over Rx reference point
  • TS 29.228 IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents
  • TS 29.229 Cx and Dx interfaces based on the Diameter protocol; Protocol details
  • TS 29.328 IMS Sh interface: signalling flows and message content
  • TS 29.329 IMS Sh interface based on the Diameter protocol; Protocol details
  • TS 31.103 Characteristics of the IMS Identity Module (ISIM) application
  • TS 32.225 Telecommunication management; Charging management; Charging data description for the IP Multimedia Subsystem (IMS)
  • TS 32.240 Telecommunication management; Charging management; Charging architecture and principles
  • TS 32.260 Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging
  • TS 32.299 Telecommunication management; Charging management; Diameter charging applications
  • TS 33.102 3G security; Security architecture
  • TS 33.178 Security aspects of early IP Multimedia Subsystem (IMS)
  • TS 33.203 3G security; Access security for IP-based services
  • TS 33.978 Security aspects of early IP Multimedia Subsystem (IMS)

3GPP2 References

  • S.R0079-A v1.0 Support for End-to-End QoS - Stage 1 Requirements
  • S.R0086-A v1.0 IMS Security Framework
  • X.S0013-000-A v1.0 All-IP Core Network Multimedia Domain - Overview
  • X.S0013-002-A v1.0 All-IP Core Network Multimedia Domain - IP Multimedia Subsystem Stage 2
  • X.S0013-003-0 v2.0 All-IP Core Network Multimedia Domain - IP Multimedia (IMS) Session Handling; IP Multimedia (IM) Call Model - Stage 2
  • X.S0013-004-A v1.0 All-IP Core Network Multimedia Domain - IP Multimedia Call Control Protocol Based on SIP and SDP Stage 3
  • X.S0013-005-0 All-IP Core Network Multimedia Domain: IP Multimedia Subsystem Cx Interface Signaling Flows and Message Contents
  • X.S0013-006-0 All-IP Core Network Multimedia Domain - Cx Interface Based on the Diameter Protocol; Protocol Details
  • X.S0013-007-0 All-IP Core Network Multimedia Domain: IP Multimedia Subsystem - Charging Architecture
  • X.S0013-007-A v1.0 All-IP Core Network Multimedia Domain - IP Multimedia Subsystem - Charging Architecture
  • X.S0013-008-0 All-IP Core Network Multimedia Domain: IP Multimedia Subsystem - Accounting Information Flows and Protocol
  • X.S0013-008-A All-IP Core Network Multimedia Domain - IP Multimedia Subsystem - Offline Accounting Information Flows and Protocol
  • X.S0013-010-0 v1.0 All-IP Core Network Multimedia Domain: IP Multimedia Subsystem Sh Interface; Signaling Flows and Message Contents - Stage 2
  • X.S0013-011-0 v1.0 All-IP Core Network Multimedia Domain: Sh Interface Based on Diameter Protocols Protocol Details - Stage 3
  • X.S0013-012-0 v1.0 All-IP Core Network Multimedia Domain - Service Based Bearer Control - Stage 2
  • X.S0013-014-0 v1.0 All-IP Core Network Multimedia Domain - Service Based Bearer Control - Tx Interface Stage 3
  • X.S0016-000-A v1.0 3GPP2 Multimedia Messaging System MMS Specification Overview, Revision A
  • X.S0027-002-0 v1.0 Presence Security
  • X.S0027-003-0 v1.0 Presence Stage 3
  • X.S0029-0 v1.0 Conferencing Using the IP Multimedia (IM) Core Network (CN) Subsystem
  • X.S0049-0 v1.0 All-IP Network Emergency Call Support

IETF References

  • RFC 1594 (March 1994): “FYI on Questions and Answers to Commonly Asked “New Internet User” Questions”
  • RFC 1889 (January 1996): “RTP: A Transport Protocol for Real-Time Applications”
  • RFC 2246 (January 1999): “TLS protocol version 1.0”
  • RFC 2327 (April 1998): SDP: Session Description Protocol
  • RFC 2401 (November 1998): “Security Architecture for the Internet Protocol (IPSec)”
  • RFC 2403 (November 1998): “The Use of HMAC-MD5-96 within ESP and AH”
  • RFC 2404 (November 1998): “The Use of HMAC-SHA-1-96 within ESP and AH”
  • RFC 2462 (December 1998): “IPv6 Address Autoconfiguration”
  • RFC 2617 (June 1999): “HTTP Authentication: Basic and Digest Access Authentication”
  • RFC 2753 (January 2000): “A Framework for Policy-based Admission Control”
  • RFC 2833 (May 2000): “RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals”
  • RFC 2915 (September 2000): The Naming Authority Pointer (NAPTR) DNS Resource Record
  • RFC 2976 (October 2000): “The SIP INFO Method”
  • RFC 3041 (January 2001): “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”
  • RFC 3261 (June 2002): “SIP: Session Initiation Protocol”
  • RFC 3262 (June 2002): “Reliability of provisional responses in Session Initiation Protocol (SIP)”
  • RFC 3263 (June 2002): “Session Initiation Protocol (SIP): Locating SIP Servers”
  • RFC 3264 (June 2002): “An Offer/Answer Model with Session Description Protocol (SDP)”
  • RFC 3265 (June 2002): “Session Initiation Protocol (SIP) - Specific Event Notification”
  • RFC 3280 (April 2002): “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”
  • RFC 3310 (September 2002): “Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)”
  • RFC 3311 (September 2002): “The Session Initiation Protocol (SIP) UPDATE Method”.
  • RFC 3312 (October 2002): “Integration of Resource Management and Session Initiation Protocol (SIP)”
  • RFC 3313 (January 2003): “Private Session Initiation Protocol (SIP) Extensions for Media Authorization”
  • RFC 3315 (July 2003): “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”
  • RFC 3320 (January 2003): “Signaling Compression (SigComp)”
  • RFC 3321 (January 2003): “Signaling Compression (SigComp) - Extended Operations”
  • RFC 3323 (November 2002): “A Privacy Mechanism for the Session Initiation Protocol (SIP)”
  • RFC 3325 (November 2002): “Private Extensions to the Session Initiation Protocol (SIP) for Network Asserted Identity within Trusted Networks”
  • RFC 3326 (December 2002): “The Reason Header Field for the Session Initiation Protocol (SIP)”
  • RFC 3327 (December 2002): “Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts”
  • RFC 3329 (January 2003): “Security Mechanism Agreement for the Session Initiation Protocol (SIP)”
  • RFC 3388 (December 2002): “Grouping of Media Lines in the Session Description Protocol (SDP)”
  • RFC 3428 (December 2002): “Session Initiation Protocol (SIP) Extension for Instant Messaging”
  • RFC 3455 (January 2003): “Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)”
  • RFC 3485 (February 2003): “The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)”
  • RFC 3486 (February 2003): “Compressing the Session Initiation Protocol (SIP)”
  • RFC 3515 (April 2003): “The Session Initiation Protocol (SIP) Refer method”
  • RFC 3556 (July 2003): “Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth”
  • RFC 3581 (August 2003): “An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing”
  • RFC 3588 (September 2003): “Diameter Base Protocol”
  • RFC 3608 (October 2003): “Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration”
  • RFC 3665 (December 2003): “Session Initiation Protocol (SIP) Basic Call Flow Examples”
  • RFC 3680 (March 2004): “A Session Initiation Protocol (SIP) Event Package for Registrations”
  • RFC 3761 (April 2004): “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)”
  • RFC 3824 (June 2004): “Using E.164 numbers with the Session Initiation Protocol (SIP)”
  • RFC 3840 (August 2004): “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)”
  • RFC 3841 (August 2004): “Caller Preferences for the Session Initiation Protocol (SIP)”
  • RFC 3842 (August 2004): “A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)”
  • RFC 3856 (August 2004): “A Presence Event Package for the Session Initiation Protocol (SIP)”
  • RFC 3857 (August 2004): “A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)”
  • RFC 3858 (August 2004): “An Extensible Markup Language (XML) Based Format for Watcher Information”
  • RFC 3861 (August 2004): “Address Resolution for Instant Messaging and Presence”
  • RFC 3891 (September 2004): “The Session Initiation Protocol (SIP) “Replaces” Header”
  • RFC 3892 (September 2004): “The Session Initiation Protocol (SIP) Referred-By Mechanism”
  • RFC 3903 (October 2004): “Session Initiation Protocol (SIP) Extension for Event State Publication”
  • RFC 3911 (October 2004): “The Session Initiation Protocol (SIP) “Join” Header”
  • RFC 3966 (December 2004): “The tel URI for Telephone Numbers”
  • RFC 3986 (January 2005): “Uniform Resource Identifier (URI): Generic Syntax”
  • RFC 4028 (April 2005): “Session Timers in the Session Initiation Protocol (SIP)”
  • RFC 4032 (March 2005): “Update to the Session Initiation Protocol (SIP) Preconditions Framework”
  • RFC 4077 (May 2005): “A Negative Acknowledgement Mechanism for Signaling Compression”
  • RFC 4244 (November 2005): “An Extension to the Session Initiation Protocol (SIP) for Request History Information”
  • RFC 4317 (December 2005): “Session Description Protocol (SDP) Offer/Answer Examples”
  • RFC 4353 (February 2006): “A Framework for Conferencing with the Session Initiation Protocol (SIP)”
  • RFC 4475 (May 2006): “Session Initiation Protocol (SIP) Torture Test Messages”
  • RFC 4566 (July 2006): “SDP: Session Description Protocol”
  • RFC 4975 (September 2007): “Message Session Relay Protocol (MSRP)”
  • RFC 5031 (January 2008): “A Uniform Resource Name (URN) for Emergency and Other Well-Known Services”
  • RFC 5049 (December 2007): “Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)”
  • RFC 5112 (January 2008): “The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)”
  • RFC 5491 (March 2009): “GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations”
  • RFC 5626 (October 2009): “Managing Client Initiated Connections in the Session Initiation Protocol (SIP)”

Other

  • Packet-Cable spec (PKT-TR-SEC-V02-061013)