The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This procedure describes how to create a Gx service in which the PCRF mirrors the QoS received from the PCEF/Gateway. When the PCRF receives a Credit-Control-Request (Initial) message, it sends the same QoS parameters back to the PCEF in the Credit-Control-Answer (Initial) message.
The Diameter Gy reference point is located between the OCS and the PCEF. The CPS supports using the Gy reference point for usage monitoring of the on-board OCS known as the Multi-service Balance Manager (MsBM) against a PCEF.
CPS uses the Gy RatingGroup Service Configuration Object within the Use Case Templates to hold the configuration parameters for Gy. The following procedure describes how to set up a Gy RatingGroup that will be sent upon a CCR-i request from the PCEF. The Gy RatingGroup service option would then be added to a service along with a Gx rule or QoS.
For more information, see Gx Interface Configuration for details on how to create a valid Gx service.
The following procedure is based on the ASR5K acting as the PCEF supporting the Enhanced Charging Service (ECS) mechanism for Gy “Pull” Usage Monitoring. The RatingGroup configuration for Gy will work in a similar method with any supported PCEF using the Gy interface.
The Sy reference point is located between the Policy and Charging Rules Function (PCRF) and the Online Charging System (OCS). The Sy reference point enables the transfer of information relating to subscriber spending from OCS to PCRF and supports the following functions:
Since the Sy interface resides between PCRF and OCS in the HPLMN, roaming with home routed or visited access as well as non-roaming scenarios is supported in the same manner.
The following procedure describes how to subscribe to the OCS (Online charging system) counter status updates from the PRCF side by initiating a 'Spending Limit Request (SLR)' message:
Step 1 | Open the Policy Builder GUI, and select the Services tab. |
Step 2 | Create a Gx
service as described in
Gx Interface Configuration.
Now you are ready to create an Sy service as described in the following steps. |
Step 3 | In the left-hand pane, select . |
Step 4 | In the
Summary pane, click
Use Case
Template under
Create
Child, and then do the following:
|
Step 5 | In the left-hand
pane, select
.
The new Sy option is displayed at the bottom of the list of service options. |
Step 6 | Select
Sy in the
Service
Options list, and do the following:
|
Step 7 | In the left-hand pane, select . |
Step 8 | In the
Services Summary pane, click
Service under
Create
Child, and do the following:
|
Step 9 | Select The new Sy service is now available to all Policy Server (QNS) nodes for processing. . |
Step 10 | Verify that
the new Sy service is available for use by doing the following:
|
The Rx reference point is used to exchange application-level session information between the Policy and Charging Rules Function (PCRF) and the Application Function (AF). This information is part of the input used by the PCRF for the Policy and Charging Control (PCC) decisions.
The PCRF exchanges the PCC rules with the Policy and Charging Enforcement Function (PCEF) and QoS rules with the Bearer Binding and Event Reporting Function (BBERF).
The PCRF provides network control regarding the service data flow detection gating QoS and flow based charging (except credit management) towards the PCEF. The PCRF receives session and media related information from the AF and informs AF of traffic plane events.
When a new AF session is being established and media information for this AF session is available at the AF and the related media require PCC supervision the AF shall open an Rx Diameter session with the PCRF for the AF session using an AA-Request command unless an Rx session has already been established for the AF session.
The AF shall provide the full IP address of the UE using either Framed-IP-Address AVP or Framed-Ipv6-Prefix AVP and the corresponding Service Information within Media-Component-Description AVP(s). The AF shall indicate to the PCRF as part of the Media-Component-Description whether the media IP flow(s) should be enabled or disabled with the Flow-Status AVP.
The AF may include the AF-Application-Identifier AVP into the AA-Request in order to indicate the particular service that the AF session belongs to. This AVP can be provided at both AF session level and Media-Component-Description level. When provided at both levels the AF-Application Identifier provided within the Media-Component-Description AVP will have precedence.
Use Case:
The following procedure describes how to configure the Rx parameters that are necessary for the establishment of a dedicated bearer and calculating/deriving the QoS for the Dynamic Charging rule names that PCRF sends to the PCEF using a Gx RARmessage:
The Sd reference point is located between the Policy and Charging Rules Function (PCRF) and the Traffic Detection Function (TDF).
For the solicited application reporting the Sd reference point is used for:
For the unsolicited reporting the Sd reference point is used for:
The PCRF may provide ADC Rules to the TDF by using Sd interface.
Once the start or stop of the application's traffic matching one of the ADC Rules is detected if PCRF has previously subscribed to the APPLICATION_START/APPLICATION_STOP Event-Triggers unless a request to mute such a notification (Mute-Notification AVP) is part of the corresponding ADC Rule the TDF shall report the information regarding the detected application's traffic to the PCRF and apply the enforcement actions if defined within the corresponding ADC Rule.
Use-Case:
The following procedure describes how to initiate an Sd session from PCRF towards the TDF by sending a Predefined ADC Rule using a TDF-Session-Request (TSR) message to the TDF and getting a successful TDF-Session-Answer (TSA) message on the PCRF:
Step 1 | Open the Policy Builder GUI, and select the Services tab. |
Step 2 | Create a Gx
service as described in
Gx Interface Configuration.
Now you are ready to create an Sd service as described in the following steps. |
Step 3 | In the left-hand pane, select . |
Step 4 | In the
Summary pane, click
Use Case
Template under
Create
Child, and then do the following:
|
Step 5 | In the left-hand
pane, select
.
The new Sd option is displayed at the bottom of the list of service options. |
Step 6 | Select
Sd in the
Service
Options list, and do the following:
|
Step 7 | In the left-hand pane, select . |
Step 8 | In the
Services
Summary pane, click
Service under
Create
Child, and do the following:
|
Step 9 | Select The new Sd service is now available to all Policy Server (QNS) nodes for processing. . |
Step 10 | Select the Reference Data tab. |
Step 11 | In the left-hand pane, select . |
Step 12 | In the
Summary pane, click
Sd
Push Rules under
Create
Child.
The Sd Push Rules pane appears. In order to initiate connections toward the TDF on the Sd interface, the table shown in the following figure needs to be populated with the origin and remote Host/Realm configuration. The Sd service/template will send messages to the TDF based on the host/realm configuration defined here. |
Step 13 | Verify that
the new Sd service is available for use by doing the following:
|
CPS supports the ability to connect to the Home Subscriber Server (HSS) over the Sh interface to parse subscriber profile data in order to make policy decisions.
CPS queries the HSS on Gx session establishment and caches the subscriber data locally. CPS allows the operator to configure which attributes need to be extracted from the User-Data AVP and stored.
The connection to the HSS must be enabled by configuring it in the Outbound Peers section in the Diameter Stack configuration.
Note | When defining the Realm in the Realms table, enter the Processing Protocol as SH_TGPP. |
Sh interface connections in CPS are defined per domain and therefore are configured on the Domains screen in Policy Builder.
Note | The following steps represent the most common way to configure an Sh interface connection, but other configuration options are available. |
Step 1 | Follow the steps in Defining the General Attributes of the Domain to create a new domain for the Sh Interface. | ||
Step 2 | On the
General tab, set
Authorization to
Allow
all Users.
| ||
Step 3 | On the Provisioning tab, set Provisioning to <not set>. | ||
Step 4 | On the Advanced Rules tab, select the appropriate service in the Default Service field. The default service applies to all subscribers’ requests that hit the Sh domain. | ||
Step 5 | Continue with the instructions in Defining the Additional Profile Data of the Domain. |
Note | Enabling this feature may result in CPS system performance degradation. |
CPS can now receive and parse multiple values via Sh that use the same location in the data structure. These values are then resolved in conjunction with CRD tables to determine the service and appropriate AVPs to add to the session. This capability allows duplicate data structures to be processed and resolved rather than requiring unique data structures for all values, as was the case for CPS versions prior to 11.0.
The following example illustrates an incoming Sh response that contains multiple Entitlement and Custom AttributeName='4GPFO' values that are not unique. A maximum of five values from the incoming response will be used to determine a "bundled" result. The incoming values are processed against the CRD to compress them into a final result based on priorities.
<Sh-Data> <RepositoryData> <ServiceIndication>CamiantUserData</ServiceIndication> <SequenceNumber>0</SequenceNumber> <ServiceData><CamiantShUser xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:noNamespaceSchemaLocation='CamiantShUser.xsd'> <![CDATA[<Version>1.0</Version> <AccountId>274500345196</AccountId> <Entitlement>RTA</Entitlement> <Entitlement>RTB</Entitlement> <Entitlement>RTC</Entitlement> <Custom AttributeName='BillingPlanCode'>L03</Custom> <Custom AttributeName='4GPFO'>THR200k200k</Custom> <Custom AttributeName='4GPFO'>THR200k300k</Custom> <UserId Type='E164' Scope='Public'>2345557890</UserId> <UserId Type='NAI' Scope='Private'>0333444123456789@epc.mnc444.mcc333.3gpp.network.org</UserId> <EquipmentId Type='IMEISV' DeviceType='Phone'>35-209900-176148-23</EquipmentId>]]> </CamiantShUser> </ServiceData> </RepositoryData> </Sh-Data>
This procedure describes how to configure Policy Builder to assign multiple entitlements to a subscriber, which allows services to be used in a more targeted manner.
Step 1 | Log in to Policy Builder. |
Step 2 | Create a Search
Table Group and a corresponding Custom Reference Data Table as follows:
|
Step 3 | Configure a
bundle profile as follows:
|
Step 4 | Configure the Sh
Profile in a new domain or in an existing one:
|
For more information on LDAP/Ud interface configuration, refer to Domains.