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.
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.
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:
To enable VoLTE services in CPS following diameter configuration is required in Policy Builder:
See Diameter Configuration for information on configuring the diameter stack for Rx interface.
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:
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: 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): Defining a default service: See Basic Systems Configuration for more information on Domain configuration. |
While defining the service for VoLTE call, following service options can be used.
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.
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.
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.
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. |
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).
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.
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):
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 |
|
For VoLTE calls, CPS identifies a stale Gx session from the latest Gx session thus allowing CPS to load the latest Gx session and act accordingly. For this, the secondary key mapping stores the primary key in addition to the bucket ID and the site ID, that is, SecondaryKey = <BucketId>; <Site Id>; <Primary Key>.
To enable this feature, add the following parameter in the /etc/broadhop/qns.conf file:
-Dcache.config.version=1
After migration starts, QNS queries with the old format first. If secondary key mapping is not found with the old format, QNS queries with the new format. This leads to increase in query on cache ring during the data migration process. Due to this, there could be some performance impact during the migration process.
Primary keys are stored in the memcache. This increases storage on the memcache. By default, memcache has two GB memory limit. Once memory limit is reached, memcache automatically deletes old records to accommodate new records.
To accommodate more sessions, add more ringsets to distribute data among multiple ringsets.
In case no sessionmgr is available to add a ringset, memory limit can be increased on each sessionmgrs (default two GB) by changing the value of CACHESIZE in the /etc/sysconfig/memcached file on sessionmgr.
Key storage (memcache) size can be obtained using the following command on sessionmgr:
Available (in MBs) = Max Limit - Used (in MBs)
Upgrading CPS to use the new mapping format
To upgrade CPS to change the mapping to the new format, do the following:
Add the flag -Dcache.config.version=1 in /etc/broadhop/qns.conf file.
Copy the file to all VMs.
Restart the QNS service.
Repeat the above steps for all the sites.
Wait for all sites to come up.
Add the keys being used for the look up in Lookaside Keys Prefixes in in Policy Builder. See Adding an HA Cluster.
Run rebuildAllSkRings from QNS on one of the sites. This starts the data migration process and changes the mapping to the new format.
Once migration is complete, CPS uses the new format.
Restoring CPS to use the old mapping format
To restore CPS to use the old format, that is, disable the feature, do the following:
Clear scheduler and ring set in Admin DB. To do this:
Log into the administration database primary member.
Run the following commands in Mongo:
PRIMARY> use scheduler PRIMARY> db.tasks.remove({"type":"migrateCache"}); PRIMARY> use sharding PRIMARY> db.versions.update({"_id":"cache_config"},{$set:{"migrationStatus": "READY"}}); PRIMARY> db.cache_config.update({},{$unset:{migratingShards:1}},false,true); PRIMARY> db.config.update({},{$inc: {version:1}})
Run the following commands to verify there is no pending task:
PRIMARY> use scheduler PRIMARY> db.tasks.find({"type":"migrateCache"});
Set -Dcache.config.version=0 in /etc/broadhop/qns.conf. Copy the file to all VMs and restart the QNS service.
Repeat step 2 for all the sites.
Wait for all sites to come up.
Once all sites are up, run rebuildAllSkRings from QNS on one of the sites. This starts the data migration process and changes the mapping back to the old format.
You can keep checking the status of data migration by running skRingRebuildStatus.
Once migration is complete, CPS uses the old format.
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:
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 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).
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).
This section covers the following topics:
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
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.
Input |
Output
|
||
---|---|---|---|
AAR |
QoS Derivation Algorithm |
CRD Value |
|
MBR |
MBR |
MBR |
MBR |
|
GBR |
GBR |
GBR |
|
QCI |
QCI |
QCI |
|
ARP |
ARP |
ARP |
Input |
Output
|
||
---|---|---|---|
AAR |
QoS Derivation Algorithm |
CRD Value |
|
MBR |
MBR |
MBR |
MBR |
|
GBR |
GBR |
GBR |
|
QCI |
QCI |
QCI |
|
ARP |
ARP |
ARP |
Input |
Output |
||
---|---|---|---|
AAR |
QoS Derivation Algorithm |
CRD Value |
|
MBR |
MBR |
MBR |
min(MBR, MBR) |
|
GBR |
GBR |
min(GBR, GBR) |
|
QCI |
QCI |
min1 (QCI, QCI) |
|
ARP |
ARP |
min(PL, PL) and PV, PC based on chosen ARP |
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 for this feature requires configuring a CRD table in reference data section and 'RxSTGConfiguration' service configuration object in use case template.
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):
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.)
Output columns can also be defined for flow-information attributes (Flow Description and Flow Status). When a flow-information attribute is added to output, it requires defining two column entries one for action and the other for value. The value AVP name needs to be defined as per standard (3GPP TS 29.214) attribute AVP name whereas the action AVP name needs to be as mentioned below (for the corresponding flow-information attributes):
Similarly when mapping the output columns for CRD values of flow-information attributes use the exact attribute name (for example, “ Flow-Description” “ Flow-Status”.)
The following steps configure the CRD table for defining the Qos-Action details and Service options details (RxSTGConfiguration) for setting up the service.
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.
| ||
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. |
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 for defining ranged columns in RxSTGConfiguration:
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). MBR_UL_MIN (represents minimum value of MBR_UL in CRD table). 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:
|
Step 4 | Set Control
Center table values as follows:
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: |
Step 5 | Use the same AVP name in the List of Input AVP columns in the service configuration. |
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.
Use RxChargingParameterSTGConfig service configuration for setting the charging parameters for dedicated bearers created for IMS session (non-sponsored data case).
The following steps configure the STG for defining the charging parameters details and Service options details (RxChargingParameterSTGConfig) for setting up the service.
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.
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. |
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. |
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.)
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.
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).
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:
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.
CPS supports the creation and modification of default and dedicated bearers based on attributes received from MOG over the Rx prime interface.
Default bearer characteristics can be dynamically modified 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/MOG on the Rx prime interface. MOG initiates an Rx session with CPS as an AF to establish an Rx session by sending an AAR.
CPS parses the AAR to look for Dynamic-PCC-requested-QoS custom AVP that has the QoS values and additionally Priority and Intention values as well.
Intention values are Boost and Throttle.
In case of boost, CPS checks if the requested QoS values (either from the AAR message or derived values from the CRD table) are higher than existing. It then uplifts the bearer. If the requested QoS values are lower than existing, CPS does not uplift the bearer.
In case of throttle, CPS checks if the requested QoS values (either from the AAR message or derived values from the CRD table) are lower than existing. It then downgrades the bearer. If the requested values are higher than existing, CPS ignores the request.
CPS makes sure that if the uplift/downgrade of QoS attributes results in the default bearer having QCI and ARP same as any existing dedicated bearer then those rules and flows are installed on the default bearer associated with the existing dedicated bearer. That is, the dedicated bearer is removed when its QCI and ARP match the default bearer. With the removal of the dedicated bearer, all the flows and rules associated with this bearer are also removed.
QoS attributes are also derived from the CRD evaluation if the corresponding action defined in the RxSTGDefaultBearerConfiguration table for the QoS attributes is "Enforce". For the RxSTGDefaultBearerConfiguration service option parameters, see RxSTGDefaultBearerConfiguration.
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 Dynamic-PCC-requested-QoS AVP. CPS takes into consideration the 'Priority' 'Intent' 'MOG/AF requested QoS' and 'calculated QoS' for deriving the values for modified default bearer QoS.
AAR message having Media-Type AVP in Media-Component-Description AVP and Service-Info-Status AVP set to value FINAL_SERVICE_INFO(0) indicates the creation of a dedicated bearer over the Rx prime interface. If Service-Info-Status AVP is not present, the Dedicated-Bearer-QoS AVP can also result in creation of the dedicated bearer.
CPS also uses the Media-Type AVP value received in the AAR message to spawn the dedicated bearer.
QoS attributes are also derived from the CRD evaluation. The default action defined in the RxSTGConfiguration table for the QoS attributes is "Enforce".
In case of multi-value QCI Media-Type, the QCI value is obtained through the Dynamic-Requested-PCC-QoS AVP.
RxSTGDefaultBearerConfiguration service configuration is used for CRD evaluation of Default bearer QoS on receiving Rx AAR with Dynamic-PCC-Requested-QoS AVP. For more information on the RxSTGDefaultBearerConfiguration service option parameters, see RxSTGDefaultBearerConfiguration.
ModifyChargingRules service configuration is used to modify the default bearer charging rule AVPs based on TDF-Application Identifier, QoS-Class-Identifier, Sponsor-Identity, and Application-Service-Provider-Identity of already installed charging rule. For more information on the ModifyChargingRules service option parameters, see ModifyChargingRules.
In the ActionOnDefaultBearerQoSChange service configuration, if CollapseDedicatedBearer value is set to true then CPS makes sure that if the uplift or downgrade of QoS attributes results in the default bearer having QCI and ARP same as any existing dedicated bearer then it installs those rules and flows on the default bearer associated with the existing dedicated bearer. This is due to the fact that PCEF removes the dedicated bearer when QCI and ARP matches with the default bearer. With the removal of the dedicated bearer all the flows and rules associated with that bearers are removed. For more information on the ActionOnDefaultBearerQoSChange service option parameters, see ActionOnDefaultBearerQoSChange.
When there are multiple Rx sessions with dynamic PCC requests having same priority, CPS by default selects 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 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.
CPS supports 'Sponsored Connectivity Data' over Rx interface (IMS session). Sponsored data connectivity is supported by CPS based on service data flows associated with one or more PCC rules if the information about the sponsor the application service provider and optionally the threshold values are provided by the AF. When CPS receives the flow based usage thresholds from the AF then it uses the sponsor identity to generate a monitoring key.
Operator can override the Monitoring-Key generated by CPS by specifying the desired monitoring-keys in 'Sponsored Profile' table under Gx Client in 'Reference Data' section. Key to this table are the 'Sponsored-Id' and 'Application-Service-Provider-Identifier' AVP values received from the AF.
An example configuration is given below:
CPS also supports suppressing the 'Sponsor-Identity' AVP from PCC rules generated for Sponsored Data. This configuration is required when the PCEF does not support 'Sponsor-Identity' AVP. In this case if CPS requests a PCEF to create a dedicated bearer with Sponsor-Identity then the PCEF may reject the request because it does not support the Sponsor-Identity AVP. So by selecting the check box shown below CPS can exclude the Sponsor-Identity AVP from the PCC rule definition. (By default the value is unchecked).
See Gx Clients for more information on configuring Gx Client.
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:
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.
Parameter |
Description |
---|---|
Mps Eps Priority Enabled |
Field to invoke Priority EPS Service. |
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:
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. |
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.
Step 1 | Log into Policy Builder. |
Step 2 | Select the Reference Data tab. |
Step 3 | Select . |
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.
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. |
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.
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:
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.
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.
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.
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).