Summary Data

Revision History

This feature adds support for the Presence Reporting Area (PRA) functionality to comply with the 3GPP standards for Gy interface.

The Presence Reporting Area is an area defined within the 3GPP packet domain for reporting of UE presence within that area. This is required for policy control and in charging scenarios.

Currently, when the PRA information is received, P-GW forwards the Presence Reporting Area Information to the PCRF and this information is not being sent to OCS(Gy).

Following are the specific requirements to support specific Gy interface in P-GW:

1. Presence reporting status : Upon receiving Trigger-Type 73 in CCA-I, P-GW will send Presence-Reporting-Status in CCRU/T towards OCS whenever there is PRA status change reported through S-GW

2. Extended QoS parameters to be sent in CCR messages towards OCS as part of QoS-Information AVP

3. Enhanced-Diagnostics AVP in CCR-T: Report RAN-NAS-Release-Cause Only in CCR-T

4. Support for Multiple Subscription-ID-E.164 ,IMSI and NAI

1. The following procedure describes the PRA supporting for Gy interface and its associated behavior:

   During an IP-CAN session, the PCRF determines whether the reports for change of the UE presence in the PRA is required for an IP-CAN session. Then the PCRF determines based on the subscriber's profile configuration and the supported AVP features. The parameter CNO-ULI is set for the same. For the IP-CAN session reporting, the PCRF provides Presence-Reporting-Area-Information AVP, which contains the PRA identifier within the Presence-Reporting-Area-Identifier AVP to the PCEF. For a UE-dedicated PRA, the PCRF provides the list of elements consisting of the PRA within the Presence-Reporting-Area-Elements-List AVP to the PCEF. Presence-Reporting-Area-Elements-List is not currently supported. The PCRF subscribes to the CHANGE_OF_UE_PRESENCE_IN_PRESENCE_REPORTING_AREA_REPORT (48) event trigger at the PCEF at any time during the entire IP-CAN session to activate the reporting changes of the UE presence in the PRA.

   For the same IP-CAN session, the OCS can also determine if the UE presence requires any updates to OCS in Presence-Area-Information AVP. To support this, you must enable the 'trigger pra' config. OCS must send the Trigger-type CHANGE_OF_UE_PRESENCE_IN_PRESENCE_REPORTING_AREA (73) in Trigger AVP as part of CCA-I towards PGW. The OCS also sends the Presence-Reporting-Area-Identifier in CCA-I (the assumption is that it will same as the PRAID sent from PCRF). PRA reports are then sent towards OCS.

   Upon receiving Trigger-Type 73 in CCA-I, PGW will send Presence-Reporting-Status in CCRU/T towards OCS whenever there is PRA status change reported through S-GW. Presence reporting support is already available for updating Presence Action Start/Stop towards S-GW in CSReq for the Gx interface. For the Gy interface, the same control plane infrastructure is used. A new trigger type is introduced under credit control for the Gy interface so that Trigger Type -CHANGE_OF_UE_PRESENCE_IN_PRESENCE_REPORTING_AREA(73) is processed in CCA messages sent from OCS.

   When the trigger type CHANGE_OF_UE_PRESENCE_IN_PRESENCE_REPORTING_AREA (73) is enabled over Gy interface, PRA-IDs are sent to PGW in CCA-I/CCA-U. Whenever there is a PRA status change(MBReq with PRA change), the CCR-U with PRA information AVP is sent to OCS as well.

   When the session ends, CCR-T has the PRA information AVP along with the details of the latest PRA-ID and status. At this time the assumption is that Gx and Gy sides would subscribe to the same PRA-ID since it is for the same session. It is also assumed that Gy side subscribe/unsubscribe for a PRA-ID session would not send PRA Start/Stop in CSReq towards SGW since it is already handled from the Gx side. Gy side would only keep a record of PRA-ID for which the presence reporting needs to be sent to the OCS server or not.

2. Extended QoS parameters to be sent in CCR messages towards OCS as part of QoS-Information AVP

   Following extended parameters must be included in the QoS-Information AVP sent to OCS:

   1. Extended-Max-Requested-BW-UL

   2. Extended-Max-Requested-BW-DL

   3. Extended-GBR-UL

   4. Extended-GBR-DL

   5. Extended-APN-AMBR-UL

   6. Extended-APN-AMBR-DL

   When the PCRF has programmed Extended QOS parameters for a particular subscriber, the Extended QOS parameters needs to be sent to OCS in CCR message. The new AVPs sent as part of CCR-Initial/update/Terminate is applicable as per policy updated from PCRF for the specific subscriber.

   ACSMGR has infomation on QoS parameters for the bearer and this is used to send information to DCCA and ultimately OCS server.

3. Enhanced-Diagnostics AVP in CCR-T: Report RAN-NAS-Release-Cause Only in CCR-T

   The Enhanced-Diagnostics AVP (AVP code 3901) is sent in CCR-T message towards OCS and complements the Change-Condition AVP for Offline Charging from PCN Nodes. The RAN-NAS-Release-Cause AVP is under a grouped AVP to allow extensions to other types of release causes in the future.

4. Support for Multiple Subscription-ID - E.164 ,IMSI and NAI

   Multiple subscription ID enables required for various service types under Credit Control Configuration.

   Currently, Multiple subscription ID AVP is encoded in the Gy CCRs based on dictionary and service-type checks. With the subscription ID AVP, customers will have the provision of enabling required Subscription-Id types for various services.

   Each service can have a maximum of three Subscription-Id types (for example: E164, IMSI and NAI) and the advantage of this Multiple subscription ID is that any further dictionary additions in DCCA can be minimized.

This section provides information on configuration commands available in support of this feature:

• Configuring PRA (cno-uli) for Gx

• Configuring PRA for Gy

Use the following configuration commands to enable the Subscription-Ids for various service types:

configure 
   active-charging service service_name 
      credit-control-group group_name 
         subscription-id service-type closedrp ( e164 | imsi | nai } 
   end 

For an instance, if a customer wants E.164, IMSI and NAI value to be encoded in Gy CCR for P-GW service, then the below CLI should be configured in the Credit Control Configuration mode.

subscription-id service-type pgw e164 imsi nai

NOTES:

• subscription-id : Configures Credit Control subscription-ids for service-types.

• service-type : Configures Credit Control subscription-ids based on service-types.

• closedrp : Configures subscription-id for closedrp service.

Use the following configuration commands in Policy Control Configuration to enable the Extended Bandwidth QoS:

configure 
             context context_name 
                ims-auth-service ims_auth_service_name 
                   policy-control 
                      [ no ]diameter encode-supported-features extended-bw-newradio
      end 

show active-charging sessions full all

The following new field is displayed to the output of this command:

• Pending Triggers: pra

show active-charging service all | grep pra

The following new fields are displayed to the output of this command:

• Service name

• Credit Control

  • Trigger type:pra