Policy-Based Management and EV-DO Rev A


Policy-Based Management and EV-DO Rev A
 
 
This chapter provides information on configuring an enhanced, or extended, service. The product administration guides provide examples and procedures for configuration of basic services on the system. 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.
Important: The EV-DO Rev A features described in this chapter are only available if you have purchased and installed a session use license EV-DO Rev A PDSN License on your system. If you have not previously purchased this enhanced feature, contact your sales representative for more information.
Important: If the EV-DO Rev A PDSN License is not available or if the number of Rev A sessions exceeds the license limits, the Rev A calls are downgraded to Rev 0 calls.
EV-DO Rev A is an enhanced version of CDMA2000 EV-DO that provides the foundation for next-generation, IP-based, broadband wireless voice and data networks. EV-DO Rev A is backward compatible and interoperable with EV-DO Rev 0 networks and devices, with continued support for both Simple IP and Mobile IP sessions.
EV-DO Rev A includes higher data rates (3.1 Mbps on the forward link and 1.8Mbps on the reverse link) and improved Quality of Service (QoS) support.
This chapter describes the following:
 
Policy-based Management Overview
Policy-based management provides a way to allocate network resources; primarily network bandwidth, Quality of Service (QoS), security, and accounting according to defined business policies. These policies can be either static or dynamic. In a static policy the traffic flow is predefined by exact rules. For dynamic policies, the flows are created dynamically by external signaling. The dynamic policies validate the flows and apply the necessary policy actions required for each flow.
In flow-based traffic policies, policy modules interact with the system through a set of well defined entry points, provide access to a stream of system events and permit the defined policies to implement access control decisions, provide QoS enforcement and accounting decisions, etc.
A policy is defined as
policy: condition = > action
 
condition: specifies the flow-parameters such as source-address, destination-address, source-port, destination-port, protocol, etc. for ingress and/or egress packets.
action: specifies a set of treatments for a flow/packet when condition matches. These actions are typically based on flow classification and QoS processing for individual flows and DSCP marking.
 
Supported Standards
The following standards were referenced for the system’s EV-DO Rev A implementation:
 
 
Quality of Service in EV-DO Rev A
The QoS feature in Rev A enables a Mobile Node (MN) to negotiate and setup QoS for the air interface with the RAN while using the PDSN for QoS authorization and classifying user traffic flows. Network entities including the PDSN, PCF, AAA server, RAN and the mobile are all involved in setting up the desired QoS parameters for the MN. QoS may be applied for both Simple IP and Mobile IP calls.
The QoS is created in a subscriber profile on the AAA server. When the subscriber is authenticated, the AAA server passes the subscriber’s QoS on to the PDSN, which then passes the information on to the PCF. The PCF determines whether or not to grant the subscriber the QoS.
The following graphic shows an EV-DO Rev A network.
 
EV-DO Rev A Network
The interface between the MN and the RAN can support multiple simultaneous connections of the same or different packet data service options. These connections are referred to as packet data flows or link flows.
The three main entities involved in the QoS procedures for Rev A are the MN, RAN and the PDSN. The PDSN authenticates the MN during call setup and obtains the QoS profile for the subscriber. The PDSN conveys the subscriber's QoS profile to the PCF using A11 messaging. The PDSN and RAN store the QoS profile attributes.
Important: The RAN can map multiple IP flows to a single A10 connection.
When the MN requests QoS parameter setup with the RAN, the RAN verifies the request using a stored QoS profile. If the subscriber is authorized for the requested QoS parameters, the RAN provides the MN with a granted QoS profile and also sends the granted QoS profile to the PDSN via A11 messaging. If QoS was granted, the PCF sets up new auxiliary A10 connections for carrying traffic corresponding to the granted QoS and maps the requested flows over the A10 connections. The PCF uses A11 messaging to signal new A10 connection creation and to convey the requested and granted QoS parameters and the mapping of flows to A10 connections.
Important: If the subscriber is not authorized, the RAN denies the requested QoS profile to the MN and downgrades the flow to best effort traffic.
The MN sends Traffic Flow Templates that identify different IP flows in both the forward and reverse directions to the PDSN. The PDSN stores the TFTs. For traffic towards the mobile network, the PDSN uses the TFTs to identify the traffic flows and to map the flows to different A10 connections and for flow-based accounting. For traffic from the mobile network, the PDSN looks up the flow for per-flow based accounting. The PDSN also tracks accounting per A10 connection in addition to a per-flow basis.
 
Flow Mapping
Flow mapping includes these basic areas:
 
 
Basic TFT processing
The MN may be assigned one IP address. This IP address is not associated with any particular A10 connection. The MN may send Traffic Flow Templates (TFTs) for flow mapping to the PDSN carried over RSVP reservation messages. The TFTs are used to map forward traffic to the main or auxiliary A10 connections and to indicate if a specific flow treatment (such as header compression) should be applied for the matching packets. The TFTs are also used by PDSN to associate packets from forward and reverse traffic to flows for flow-based accounting and QoS enforcement. Since the MN may be assigned multiple IP addresses, each TFT corresponds to a specific IP address.
The TFTs can contain:
 
After the main and auxiliary A10 connections are created, the MN sends TFTs to the PDSN via a reservation message (RSVP).
 
Forward Traffic Processing
When a packet arrives at the PDSN from the external IP network, the packet is matched against the set of packet filters stored at the PDSN. The packet is sent down the A10 connection that matches the flow id in the packet filter.
If flow treatment is specified for that matching packet filter, such as ROHC compression, the specified treatment is applied to the packets. Otherwise, the default treatment is applied. If no packet filters match the incoming packet, the PDSN forwards the packet over the main A10 connection.
 
EV-DO Rev A Call Setup
The following figure describes the setup procedures for Rev A calls. Note that Rev A supports both Simple IP and Mobile IP calls.
 
EV-DO Rev A Call Setup
EV-DO Rev A Call Setup Description
 
Call Flow for Updating QoS for Dynamic Flows
The PDSN and the PCF can perform QoS update procedures to modify the QoS that is granted for an IP flow. The QoS update procedure is applicable to dynamic flows only.
You can configure the system to ensure that the granted QoS is downgraded to best effort (i.e. class x to best effort but not class x to class x-1). The reservation for the downgraded flow is removed at the RNC and PCF and the user detail record for the flow is closed at the PDSN.
In a downgrade scenario, the PDSN downgrades the profile ID for a flow from the Profile ID that was originally granted by the RAN. The profile ID is downgraded to a lower precedence profile ID or to best effort.
Important: If the EV-DO Rev A PDSN License is not available or if the number of Rev A sessions exceeds the license limits, the Rev A calls are downgraded to Rev 0 calls. If the profile ID does not match, the flow will be downgraded to best effort.
In an update scenario, the updates may be triggered by one of the following:
 
The following call flow describes a successful flow setup with QoS update from PDSN.
 
Successful Flow Setup with QoS Update from PDSN
1.
2.
3.
4.
The PDSN accepts the Registration Request message, updates the flow mappings, and responds with an RRP.
 
EV-DO Rev A Important Commands
Important: If you are using EV-DO Rev A without Intelligent Traffic Control (ITC), you must define the type of traffic policing as dynamic. If you are using EV-DO Rev A with ITC, you can use commands to set flow-based policies using class-map, policy-map, and policy groups. Refer to EV-DO Rev A with ITC Support for an overview of Rev A and ITC. Refer to the Intelligent Traffic Control chapter or additional information on configuring flow-based traffic policies.
The commands listed in the following table are used to configure and monitor EV-DO Rev A commands. Detailed information, including description, syntax, and usage for each of these commands can be found in the Command Line Interface Reference.
EV-DO Rev A Commands
 
RADIUS Accounting for EV-DO Rev A
RADIUS accounting for EV-DO Rev A traffic can either be session-based or flow-based. By default the system is set to session-based accounting. In session-based accounting, only a single accounting message is generated for the subscriber session, not separate accounting messages for individual A10 connections or flows. When the system is set for flow-based accounting, separate messages are sent for each flow and A10 sessions. Flow-based accounting includes the following options:
 
all-flows: Generates separate RADIUS accounting messages per access flow. Separate accounting messages are not generated for data path connections. (For example, separate messages are not sent for the main A10 or auxiliary connections.)
auxiliary-flows: Generates RADIUS accounting records for the main data path connection and for access-flows for all auxiliary data connections. (For example, separate RADIUS accounting messages are generated for the main A10 session and for access-flows within auxiliary A10 connections. The main A10 session accounting does not include octets or other accounting information from the auxiliary flows.)
main-a10-only: Configures access-flow-based single accounting messages (for example only single start/interim/stop) are generated for the main A-10 flows only.
none: Separate RADIUS accounting messages are generated for all data path connections (for example, PDSN main or auxiliary A10 connections) but not for individual access-flows. This is essentially A10 connection-based accounting.
 
RADIUS Attributes
The RADIUS attributes listed in the following table are used to configure EV-DO Rev A accounting for subscribers configured on remote RADIUS servers. More information on these attributes can be found in the AAA Attribute Reference.
The RADIUS attributes listed in the following table are used to configure RSVP Signaling for subscribers configured on remote RADIUS servers. More information on these attributes can be found in the AAA Attribute Reference.
These attributes can be found in the StarentVSA and the StarentVSA1 dictionaries.
 
EV-DO Rev A with ITC Support
Important: The EV-DO Rev A features described in this section are only available if you have purchased and installed session use licenses EV-DO Rev A PDSN License and Intelligent Traffic Control License on your system. The Intelligent Traffic Control license enables policy related commands which allow DSCP marking, traffic policing, DOS Marking, etc. If you have not previously purchased these enhanced features, contact your sales representative for more information.
You can configure your system to support both EV-DO Rev A and Intelligent Traffic Controls (ITC). ITC uses flow-based traffic policing to configure and enforce bandwidth limitations per subscriber. Enabling EV-DO Rev A with ITC allows you to control the actual level of bandwidth that is allocated to individual subscriber sessions and the application flows within the sessions.
For more information on Intelligent Traffic Controls (ITC) and configuring flow-based traffic policing on your system, refer to the Flow-based Traffic Policing Configuration section in this manual.
 
Flow-based Traffic Policy
Flow-based traffic policies and traffic policing are configured on a per-subscriber basis for either locally configured subscribers on the system or subscriber profiles configured on a remote RADIUS server.
Flow-based traffic policy is configured with the following building blocks:
Class Maps: The basic building block of a flow-based traffic policing. Class maps are used to control over the packet classification.
Policy Maps: A more advanced building block for flow-based traffic policing. Policy maps manage admission control based on the Class Maps and the corresponding flow treatment based on QoS traffic policing or QoS DSCP marking.
Policy Group: This is a set of one or more Policy Maps applied to a subscriber. Policy groups also resolve conflict if a flow matches multiple policies.
Important: For more information on Intelligent Traffic Controls (ITC) and configuring flow-based traffic policies on your system, to the Flow-based Traffic Policing Configuration section in this manual.
 
ITC Important Commands
Important: If you are using EV-DO Rev A with ITC, you can use commands to set flow-based policies using class-map, policy-map and policy groups. Refer to EV-DO Rev A with ITC Support for an overview of Rev A and ITC. Refer to the Intelligent Traffic Control chapter for additional information on configuring flow-based traffic policies.
The commands listed in the following table are used to configure and monitor ITC. Detailed information, including description, syntax, and usage for each of these commands can be found in the Command Line Interface Reference.
ITC Commands
Important: This is only applicable for static policies.
 
DSCP Marking Commands
Policy CLI commands are used to configure the policy for the Differentiated Services Code Point (DSCP) marking. DSCP marking includes configurations to set the DSCP for the inner or outer packet or to copy the inner marking to the outer packet.
DSCP markings are applied to signaling and bearer packets destined for the Radio Network Controller (RNC) (in the forward direction) and to the Application Server (AS) in the reverse direction.
The Command Line Interface Reference includes several chapters with more specific information about commands needed to configure DSCP. Refer to the following chapters:
 

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