Rx Services

Overview

Cisco Policy Suite (CPS) for Mobile is a carrier-grade policy, charging, and subscriber data management solution. It helps service providers rapidly create and bring services to market, deliver a positive user experience, and optimize network resources. It also generates monetization opportunities across 3G, 4G, and LTE access networks as well as IP Multimedia Subsystem (IMS) service architectures.

CPS supports various carrier-based multi-media services by acting as a gateway between the IMS core and Packet core network. CPS PCRF supports 3GPP standard Rx interface and comply with related specifications (29.214, 29.213 and 29.212). With these capabilities CPS supports VoLTE, VoLTE emergency calls, Dynamic PCC, MPS, Sponsored Data, QoS enhancements, SRVCC, Access network information reporting and many more such functionalities.

This chapter covers information on various services and policies related to Rx interface mentioned above. It gives functional information, configuration details and troubleshooting steps for setting up Rx related services and features in CPS.

VoLTE

This section explains CPS policy management configuration for Voice over LTE (VoLTE). VoLTE requires a policy management solution to:

Establish and release the bearer for voice traffic on behalf of the IP multimedia system (IMS) domain.
Forward the bearer allocation status and subscriber location from the packet core to the IMS domain.
Forward charging information from the IMS domain to the evolved packet core.
Handle supplementary services, such as call forwarding and call holding, that are delivered in the IMS domain.

A normal VoLTE call includes:

Creating a Gx session with default bearer activation (for example, QCI=5 for SIP signaling).
UE IMS (SIP) registration.
P-CSCF (AF) initiates dedicated bearer requests to CPS (AAR with Media-Component-Description, Specific-Action, and so on.
Creating a Rx session and session binding at CPS (bind to Gx session).
PCRF authorizes QoS and dedicated bearer activation (for example, QCI=1 for VoLTE voice bearer, MBR, GBR, and so on).
QoS information is derived based on algorithm defined in section 6.3 of 3GPP 29.213 specifications.
QoS information is updated based on QoS policies or services configured in CPS (for example, Dynamic QoS).
PCEF reports bearer creation status and same is indicated to P-CSCF by CPS.

The following diagram shows the above steps with an example for dedicated bearer establishment in VoLTE call flow:

Policy Builder Configuration

Diameter Stack for Rx

To enable VoLTE services in CPS following diameter configuration is required in Policy Builder:

Local endpoints to bind and bring up the diameter server for Rx interface.
Entry in the 'Inbound Peers' for realms and peers that will interact with CPS over Rx interface.

See Diameter Configuration for information on configuring the diameter stack for Rx interface.

Service Configuration for VoLTE

Domain Configuration

A dedicated “IMS” APN may be used for VoLTE traffic. Typically, established during initial attach as default APN. In CPS, operator may define a separate domain to authorize VoLTE calls based on the APN (Called-Station-Id) received in the CCR-I message.

See Basic Systems Configuration for information on configuring a domain.

The following example shows a sample domain configuration:

Procedure

Step 1	Log into Policy Builder.
Step 2	Click the Services tab.
Step 3	Under Domains, click Summary and then create a child domain.
Step 4	Configure the domain by setting the required configuration for Authorization, Location and default service details as shown in example below. In this example the domain is configured for messages received with “IMS” APN (Called-Station-Id), it authorizes all user and attaches a default service (with name “IMS”) to the subscriber. Select Allow all Users for Authorization: Figure 2. General Domain Information Use this domain for calls received for “IMS” APN (APN is derived from 'Called-Station-Id' AVP received in CCR-I message and mapped to a LOGICAL_APN AVP): Figure 3. Domain Locations Defining a default service: Figure 4. Default Service See Basic Systems Configuration for more information on Domain configuration.

Service Configuration

While defining the service for VoLTE call, following service options can be used.

RxQoSInformation Service Configuration

This service configuration provides an option to define QoS values at service level to be used for dedicated bearer. It provides values to be used during the derivation of the Maximum Authorized Data Rates Authorized Guaranteed Data Rates and Maximum Authorized QoS Class Id in the PCRF whenever the “operator special policy exists” phrase is used in the algorithm (3GPP 29.213) description.

The service configuration provides only the QoS AVP output values. It does not have any key parameters. So the QoS values are applied based upon the service (code) enabled for the subscriber.

Table 1. RxQosInformation Service Configuration Parameters
Parameter	Description
Qci	QoS-Class-Identifier AVP value
Max Requested Bandwidth U L	Max-Requested-Bandwidth-UL AVP value
Max Requested Bandwidth D L	Max-Requested-Bandwidth-DL AVP value
Guaranteed Bitrate UL	Guaranteed-Bitrate-UL AVP value
Guaranteed Bitrate DL	Guaranteed-Bitrate-DL AVP value
ARP (Allocation Retention Priority)
Priority-Level	Priority-Level AVP value
Preemption-Capability	Pre-emption-Capability AVP value
Preemption-Vulnerability	Pre-emption-Vulnerability AVP value

For more information on these parameters, see Diameter Configuration.

RxAppQosInformation Service Configuration

This service configuration provides an option to define authorized QoS values at service level for a combination of 'Application-id' and 'Media-Type' value. It provides values to be used during the derivation of the Maximum Authorized Data Rates Authorized Guaranteed Data Rates and Maximum Authorized QoS Class Id in the PCRF whenever the “operator special policy exists” phrase is used in the algorithm (3GPP 29.213) description.

The service configuration uses the Af-Application-Id and Media-Type as keys (inputs) for selecting the QoS information AVP values. So the QoS values are selected based upon the Af-Application-Id Media-Type (received in the AAR message) and the service (code) enabled for the subscriber.

Table 2. RxAppQosInformation Service Configuration Parameters
Parameter	Description
Af Application Id (Input)	Specify the AF-Application-Id for which the QoS values should be applied.
Media Type (Input)	Specify the Media-Type for which the QoS values should be applied. (Integer value as per 3GPP specifications).
Qci	QoS-Class-Identifier AVP value
Max Requested Bandwidth U L	Max-Requested-Bandwidth-UL AVP value
Max Requested Bandwidth D L	Max-Requested-Bandwidth-DL AVP value
Guaranteed Bitrate UL	Guaranteed-Bitrate-UL AVP value
Guaranteed Bitrate DL	Guaranteed-Bitrate-DL AVP value
ARP (Allocation Retention Priority)
Priority-Level	Priority-Level AVP value
Preemption-Capability	Pre-emption-Capability AVP value
Preemption-Vulnerability	Pre-emption-Vulnerability AVP value

For more information on these parameters see Diameter Configuration.

Note

When both RxQosInformation and RxAppQosInformation service configuration are configured, then CPS derives QoS values based on RxAppQosInformation and if not found then it uses RxQosInformation values.

RxGaranteedBitRateOverride Service Configuration

This service configuration provides a configuration option for copying the Max Requested Bit-rate values into Guaranteed Bit-rate. This configuration is applicable when CPS is not able to derive Guaranteed Bitrate values based on the QoS derivation algorithm defined in 3GPP 29.213 specification. So if GBR is not derived and this service option is configured then CPS will copy the values derived for Max Requested Bitrates into Guranteed Bitrates (applicable for both UL and DL).

Table 3. RxGaranteedBitRateOverride Parameter
Parameter	Description
Set Guaranteed Bitrates from Max requested Bitrates	Flag that indicates whether to copy the MBR values into GBR values when GBR is not derived Default value is checked (true).

Note

In a VoLTE specific service Operator can also define basic Gx specific services configurations like DefaultBearerQos Event-Trigger and so on. For more information on these services configuration, see Gx/Sd Services.

The following steps configure the Service options details (RxAppQosInformation RxAppQosInformation) for setting up a sample VoLTE specific service.

Procedure

Step 1	Log into Policy Builder.
Step 2	Go to the Services tab.
Step 3	Under Use Case Templates, click Summary and then create a child Use Case Template.
Step 4	Add a name to the template, for example, `Rx_VoLTE`.
Step 5	Click Actions tab.
Step 6	Click Add in the Service Configuration pane and add “RxQosInfomration” service configurations listed under the 'rx' section. Similarly, operator can optionally add other service configurations like RxAppQosInformation, RxGuaranteedBitrateOverride, listed under 'rx' section as well as DefaultBearerQos, Event-Trigger, and so on. listed under 'gx' section.
Step 7	Click Services Options. The newly created template is available here.
Step 8	Create a child Service Option, for example, `volte`.
Step 9	Click OK. The newly created service options should have the service configuration objects that were added previously at the template level.
Step 10	Select the RxQoSInfomration service configuration and configure it as per your requirements. Figure 5. RxQoSInformation Service
Step 11	Select the RxAppQoSInfomration service configuration and configure it as per your requirements. Figure 6. RxAppQoSInformation Service
Step 12	Select the RxGuaranteedBitrateOverride service configuration and configure it as per your requirements. Figure 7. RxGuaranteedBitrateOverride Service
Step 13	Click Services and create a child service, for example, `volte_service`.
Step 14	Update the Code and Name as `volte_service`.
Step 15	Click Add and select the Service Option volte created earlier.

Service Configuration to Handle VoLTE Issues

Dedicated Bearer Creation Fails

In case VoLTE setup fails, that is, the dedicated bearer creation fails with some RAN/NAS cause code, CPS receives the rule failure report with a RAN/NAS cause code from PCEF. CPS can retry the dedicated bearer setup based on these RAN/NAS cause codes, so that the failure to create the dedicated bearer can be minimized.

Use the RxRanNasCauseRetry service option to handle this issue. For this, create the following list of RAN/NAS Search Table Groups (STGs):

Table 4. STG Name Reference Mapping
Stg Reference	Stg Name
Ran_Nas_Cause_Mapping_Table	Ran_Nas_Cause_Mapping
Rx_Parameters_Table	Rx_Parameters
Gx_Parameters_Table	Gx_Parameters
Sy_Parameters_Table	Sy_Parameters
Ran_Nas_Retry_Mapping_Table	Ran_Nas_Retry_Mapping

Note

Stg Reference is bound to the CRD table created by the user.
Stg Name is the corresponding CRD table name entered by the user in the RxRanNasCauseRetry service option. The STG name should be same as the Stg Name values in the above table.
For more information on how to create Search Table Groups, refer to RxSTGConfiguration Service Configuration.
CPS supports wildcarding for all the input values in the CRD tables. To use wildcarding, select the Best Match check box in the STG table. CPS supports wildcarding as per the standard Java regex patterns.

Procedure

Step 1

Create the Ran_Nas_Cause_Mapping CRD table as follows:

This table is used to find the RAN/NAS Cause group from Protocol type and Cause type.

Note

The Protocol Type and Cause Type are decoded from the RAN-NAS-Release-Cause AVP. For example, if the system receives 1234 as the RAN-NAS-Release-Cause AVP, 1 is decoded as the Protocol Type and 2 is decoded as the Cause Type. Cause value 34 can be ignored.

If multiple instances of RAN-NAS-Release-Cause AVP are received in a message, CPS runs a CRD query for each RAN/NAS cause code and gets the corresponding RAN/NAS cause group. The group with the highest priority is chosen.

Refer to the following table for its parameters.

Note

Avp Name column is the corresponding AVP name entered by the user in the RxRanNasCauseRetry service option. The AVP name should be same as the Avp Name values shown in the following table.

Table 5. Ran_Nas_Cause_Mapping CRD Table
Column Name	Avp Name	Binding/Retriever	Column Type
Ran_Nas_Protocol_Type	Ran-Nas-Protocol-Type	None	Input
Ran_Nas_Cause_Type	Ran-Nas-Cause-Type	None	Input
Group_Priority	Group-Priority	Not Applicable	Output
Ran_Nas_Cause_Group	Ran-Nas-Cause-Group	Not Applicable	Output

Configure the Ran_Nas_Cause_Mapping table in the RxRanNasCauseRetry service option as shown in the following figure:

Figure 8. RxRanNasCauseRetry Service Option for Ran_Nas_Cause_Mapping

Where,

Use Success Event Trigger in Rule Retry:

When set to true: CPS adds the SUCCESSFUL_RESOURCE_ALLOCATION event trigger in rule retry CCA message. This is added so that PCEF can notify the successful allocation of the rule. On receipt of successful resource event for the rule from PCEF, CPS sends success Rx RAR to AF with success RAN/NAS cause and all last known RAN/NAS cause AVPs received from PCEF for this rule.
When set to false: CPS does not use SUCCESSFUL_RESOURCE_ALLOCATION event trigger. So, on Ran Nas Retry timer expiry, CPS treats it as successful installation of the rule and sends success Rx RAR to AF with success RAN/NAS cause and all last known RAN/NAS cause AVPs received from PCEF for this rule.

Note

CPS sends success Rx RAR only if Rx-Message-On-Retry-Success is true in the CRD data.

Ran Nas Retry Timeout in Ms: The time (in milliseconds) after which the TimerExpired message is pushed into policy engine to evaluate rule retry as success or failure and also send RAR on Rx and Gx.

Note

If Use Success Event Trigger in Rule Retry is true, rule retry is treated as failure on this timer expiry.
If Use Success Event Trigger in Rule Retry is false, rule retry is treated as success on this timer expiry.

Step 2

Create the Rx_Parameters CRD table as follows:

This table is used to configure Rx parameters to be used in RAN/NAS retry algorithm. Input is one or more of the following supported Rx Parameters and Output is Rx_Parameters_Group.

Refer to the following table for the list of currently supported input parameters on the Rx interface.

Note

Avp Name column is the corresponding AVP name entered by the user in the RxRanNasCauseRetry service option. The AVP name should be same as the Avp Name values shown in the following table.
Not all parameters are mandatory. Choose the parameters as per your requirement.

Table 6. Rx_Parameters CRD Table
Column Name	Avp Name	Binding/Retriever	Column Type
AF_Application_Identifier	AF-Application-Identifier	None	Input
Media_Type	Media-Type	None	Input
Bearer_Setup	Bearer-Setup	None	Input
Rx_Session_Number	Rx-Session-Number	None	Input
Sponsor_Identity	Sponsor-Identity	None	Input
Application_Service_ Provider_Identity	Application-Service- Provider-Identity	None	Input
Service_URN	Service-URN	None	Input
Rx_Request_Type	Rx-Request-Type	None	Input
Ran_Nas_Cause_Group	Ran-Nas-Cause-Group	None	Input
Rx_Parameters_Group	Rx-Parameters-Group	Not Applicable	Output

Configure the Rx Parameters table in the RxRanNasCauseRetry service option as shown in Figure 1.

Step 3

Create the Gx_Parameters CRD table as follows:

This table is optional and is used to configure Gx parameters to be used in RAN/NAS retry algorithm. Inputs are one or more of the following supported GxParameters and Output is Gx_Parameters_Group.

Refer to the following table for the list of currently supported input parameters on the Gx interface.

Note

Avp Name column is the corresponding AVP name entered by the user in the RxRanNasCauseRetry service option. The AVP name should be same as the Avp Name values shown in the following table.

Table 7. Gx_Parameters CRD Table
Column Name	Avp Name	Binding/Retriever	Column Type
IMSI	IMSI	Session MSISDN	Input
MSISDN	MSISDN	Session IMSI	Input
Called_Station_Id	Called-Station-Id	Gx APN	Input
3GPP_SGSN_MCC_MNC	3GPP-SGSN-MCC-MNC	Gx MCCMNC Location Based	Input
Location	Location	Gx User Location Information	Input
IP_CAN_Type	IP-CAN-Type	Gx IP CAN Type	Input
RAT_Type	RAT-Type	Gx RAT Type	Input
Online	Online	None	Input
Offline	Offline	None	Input
PCC_Rule_Status	PCC-Rule-Status	None	Input
Rule_Failure_Code	Rule-Failure-Code	None	Input
Gx_Parameters_Group	Gx-Parameters-Group	Not Applicable	Output

Configure the Gx Parameters table in the RxRanNasCauseRetry service option as shown in Figure 1.

Step 4

Create the Sy_Parameters CRD table as follows:

This table is optional and is used to configure Sy parameters to be used in RAN/NAS retry algorithm. Input is one or more of the following supported Sy Parameters and Output is Sy_Parameters_Group.

Refer to the following table for the list of currently supported input parameters on the Sy interface.

Note

Avp Name column is the corresponding AVP name entered by the user in the RxRanNasCauseRetry service option. The AVP name should be same as the Avp Name values shown in the following table.

Table 8. Sy_Parameters CRD Table
Column Name	Avp Name	Binding/Retriever	Column Type
Policy_Counter_Identifier	Policy-Counter-Identifier	None	Input
Policy_Counter_Status	Policy-Counter-Status	None	Input
Command_Code	Command-Code	None	Input
SL_Request_Type	SL-Request-Type	None	Input
Result_Code	Result-Code	None	Input
Sy_Parameters_Group	Sy-Parameters-Group	Not Applicable	Output
Group_Priority	Group-Priority	None	Output

Configure the Sy Parameters table in the RxRanNasCauseRetry service option as shown in Figure 1.

Step 5

Create the Ran_Nas_Retry_Mapping CRD table as follows:

This is the final table that uses the output values from the above tables.

Refer to the following table for its parameters.

Note

Avp Name column is the corresponding AVP name entered by the user in the RxRanNasCauseRetry service option. The AVP name should be same as the Avp Name values shown in the following table.

Table 9. Ran_Nas_Retry_Mapping CRD Table
Column Name	Avp Name	Binding/Retriever	Column Type
Gx_Parameters_Group	Gx-Parameters-Group	None	Input
Rx_Parameters_Group	Rx-Parameters-Group	None	Input
Sy_Parameters_Group	Sy-Parameters-Group	None	Input
Max_Retry_Attempt	Max-Retry-Attempt	Not Applicable	Output
Rx_Message_On_Retry_Success	Rx-Message-On-Retry-Success	Not Applicable	Output
Ran_Nas_Custom_Success_Code	Ran-Nas-Custom-Success-Code	Not Applicable	Output

Where,

Max-Retry-Attempt: Maximum retry attempts to be done before considering it as failure.
Rx_Message_On_Retry_Success: Decides whether to send Rx RAR on successful retry.
- If value configured as true: Sends Rx RAR on successful retry with all the RAN/NAS cause codes received so far from the PCEF.
- If value configured as false: Does not send Rx RAR on successful retry.
Ran-Nas-Custom-Success-Code: This is one of the spare values in the RAN-NAS-Cause protocol type field. Valid values are 6 to 15. So, to indicate that the Rx RAR is sent for a successful retry, PCRF encodes one RAN-NAS-Release-Cause AVP with this protocol type value. The cause type and cause value should be ignored by the receiver.

Configure the Ran_Nas_Retry_Mapping table in the RxRanNasCauseRetry service option as shown in the following figure:

Figure 9. RxRanNasCauseRetry Service Option for Ran_Nas_Retry_Mapping

Dynamic Rule Naming (Multiple Dedicated Bearer QoS)

CPS supports multiple dedicated QoS Bearers (video and audio) within a subscriber's IP-CAN session includes splitting up Gx based RAR messages to provides quality video calls.

When a AAR message is received through the Rx interface with Media-Component-Description a Gx RAR request is sent with the new dynamic PCC rules for initiating new dedicated bearers. Since CPS generates these rules dynamically it automatically generates the rule-name using the following syntax:

_<Rx-Linked-Session-Number>_<Media-Component-Number>_<Media-Sub-ComponentFlow-Number>_<Rule-Name>_<Media-Type>

The items in this name are:

Rx-Linked-Session-Number: An internal number that identifies an Rx-session bound to a Gx-session.
Media-Component-Number: Corresponding AVP value as received in Media-Component-Description Grouped AVP for an AAR message.
Media-Sub-ComponentFlow-Number: Corresponding AVP value as received in Media-Component-Description->Media-Sub-Component Grouped AVP for an AAR message.
Rule-Name: A partial name configured in Policy Builder (as derived using AF-Application-Identifier and Media-Type values from 'Custom dynamic rule name' table in Gx Client. Default value “AF”).

for example, “_1_1_1_SIP_AUDIO” “_2_3_1_SIP_VIDEO” and so on.

See Gx Clients for more information on configuring the table in Gx client.

QoS Selection

QoS on dynamic rule (dedicated bearer) created for rx session is derived based upon the algorithm mentioned in section 6.3 of 3GPP 29.213 specification. This algorithm specifies how QoS Class (QCI) Maximum Authorized Data Rates (MBR) Authorized Guaranteed Data Rates (GBR) and Allocation Retention Policy (ARP) are derived based on the media details (Media-Component-Description) send by the AF (IMS).

Table 10. QoS Selection Parameters
Phrase mentioned in Algorithm	Policy Builder section to refer
“as defined by operator specific algorithm”	“RxQosInformation” and “RxAppQosInformation” service configuration.
“AF-Application-Identifier AVP demands application specific data rate”	“Application Qos Policy” defined in Rx Profile
“Codec-Data AVP provides Codec information for a codec that is supported by a specific algorithm”	“Codec Qos Policy” defined in Rx Profile

(See Rx Profile for more information on configuration of Rx Profile).

Dynamic QoS

This section covers the following topics:

Programmatic CRD (QoS Action)
Logical Operator Support in Programmatic CRD tables for RxSTGConfiguration
Support of Charging Parameters for Dynamic Rules using CRD Tables
Charging Parameters for Sponsored Data

Programmatic CRD (QoS Action)

CPS supports the management of Dedicated Bearer QoS attribute values for Rx IMS application sessions by applying actions QoS-Bounding QoS-Mirroring and QoS-Enforced on Dedicated Bearer QoS calculated as per specification 29.213.

CPS will set the QoS attributes values on the dedicated bearer based on the following QoS actions

Enforce: This action for any QoS attribute will enforce the values from custom reference data (CRD) table.
Mirror: This action will copy the QoS attributes values requested by the AF (received in the AAR message).
Bound: This action will calculate the minimum value between the QoS defined in CRD table and AF requested values or values calculated as per QoS derivation algorithm (29.213).

The following table explains how CPS will derive dedicated bearer QoS-information attributes based on:

The value received in AAR message (AF requested QoS)
Value derived from QoS derivation algorithm defined in 29.213
QoS-Action (Mirror Enforce Bound) and their respective values configured in CRD table

The pattern of the attributes in output column indicates from which input column the value is derived.

QoS-Action Mirror:

Table 11. QoS-Action Mirror
Input			Output
AAR	QoS Derivation Algorithm	CRD Value	Output
MBR	MBR	MBR	MBR
	GBR	GBR	GBR
	QCI	QCI	QCI
	ARP	ARP	ARP

QoS-Action Enforce:

Table 12. QoS-Action Enforce
Input			Output
AAR	QoS Derivation Algorithm	CRD Value	Output
MBR	MBR	MBR	MBR
	GBR	GBR	GBR
	QCI	QCI	QCI
	ARP	ARP	ARP

QoS-Action Bound:

Table 13. QoS-Action Bound
Input			Output
AAR	QoS Derivation Algorithm	CRD Value	Output
MBR	MBR	MBR	min(MBR, MBR)
	GBR	GBR	min(GBR, GBR)
	QCI	QCI	min¹ (QCI, QCI)
	ARP	ARP	min(PL, PL) and PV, PC based on chosen ARP

¹ As per Bound definition, we still select min value, but min value for QCI translates to max QCI value.

In order to apply the various QoS actions Enforce, Mirror and Bounding CPS needs to provide a new Rx service configuration object which can be applied to subscriber. CPS also supports custom reference data (CRD) tables where for a combination of subscriber and session attributes can be used as an input to derive the output values. These lookup can be performed by using the Input attributes and values as a key and derive a result set of Output attribute and value which can be used to calculate various applicable QoS parameters.

Policy Builder Configuration

Policy builder configuration for this feature requires configuring a CRD table in reference data section and 'RxSTGConfiguration' service configuration object in use case template.

RxSTGConfiguration Service Configuration

Table 14. RxSTGConfiguration Service Configuration Parameters
Parameter	Description
Stg Name	Reference to the Search Table Group containing the CRD tables that defines the QoS Action for Rx specific dynamic rules (dedicated bearer).
List of Input Columns (List of ColumnAndAvpPair)	Define the mapping between the 'AVP Names' and the key 'Columns' defined in the selected STG. These AVPs will be the inputs while evaluating the CRD table in STG.
Avp Name	Name of the diameter AVP (received in Media Component Description AVP of the AAR message) which is to be used as input for CRD table evaluation. (for example, “Flow-Number” “Media-Component-Number” etc).
Column	Reference to the key column in STG corresponding to the specified AVP.
List of Output Columns (List of ColumnAndAvpPair)	Define the mapping between the AVP Names and the output columns defined in the STG selected. These mapping indicate how the output column's values are mapped to AVPs after the CRD is evaluated.
Avp Name	Name of the diameter AVP (attribute from Qos-Information) to which the value of the output column should be mapped to while setting the Qos-Information for the dedicated bearer on Gx. (for example, “Qos-Class-Identifier”) Similarly for Qos-Actions on the attribute the AVP Name specifies the qos-action for a specific Qos-Information attribute (for example, “Qci”). Refer the note below.
Column	Reference to the output column defined in the STG selected.

Note

The values of “AVP name” must be exact same as per specifications (for example, Media-Component-Number Flow-Number etc.) while defining input columns to RxSTGConfiguration.

Output columns can be defined for one or more of the QoS attributes. When a QoS attribute is added to output, it requires defining two column entries one for QoS action and one for QoS value. The QoS value AVP name needs to be defined as per standard (3GPP TS 29.214) QoS attribute AVP name whereas QoS action AVP name needs to be as mentioned below (for the corresponding QoS attribute):

Qci
Max Req Bandwidth U L
Max Req Bandwidth D L
Guaranteed Bit Rate U L
Guaranteed Bit Rate D L
Priority Level
Preemption Capability
Preemption Vulnerability

Similarly when mapping the output columns for CRD values of Qos-Information attribute use the exact QoS attribute name (for example, “Qos-Class-Identifier” “Max-Requested-Bandwidth-UL” etc.)

The following steps configure the CRD table for defining the Qos-Action details and Service options details (RxSTGConfiguration) for setting up the service.

Procedure

Step 1

Log into Policy Builder.

Step 2

Select the Reference Data tab.

Step 3

Click Custom Reference Data Tables and create a CRD table under Search Table Group as shown in example below. For more information on how to configure Search Table Groups, see Services.

The following example shows three key columns for the CRD table. 'Media-Component-Number' and 'Flow-Number' columns will be mapped to the respective AVPs by setting the respective AVP Names in service-option configuration. Whereas the additional 'RAT-Type' key column is bound to the Gx session attribute.

Step 4

Go to the Services tab.

Step 5

Under Use Case Templates, click Summary and then create a child Use Case Template.

Step 6

Add a name to the template, for example, Rx_CRD_QoS.

Step 7

Click Actions tab.

Step 8

Click Add in the Service Configuration pane and add RxSTGConfiguration service configurations listed under 'rx' section.

Step 9

Go to Services Options; the newly created template is available here.

Step 10

Create a child Service Option for example, qos_enhancement.

Step 11

Click OK. The newly created service options should have the service configuration objects which were added previously at the template level.

Step 12

Select the RxSTGConfiguration service configuration and configure it as per the following example:

Refer to the example configuration below that shows 'Media-Component-Number' and 'Flow-Number' Columns in CRD are bound to respective AVP names (received in 'Media-Component-Description' AVP received in AAR message). For output column pairs the sample configuration shows 'Qci' and 'Max Req Bandwidth U L' being mapped to the respective columns in CRD for QoS actions and 'Qos-Class-Identifier' and 'Max-Requested-Bandwidth-UL' columns are mapped to the respective AVPs for CRD values.

Note

To add multiple input columns select List of Input Column AVP Pairs (List) row and click Add Child to create a new ColumnAndAvpPair row to add the input column details. Follow same steps to add output columns in 'List of Output Column Avp Pairs'.

Step 13

Click Services and create a child service, for example, rx_qos_action.

Step 14

Update the Code and Name as rx_qos_action.

Step 15

Click Add and select the qos_enhancement service option created earlier.

Control Center Configuration

Setting up the CRD table in the STG

Procedure

Step 1

Log into Control Center to define the values for the parameters defined in Custom Reference Data tables.

Step 2

Select the Configuration tab.

Step 3

Under Reference Data, click Custom Reference Data Table to open a dialog box. Select a row and edit the values according to your requirements.

Note

Since QoS Action columns have fixed values (“Mirror”, “Bound”, “Enforce”), user can define these values in Valid Values section while defining the column for CRD table.

Logical Operator Support in Programmatic CRD tables for RxSTGConfiguration

CPS users can now configure the CRD table to check if the requested value is present within the range of values present in the CRD tables and fetch the matching records. CRD tables now support Maximum and Minimum columns for each AVP.

For example operator now can configure the CRD table for QoS derivation based on the range of the “Max-Requested-Bandwidth-UL” AVP value (received in AAR message). For this operator create two columns (for example, MBR_UL_Max and MBR_UL_Min) and bind them to the same attribute/AVP. CPS then uses the min and max to check the range.

Note This functionality is currently available for RxSTGConfiguration only.

Policy Builder Configuration

Policy Builder configuration for defining ranged columns in RxSTGConfiguration:

Procedure

Step 1	Refer to the steps mentioned in Programmatic CRD (QoS Action) for creating the CRD table and configuring the RxSTGConfiguration.
Step 2	For the input attribute whose range is to be checked, create two columns for Maximum and Minimum value. This example creates a CRD table that supports deriving Qci value based on the range of “Max-Requested-Bandwidth-UL” value received in AAR message. MBR_UL_MAX Column (represents maximum value of MBR_UL in CRD table). Figure 13. MBR_UL_MAX Input Column MBR_UL_MIN (represents minimum value of MBR_UL in CRD table). Figure 14. MBR_UL_MIN Input Column Make sure that Matching Operator is selected properly i.e for Maximum value column need to select 'gt' or 'gte' and for Minimum value column select 'lt' or 'lte' and QCI column is a result column need to specify that at result column section of STG table.
Step 3	In RxSTGconfiguration, map the corresponding input columns defined above with the same AVP name (Max-Requested-Bandwidth-UL) as shown below: Figure 15. RxSTGconfiguration Column Parameter
Step 4	Set Control Center table values as follows: Figure 16. Setting Control Center Table Values So with the above configuration, If CPS receives an Rx-AAR message with “Max-Requested-Bandwidth-UL” AVP having value as “4000” then the dynamic rule generated will have Qci value as '6' based on following evaluation: 2000 (MBR Min CRD value) < 4000 (Requested value) 8000 (MBR Max CRD value) > 4000 (Requested value) Fetch the record and give the Result Column value (QCI as 6).
Step 5	Use the same AVP name in the List of Input AVP columns in the service configuration.

Support of Charging Parameters for Dynamic Rules using CRD Tables

CPS supports configurations for setting up the charging parameters on the dedicated bearer created for IMS application sessions (Rx sessions). The charging parameters (like Rating-Group Service-Identifier Metering-Method etc.) can be derived based on certain parameters in the Media-Component-Description AVP received in AAR message (for example, AF-Application-Identifier Flow-Status etc) or any session or SPR attributes. CPS supports configuration of static tables as well as CRD tables to define the criteria for selecting the desired charging parameters on the dynamic PCC rule (dedicated bearer).

CPS will first evaluate the CRD table defined in 'RxChargingParameterSTGConfig' service configuration and if no parameters are derived then CPS will look into the static table defined in 'Dynamic Rule charging parameters' section under Rx-Profile. (See Diameter Configuration for more information.)

CPS also supports a separate configuration for deriving the charging parameters when dedicated bearer is created for sponsored data. CPS will first evaluate the CRD table defined in 'RxSponsoredDataChargingParam' service configuration and if no parameters are derived then CPS will look into the static table defined in 'Sponsored Data Charging Parameter' section under Rx-Profile.

Policy Builder Configuration

Use RxChargingParameterSTGConfig service configuration for setting the charging parameters for dedicated bearers created for IMS session (non-sponsored data case).

RxChargingParameterSTGConfig Service Configuration

The following steps configure the STG for defining the charging parameters details and Service options details (RxChargingParameterSTGConfig) for setting up the service.

Procedure

Step 1

Log into Policy Builder.

Step 2

Select the Reference Data tab.

Step 3

Click Custom Reference Data Tables and create a CRD table under Search Table Group as shown in the following figures. For more information on how to configure Search Table Groups, see Services.

The following figures show three key columns for the CRD. The Media-Type and Flow-Status columns will be mapped to the respective AVPs from AAR message (by setting the corresponding AVP Names in service-option configuration in Step 10). And an additional RAT_Type key column is used, which is bound to the Gx session attribute.

Step 4

Select the Services tab.

Step 5

Under Use Case Templates, click Summary and then create a child Use Case Template.

Step 6

Add a name to the template, for example, Rx_Doc.

Step 7

Click Actions tab.

Step 8

Click Add in the Service Configuration pane and add RxChargingParameterSTGConfig service configurations listed under 'rx' section.

Step 9

Go to Services Options; the newly created template is available here.

Step 10

Create a child Service Option for example, rx_charging.

Step 11

Click OK. The newly created service options should have the service configuration objects that were added previously at the template level.

Step 12

Select the RxChargingParameterSTGConfig service configuration and configure it as per your requirements.

Note

To add multiple input columns, select the List of Input Column AVP Pairs (List) row and click Add Child to create a new ColumnAndAvpPair row to add the input column details. Follow the same steps to add output columns in List of Output Column Avp Pairs.

Note

The values of “AVP name” must be same as per specifications (for example, Media-Component-Number Flow-Number etc.) while defining input columns to RxChargingParameterSTGConfig.

Whereas for output column AVP Pairs in RxChargingParameterSTGConfig while defining the charging parameter attribute use the exact AVP name for charging parameters in Charging-Rule-Definition as per specification. (for example, Rating-Group Service-Identifier etc.)

For parameter descriptions, refer to RxChargingParameterSTGConfiguration.

Step 13

Click Services and create a child service, for example, abc.

Step 14

Update the Code and Name as abc.

Step 15

Click Add and select the abc service option created earlier.

Control Center Configuration

Setting Up the CRD Table in the STG

Procedure

Step 1	Log into Control Center to define the values for the parameters defined in Custom Reference Data tables.
Step 2	Select the Configuration tab.
Step 3	Under Reference Data, click Custom Reference Data Table name to open a dialog box.
Step 4	Select a row and edit the values according to your requirements. A few columns have fixed values (For example, value for Flow-Status column is “ENABLED-UPLINK (0)”, “ENABLED-DOWNLINK (1)”, “ENABLED (2)”, and so on.) So, you can define these values in the Valid Values section while defining the column for the CRD table.

Charging Parameters for Sponsored Data

As explained in the previous section CPS supports defining CRD tables to set the charging parameters on dynamic rules (dedicated bearer) created for IMS session. User can define various inputs to the CRD table to define different evaluation criteria.

In case the dedicated bearer is created for a sponsored data access CPS supports a different service configuration and CRD tables to define the evaluation criteria for selecting charging parameters on dynamic rules. RxSponsoredDataChargingParam is the service configuration defined in CPS to configure the CRD details for setting charging parameters on dedicated bearer created for sponsored data. This service configuration supports defining Sponsor-Identity (provided in Sponsored-Connectivity-Data) as one of the input column in the CRD table created for charging parameters of sponsored-data.

CPS will first evaluate the CRD table defined in 'RxSponsoredDataChargingParam service configuration and if no parameters are derived then CPS will look into the static table defined in 'Sponsored Data charging parameters' section under Rx-Profile. (See Diameter Configuration for more information.)

Policy Builder Configuration

Refer to the policy-builder configuration in Logical Operator Support in Programmatic CRD tables for RxSTGConfiguration. Create an extra key column for Sponsor-Identity in the CRD table. Correspondingly, in the service configuration, add an extra input AVP mapping for Sponsor-Identity AVP and its CRD column.

SRVCC

Single Radio Voice Call Continuity (SRVCC) solution seamlessly maintains voice calls as mobile users move from LTE to non-LTE coverage areas. This solution transfers VoLTE calls in progress from LTE to legacy voice networks. Without SRVCC, a VoLTE call on a device moving out of LTE coverage will be dropped.

To support SRVCC solution, CPS support notifying the AF (IMS System) when dynamic rules (created for Rx) on Gx fails because of handover from packet switched (PS) to Circuit Switched (CS).

NPLI (Access Network)

Cisco Policy Suite (CPS) provides Access Network Information (Network Provided Location Information) (for example User Location User Timezone information and so on) Reporting over Gx and Rx Interfaces.

In this feature CPS supports ACCESS_NETWORK_INFO_REPORT Event-Trigger and specific-action on Gx and Rx interface respectively to provide the necessary Access Network Information.

When AF requests the PCRF for access network information the PCRF (CPS) subscribes the requested Access Network Information from the PCEF within the Required-Access-Info AVP which is included in the Charging-Rule-Definition AVP. When the Access Network Information is available the PCEF provides the required Access Network Information to the PCRF within the 3GPP-User-Location-Info AVP or 3GPP-MS-TimeZone AVP or both as requested by the PCRF.

If CPS receives STR with 'Required-Access-Info' AVP then the same will be send in 'Charging-Rule-Remove'. Only in this case STA message will be held till CPS receives CCR-U with access-network-info AVPs (location/timezone).

Note PCEF PCRF and the AF should be compliant with the NetLOC supported feature.

CPS will report NetLoc-Access-Support (0) AVP in AAA and STA message when it gets Required-Access-Info AVP but PCEF does not support NetLoc feature. CPS will report INDICATION_OF_ACCESS_NETWORK_INFO_REPORTING_FAILURE SpecificAction in RAR message when gateway reports NetLoc-Access-Support (0) in CCR-U.

The PCEF provides the following information during an ACCESS_NETWORK_INFO_REPORT event trigger within the Event-Trigger AVP:

3GPP-User-Location-Info AVP (If available)
User-Location-Info-Time AVP (If available)
3GPP-SGSN-MCC-MNC AVP (If the location information is not available) or 3GPP-MS-TimeZone AVP or both.

Note

The Gx Event-Trigger used in this feature is specific to 3GPP R11 specification. Make sure the CPS is not configured to use V9 Event-Triggers.

To enable NetLoc support:

NetLoc flag must be enabled on both Gx and Rx sessions.
For Gx CCR(I) and CCA(I) should have Supported-Features Group AVP with Feature-List and feature bit 10 enabled.
For Rx initial AAR should have Supported-Features Group AVP with Feature-List feature bit 5 enabled.

See Diameter Configuration for more information on configuring the parameters.

Dynamic PCC (MOG)

Dynamic PCC allows a user (subscriber) that is currently under rate limits to dynamic modify their default bearer characteristic to support higher bit rates in run time. This is an opt-in service and allows the user to request and update (boost/throttle) in QoS on demand.

To support this functionality CPS can boost/throttle the QoS values on Default Bearer based on a trigger from the AF/CSB (Cisco Service Bus) on the Rx prime interface. CSB shall initiate an Rx session with CPS as an AF and establish an Rx session by sending an AAR.

CPS shall parse the AAR to look for a custom AVP which is “Dynamic-PCC-request-QoS” that has the QoS values and additionally Priority and Intent values as well.

It is possible that there are multiple Rx (IMS) Sessions for a single Gx session and each Rx session may influence the QoS values by sending the above mentioned custom AVP. CPS shall take into consideration the 'Priority' 'Intent' 'CSB/AF requested QoS' and 'calculated QoS' for deriving the values for modified default bearer QoS.

Policy Builder Configuration

No Service configuration is required for this feature.

But, when there are multiple Rx sessions with dynamic PCC requests having same priority then CPS by default will select the QoS values from the BOOST request. CPS provides a configuration flag in 'Gx Client' for overriding the default behavior of 'BOOST' with 'THROTTLE'. So:

If the check box (Override Boost with Throttle for Similar Priority) is checked, then throttle request takes precedence over boost request.
If the check box is unchecked, then throttle takes precedence over boost.

See Diameter Configuration for more information.

VoLTE Emergency Calls

VoLTE Emergency Calls can be processed only if the Rx session is linked to a Gx session which has a default bearer established towards an emergency APN. See Rx Clients for more information on configuring VoLTE emergency details in Rx Client.

For an emergency call Service-URN is used instead of AF Application ID and thus can be configured using all options where AF-Application-ID is used. Refer to option Override AF App Id with URN for Emergency sessions in the parameters table under Rx Clients. The AF may include the Service-URN AVP in order to indicate that the new AF session relates to emergency traffic. If the CPS receives the Service-URN AVP indicating an emergency session then CPS can prioritizing service flows relating to the new AF session.

Multi-Media Priority Services

Cisco Policy Suite provides Enhanced Multi-Media Priority Services (eMPS) for priority subscribers. CPS also prioritizes VoLTE/IMS calls for priority subscribers. CPS provides the ability to determine priority subscribers and provide priority services. There are two types of MPS:

Always-on: For a user with always-on MPS subscription, priority treatment is provided for all PS sessions.
On-demand: On-demand MPS is applied when priority treatment is explicitly requested by user with specific access code (MPS-Identifier).

This feature is configured through:

Always On
- Gx Service Configuration
- Reference Data for Always-on MPS Priority
On Demand
- On-demand MPS-Identifier
- Obtaining Highest Priority Qci Using Max Function

Gx Service Configuration

EMPS Service Configuration

CPS provides a service configuration ('EMPS' under 'gx' service configuration) for defining the MPS EPS Priority MPS Priority Level and IMS Signaling Priority level. This is required for Always on MPS.

When a user configured with MPS subscription initiates a session the priority level from the subscription data QCI Preemption Capability and Preemption Vulnerability from MPS profile are used to set default bearer QoS. Also all preconfigured dynamic rules are updated to use the new priority level.

When the session is initiated from IMS APN the IMS Signaling Priority is used as priority level if configured under subscription data.

Table 15. EMPS Service Configuration Parameters
Parameter	Description
Mps Eps Priority Enabled	Field to invoke Priority EPS Service. 1 enable 0 disable
Mps Priority Level	Indicates the priority level (Integer range 1-15).
IMS Signaling Priority	IMS signaling priority level (Integer range 1-15).

The following are the steps to configure this service configuration:

Procedure

Step 1	Log into Policy Builder.
Step 2	Select the Services tab.
Step 3	Under Use Case Templates, click Summary and then create a child Use Case Template.
Step 4	Add a Name to the template, for example, `IMS_usecase`.
Step 5	Select Actions tab.
Step 6	Click Add in the Service Configuration pane and add EMPS service configurations listed under 'gx' section.
Step 7	Go to Services Options; the newly created template would be available here.
Step 8	Create a child Service Option for example, `eMPS`.
Step 9	Click OK. The newly created service options should have the service configuration objects which were added previously at the template level.
Step 10	Select the EMPS service configuration and configure it as per your requirements.

Reference Data for Always-on MPS Priority

In the Policy Builder's Reference Data, a new profile Mps Profiles is added under Diameter Defaults to support eMPS priority. The MPS Profile provides MPS attributes required for priority service provisioning. The priority level value from Service configuration takes precedence over MPS Profile value.

Procedure

Step 1	Log into Policy Builder.
Step 2	Select the Reference Data tab.
Step 3	Select Diameter Defaults > Mps Profiles.
Step 4	In the summary window, click Mps Profile to create an Mps Profile.
Step 5	To add an Ims Apn, click Add, enter the Ims Apn in the field provided and click OK. This field can accommodate several Ims Apn that are used to match with the incoming service request for priority service. The values that are received by the Default Bearer QoS are looked up for a suitable Ims Apn match. If the APN value of a Gx session request matches IMS APN, IMS signaling priority from EMPS service is used as priority level.
Step 6	Assign values for Always-on MPS attributes in the MPS QoS section. An example is given below. Figure 22. MPS Profile Configuration For information on the parameters mentioned above, see MPS Profile. On receiving a request, the Ims Apn is checked up for a match, if there is suitable match then the values assigned in the Mps Qos section CPS selects the IMS signaling priority from EMPS service.

On-demand MPS-Identifier

The section, Reference Data > Diameter Defaults > Rx Profiles has a new table to support Rx initiated sessions. When an Rx session is initiated with an MPS-Identifier, the incoming message is mapped with input parameters such as MPS Id and Media Type, and the session is processed further. MPS QoS Policy table is the newly added table to the Rx Profiles in the Policy Builder.

The incoming message is mapped with the input parameters, which are MPS Id and Media Type, if the parameters match the corresponding value from the other columns - Priority Level, Preemption Capability, Preemption Vulnerability and Qci, are provided to provide the necessary service. For more information, see Rx Profile.

Obtaining Highest Priority Qci Using Max Function

When an EPS subscription for a subscriber is configured to be always-on, and an Rx session is initiated with MPS-ID, the higher priority level and higher QCI is derived and applied to the default EPS. ARP of the Rx dynamic rule is derived from Reservation priority if present in the AAR, otherwise defaulted to the value in configuration.

The Max function uses the following precedence order to derive the QCI values:

2 > 1 > 4 > 3 > 5 > 6 > 7 > 8 > 9

For additional information refer to 3GPP spec 29.213 (R11).

When there are multiple Rx sessions, the default bearer and default EPS bearer QoS is updated with the highest value of QCI, ARP.

The highest value is derived from the Rx sessions and Default Bearer if subscribed to always-on MPS.
The highest value is derived from the Rx session if not subscribed to always-on MPS.

Rx session termination: When a Rx session terminates, and if it is the last Rx session to terminate, the default bearer and default EPS bearer QCI/ARP is reverted to:

Single Rx session with MPS: revert Default Bearer to normal or always-on Qci or ARP.
Multiple Rx sessions with different MPS: revert default bearer to highest Qci or ARP among the remaining Rx sessions.

There are two main scenarios that take place during an Rx Session:

On Demand without Always-on Configuration
On Demand with Always-on Configuration

On Demand Without Always-on Configuration

Default Bearer

When multiple Rx sessions are initiated with MPS-ID, the highest priority level and highest QCI is derived and applied to the default EPS.
If reservation priority is not present in AAR, the priority configured for the particular MPS-ID is used. In the Rx profile > MPS Qos Policy table, a blank value is defined in the Media Type column, which applies to the Default Bearer. If the configuration is missing, default reservation priority (0) is used.

The new Priority Level and Qci are applied to the Default Bearer QoS and also to the Gx pre-configured rules.

Dedicated Bearer

Priority Level of the Rx dynamic rule is derived from Reservation priority if present in the AAR from the media component description; otherwise the default value in the configuration is used. QCI of Rx dynamic rule is derived from the Rx profile configuration. Preemption Capability and Preemption Vulnerability are determined from Rx profile for each MPS-Id.

On Demand With Always-On Configuration

Default Bearer

When an Rx session request is received with an MPS-ID along with message level (AAR) reservation-priority:

The ARP priority level is derived from the highest value between reservation priority and always-on priority (or IMS priority if applicable).
The value of QCI is derived from the highest value between MPS-ID specific Qci and always-on Qci. When multiple Rx sessions are created with MPS-ID and message level (AAR) reservation priority.
The ARP Priority Level is derived from highest value between session level reservation-priority (among active sessions) and always-on priority (or IMS priority if applicable).
The value of Qci is derived from the highest value between MPS-ID specific Qci and always-on Qci.

In both cases, if reservation priority is not present in the AAR, the priority configured for each MPS-Id is used. In the Rx profile > MPS Qos Policy table, a blank value is defined for the Media Type column, which applies to the Default Bearer. If the configuration is missing, default reservation priority (0) is used.

The new Priority Level and Qci is applied to the Default Bearer QoS and also to the Gx pre-configured rules.

Dedicated Bearer

Priority Level of the Rx dynamic rules is derived from the highest value between always-on MPS and the reservation priority, if the reservation priority is defined in the AAR Media component description.

If the reservation priority is not present in Media-Component-Description, the value of reservation priority is derived from the highest value between always-on MPS and from the Rx Profile configuration (based on MPS-ID and Media Type).

Preemption Capability and Preemption Vulnerability are determined from Rx profile for each MPS-Id and Media Type. QCI value is derived from the higher value between MPS profile and Rx MPS profile (based on Media Type and MPS-ID).

CPS Mobile Configuration Guide, Release 10.1.0

Bias-Free Language

Results

Chapter: Rx Services

Rx Services

Overview

VoLTE

Policy Builder Configuration

Diameter Stack for Rx

Service Configuration for VoLTE

Domain Configuration

Procedure

Service Configuration

RxQoSInformation Service Configuration

RxAppQosInformation Service Configuration

RxGaranteedBitRateOverride Service Configuration

Procedure

Service Configuration to Handle VoLTE Issues

Dedicated Bearer Creation Fails

Procedure

Dynamic Rule Naming (Multiple Dedicated Bearer QoS)

QoS Selection

Dynamic QoS

Programmatic CRD (QoS Action)

QoS-Action Mirror:

QoS-Action Enforce:

QoS-Action Bound:

Policy Builder Configuration

RxSTGConfiguration Service Configuration

Procedure

Control Center Configuration

Setting up the CRD table in the STG

Procedure

Logical Operator Support in Programmatic CRD tables for RxSTGConfiguration

Policy Builder Configuration

Procedure

Support of Charging Parameters for Dynamic Rules using CRD Tables

Policy Builder Configuration

RxChargingParameterSTGConfig Service Configuration

Procedure

Control Center Configuration

Setting Up the CRD Table in the STG

Procedure

Charging Parameters for Sponsored Data

Policy Builder Configuration

SRVCC

NPLI (Access Network)

Dynamic PCC (MOG)

Policy Builder Configuration

VoLTE Emergency Calls

Sponsored Data

Multi-Media Priority Services

Gx Service Configuration

EMPS Service Configuration

Procedure

Reference Data for Always-on MPS Priority

Procedure

On-demand MPS-Identifier

Obtaining Highest Priority Qci Using Max Function

On Demand Without Always-on Configuration

Default Bearer

Dedicated Bearer

On Demand With Always-On Configuration

Default Bearer

Dedicated Bearer

Was this Document Helpful?

Contact Cisco