Enhanced Charging Service Overview

Enhanced Charging Service Overview
 
 
This chapter provides an overview of Enhanced Charging Service (ECS)/Active Charging Services (ACS).
ECS is an enhanced or extended premium service. The System Administration Guide provides basic system configuration information, and the product administration guides provide information to configure the core network service functionality. It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model before using the procedures in this chapter.
This chapter covers the following topics:
 
 
Introduction
The ECS is an in-line service that is integrated within the system. ECS enhances the mobile carrier’s ability to provide flexible, differentiated, and detailed billing to subscribers with Layer 3 through Layer 7 packet inspection, and the ability to integrate with back-end billing system.
 
Charging Subsystem
The ECS has analyzers that examine uplink and downlink traffic and rules that define what packet content to take action on and what action to take when the rule is true. The analyzers also generate usage records for the billing system.
 
The various functions of ECS subsystem are:
 
 
Traffic Analyzers
Traffic analyzers in ECS are based on configured rules. Rules used for traffic analysis analyze packet flows and form usage records. Usage records are created per content type and forwarded to a prepaid server or to a billing system.
 
The Traffic Analyzer function can perform shallow (Layer 3 and Layer 4) and deep (above Layer 4) packet inspection of IP packet flows. It is able to correlate all layer 3 packets (and bytes) with higher layer trigger criteria (for example, URL detected in an HTTP header). It also performs stateful packet inspection for complex protocols like FTP, RTSP, and SIP that dynamically open ports for the data path and this way, user plane payload is differentiated into “categories”. Traffic analyzers can also detect video streaming over RTSP, and image downloads and MMS over HTTP and differential treatment can be given to the Vcast traffic.
Traffic analyzers work at the application level as well, and perform event-based charging without the interference of the service platforms.
The ECS content analyzers can inspect and maintain state across various protocols at all layers of the OSI stack. The ECS supports inspecting and analyzing the following protocols:
 
 
Shallow Packet Inspection
Shallow packet inspection is defined as inspection of the layer 3 (IP header) and layer 4 (for example, UDP or TCP header) information in the user plane packet flow.
 
Shallow inspection is examining the IP header (Layer 3) or UDP or TCP header (Layer 4). Deep-packet inspection is typically the examination of Uniform Resource Identifier (URI) information (Layer 7). Shallow packet analyzers typically determine the destination IP address or port number of a terminating proxy, whereas deep-packet analyzers typically identify the destination of a terminating proxy.
 
Deep Packet Inspection
In some cases, Layer 3 and 4 analyzers that identify a trigger condition are insufficient for billing purposes, so layer 7 is used.
 
For example, the Web site www.companyname.com corresponds to IP address 1.1.1.1. The stock quote page (www.companyname.com/quotes) and the company page (www.companyname.com/business) are chargeable services. All other pages on this site are free. Since all parts of this Web site corresponds to a destination address of 1.1.1.1 and port number 80 (http), so determination of chargeable user traffic is possible through the actual URL (Layer 7) only.
DPI performs packet inspection beyond Layer 4 inspection and is typically deployed for:
 
 
Supported Accounting and Charging Interfaces
 
Accounting Interfaces for Postpaid Service
ECS supports the following accounting interfaces for postpaid subscribers:
 
 
 
Accounting and Charging Interface for Prepaid Service
ECS supports the following Credit Control Interfaces for prepaid subscribers:
 
 
 
Charging Records in ECS
ECS provides the following charging records for postpaid and prepaid charging:
 
 
 
Licensing
ECS is a licensed feature, the features described in this chapter are only available if you have purchased and installed the required license:
 
[ 600-00-7526 ] Enhanced Charging Bundle 1 1k Sessions — To enable and configure ECS functionality
[ 600-00-7574 ] Enhanced Charging Bundle 2 1k Sessions — To enable and configure Diameter and DCCA functionality with ECS
Important: For information on additional license requirements for enhanced or customer-specific features, please contact your local sales/service representative.
 
ECS Architecture
The following figure depicts the Enhanced Charging Service architecture managed by the Session Controller (SessCtrl) and Session Manager (SessMgr) subsystems.
 
ECS Architecture
 
How ECS Works
This section describes the major components of the ECS solution, and the roles they play.
 
Content Service Steering: Redirects incoming traffic to the ECS subsystem
Protocol Analyzer: Performs inspection of incoming packets
Rule Definitions: Specifies the packets to inspect or the charging actions to apply to packets based on content
Rulebases: Allows grouping one or more number of rule definitions together to define the billing policies for individual subscribers or group of subscribers
 
Content Service Steering
Content Service Steering (CSS) enables directing selective subscriber traffic into the ECS subsystem (In-line services internal to the system) based on the content of the data presented by mobile subscribers.
CSS uses Access Control Lists (ACLs) to redirect selective subscriber traffic flows. ACLs control the flow of packets into and out of the system. ACLs consist of “rules” (ACL rules) or filters that control the action taken on packets matching the filter criteria.
ACLs are configurable on a per-context basis and applies to a subscriber through either a subscriber profile (for PDSN) or an APN profile (for GGSN) in the destination context.
Important: For more information on CSS, refer to the Content Service Steering chapter of the System Enhanced Feature Configuration Guide. For more information on ACLs, refer to the IP Access Control Lists chapter of the System Enhanced Feature Configuration Guide.
 
Protocol Analyzer
The Protocol Analyzer is the software stack responsible for analyzing the individual protocol fields and states during packet inspection.
 
The Protocol Analyzer performs two types of packet inspection:
 
Shallow Packet Inspection: Inspection of the layer 3 (IP header) and layer 4 (for example, UDP or TCP header) information.
Deep Packet Inspection: Inspection of layer 7 and 7+ information. DPI functionality includes:
The Protocol Analyzer performs a stateful packet inspection of complex protocols, such as FTP, RTSP, and SIP, which dynamically open ports for the data path, so the payload can be classified according to content.
The Protocol Analyzer is also capable of determining which layer 3 packets belong (either directly or indirectly) to a trigger condition (for example, URL). In cases where the trigger condition cannot be uniquely defined at layers 3 and 4, then the trigger condition must be defined at layer 7 (i.e., a specific URL must be matched).
 
Protocol Analyzer Software Stack
Every packet that enters the ECS subsystem must first go through the Protocol Analyzer software stack, which comprises of individual protocol analyzers for each of the supported protocols.
 
 
ECS Protocol Analyzer Stack
Note that protocol names are used to represent the individual protocol analyzers.
Each analyzer consists of fields and states that are compared to the protocol-fields and protocol-states in the incoming packets to determine packet content.
 
Rule Definitions
Rule definitions (Ruledefs) are user-defined expressions, based on protocol fields and/or protocol-states, which define what actions to take when specific field values are true. Expressions may contain a number of operator types (string, =, >, etc.) based on the data type of the operand. For example, “string” type expressions like URLs and host name can be used with comparison operators like “contains”, “!contains”, “=”, “!=”, “starts-with”, “ends-with”, “!starts-with” and “!ends-with”. Integer type expressions like “packet size” and “sequence number” can be used with comparison operators like “=”, “!=”, “>=”, “<=”. Each ruledef configuration consists of multiple expressions applicable to any of the fields or states supported by the respective analyzers.
Ruledefs are of the following types:
 
Routing Ruledefs: Routing ruledefs are used to route packets to content analyzers. Routing ruledefs determine which content analyzer to route the packet to when the protocol fields and/or protocol-states in ruledef expression are true. Up to 256 ruledefs can be configured for routing.
Charging Ruledefs: Charging ruledefs are used to specify what action to take based on the analysis done by the content analyzers. Actions can include redirection, charge value, and billing record emission. Up to 2048 ruledefs can be configured for charging.
Post-processing Ruledefs: Used for post-processing purposes. Enables processing of packets even if the rule matching for them has been disabled.
When a ruledef is created if the rule-application is not specified, by default the system configures the ruledef as a charging ruledef.
Ruledefs support a priority configuration to specify the order in which the ruledefs are examined and applied to packets. The names of the ruledefs must be unique across the service or globally. A ruledef can be used across multiple rulebases.
Important: Ruledef priorities control the flow of the packets through the analyzers and control the order in which the charging actions are applied. The ruledef with the lowest priority number invokes first. For routing ruledefs, it is important that lower level analyzers (such as the TCP analyzer) be invoked prior to the related analyzers in the next level (such as HTTP analyzer and S-HTTP analyzers), as the next level of analyzers may require access to resources or information from the lower level. Priorities are also important for charging ruledefs as the action defined in the first matched charging rule apply to the packet and ECS subsystem disregards the rest of the charging ruledefs.
Each ruledef can be used across multiple rulebases, and up to 2048 ruledefs can be defined in a charging service.
Ruledefs have an expression part, which matches specific packets based upon analyzer field variables. This is a boolean (analyzer_field operator value) expression that tests for analyzer field values.
 
The following is an example of a ruledef to match packets:
http url contains cnn.com
–or–
http any-match = TRUE
The following is an example of a ruledef to route packets to the HTTP analyzer:
route priority 50 ruledef rule-for-http analyzer http
Where, rule-for-http has been defined with the expressions: tcp either-port = 80
The following example applies actions where:
ruledef port-80
  tcp either-port = 80
  rule-application routing
  exit
ruledef bbc-news
  http url starts-with http://news.bbc.co.uk
  rule-application charging
  exit
ruledef catch-all
  ip any-match = TRUE
  rule-application charging
  exit
charging-action free-site
  content-id 100
  [ ... ]
  exit
charging-action charge-by-duration
  content-id 101
  [ ... ]
  exit
rulebase standard
  [ ... ]
  route priority 1 ruledef port-80 analyzer http
  action priority 101 ruledef bbc-news charging-action free-site
  action priority 1000 ruledef catch-all charging-action charge-by-duration
  [ ... ]
  exit
The following figure illustrates how ruledefs interact with the Protocol Analyzer Stack and Action Engine to produce charging records.
 
ECS In-line Service Processing
Packets entering the ECS subsystem must first pass through the Protocol Analyzer Stack where routing ruledefs apply to determine which packets to inspect. Then output from this inspection is passed to the Charging Engine, where charging ruledefs apply to perform actions on the output.
 
Routing Ruledefs and Packet Inspection
The following figure and the steps that follow describe the details of routing ruledef application during packet inspection.
 
Routing Ruledefs and Packet Inspection
Step 1
Step 2
Step a
Step b
Step c
Important: In the current release traffic routes to the ICMP, TCP, and UDP analyzers by default. Therefore, defining routing ruledefs for these analyzers is not required.
Step 3
The ruledefs’ priority determines the order in which the ruledefs are compared against packets.
Step 4
Step 5
Step a
Step b
 
Charging Ruledefs and the Charging Engine
This section describes details of how charging ruledefs are applied to the output from the Protocol Analyzer Stack.
The following figure and the steps that follow describe the process of charging ruledefs and charging engines.
 
Charging Ruledefs and Charging Engine
Step 1
Step 2
 
Group-of-Ruledefs
Group-of-Ruledefs enable grouping ruledefs into categories. When a group-of-ruledefs is configured in a rulebase, if any of the ruledefs within the group matches, the specified charging-action is performed, any more action instances are not processed.
 
A group-of-ruledefs may contain optimizable ruledefs. Whether a group is optimized or not is decided on whether all the ruledefs in the group-of-ruledefs can be optimized, and if the group is included in a rulebase that has optimization turned on, then the group will be optimized.
When a new ruledef is added, it is checked if it is included in any group-of-ruledefs, and whether it needs to be optimized, etc.
 
Rulebase
A rulebase is a collection of ruledefs and their associated billing policy. The rulebase determines the action to be taken when a rule is matched. A maximum of 512 rulebases can be specified in an ECS service.
 
It is possible to define a ruledef with different actions. For example, a Web site might be free for postpaid users and charge based on volume for prepaid users. Rulebases can also be used to apply the same ruledefs for several subscribers, which eliminate the need to have unique ruledefs for each subscriber.
 
Enhanced Services in ECS
This section describes the enhanced and extended features supported in ECS.
 
Important: Features described in this section are license enabled. If you have not previously purchased licenses for these services, contact your sales representative for more information.
 
Session Control in ECS
In conjunction with the Cisco ASR 5000 chassis, the ECS provides a high-level network flow and bandwidth control mechanism through the Session Control system. ECS Session Control feature uses the interaction between SessMgr subsystem and Static Traffic Policy Infrastructure support of the chassis to provide an effective method to maximize network resource usage and enhancement of overall user experience.
 
This feature provides the following functionality:
 
Flow Control Functionality: This functionality provides the ability to define and manage the number of simultaneous IP-based sessions and/or the number of simultaneous instances of a particular application permitted for the subscriber.
If a subscriber begins a packet data session and system is either pre-configured or receives a subscriber profile from the AAA server indicating the maximum amount of simultaneous flow for a subscriber or an application is allowed to initiate. If subscriber exceeds the limit of allowed number of flows for subscriber or type of application system blocks/redirect/discard/terminate the traffic.
The following type of flow quotas are available for Flow Control Functionality:
Subscriber-Level Session Quota: Configurable on a per-rulebase basis
Application-Level Session Quota: Configurable on a per-charging-action basis
Bandwidth Control Functionality: This functionality allows the operator to apply rate limit to potentially bandwidth intensive and service disruptive applications.
Using this feature the operator can police and prioritize subscribers’ traffic to ensure that no single or group of subscribers’ traffic negatively impacts another subscribers’ traffic.
For example, if a subscriber is running a P2P file sharing program and the system is pre-configured to detect and limit the amount of bandwidth to the subscriber for P2P application. The system gets the quota limit for bandwidth from PDP context parameter or individual subscriber. If the subscriber’s P2P traffic usage exceeds the pre-configured limit, the Session Control discards the traffic for this subscriber session.
Session Control feature in ECS also provides the controls to police any traffic to/from a subscriber/application with the chassis.
 
Time and Flow-based Bearer Charging in ECS
ECS supports Time-based Charging (TBC) to charge customers on either actual consumed time or total session time usage during a subscriber session. TBC generates charging records based on the actual time difference between receiving the two packets, or by adding idle time when no packet flow occurs.
 
ECS also supports Flow-based Charging (FBC) based on flow category and type.
PDP context charging allows the system to collect charging information related to data volumes sent to and received by the MS. This collected information is categorized by the QoS applied to the PDP context. FBC integrates a Tariff Plane Function (TPF) to the charging capabilities that categorize the PDP context data volume for specific service data flows.
Service data flows are defined by charging rules. The charging rules use protocol characteristics such as:
 
FBC provides multiple service data flow counts, one each per defined service data flow. When FBC is configured in the ECS, PDP context online charging is achieved by FBC online charging using only the wildcard service data flow.
When further service data flows are specified, traffic is categorized, and counted, according to the service data flow specification. You can apply wildcard to service data flow that do not match any of the specific service data flows.
The following are the chargeable events for FBC:
 
Start of PDP context: Upon encountering this event, a Credit Control Request (CCR) starts, indicating the start of the PDP context, is sent towards the Online Charging Service. The data volume is captured per service data flow for the PDP context.
Start of service data flow: An interim CCR is generated for the PDP context, indicating the start of a new service data flow, and a new volume count for this service data flow is started.
Termination of service data flow: The service data flow volume counter is closed, and an interim CCR is generated towards the Online Charging Service, indicating the end of the service data flow and the final volume count for this service data flow.
End of PDP context: Upon encountering this event, a CCR stop, indicating the end of the PDP context, is sent towards the Online Charging Service together with the final volume counts for the PDP context and all service data flows.
Expiration of an operator configured time limit per PDP context: This event triggers the emission of an interim CCR, indicating the elapsed time and the accrued data volume for the PDP context since the last report.
Expiration of an operator configured time limit per service data flow: The service data flow volume counter is closed and an interim CCR is sent to the Online Charging Service, indicating the elapsed time and the accrued data volume since the last report for that service data flow. A new service data flow container is opened if the service data flow is still active.
Expiration of an operator configured data volume limit per PDP context: This event triggers the emission of an interim CCR, indicating the elapsed time and the accrued data volume for the PDP context since the last report.
Expiration of an operator configured data volume limit per service data flow: The service data flow volume counter is closed and an interim CCR is sent to the Online Charging Service, indicating the elapsed time and the accrued data volume since the last report for that service data flow. A new service data flow container is opened if the service data flow is still active.
Change of charging condition: When QoS change, tariff time change are encountered, all current volume counts are captured and sent towards the Online Charging Service with an interim CCR. New volume counts for all active service data flows are started.
Administrative intervention by user/service also force trigger a chargeable event.
A Flow Data Record (FDR) is generated for each of the above events. These generated records are stored in an EDR/UDR/FDR (xDR) and eG-CDR format (for GGSN deployments) and retrieved by ESS/GSS/mediation system for charging and/or analysis.
The file naming convention for created xDRs (EDR/UDR/FDRs) are described in the Impact on xDR File Naming section.
 
Content Filtering Support
ECS provides off-line content filtering support and in-line static and dynamic content filtering support to control static and dynamic data flow and content requests.
 
Content Filtering Server Group Support
ECS supports external Content Filtering servers through Internet Content Adaptation Protocol (ICAP) implementation between ICAP client and Active Content Filter (ACF) server (ICAP server).
ICAP is a protocol designed to support dynamic content filtering and/or content insertion and/or modification of Web pages. Designed for flexibility, ICAP allows bearer plane nodes such as firewalls, routers, or systems running ECS to interface with external content servers such as parental control (content filtering) servers to provide content filtering service support.
 
In-line Content Filtering Support
Content Filtering is a fully integrated, subscriber-aware in-line service available for 3GPP and 3GPP2 networks to filter HTTP and WAP requests from mobile subscribers based on the URLs in the requests. This enables operators to filter and control the content that an individual subscriber can access, so that subscribers are inadvertently not exposed to universally unacceptable content and/or content inappropriate as per the subscribers’ preferences. Content Filtering uses Deep Packet Inspection (DPI) capabilities of ECS to discern HTTP and WAP requests.
Important: For more information on Content Filtering support, refer to the Content Filtering Services Administration Guide.
 
IP Readdressing Feature
Readdressing of packets based on the destination IP address of the packets enables redirecting unknown gateway traffic to known/trusted gateways.
IP Readdressing is configured in the flow action defined in a charging action. IP readdressing works for traffic that matches particular ruledef, and hence the charging action. IP readdressing is applicable to both uplink and downlink traffic. In the Enhanced Charging Subsystem, uplink packets are modified after packet inspection, rule matching, etc., where the destination IP/port is determined, and replaced with the readdress IP/port just before they are sent out. Downlink packets (containing the readdressed IP/port) are modified as soon as they are received, before the packet inspection, where the source IP/port is replaced with the original server IP/port number.
For one flow from an MS, if one packet is re-addressed, then all the packets in that flow will be re-addressed to the same server. Features like DPI, rule-matching, etc. remain unaffected. Each IP address + port combination will be defined as a ruledef.
In case of IP fragmentation, packets with successful IP re-assembly will be re-addressed. However, IP fragmentation failure packets will not be re-addressed.
 
Next-hop Address Configuration
ECS supports the ability to set the next-hop default gateway IP address as a charging action associated with any ruledef in a rulebase. This functionality provides more flexibility for service based routing allowing the next-hop default gateway to be set after initial ACL processing. This removes need for AAA to send the next-hop default gateway IP address for CC opted in subscribers.
How it works:
Step 1
Step 2
Step 3
Step 4
 
X-Header Insertion and Encryption Feature
This section describes the X-Header Insertion and Encryption features.
Important: This feature is license dependent. Please contact your local sales representative for more information.
 
X-Header Insertion
This section provides an overview of the X-Header Insertion feature.
Extension header (x-header) fields are the fields not defined in RFCs or standards but can be added to headers of protocol for specific purposes. The x-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields should be ignored by the recipient and must be forwarded by transparent proxies.
The X-Header Insertion feature enables inserting x-headers in HTTP/WSP GET and POST request packets. Operators wanting to insert x-headers in HTTP/WSP GET and POST request packets, can configure rules for it. The charging-action associated with the rules will contain the list of x-headers to be inserted in the packets.
For example, if an operator wants to insert header field x-rat-type in the HTTP header with its value being rat-type, i.e. the header inserted should be:
x-rat-type: geran
where, rat-type is geran for the current packet.
Configuring the X-Header Insertion feature involves:
Step 1
Step 2
Step 3
Step 4
 
X-Header Encryption
This section provides an overview of the X-Header Encryption feature.
X-Header Encryption enhances the X-header Insertion feature to increase the number of fields that can be inserted, and also enables encrypting the fields before inserting them.
If x-header insertion has already happened for an IP flow (because of any x-header format), and if the current charging-action has the first-request-only flag set, x-header insertion will not happen for that format. If the first-request-only flag is not set in a charging-action, then for that x-header format, insertion will continue happening in any further suitable packets in that IP flow.
Changes to x-header format configuration will not trigger re-encryption for existing calls. The changed configuration will however, be applicable for new calls. The changed configuration will also apply at the next re-encryption time to those existing calls for which re-encryption timeout is specified. If encryption is enabled for a parameter while data is flowing, since its encrypted value will not be available, insertion of that parameter will stop.
Important: Recovery of flows is not supported for this feature.
The following steps describe how X-Header Encryption works:
Step 1
Step 2
Step 3
Step 4
 
Limitations to the Header Insertion Feature
The following are limitations to insertion of x-header fields in HTTP headers:
 
The following are limitations to insertion of x-header fields in WSP headers:
 
 
Post Processing Feature
The Post Processing feature enables processing of packets even if the rule matching for them has been disabled. This enables all the IP/TCP packets including TCP handshaking to be accounted and charged for in the same bucket as the application flow. For example, delay-charged packets for IP Readdressing and Next-hop features.
 
A ruledef can be configured as a post-processing rule in the ruledef itself using rule-application of the ruledef. A rule can be charging, routing, or a post-processing rule. If the same ruledef is required to be a charging rule in one rulebase and a post-processing rule in another one, then two separate identical ruledefs must be defined.
 
How the Post-processing Feature Works
The following steps describe how the Post-processing feature works:
Step 1
Step 2
Step 3
Step 4
Step 5
If no disposition action is obtained by matching post-processing rules, the one obtained by matching charging-rules will be applied.
Irrespective of whether post processing is required or not, even if a single post-processing rule is configured in the rulebase, post processing will be done.
The following points should be considered while configuring post-processing rules for next-hop/readdressing.
 
For x-header insertion, there should either be a post-processing rule whose charging-action gives no disposition-action or the packet should not match any of the post-processing rules so that the disposition action obtained from charging-rule matching is applied.
 
Time-of-Day Activation/Deactivation of Rules
Within a rulebase, ruledefs/groups-of-ruledefs are assigned priorities. When packets start arriving, as per the priority order, every rule/group-of-ruledefs in the rulebase is eligible for matching regardless of the packet arrival time. By default, the ruledefs/groups-of-ruledefs are active all the time.
The Time-of-Day Activation/Deactivation of Rules feature uses time definitions (timedefs) to activate/deactivate static ruledefs/groups-of-ruledefs such that they are available for rule matching only when they are active.
Important: The time considered for timedef matching is the system’s local time.
 
How the Time-of-Day Activation/Deactivation of Rules Feature Works
The following steps describe how the Time-of-Day Activation/Deactivation of Rules feature enables charging according to the time of the day/time:
Step 1
A maximum of 10 timedefs can be created in an ECS service.
Step 2
A maximum of 24 timeslots can be configured in a timedef.
Step 3
One timedef can be used with several ruledefs/group-of-ruledefs. If a ruledef/group-of-ruledefs does not have a timedef associated with it, it will always be considered as active.
Step 4
This release does not support configuring a timeslot for a specific date.
If, in a timeslot, only the time is specified, that timeslot will be applicable for all days.
If for a timeslot, “start time” > “end time”, that rule will span the midnight. I.e. that rule is considered to be active from the current day till the next day.
If for a timeslot, “start day” > “end day”, that rule will span over the current week till the end day in the next week.
In the following cases a rule will be active all the time:
 
 
URL Filtering
The URL Filtering feature simplifies using rule definitions for URL detection.
The following configuration is currently used for hundreds of URLs:
 
ruledef HTTP://AB-WAP.YZ
  www url starts-with HTTP://CDAB-SUBS.OPERA-MINI.NET/HTTP://AB-WAP.YZ
  www url starts-with HTTP://AB-WAP.YZ
  multi-line-or all-lines
  exit
In the above ruledef:
 
Prefixed URLs are URLs of the proxies. A packet can have a URL of the proxy and the actual URL contiguously. First a packet is searched for the presence of proxy URL. If the proxy URL is found, it is truncated from the parsed information and only the actual URL (that immediately follows it) is used for rule matching and EDR generation.
The group-of-ruledefs can have rules for URLs that need to be actually searched (URLs that immediately follow the proxy URLs). I.e., the group-of-prefixed-URLs will have URLs that need to be truncated from the packet information for further ECS processing, whereas, the group-of-ruledefs will have rules that need to be actually searched for in the packet.
URLs that you expect to be prefixed to the actual URL can be grouped together in a group-of-prefixed-URLs. A maximum of 64 such groups can be configured. In each such group, URLs that need to be truncated from the URL contained in the packet are specified. Each group can have a maximum of 10 such prefixed URLs. By default, all group-of-prefixed-URLs are disabled.
In the ECS rulebase, you can enable/disable the group-of-prefixed-URLs to filter for prefixed URLs.
Important: A prefixed URL can be detected and stripped if it is of the type “http://www.xyz.com/http://www.abc.com”. Here, “http://www.xyz.com” will be stripped off. But in “http://www.xyz.com/www.abc.com”, it cannot detect and strip off “http://www.xyz.com” as it looks for occurrence of “http” or “https” within the URL.
 
ECS Deployment
The following figure shows a typical example of ECS deployment in a mobile data environment.
 
Deployment of ECS in a Mobile Data Network
 
Accounting Interfaces
ECS supports different accounting and charging interfaces for prepaid and postpaid charging and record generation.
 
Important: Some feature supports described in this section are license enabled. If you have not previously purchased licenses for these services, contact your sales representative for more information.
 
GTPP Accounting
Important: GTPP Accounting is only available for GGSN networks.
GTTP accounting in ECS allows the collection of counters for different types of data traffic, and including that data in a G-CDR that is sent to a Charging Gateway Function (CGF).
Standard G-CDRs do not have an attribute which defines traffic counters depending upon the traffic type but they do have a field named “Record Extensions” where all vendor-specific information can be included. ECS includes the counters for different types of data traffic in this field when sending a G-CDR.
 
RADIUS Accounting and Credit Control
The Remote Authentication Dial-In User Service (RADIUS) interface in ECS is used for the following purposes:
 
 
Subscriber Category Request: ECS obtains the subscriber category from the AAA server (either prepaid or postpaid) when a new data session is detected. The AAA server used for the subscriber category request can be different from the AAA server used for service authorization and accounting.
Service Access Authorization: ECS requests access authorization for a specific subscriber and a newly detected data session. The AAA server is the access Policy Decision Point and the ECS the Policy Enforcement Point.
On-line Service Accounting (Prepaid): ECS reports service usage to the AAA server. The AAA server acts as a prepaid control point and the ECS as the client. Accounting can be applied to a full prepaid implementation or just to keep ECS updated of the balance level and trigger a redirection if the subscriber balance reaches a low level.
 
Diameter Accounting and Credit Control
The Diameter Credit Control Application (DCCA) is used to implement real-time online and/or offline charging and credit control for a variety of services, such as network access, messaging services, and download services.
 
In addition to being a general solution for real-time cost and credit control, DCCA includes these features:
 
Real-time Rate Service Information: DCCA can verify when end subscribers' accounts are exhausted or expired; or deny additional chargeable events.
Support for Multiple Services: DCCA supports the usage of multiple services within one subscriber session. Multiple service support includes:
 
Gx Interface Support
Important: This feature is only available in GGSN/UMTS networks.
The Gx interface is used in IMS deployment in GPRS/UMTS networks. Gx interface support on the system enables wireless operators to intelligently charge the services accessed depending on the service type and parameters with rules. It also provides support for IP Multimedia Subsystem (IMS) authorization in a GGSN service. The goal of the Gx interface is to provide network-based QoS control as well as dynamic charging rules on a per bearer basis for an individual subscriber. The Gx interface is in particular needed to control and charge multimedia applications.
Rel 6. Gx Interface: The provisioning of charging rules that are based on the dynamic analysis of flows used for the IMS session is carried out over the Gx interface. The Rel. 6 Gx interface is located between the Access Gateway functioning as Traffic Plane Function (TPF), and the Charging Rule Function (CRF). The GGSN/TPF acts as the client where as the CRF contains the Diameter server functionality. Rel. 6 Gx interface is based on the Diameter base protocol (DIABASE) and the Diameter Credit Control Application (DCCA) standard.
Rel. 7 Gx Interface: The Rel. 7 Gx interface enables policy-based admission control support (enforcing policy control features like gating, bandwidth limiting, etc.,) and Flow-based Charging (FBC). This is accomplished via dynamically provisioned Policy Control and Charging (PCC) rules. These PCC rules are used to identify service data flows and do charging. Other parameters associated with the rules are used to enforce policy control.
The PCC architecture allows operators to perform service-based QoS policy, and flow-based charging control. In the PCC architecture, this is accomplished mainly by the Policy and Charging Enforcement Function (PCEF)/GGSN and the Policy and Charging Rules Function (PCRF).
Important: For more information on Gx interface support, see Gx Interface Support chapter of the System Enhanced Feature Configuration Guide.
 
Gy Interface Support
Important: This feature is only available in GGSN/UMTS networks.
The Gy interface provides a standardized Diameter interface for real-time content-based charging of data services. It is based on the 3GPP standards and relies on quota allocation.
It provides an online charging interface that works with the ECS Deep Packet Inspection feature. With Gy, customer traffic can be gated and billed in an “online” or “prepaid” style. Both time- and volume-based charging models are supported. In all these models, differentiated rates can be applied to different services based on shallow or deep-packet inspection.
Gy is a Diameter interface. As such, it is implemented atop, and inherits features from, the Diameter Base Protocol. The system supports the applicable base network and application features, including directly connected, relayed or proxied DCCA servers using TLS or plaintext TCP.
In the simplest possible installation, the system will exchange Gy Diameter messages over Diameter TCP links between itself and one “prepay” server. For a more robust installation, multiple servers would be used. These servers may optionally share or mirror a single quota database so as to support Gy session failover from one server to the other. For a more scalable installation, a layer of proxies or other Diameter agents can be introduced to provide features such as multi-path message routing or message and session redirection features.
Gy interface is the reference point between Diameter server and GGSN for online accounting and charging through Diameter based protocol. The Diameter server functions as Online Charging Service (OCS) and provides the online charging data to the GGSN, which acts as a Charging Data Function (CDF). Connection between Diameter Client (Diabase) and OCS is maintained by underlaying TCP connection of Diameter based protocol and exchanges a series of messages to check the status of the connection and capabilities.
The Diameter Credit Control Application (DCCA) which resides as part of the ECS manages the credit and quota for a subscriber.
The following figure depicts a typical Gy interface implementation between GGSN (CDF) and Diameter server (OCS) with ECS.
 
Logical Online Charging with Gy Interface
 
Standard GGSN Call Detail Records (G-CDRs)
Important: G-CDRs are only available in GGSN networks.
G-CDRs are generated according to 3GPP TS 32.251 V6.6.0.
Currently ECS supports generation of CDRs using AAAMgrs only.
 
G-CDR Format
The G-CDRs can be in ASN.1 format.
Important: For more information on G-CDR fields, refer to the AAA Interface Administration and Reference Guide.
 
Enhanced GGSN Call Detail Records (eG-CDRs)
Important: eG-CDRs are only available in GGSN networks.
The ECS also supports enhanced G-CDRs, which is an enhanced format of standard G-CDRs to provide greater portability of charging information.
eG-CDRs are compliant with 3GPP TS 32.298 v6.5.0 for Rel. 6 based dictionaries, and with 3GPP TS 32.298 v7.4.0 for Rel. 7 based dictionaries.
By default, the G-CDR does not support the traffic and vendor specific records. To support a traffic and vendor specific record, the ECS must be configured to generate eG-CDRs. eG-CDRs are useful to implement TBC and FBC to ECS.
eG-CDR supports customer specific formats configured in Ga context in a GGSN service with standard or custom specific GTPP dictionaries.
 
eG-CDR Format
The eG-CDRs can be in ASN.1 format.
 
Triggers to Update eG-CDRs
The following table lists the trigger conditions to update charging information in an eG-CDR.
Triggers for charging information update in eG-CDR
 
Triggers to Close eG-CDRs
The following table lists the trigger conditions to close the eG-CDR.
Triggers for closing an eG-CDR
Important: For more information on eG-CDR fields, refer to the AAA Interface Administration and Reference Guide.
 
Event Detail Records (EDRs)
Event Detail Records (EDRs) are usage records with support to configure content information, format, and generation triggers by the system administrative user.
EDRs are generated according to explicit action statements in rule commands. Several different EDR schema types, each composed of a series of analyzer parameter names, are specified in EDR. EDRs are written at the time of each event in CSV format. EDRs are stored in timestamped files that can be downloaded via SFTP from the configured context.
EDRs are generated on per flow basis, and as such they catch whatever bytes get transmitted over that flow including retransmitted.
 
EDR format
The EDRs can be generated in comma separated values (CSV) format as defined in the traffic analysis rules.
 
Important: In EDRs, the maximum field length for normal and escaped strings is 127 characters. If a field’s value is greater than 127 characters, in the EDR it is truncated to 127 characters.
 
Flow-overflow EDR
Flow-overflow EDR or Summary FDR is a feature to count the data bytes from the subscriber that are missed due to various reasons in ECS.
In case any condition that affects the callline (FLOW end-condition like hagr, handoff) occurs, flow-overflow EDR generation is enabled, an extra EDR is generated. Based on how many bytes/packets were transferred from/to the subscriber for which ECS did not allocate data session. This byte/packet count is reflected in that extra EDR. This extra EDR is nothing but “flow-overflow” EDR or Summary FDR.
The extra EDR is generated if all of the following is true:
 
The bytes/packet count will be printed as a part of “sn-volume-amt” attribute in the EDR. Hence, this attribute must be configured in the EDR format.
 
EDR Generation in Flow-end and Transaction Complete Scenarios with sn-volume Fields
“sn-volume-amt” counters will be re-initialized only when the fields are populated in EDRs. For example, consider the following two EDR formats:
 
edr-format edr1
  rule-variable http url priority 10
  attribute sn-volume-amt ip bytes uplink priority 500
  attribute sn-volume-amt ip bytes downlink priority 510
  attribute sn-volume-amt ip pkts uplink priority 520
  attribute sn-volume-amt ip pkts downlink priority 530
  attribute sn-app-protocol priority 1000
  exit
edr-format edr2
  rule-variable http url priority 10
  attribute sn-app-protocol priority 1000
  exit
“sn-volume-amt counters” will be re-initialized only if these fields are populated in the EDRs. Now if edr2 is generated, these counters will not be re-initialized. These will be re-initialized only when edr1 is generated. Also, note that only those counters will be re-initialized which are populated in EDR. For example, in the following EDR format:
 
edr-format edr3
  rule-variable http url priority 10
  attribute sn-volume-amt ip bytes uplink priority 500
  attribute sn-volume-amt ip bytes downlink priority 510
  attribute sn-app-protocol priority 1000
  exit
If edr3 is generated, only uplink bytes and downlink bytes counter will be re-initialized and uplink packets and downlink packets will contain the previous values till these fields are populated (say when edr1 is generated).
For the voice call duration for SIP reporting requirements, ECS SIP analyzer keeps timestamp of the first INVITE that it sees. It also keeps a timestamp when it sees a 200 OK for a BYE. When this 200 OK for a BYE is seen, SIP analyzer triggers creation of an EDR of type ACS_EDR_VOIP_CALL_END_EVENT. This will also be triggered at the time of SIP flow termination if no 200 OK for BYE is seen. In that case, the last packet time will be used in place of the 200 OK BYE timestamp. The EDR generation logic calculates the call duration based on the INVITE and end timestamps, it also accesses the child RTP/RTCP flows to calculate the combined uplink/downlink bytes/packets counts and sets them in the appropriate fields.
 
Usage Detail Records (UDRs)
Usage Detail Records (UDRs) contain accounting information based on usage of service by a specific mobile subscriber. UDRs are generated based on the content-id for the subscriber, which is part of charging action. The fields required as part of usage data records are configurable and stored in the System Configuration Task (SCT).
UDRs are generated on any trigger of time threshold, volume threshold, handoffs, and call termination. If any of the events occur then the UDR subsystem generates UDRs for each content ID and sends to the CDR module for storage.
 
UDR format
The UDRs are generated in Comma Separated Values (CSV) format as defined in the traffic analysis rules.
 
Charging Record Generation
ECS provides for the generation of charging data files, which can be periodically retrieved from the system and used as input to a billing system for post-processing.
The results of traffic analyzer are used to generate Session usage data. The generated usage data are in a standard format, so that the impact on the existing billing system is minimal and at the same time, these records contain all the information required for billing based on the content.
The accounting records also contain the information to identify the user, with Dynamic address assignment and information to obtain the URL for HTTP content request or a file-name or path from FTP request, the type of service from the first packet of the connection, and transaction termination information so that the billing system can decide transaction success or failure.
Charging records support details of the termination, such as which end initiated the termination, termination type, for example RST, FIN, etc. And, in case of HTTP 1.1, whether or not the connection is still open.
ECS supports pipelining of up to 32 HTTP requests on the same TCP connection. Pipeline overflow requests are not analyzed. Such overflow requests are treated as http-error. The billing system, based on this information, decides to charge or not charge, or refund the subscriber accordingly.
To cover the requirements of standard solutions and at the same time, provide flexible and detailed information on service usage, ECS provides following type of usage records:
 
 
EDR/UDR/FDR (xDR) Storage
The system allocates 512 MB of memory on the packet processing card’s RAM to store generated charging detail record files (xDRs). The generated xDRs are stored in CSV format in the /records directory on the packet processing card RAM. As this temporary storage space (size configurable) reaches its limits, the system deletes older xDRs to make room for new xDRs. Setting gzip file compression extends the storage capacity approximately 10:1.
Because of the volatile nature of the memory, xDRs can be lost due to overwriting, deletion, or unforeseen events such as power or network failure or unplanned chassis switchover. To avoid loosing charging and network analysis information, configure the CDR subsystem in conjunction with the ESS to offload the xDRs for storage and analysis. Or, configure the system to push records to the ESS.
 
Hard Disk Support on SMC Card
In the ASR 5000, a hard disk enables additional storage capability. When storing CDR files on the SMC hard disk, first they are stored on RAMFS before they are moved to the hard disk, then they can be off-loaded via FTP or SFTP to an external server (such as the L-ESS or the GSS) or billing system.
When using the hard disk for EDR/UDR storage, EDR/UDR files are transferred from RAMFS on the PSC card to the hard disk on the SMC card. The hard disk may also be used to store any data that needs to be backed up.
The secondary SMC card also contains a hard disk which serves as a redundant, and becomes active during an SMC failover. The hard disk on the secondary is mirrored to the hard disk on the primary in order to avoid any data loss. Basically, the drives are raid-1 redundant.
 
Charging Methods and Interfaces
 
Prepaid Credit Control
Prepaid billing operates on a per content-type basis. Individual content-types are marked for prepaid treatment. A match on a traffic analysis rule that has a prepaid-type content triggers prepaid charging management.
 
In prepaid charging, ECS performs the metering function. Credits are deducted in real time from an account balance or quota. A fixed quota is reserved from the account balance and given to the system by a prepaid rating and charging server, which interfaces with an external billing system platform. The system deducts volume from the quota according to the traffic analysis rules. When the subscriber’s quota gets to the threshold level specified by the prepaid rating and charging server, system sends a new access request message to the server and server updates the subscriber's quota. The charging server is also updated at the end of the call.
ECS supports the following credit control applications for prepaid charging:
 
RADIUS Credit Control Application: RADIUS is used as the interface between ECS and the prepaid charging server. The RADIUS Prepaid feature of ECS is separate to the system-level Prepaid Billing Support and that is covered under a different license key.
Diameter Credit Control Application: The Diameter Credit Control Application (DCCA) is used to implement real-time credit control for a variety of services, such as networks access, messaging services, and download services.
In addition to being a general solution for real-time cost and credit control, DCCA includes the following features:
 
Real-time Rate Service Information: DCCA can verify when end subscribers' accounts are exhausted or expired; or deny additional chargeable events.
Support for Multiple Services: DCCA supports the usage of multiple services within one subscriber session. Multiple service support includes:
 
Postpaid
In a postpaid environment, the subscribers pay after use of the service. AAA/RADIUS server is responsible for authorizing network nodes (GGSNs, PDSNs, or HAs) to grant access to the user, and the CDR system generates G-CDRs/eG-CDRs/EDRs/UDRs for billing information on pre-defined intervals of volume or per time.
 
Important: G-CDRs and eG-CDRs are only available in GGSN networks.
ECS also supports FBC and TBC methods for postpaid billing. For more information on FBC and TBC in ECS, see the Enhanced Services in ECS section.
 
Prepaid Billing in ECS
In a prepaid environment, the subscribers pay for service prior to use. While the subscriber is using the service, credit is deducted from subscriber’s account until it is exhausted or call ends. The prepaid charging server is responsible for authorizing network nodes (PDSNs and HAs, or GGSNs) to grant access to the user, as well as grant quotas for either time connected or volume used. It is up to the network node to track the quota use, and when these use quotas run low, the network node sends a request to the prepaid server for more quota.
 
If the user has not used up the purchased credit, the server grants quota and if no credit is available to the subscriber the call will be disconnected. ECS and DCCA manage this functionality by providing the ability to set up quotas for different services.
Prepaid quota in ECS is implemented using RADIUS and DCCA as shown in the following figure.
 
How ECS Prepaid Billing Works
The following figure illustrates a typical prepaid billing environment with system running with ECS.
 
Prepaid Billing Scenario with ECS
 
Credit Control Application (CCA) in ECS
This section describes the credit control application that is used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, download services, etc. It provides a general solution to the real-time cost and credit control.
CCA with RADIUS or Diameter interface uses a mechanism to allow the user to be informed of the charges to be levied for a requested service. In addition, there are services such as gaming and advertising that may debit from a user account.
 
How Credit Control Application (CCA) Works for Prepaid Billing
The following figure and steps describe how CCA works with in a GPRS/UMTS or CDMA-2000 network for prepaid billing.
 
Prepaid Charging in GPRS/UMTS/CDMA-2000 Networks
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Important: External Storage System (ESS) is an optional and separately licensed feature which can be used with or without a billing/mediation system. For more information on the ESS, see the External Storage System section.
 
Postpaid Billing in ECS
This section describes the postpaid billing that is used to implement off-line billing processing for a variety of end user services.
 
The following figure shows a typical deployment of ECS for postpaid billing system.
 
Postpaid Billing System Scenario with ECS
 
How ECS Postpaid Billing Works
 
ECS Postpaid Billing in GPRS/UMTS Networks
The following figure and steps describe how ECS works in a GPRS/UMTS network for postpaid billing.
 
Postpaid Billing with ECS in GPRS/UMTS Network
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
 
Postpaid Billing in CDMA-2000 Networks
The following figure and steps describe how ECS works within a CDMA-2000 network for postpaid billing.
 
Postpaid Billing with ECS in CDMA-2000 Network
 
External Storage System
The External Storage System (ESS) is a high availability, fault tolerant, redundant solution for short-term storage of files containing detail records (UDRs/EDRs/FDRs (xDRs)). To avoid loss of xDRs on the chassis due to overwriting, deletion, or unforeseen events such as power or network failure or unplanned chassis switchover, xDRs are off-loaded to ESS for storage and analysis to avoid loss of charging and network analysis information contained in the xDRs.
The xDR files can be pulled by the L-ESS from the chassis, or the chassis can push the xDR files to the L-ESS using SFTP protocol. In the Push mode, the L-ESS URL to which the CDR files need to be transferred to is specified. The configuration allows a primary and a secondary server to be configured. Configuring the secondary server is optional. Whenever a file transfer to the primary server fails for four consecutive times, the files will be transferred to the secondary server. The transfer will switch back to the original primary server when:
 
In the push transfer mode, the following can be configured:
 
The system running with ECS stores xDRs on an L-ESS, and the billing system collects the xDRs form the L-ESS and correlates them with the AAA accounting messages using 3GPP2-Correlation-IDs (for PDSN) or Charging IDs (for GGSN).
Important: For more information on the ESS, please refer to the ESS Installation and Administration Guide.
 
System Resource Allocation
ECS does not require manual resource allocation. The ECS subsystem automatically allocates the resources when ECS is enabled on the chassis. ECS must be enabled on the chassis before configuring services.
 
Redundancy Support in ECS
This section describes the redundancy support available in ECS to recover user sessions and charging records in the event of software/hardware failure.
 
Caution: Persistent data flows are NOT recoverable during session recovery.
Important: Redundancy is not available in the current version of the Cisco XT2 platform.
 
Intra-chassis Session Recovery Interoperability
Intra-chassis session recovery is coupled with SessMgr recovery procedures.
 
Intra-chassis session recovery support is achieved by mirroring the SessMgr and AAAMgr processes. The SessMgrs are paired one-to-one with the AAAMgrs. The SessMgr sends checkpointed session information to the AAAMgr. ECS recovery is accomplished using this checkpointed information.
Important: In order for session recovery to work there should be at least four packet processing cards, one standby and three active. Per active CPU with active SessMgrs, there is one standby SessMgr, and on the standby CPU, the same number of standby SessMgrs as the active SessMgrs in the active CPU.
There are two modes of session recovery, one from task failure and another on failure of CPU or packet processing card.
 
Recovery from Task Failure
When a SessMgr failure occurs, recovery is performed using the mirrored “standby-mode” SessMgr task running on the active packet processing card. The “standby-mode” task is renamed, made active, and is then populated using checkpointed session information from the AAAMgr task. A new “standby-mode” SessMgr is created.
 
Recovery from CPU or Packet Processing Card Failure
When a PSC, PSC2, or PPC hardware failure occurs, or when a planned packet processing card migration fails, the standby packet processing card is made active and the “standby-mode” SessMgr and AAAMgr tasks on the newly activated packet processing card perform session recovery.
 
Inter-chassis Session Recovery Interoperability
The system supports the simultaneous use of ECS and the Inter-chassis Session Recovery feature. (For more information on the Inter-chassis Session Recovery feature, refer to the System Administration and Configuration Guide.) When both features are enabled, ECS session information is regularly checkpointed from the active chassis to the standby as part of normal Service Redundancy Protocol processes.
 
In the event of a manual switchover, there is no loss of accounting information. All xDR data from the active chassis is moved to a customer-configured ESS before switching over to the standby. This data can be retrieved at a later time. Upon completion of the switchover, the ECS sessions are maintained and the “now-active” chassis recreates all of the session state information including the generation of new xDRs.
In the event of an unplanned switchover, all accounting data that has not been written to the external storage is lost. (Note that either the ESS can pull the xDR data from the chassis, or the chassis can push the xDR files to a configured ESS at user-configured intervals. For more information, see External Storage System section.) Upon completion of switchover, the ECS sessions are maintained and the “now-active” chassis recreates all of the session state information including the generation of new xDRs.
Regardless of the type of switchover that occurred, the names of the new xDR files will be different from those stored in the /records directory of packet processing card RAM on the “now-standby” chassis. Also, in addition to the file name, the content of many of the fields within the xDR files created by the “now-active” chassis will be different. ECS manages this impact with recovery mechanism. For more information on the differences and how to correlate the two files and other recovery information, see the Impact on xDR File Naming section.
 
Inter-chassis Session Recovery Architecture
 
Inter-chassis redundancy in ECS uses Flow Detail Records (FDRs) and UDRs to manage the switchover between Active-Standby system. xDRs are moved between redundant external storage server and Active-Standby systems.
 
Recovery from L-ESS Failure
External storage server is responsible for sending records (pulled/pushed from the chassis) to the billing system. A cluster of two L-ESSs is implemented to fulfill the requirements for L-ESS redundancy.
 
Impact on xDR File Naming
The xDR file name is limited to 256 characters with following syntax:
 
basename_ChargSvcName_ timestamp_SeqNumResetIndicator_FileSeqNumber
where:
 
basename: A global configurable text string that is unique per system that uniquely identifies the global location of the system running ECS.
ChargSvcName: A system context-based configurable text string that uniquely identifies a specific context-based charging service.
timestamp: Date and time at the instance of file creation. Date and time in the form of “MMDDYYYYHHmmSS” where HH is a 24-hour value from 00-23.
SeqNumResetIndicator: A one-byte counter used to discern the potential for duplicated FileSeqNumber with a range of 0 through 255, which is incremented by a value of 1 for the following conditions:
FileSeqNumber: Unique file sequence number for the file with 9 digit integer having range from 000000000 to 999999999. It is unique on each system.
With inter-chassis session recovery, only the first two fields in the xDR file names remain consistent between the active and standby chassis as these are parameters that are configured locally on the chassis. Per inter-chassis session recovery implementation requirements, the two chassis systems must be configured identically for all parameters not associated with physical connectivity to the distribution node.
The fields “timestamp”, “SeqNumResetIndicator”, and “FileSeqNumber” are all locally generated by the specific system through CDR subsystem, regardless of whether they are in an Inter-chassis Session Recovery arrangement or not.
 
As such, the “SeqNumResetIndicator” field is used to distinguish between xDR files which have the same “FileSeqNumber” as a previously generated xDR as a result of:
 
In any scenario where the “FileSeqNumber” is reset to 0, the value of the “SeqNumResetIndicator” field is incremented by 1.
 
 
Impact on xDR File Content
The following scenarios impact the xDR file content:
 
 
On system startup, xDR files are generated in accordance with the standard processes and formats. If the system fails at any time it results in an inter-chassis session recovery switchover from active to standby and the following occurs depending on the state of the call/flow records and xDR file at the time of failure:
Upon detection of a failure of the original active chassis, the standby chassis transits to the active state and begins serving the subscriber sessions that were being served by the now failed chassis. Any subsequent new subscriber session will be processed by this active chassis and will generate xDRs per the standard processes and procedures.
However, this transition impacts the xDRs for those subscribers that are in-progress at the time of the transition. For in progress subscribers, a subset of the xDR fields and their contents are carried over to the newly active chassis via the SRP link. These fields and their contents, which are carried over after an Inter-chassis Session Recovery switchover, are as follows:
All remaining fields are populated in accordance with the procedures associated with any new flow with the exceptions that, the field “First Packet Direction” is set to “Unknown” for all in-progress flows that were interrupted by the switchover and the field “FDR Reason” is marked as a PDSN Handoff and therefore is set to a value of “1” and corresponding actions are taken by the billing system to assure a proper and correct accounting of subscriber activities.

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883