Response-based Charging

This chapter describes the response-based Charging feature and provides detailed information on the following topics:

Feature Description

The Response-based Charging feature is introduced to classify data volumes for HTTP request with the content-id and service-id of the HTTP response. Charging of HTTP request packets will be deferred until the HTTP response packet arrives. Once the response is received, the request packet will be charged according to the service-id and content-id of the response.

  • Response-based charging is supported only for the HTTP protocol. When a HTTP method is configured, it will be applicable to all HTTP transactions of that method type for the subscriber. There is no capability to selectively enable response-based charging for some HTTP transactions of a particular HTTP method type and not to other transactions of the same method for a subscriber.

  • Response-based charging supports pipelined HTTP requests (both concatenated and non-concatenated). This will also support persistent HTTP connections. In case of pipelined HTTP requests of different HTTP methods, this feature will be applied only to those HTTP methods for which it is configured.

  • Response-based Charging can be enabled for subscribers classified according to the APN, Virtual-APN, Rulebase, or a combination of these.

  • A configurable option is provided to limit the behavior to HTTP methods configured for response-based charging. The charge-request-to-response CLI command is added in the ACS Trigger Action configuration mode to delay charging for a subscriber flow.

The Response-based Charging feature supports both offline and online charging modes.

  • Offline charging: Response-based charging of HTTP request packet will be reflected in the offline charging records such as EDR, EGCDR, UDR, and RF. According to the billing method configured in the billing policy, the HTTP request bytes will be accounted for against the rating group/content-id of the HTTP response and will be reflected in the data record generated.

  • Online charging: Online charging using Gy interface and Volume Reporting based on monitoring key via Gx interface will be supported. Response-based charging of HTTP request packet will be reflected in these charging methods. According to the billing method configured in the billing policy, the HTTP request bytes will be accounted for against the rating group/content-id of the HTTP response and will be reflected in the data volume reported.

The service-scheme framework configuration is required to configure and enable the Response-based Charging feature for a subscriber. This framework is introduced to disassociate the dependency with rulebase/PCRF and update the policies specific to subscribers based on pre-configured events. For more information on the service-scheme framework, see the ECS Administration Guide.

Relationships to Other Features

This section describes the interoperability of the Response-based Charging feature with other ECS features.

  • Delay charging of control packets:

    • Charge-to-application option: This option to delay charging of control packets delays rulematching and charging of all TCP control packets or subsets of it, depending on the configuration. These packets are rulematched and charged according to the first application packet of the HTTP flow. This feature and all its variants will continue to work as is when response-based charging is not configured. When response-based charging is configured, these packets will be rulematched according to the first HTTP request packet but will be charged according to the HTTP response.

    • Charge-separate-from-application option: This option to delay charging of control packets delays rule matching and charging of TCP control packets and charges them to an L7/L4/L3 rule at the end of the flow. This feature will continue to work as is when response-based charging is configured or not.

  • Websocket: This feature involves charging subsequent packets of the flow after HTTP GET request as per the HTTP request, if the HTTP flow is upgraded to be a websocket flow. When Response-based charging is configured for HTTP GET method, the HTTP GET request and all subsequent packets are charged according to the HTTP response, if the flow is upgraded to a websocket flow.

  • Transactional Rule Matching (TRM): When TRM is enabled for a subscriber, TRM gets engaged on the HTTP request packet and rule match for subsequent packets is bypassed. These packets are charged according to the content-id and service-id of the HTTP request. Since rule match is bypassed for HTTP response, response-based charging will not be supported with TRM.

  • Response-based TRM: When Response-based TRM is enabled for a subscriber, TRM gets engaged on the HTTP response packet and rule match for subsequent packets is bypassed. Response-based charging will be supported with Response-based TRM.

  • HTTPS, RTSP, RTCP and WSP analyzers: Response-based charging is not supported for these analyzers. This feature is supported only for the HTTP protocol.

Limitations for Response-based Charging

The HTTP request packet will be sent towards the server but charging will be deferred. On receiving a response, the following charging methods will be implemented based on the treatment for the response.

  • Response packet gets dropped in ECS (drop due to bandwidth limiting, flow actions, etc.):

    The request packet will be charged according to the service-id, content-id, and rating-group of the HTTP response. If delay charging of control packets is enabled for the subscriber, the TCP TWH (three-way-handshake) control packets along with HTTP request will be charged according to the service-id, content-id and rating-group of HTTP response.

  • Response packet is lost in transit and not received at ECS:

    If the request packet gets retransmitted by the client and a response is received, the original and retransmitted request packets will be charged according to the response. If the response is not received even after retransmissions, then the parent TCP flow will timeout. In this case, the request packets for which charging is still pending will be rule matched again and charged according to the L3/L4 rule. If delay charging of control packets is enabled for the subscriber, the TCP TWH control packets along with HTTP request will be rule matched again and charged according to the L3/L4 rule that it matches.

How It Works

This section describes the Response-based Charging configuration. The Service Scheme framework configuration is required to configure and enable this feature for a subscriber.

Use the sample configuration to enable the response-based Charging feature for a subscriber on a particular rulebase. 

configure 
   active-charging service s1 
      trigger-action ta1 
         charge-request-to-response http all 
      #exit 
      trigger-condition tc1 
         any-match = TRUE 
      #exit 
      service-scheme ss1 
          trigger sess-setup 
             priority 1 trigger-condition tc1  trigger-action ta1 
         #exit 
      #exit 
      subs-class sc1 
         rulebase = rb1 
      #exit 
      subscriber-base sb1 
          priority 1 subs-class sc1  bind service-scheme ss1 
      #exit

Notes:

  • If transactional-rule-matching is configured in the rulebase and response-based charging is also configured in the trigger-action for a subscriber, then response-based TRM must be configured in the same trigger-action for response-based charging to be functional.

  • If transactional-rule-matching is not configured in the rulebase and response-based charging is configured in the trigger-action for a subscriber, then it is optional to configure response-based TRM in the same trigger-action. Response-based charging will be functional with or without the configuration of response-based TRM in the trigger-action.

Configuring Response-based Charging

Use the following configuration in the ACS Trigger Action Configuration mode to allow operators to charge the HTTP request packets based on the specified HTTP response received. 

configure 
   active-charging service <service_name> 
      trigger-action <trigger_action_name> 
         [ no ] charge-request-to-response http { all | connect | delete | get | head | options | post | put | trace } 
         exit

Notes:

  • To disable the feature for the subscriber, configure the following command:

    no charge-request-to-response http all

  • The response-based charging feature applies to the following HTTP methods:

    • all - Applies to all HTTP methods

    • connect - HTTP Connect method

    • delete - HTTP Delete method

    • get - HTTP Get method

    • head - HTTP Head method

    • options - HTTP Options method

    • post - HTTP Post method

    • put - HTTP Put method

    • trace - HTTP Trace method

Verifying the Response-based Charging Configuration

Enter the following command to check if the response-based charging feature is applied to the different HTTP transactions based on HTTP request methods:

show active-charging analyzer statistics name http

Monitoring and Troubleshooting the Response-based Charging feature

This section provides information on the show commands available to support this feature.

show active-charging analyzer statistics name http

The following fields display the count per HTTP method that has response-based charging applied.

A sample output is shown below. 

Response Based Charging: 
 GET      1    POST   0 
CONNECT   0    PUT    0 
HEAD      0    OPTION 0 
DELETE    0    TRACE  0 
Websocket 0

show active-charging trigger-action all

The following fields displays the specified HTTP method(s) that has response-based charging applied. This field displays "all" if all HTTP methods are configured and "none" if no HTTP method is configured.

  • HTTP Response Based Charging