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.
Features and Functionality
- Base Software
The following
is a list containing a variety of features found in the SCM and
the benefits they provide.
This section describes
the following features:
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
- 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.
This section describes
the following features:
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.