QoS Management


QoS Management
 
 
This chapter describes the Quality of Service (QoS) management on ST16 and Cisco® ASR 5000 Chassis and explains how it is configured. 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, as described in the respective product Administration Guide, before using the procedures in this chapter.
 
This chapter describes the following:
 
Introduction
The QoS Traffic Policing functionality supported by the GGSN implements QoS for subscribers based on the configuration of the APN template used as described in Traffic Policing and Shaping in this guide. As a result, all subscriber PDP contexts using the APN receive the same QoS level. This could lead to unused or under-utilized bandwidth by some subscribers and thus reducing the amount of resources available to others.
 
Dynamic QoS Renegotiation
Dynamic QoS Renegotiation minimizes the risk of bandwidth mis-appropriation. This feature allows the GGSN to analyze application traffic, and trigger QoS renegotiation with the SGSN to optimize service performance.
 
In Dynamic QoS Renegotiation, the GGSN performs packet inspection of application traffic to detect the type of service being utilized and automatically renegotiates the QoS to the appropriate level with a maximum QoS level corresponding to the level granted by the HLR. QoS renegotiation is performed by sending an update PDP context request to the SGSN. This solution is optimal since the appropriate QoS level is always granted to the subscriber without any requirement on the handset or on the core network. The only prerequisite is QoS renegotiation support on the SGSN. In this model, over reservation of radio resources is avoided, while maintaining the appropriate bandwidth for subscribers with real requirements.
The ST16 and ASR 5000 supports L7 stateful analysis and QoS Renegotiation. Combining these functionalities results in Dynamic QoS Renegotiation. The system also generates CDRs (or real time charging information) that includes the current QoS information and the service accessed. This enables intelligent application-based charging of services, taking into account the granted QoS. It also enables rebates when it was not possible to provide the QoS level required by an application.
Important: For L7 traffic analysis ECSv2 license is required.
 
How Dynamic QoS Renegotiation Works
Implementation of Dynamic QoS Renegotiation involves the following:
 
 
Initial QoS
When the session is established, an initial level of QoS must be assigned to the subscriber. The GGSN may either grant the requested QoS, or grant a lower QoS level (minimum or intermediate level). The initial QoS remains in effect until the SGSN or GGSN requests a change. When Dynamic QoS Renegotiation is enabled, there are several conditions when the system would request a QoS change.
 
 
Service Detection
The Application analysis approach to service detection uses application level (L7) information. In the ST16 and ASR 5000, application analysis is stateful—keeping track of the application state.
 
Important: For L7 traffic analysis ECSv2 license is required.
 
Classification of Application Traffic
Application traffic can be classified into the following: Conversational, Streaming, Interactive 1, Interactive 2, Interactive 3, or Background. For more information refer to the Traffic Policing and Shaping chapter. Traffic class can be configured in the charging-action, but it does not take direction as a parameter. However, a rule matching only uplink or only downlink packets associated that with the charging-action can be configured.
For QoS renegotiation a way is needed to find out what kind of data packets are flowing through for a particular user to associate a given traffic class with the user's current usage pattern. It can be done through packet inspection as for a subscriber profile, Access Control List (ACL) does the inspection. Limits for each traffic class can be configured in the APN. The same infrastructure is reused to perform Dynamic QoS Renegotiation.
After classification of traffic, if required by subscriber profile, Dynamic QoS Renegotiation takes place.
 
L4 Packet Inspection
The advantages of L4 packet analysis is no or low impact on the system performance, and enables QoS adaptation with very limited impact on the system capacity. L4 packet inspection is fully supported by the system.
 
L7 Packet Inspection
The advantages of L7 packet analysis is higher impact on the system performance, and QoS adaptation with very limited impact on the system capacity. L7 packet inspection involves complete application layer analysis and copes with customized applications.
 
Dynamic QoS Renegotiation
Dynamic QoS Renegotiation minimizes the risk of bandwidth mis-appropriation. This feature allows the GGSN to analyze application traffic, and trigger QoS renegotiation with the SGSN to optimize service performance.
 
In Dynamic QoS Renegotiation, the GGSN performs packet inspection of application traffic to detect the type of service being utilized and automatically renegotiates the QoS to the appropriate level with a maximum QoS level corresponding to the level granted by the HLR. QoS renegotiation is performed by sending an update PDP context request to the SGSN. This solution is optimal since the appropriate QoS level is always granted to the subscriber without any requirement on the handset or on the core network. The only prerequisite is QoS renegotiation support on the SGSN. In this model, over reservation of radio resources is avoided, while maintaining the appropriate bandwidth for subscribers with real requirements.
The ST16 and ASR 5000 supports L7 stateful analysis and QoS Renegotiation. Combining these functionalities results in Dynamic QoS Renegotiation. The system also generates CDRs (or real time charging information) that includes the current QoS information and the service accessed. This enables intelligent application-based charging of services, taking into account the granted QoS. It also enables rebates when it was not possible to provide the QoS level required by an application.
Important: For L7 traffic analysis ECSv2 license is required.
 
QoS Renegotiation for a Subscriber QoS Profile
The following is the overall Dynamic QoS Renegotiation process.
 
1.
2.
As the subscriber starts using some applications, the traffic gets classified on the basis of type of data packets or traffic as mentioned in section Classification of Application Traffic and accordingly the corresponding bit in Traffic-class-bitfield get set.
3.
4.
As seen in the following figure, the QoS profile for the subscriber goes through three renegotiations to match the QoS profile of the (highest priority) application currently being used.
Dynamic QoS Renegotiation graph
When there is no traffic, traffic class drops to “Background”, and the corresponding QoS profile will negotiated as described above.
 
Network Controlled QoS (NCQoS)
 
Network-controlled QoS is the method by which the QoS for a PDP context (primary or secondary) is updated on the request of the GGSN through Network Requested Update PDP Context (NRUPC) message. It can also activate a new secondary PDP context on Network Requested Secondary PDP Context Activation (NRSPCA) message from the GGSN.
 
How Network Controlled QoS (NCQoS) Works
The GGSN activates or modifies a bearer in case of a service flow matching a statically provisioned Policy and Charging Control (PCC) rules. The network, based on QoS requirements of the application/service determines what bearers are needed and either modifies an existing bearer or activates a new one.
Statically provisioned PCC rules, called Network Requested Operation (NRO) rules, are configured as charging rules in Active Charging Service (ACS). As a part of charging action for such rules, QoS-needed and corresponding Traffic Flow Template (TFT) packet filter is configured. QoS-needed mainly consists of QoS Class Identifier (QCI) and data rates. Whereas, TFT mainly consists of uplink and downlink packet filter information.
Warning: This feature does not work in conjunction with IMS-Authorization service.
When a packet arrives, Active Charging Service (ACS) analyzes it and proceeds for rule matching based on the priority in the rulebase. If an NRO rule bound to the context on which the packet arrived matches, ACS applies the bandwidth limit and gating. If an NRO rule bound to some other context matches, ACS discards the packet.
If an unbound NRO rule matches, ACS finds a context with the same QCI as the NRO rule, where context’s Maximum Bit Rate (MBR) and matched rule’s MBR (context's MBR + matched rule's MBR) is less than the MBR for that QCI in the APN. If such a context is found, NRUPC for that context is triggered. If the request succeeds, the rule will be bound to that context.
Important: The packet that triggers the NRUPC request is discarded.
If no context satisfying the MBR limit is found, or if there is no context with the same QCI as the NRO rule, the system triggers NRSPCA. If the request succeeds, the rule will be bound to that context.
Important: The packet that triggers the NRSPCA request is discarded.
TFTs from the charging-action associated with the NRO rule are also sent as part of the NRUPC/NRSPCA request, and sent back as part of Create PDP Context response.
Finally, if a non-NRO rule matches, ACS proceeds with the normal processing of that packet. Non-NRO charging-actions can still do “flow action” or ITC (limit-for-flow-type and limit-for-bandwidth).
ACS also takes care of following:
Important: The packet that triggers the NRUPC/NRSPCA request is discarded.
 
Configuring Dynamic QoS Renegotiation
This section describes how to configure per-APN based Dynamic QoS Renegotiation.
Caution: For Dynamic QoS Renegotiation, two RADIUS attributes are required for remote subscriber configuration. For a particular subscriber, these attributes can be overridden without considering the timeout for Dynamic QoS Renegotiation and whether Dynamic QoS Renegotiation is enabled or not.
To configure Dynamic QoS Renegotiation:
Step 1
Step 2
Step 3
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Step 4
Monitor the operations as described in the Monitoring Dynamic QoS Renegotiation Operation section.
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
 
Configuring ACL for Dynamic QoS Renegotiation
Configuring an ACL and applying it to an APN template are required to specify permission and treatment levels for Dynamic QoS Renegotiation.
Use the following example to configure an ACL for Dynamic QoS Renegotiation:
configure
  context <context_name>
     ip access-list <acl_name>
        permit { tcp | udp } ........ treatment { background | conversational | interactive-1 | interactive-2 | interactive-3 | streaming }
        end
Notes:
<context_name> must be the name of the destination context in which you want to configure the ACL. The same context must be used for APN configuration.
 
Configuring Charging Action for Dynamic QoS Renegotiation
Use the following example to configure charging action parameters for Dynamic QoS Renegotiation support:
configure
  active-charging service <service_name>
     charging-action <charging_action_name> [ -noconfirm ]
        qos-renegotiate traffic-class { background | conversational | interactive <priority> | streaming }
        flow action discard [ downlink | uplink ]
           flow limit-for-bandwidth direction { downlink | uplink } peak-data-rate <bps> peak-burst-size <bytes> violate-action { discard | lower-ip-precedence } [ committed-data-rate <bps> committed-burst-size <bytes> [ exceed-action { discard | lower-ip-precedence } ] ]
           end
Notes:
 
Configuring Rulebase for Dynamic QoS Renegotiation
Use the following example to configure rulebase parameters for Dynamic QoS Renegotiation support:
configure
  active-charging service <service_name>
     rulebase <rulebase_name> [ -noconfirm ]
        qos-renegotiate timeout <timeout>
        end
 
Configuring APNs for Dynamic QoS Renegotiation
Use the following example to configure an APN template’s QoS profile in support of Dynamic QoS Renegotiation:
configure
  context <context_name>
     apn <apn_name>
        ip access-group <acl_name> [ in | out ]
        end
Notes:
<context_name> must be the name of the destination context in which you have already configured the ACL, and want to configure the APN template.
<acl_name> must be the name of the ACL that you have already configured in the context.
If in the ip access-group command of the APN Configuration Mode, the optional in or out keywords are not specified, the ACL will be applied to all packets, in and out.
 
Configuring Network Controlled QoS (NCQoS)
To configure NCQoS:
Step 1
Step 2
Step 3
Step 4
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Step 5
Monitor the operations as described in the Monitoring Dynamic QoS Renegotiation Operation section.
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
 
Configuring Packet Filter for NCQoS
Use the following example to configure packet filter parameters for NCQoS support:
configure
  active-charging service <service_name>
     packet-filter <filter_name> [ -noconfirm ]
        ip local-port { = <port_num> | range <start_port_num> to <end_port_num> }
        ip protocol { = <proto_num> | range <start_proto_num> to <end_proto_num> }
        ip remote-address { = { <ip_address> | <ip_address/mask> } | { range { <ip_address> | <ip_address/mask> } to { <ip_address> | <ip_address/mask> } }
        ip remote-port { = <port_num> | range <start_port_num> to <end_port_num> }
        direction { bi-directional | download | upload }
        priority <priority>
        end
 
Configuring Charging Action for NCQoS
Use the following example to configure charging action parameters for NCQoS support:
configure
  active-charging service <service_name>
     charging-action <charging_action_name> [ -noconfirm ]
        qos-class-identifier <identifier>
        flow action discard [ downlink | uplink ]
        tft packet-filter <filter_name>
        flow limit-for-bandwidth direction { downlink | uplink } peak-data-rate <bps> peak-burst-size <bytes> violate-action { discard | lower-ip-precedence }
        end
Notes:
A number of optional keywords and variable are available for the flow limit-for-bandwidth direction command. Refer to the Command Line Interface Reference for more information regarding this command.
 
Configuring APN for NCQoS
Use the following example to enable Bearer Control Mode (BCM) for NCQoS support:
configure
  context <context_name>
     apn <apn_name>
        bearer-control-mode [ mixed | ms-only | none ]
        end
Notes:
 
Monitoring Dynamic QoS Renegotiation Operation
Use the following steps to verify/monitor Dynamic QoS Renegotiation operations:
Step 1
 
show apn { all | name <apn_name> }
The output is a listing of APN parameter settings.
Step 2
 
show apn name <apn_name>
<apn_name> must be the name of the APN configured in the Configuring APNs for Dynamic QoS Renegotiation section.
The output of this command displays the APN’s configuration. Examine the output for the ip output access-group and ip input access-group fields. For more details refer to the Applying a Single ACL to Multiple Subscribers section in this guide.
Step 3
 
show ip access-list <acl_name>
The output is a concise listing of IP Access Control List parameter settings.
Step 4
 
show subscriber ggsn-only full
The output is a concise listing of subscribers’ settings.
Step 5
 
show active-charging sessions full all
Step 6
 
show apn statistics [ all | name <apn_name> ]
The output is a listing of APN statistics related to QoS Renegotiation.
 
Event IDs Pertaining to Dynamic QoS Renegotiation
The Session Manager facility provides several events that can be useful for diagnosing errors that could occur with implementation of Dynamic QoS Renegotiation feature.
The following table displays information pertaining to these events.
Event IDs in Session Manager Pertaining to Dynamic QoS Renegotiation
 
RADIUS Attributes
The RADIUS attributes listed in the following table are used to configure Dynamic QoS Renegotiation for subscribers configured on remote RADIUS servers. More information on these attributes can be found in the AAA Interface Administration and Reference.
RADIUS Attributes Required for Dynamic QoS Renegotiation Support
 

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