> 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

> • | Quality of Service in EV-DO Rev A

> • | EV-DO Rev A Call Setup

> • | EV-DO Rev A Important Commands

> • | RADIUS Accounting for EV-DO Rev A

> • | EV-DO Rev A with ITC Support

> 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:

> • | CDMA2000 Wireless IP Network Standard: Introduction, X.P0011-001-D v 0.5

> • | CDMA2000 Wireless IP Network Standards: Quality of Service and Header Reduction, X.P0011-004-D v 0.5

> • | CDMA2000 Wireless IP Network Standards: Accounting Services and 3GPP2 RADIUS VSAs, X.P0011-005-D v 0.5

> • | Interoperability Specification (IOS) for CDMA2000 Access Network Interfaces - Part 7 (A10 and A11 Interfaces), A.S0017-C v0.4, IOS v5.0, June 2004

> • | Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Radio Access Network Interfaces with Session Control in the Packet Control Function, V&V Version, A.S0009 v0.3, May 2005

> • | Perkins, IPv4 Mobility, RFC 3344, August 2002

> • | Braden, R.,et al, Resource ReSerVation Protocol (RSVP) -- Version 1, RFC 2205, September 1997, Proposed Standard.

> 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

> • | Forward Traffic Processing

> 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:

> • | Source and destination ports

> • | Source and destination addresses

> • | Protocol

> • | Type of service (TOS in IPv4)

> 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

> <X-Refs (online)>step <$paranum> | Description
> 1 | Main service connection is setup. Here, the PDSN receives an A11 RRQ indicating that this is a request to setup the main service connection for a Rev A call. For main A10s, the A11 RRQ always includes an SR_ID of 1, a forward traffic flow ID of 255, and a reverse traffic flow ID of 255.
> 2 | The PDSN sends an Access Request message to the AAA to authenticate the subscriber and to retrieve the subscriber’s QoS profile. (If no authentication is required, the PDSN uses the QoS profile from the default subscriber template.)
> 3 | The AAA sends the subscriber’s profile that includes the QoS profile to the PDSN.
> 4 | The PDSN stores the QoS attributes from the subscribers profile and sends a copy to the RAN via A11 Session Update message The RAN also stores the QoS attributes.
> 5 | The AT sends an IP flow reservation message to the RAN that includes the requested levels of QoS for each data flow.
> 6 | The RAN determines if the subscriber is authorized using the QoS attributes it stored from step 4. If the subscriber is authorized, the RAN sends a QoS Granted message to the AT. Otherwise, the RAN denies the QoS requested by the RAN.
> 7 | The AT sends the RAN an Acknowledgment.
> 8 | The RAN sends an A11 RRQ to the PDSN that includes SR_IDs for the auxiliary A10 connections and the QoS granted the MS.
> 9 | The PDSN verifies the QoS parameters granted to the MS using the attributes it stores in step 4 and returns an A11 RRP.
> 10 | The AT sends the TFTs—which identify the different flows in both the forward and reverse directions—to the PDSN via modified RSVP Reservation message. (RSVP formats the TFTs for the PDSN.)
> 11 | The PDSN sends Reservation Confirm message to the AT and uses the packet filters within the TFTs to map flows to the auxiliary A10 connections. The PDSN also stores the TFTs for flow look up when mapping flows in the reverse direction and for flow-based accounting. During intra-PDSN handoff, PDSN will send the subscriber QoS Profile that it received in the Access-Accept during authentication to the new PCF. This includes the list of authorized profile IDs in addition to other QoS attributes, but this does not contain the requested/granted profile IDs. The PDSN may send the profile in the A11 RRP or generates an RP Session Update message and sends it to the PCF. The system assumes that the AT uses the same NAI, even if it initiates multiple simultaneous sessions.

> ‌
> 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:

> • | TFT validation failure—The MN sent a TFT for a flow/profile id that violates the configured policy for the flow/profile-id.

> • | Traffic Violation: The MN is using the wrong link flow to send reverse data.

> • | Operator triggered: The Operator triggered an update through the CLI.

> • | Traffic Policing: Traffic policing triggered an update.

> The following call flow describes a successful flow setup with QoS update from PDSN.
> Successful Flow Setup with QoS Update from PDSN

> 1. | The Main A11 registration setup includes the following actions:

> • | The High Rate Packet Data (HRPD) connection is established over the radio link between the MN and the PCF.

> • | The PCF recognizes that no A10 connection associated with the MN is available and selects a PDSN. The PCF sends an A11-Registration Request message to the PDSN. The PCF also includes the Main Service Option for HRPD (SO59) in the message to indicate to the PDSN that this is the main service connection. The PCF includes the Connection Setup Airlink record in this message. If the main connection is active, and the PCF has received enough information about the flow, the PCF also includes the Active-Start airlink record for the main A10 connection.

> • | The A11-Registration Request message is validated and the PDSN accepts the connection by returning an A11-Registration Reply message and acceptance. The A10 connection binding information at the PDSN is updated to point to the PCF.

> • | The PDN sends a list of authorized profile ids specified in the Subscriber profile in A11-Session-Update message to the PCF. Then the PCF sends Session Update Ack back to the PDSN.

> 2. | The PCF sends an A11 Registration Request message indicating any auxiliary A10 (if it is required), the complete flow mapping information, requested profile ids from the mobile and the granted profile id for each flow.

> • | The PDSN sends an A11 Registration Reply message including all the auxiliary A10s it has for the session.

> • | The MN sends the TFT for the flow to be setup with the packet filters that identify the flow.

> • | The PDSN sends a confirmation back to the MN to accept the valid TFT.

> 3. | The PDSN updates the granted QoS for the flow because of a policy update trigger (QoS policy trigger, Operator trigger etc).

> • | The PCF sends a Session Update acknowledge message indicating that it accepted the profile id change.

> • | The PCF sends a new Registration Request message, with the new granted profile id and the flow mappings.

> 4. | The A11 Session updates with the new profile IDs is complete.

> 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

> Command | Mode | Description
> Configuration Commands
> data-over-signaling | PDSN Service Configuration | Enables or disables the data-over signaling feature for A10 packets.
> ip allowed-dscp | Subscriber Configuration | Sets the QoS Differentiated Services (DiffServ) marking that a subscriber session is allowed.
> ip qos-dscp | Subscriber Configuration | Configures quality of service options for the current subscriber using the differentiated services code point method.
> qos traffic-police | Subscriber Configuration | Sets the quality of service setting to the system default.
> Monitor Commands
> logging filter active facility sessmgr level debug | Exec | Can be used to verify policy is applied.
> monitor protocol A10, A11, User L3 | Exec | Can be used to verify signal and data between the PDSN and PCF, and between the PDSN and mobile.
> show rp full | Exec | Can be used to verify Session Update Send Reason.
> show rp full all | Exec | Can be used to verify GRE Key associated with A10 instance.
> show rsvp | Exec | Can be used to verify RSVP related statistics/counters.
> show subscribers | Exec | Can be used to verify summary rev-A flow and filter information.
> show subscribers all | Exec | Can be used to verify access technology.
> show subscribers full | Exec | Can be used to verify subscriber policy.

> ‌
> 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.

> Attribute | Description
> 3GPP2-Flow-Id | Displays the 3GPP2-Flow-Id.
> 3GPP2-Flow-Status | Displays the 3GPP2-Flow-Status.
> 3GPP2-Release-Indicator | Displays the 3GPP2-Release-Indicator.
> 3GPP2-Rev-Pdch-Rc | Displays the 3GPP2-Rev-Pdch-Rc.
> 3GPP2-Subnet | Displays the 3GPP2-Subnet.

> ‌
> 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.

> Attribute | Description
> ThreeGPP2-Rsvp-Sig-Inbound-count | Specifies the RSVP signaling octets sent by the Mobile Node.
> ThreeGPP2-Rsvp-Sig-In-Pkts | Specifies the Number of RSVP signaling packets sent by the Mobile Node.
> ThreeGPP2-Rsvp-Sig-Outbound-count | Specifies the RSVP signaling octets sent to the Mobile Node.
> ThreeGPP2-Rsvp-Sig-Out-Pkts | Specifies the Number of RSVP signaling packets sent to the Mobile Node.

> ‌
> 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

> Command | Mode | Description
> Configuration Commands
> match dst-ip-address | Class-Map Configuration Mode | Specifies a traffic classification rule based on the destination IP address of packets.
> match dst-ip-address | Class-Map Configuration Mode | Specifies a traffic classification rule based on the destination IP address of packets.
> match dst-port-range | Class-Map Configuration Mode | Specifies a traffic classification rule based on the range of destination ports of L4 packets.
> match ip-tos | Class-Map Configuration Mode | Specifies a traffic classification rule based on the IP Type of Service value in ToS field of packet.
> match packet-size | Class-Map Configuration Mode | Specifies a traffic classification rule based on the size of packet. Important: This is only applicable for static policies.
> match src-port-range | Class-Map Configuration Mode | Specifies a traffic classification rule based on the range of source ports of L4 packets.
> match srp-ip-address | Class-Map Configuration Mode | Specifies a traffic classification rule based on the source IP address of packets.
> class-map | Context Configuration Mode | Deletes/creates and enters the Class-Map configuration mode within the current destination context to configure the match rules for packet classification to flow-based traffic policing for a subscriber session flow.
> policy-map | Context Configuration Mode | Deletes/creates and enters the Policy-Map configuration mode within the current destination context to configure the flow-based traffic policing for a subscriber session flow.
> policy | Traffic Policy Group Configuration | Assigns the traffic policies, pre-configured in Policy-Map configuration mode, to a Policy Group for flow-based traffic policing to a subscriber session flow.
> qos encaps-header dscp-marking | Traffic Policy-Map Configuration | Specifies the DSCP code value marked in IP header of packet/flow to determine the QoS for traffic policing.
> qos traffic-police | Traffic Policy-Map Configuration | Enables and configures QoS policy for the flow-based traffic policing to subscriber session flow on per-flow basis.
> 3gpp2 data-over-signaling marking | Traffic Policy-Map Configuration | Indicates 3GPP2 related traffic flow for data over signaling channel.
> Monitor Commands
> logging filter active facility sessmgr level debug | Exec | Can be used to verify policy is applied, A10 is added, flow is added, tft is validated, etc.
> monitor protocol A10, A11, User L3 | Exec | Can be used to verify signal and data between the PDSN and PCF, and between the PDSN and mobile.
> show rp full | Exec | Can be used to verify Session Update Send Reason.
> show rp full all | Exec | Can be used to verify GRE Key associated with A10 instance.
> show rsvp | Exec | Can be used to verify RSVP related statistics/counters.
> show subscribers | Exec | Can be used to verify summary rev-A flow and filter information.
> show subscribers access-flows | Exec | Can be used to verify summary of flow-mapping, QoS profile, and flow-based policy information.
> show subscribers access-flows full | Exec | Can be used to verify details of flow-mapping.
> show subscribers all | Exec | Can be used to verify access technology.
> show subscribers full | Exec | Can be used to verify subscriber policy.
> show subscribers tft | Exec | Can be used to verify details of installed traffic flow template.

> ‌
> 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:

> • | Class-map Configuration Mode Commands

> • | Traffic Policy-map Configuration Mode Commands

> • | Traffic Policy-group Configuration Mode Commands

> • | PDSN Service Configuration Mode Commands

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