The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This segment describes the Quality of Service (QoS) management on Cisco® ASR 5500 chassis and explains how it is configured.
The product Administration Guides provide examples and procedures for configuration of basic services on the system. You should 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 described below.
The QoS Traffic Policing functionality supported by the GGSN implements QoS for subscribers based on the configuration of the APN template. 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 thus reducing the amount of resources available to others.
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 ASR 5500 supports L7 stateful analysis and QoS Renegotiation. These functions combine to become 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 an ECSv2 license is required. |
Implementation of Dynamic QoS Renegotiation involves the following:
Initial QoS
Service Detection
Classification of Application Traffic
Quality of Service Renegotiation
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.
Services detected that do not need high QoS: After a configurable time period of a subscriber having terminated services that require high QoS, the system could lower the QoS to a value more appropriate to the services actually being used.
Services detected that require higher QoS: As soon as a subscriber begins using a service that needs a high QoS, the system immediately attempts to raise the QoS through its service detection capability.
The Application analysis approach to service detection uses application level (L7) information. In the ASR 5500 chassis, application analysis is stateful—keeping track of the application state.
Important |
For L7 traffic analysis ECSv2 license is required. |
Application traffic can be classified into the following: Conversational, Streaming, Interactive 1, Interactive 2, Interactive 3, or Background. Traffic class can be configured in the charging-action, but it does not take direction as a parameter. However, you can configure a rule matching uplink-only or downlink-only packets and associate it with the charging-action.
QoS renegotiation requires knowing 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. This is done through packet inspection for a subscriber profile via an Access Control List (ACL). 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 and if required by subscriber profile, Dynamic QoS Renegotiation takes place.
L4 packet analysis has no or low impact on the system performance with very limited impact on system capacity. L4 packet inspection is fully supported by the system.
L7 packet analysis has a greater impact on system performance with very limited impact on the system capacity. L7 packet inspection involves complete application layer analysis and copes with customized applications.
The following is the overall Dynamic QoS Renegotiation process.
Dampening timer is started for the subscriber.
QoSI is assigned to the subscriber. This becomes the QoSC till a re-negotiation occurs, as shown in the figure below.
The traffic class bitfield is cleared.
Examine traffic-class-bitfield to determine the highest bit that is set. This gives the desired QoS Traffic Class (QoSD). The associated uplink/downlink peak-data-rate and guaranteed-data-rate values are taken from the configured parameters for this traffic class in the subscriber APN.
If QoSC matches QoSD, no QoS renegotiation is required. Otherwise, send an Update PDP Context Request to the SGSN with the QoSD values and QoS renegotiation starts.
Reset the dampening timer.
Clear the traffic-class-bitfield.
When a higher priority traffic is detected, QoS is renegotiated immediately without waiting for the dampening time to expire. For example, if the current traffic has a QoS of Interactive and the system detects streaming traffic, QoS is immediately upgraded to Streaming.
When lower priority traffic is detected, the system waits for the expiry of the dampening timer before lowering the QoS.
During "silence" or no-traffic, QoS renegotiation requests are not initiated.
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.
When there is no traffic, traffic class drops to "Background" and the corresponding QoS profile is negotiated as described above.
Network-controlled QoS is the method by which the system updates the QoS for a PDP context (primary or secondary) upon receipt of Network Requested Update PDP Context (NRUPC) messages from the GGSN. The system can also activate a new secondary PDP context upon receipt of a Network Requested Secondary PDP Context Activation (NRSPCA) message from the GGSN.
The GGSN activates or modifies a bearer whenever a service flow matches a statically provisioned Policy and Charging Control (PCC) rule. 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 the Active Charging Service (ACS). As a part of charging action for such rules, QoS-needed and corresponding Traffic Flow Template (TFT) packet filters are 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, the ACS analyzes it and performs 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 the 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 triggered 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 is bound to that context.
Important |
The packet that triggered 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 returned as part of the 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).
Before making an NRUPC/NRSPCA Request, ACS checks if there is any outstanding request for the same QCI for the same subscriber. If there is, it will not process the new request and discards the packet.
After a context is terminated, ACS unbinds all the rules bound to that context. Such a rule can later be bound to some other context when a packet matches that rule.
Important |
The packet that triggered the NRUPC/NRSPCA request is discarded. |
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 |
Configure an Access Control List (ACL), as described in the Configuring ACL for Dynamic QoS Renegotiation section. |
||
| Step 2 |
Configure an APN for Dynamic QoS Renegotiation as described in the Configuring APNs for Dynamic QoS Renegotiation section. |
||
| Step 3 |
Save your configuration as described in Verifying and Saving Your Configuration. |
||
| Step 4 |
Monitor the operations as described in the Monitoring Dynamic QoS Renegotiation Operation section.
|
Configuring an ACL and applying it to an APN template are required to specify permission and treatment levels 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:
configure
active-charging service <service_name>
charging-action <charging_action_name> -noconfirm
qos-renegotiate traffic-class streaming
flow action discard
flow limit-for-bandwidth direction downlink peak-data-rate <bps> peak-burst-size <bytes> violate-action lower-ip-precedence
end Notes:
A maximum of eight packet filters can be configured per charging action.
The flow limit-for-bandwidth command contains other option than the example shown here. See ACS Charging Action Configuration Mode Commands in the Command Line Interface Reference for more information on this command.
configure
active-charging service <service_name>
rulebase <rulebase_name> [ -noconfirm ]
qos-renegotiate timeout <timeout>
end 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:
To configure NCQoS:
| Step 1 |
Configure packet filter parameters as described in the Configuring Packet Filter for NCQoS section. |
||
| Step 2 |
Configure charging rules and actions as described in the Configuring Charging Action for NCQoS section. |
||
| Step 3 |
Configure APN template and enable bearer control mode for NCQoS as described in the Configuring APN for NCQoS section. |
||
| Step 4 |
Save your configuration as described in Verifying and Saving Your Configuration. |
||
| Step 5 |
Monitor the operations as described in the Monitoring Dynamic QoS Renegotiation Operation section.
|
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 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:
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:
Use the following steps to verify/monitor Dynamic QoS Renegotiation operations:
| Step 1 |
Verify that your APNs were configured properly by entering the following command: |
| Step 2 |
Verify that the ACLs have been properly applied by entering the following command: |
| Step 3 |
Verify that your ACL was configured properly by entering the following command: |
| Step 4 |
Monitor your QoS renegotiation status for a subscriber by running the show subscriber ggsn-only full command (Exec mode). |
| Step 5 |
For L7 based QoS Renegotiation, view how many time QoS renegotiations have happened for that session by running the show active-charging sessions full all command (Exec mode). |
| Step 6 |
View the statistics of APN related to QoS renegotiation parameters by entering the following command: |
The Session Manager facility sources event IDs that can be useful for diagnosing errors that could occur when implementing of Dynamic QoS Renegotiation feature.
| Event | Event ID | Type | Additional Information |
|---|---|---|---|
|
QoS Renegotiation timer started for subscriber |
10917 |
Info |
"Indicates that the Dynamic QoS Renegotiation timer was started for the subscriber" |
|
QoS Renegotiation timer stopped for subscriber |
10918 |
Info |
"Indicates that the Dynamic QoS Renegotiation timer was stopped for the subscriber" |
|
QoS Renegotiation timer expired for subscriber |
10919 |
Info |
"Indicates that the Dynamic QoS Renegotiation timer was expired for the subscriber" |
|
QoS Renegotiation message sent for subscriber |
10920 |
Info |
"Indicates that the Dynamic QoS Renegotiation message was sent for the subscriber" |
|
L4 classification done for subscriber traffic |
10921 |
Info |
"Indicates the kind of L4 classification that was done for the subscriber traffic." |
The RADIUS attributes listed in the following table are used to enable Dynamic QoS Renegotiation for subscribers configured on remote RADIUS servers.
For more information on these attributes, if you are using StarOS 12.3 or an earlier release, refer to the AAA and GTPP Interface Administration and Reference. If you are using StarOS 14.0 or a later release, refer to the AAA Interface Administration and Reference.
| Attribute | Description |
|---|---|
|
SN-Enable-QoS-Renegotiation (or SN1-Enable-QoS-Renegotiation) |
Enables the Dynamic QoS Renegotiation for specific profile application. This attribute displays "enable qos renegotiation". |
|
SN-QoS-Renegotiation-Timeout (or SN1-QoS-Renegotiation-Timeout) |
Timeout duration for dampening time for QoS renegotiation to specific profile application. This attribute displays "qos renegotiation timeout". |
Feedback