5.5A. (271) Accounting-Request / Answer (ACR and ACA):
§ The ACR message is sent by the NAS to report its session information to a target server downstream for accounting purpose.
§ If accounting is active, Accounting Request (ACR) messages SHOULD be sent after the completion of any Authentication or Authorization transaction and at the end of a Session.
(For External PDN or other network)
1. Gi for Between GGSN and Diameter Server for External PDN or other network
§ (ACR – Start/Stop)
§ GGSN may send a Diameter Accounting-Request (START) message to a Diameter server
§ The Diameter accounting client function may reside in a GGSN. The Diameter accounting client may send information to an accounting server
§ The Accounting-Request message also indicates to the Diameter server that the user session has started.
§ GGSN shall send a Diameter Accounting-Request (STOP) message to the Diameter server, which indicates the termination of this particular user accounting session.
§ The GGSN shall immediately send a Delete PDP context response, without waiting for an Accounting-Answer (STOP) message from the Diameter server.
§ (ACR – Interim)
§ During the life of a PDP context, some information related to this PDP context may change
§ Upon reception of an UpdatePDPContextRequest from the SGSN, the GGSN may send an Accounting Request (Interim) to the Diameter server to update the necessary information related to this PDP context
§ (ACR – Start/Stop)
§ The Diameter accounting client function may reside in a P-GW. The Diameter accounting client may send information to an accounting server
§ EPS/P-GW may send a Diameter Accounting-Request (START) message to a Diameter server
§ The Accounting-Request (START) message also indicates to the Diameter server that the user session has started.
§ Accounting-Request START message was sent previously, the P-GW shall send a Diameter Accounting-Request (STOP) message to the Diameter server, which indicates the termination of this particular bearer or user session.
§ The P-GW shall immediately send the corresponding response (e.g. Delete Bearer Request or Proxy Binding Ack with lifetime equal 0) to the peer node (e.g. S-GW) in the Packet Domain, without waiting for an Accounting-Answer (STOP) message from the Diameter server.
§ (ACR – Interim)
§ The P-GW may also send Interim updates: Upon occurrence of the following events
- RAT change,
- S-GW address change,
- QoS change,
- when the IPv4 address is allocated/ released/ re-allocated for deferred IPv4 addressing for the PDN type IPv4v6.
- at the expiry of an operator configured time limit
(For WLAN)
1. Wa for between WLAN AN and 3GPP AAA Proxy/Server
§ When Diameter is used on the Wa interface, the accounting messaging is as per defined in NASREQ IETF RFC 4005 i.e. Accounting Request Message (ACR) is sent by the WLAN-AN after any authentication transaction and at the end of the session to the 3GPP AAA Proxy/Server.
§ In addition, the WLAN-AN may send Interim accounting records.
(For 3GPP Charging)
1. Rf for between IMS Nodes and OFCS (Offline Charging Server – CDF)
§ The offline charging functionality is based on the IMS network nodes reporting accounting information upon reception of various SIP methods or ISUP messages, as most of the accounting relevant information is contained in these messages.
§ This reporting is achieved by sending Diameter Accounting Requests (ACR) [start, interim, stop and event] from the IMS nodes to the CDF and/or ECF.
Session Related CDRs
§ Accounting information for SIP sessions is transferred from the IMS nodes involved in the session to the CDF using Diameter ACR [start, interim and stop] messages.
Session Unrelated CDRs
§ Accounting information for SIP session-unrelated procedures is transferred from the IMS nodes involved in the procedure to the CDF using Diameter ACR [event] messages.
5.5B. (272) Credit-Control-Request / Answer (CCR and CCA):
§ There can be multiple credit-control servers in the system for redundancy and load balancing. The system can also contain separate rating server(s), and accounts can be located in a centralized database.
§ It is used between the Diameter credit-control client and the credit-control server to request credit authorization for a given service.
§ (3GPP – IMS Charging)
Three cases for control of user credit for online charging are distinguished:
§ Immediate Event Charging IEC
§ event charging with unit reservation (ECUR)
§ Session Charging with Unit Reservation (SCUR)
§ In the Immediate Event Charging (IEC): The granting units to the AS is performed in a single operation that also includes the deduction of the corresponding monetary units from the subscriber's account. The charging process is controlled by the corresponding CC-Request-Type EVENT_REQUEST which is sent with an CCR for a given accounting event.
§ In the Event Charging with Unit Reservation (ECUR): the CC-Request-Type INITIAL or TERMINATION_REQUEST are used for charging for a given credit control event, however, where a reservation is made prior to service delivery and committed on execution of a successful delivery.
§ Session Charging with Unit Reservation: This is used for credit control of sessions and uses the CC-Request-Type INITIAL / UPDATE and TERMINATION_REQUEST.
§ The network element may apply IEC, where CCR event messages are generated, or ECUR, using CCR Initial and Termination.
Following the protocol specifications, the following
§ (I) Initial request credit control data.
§ (U) Update request credit control data.
§ (T) Terminate request credit control data.
§ (E) Event accounting data.
2. (DCCA for Charging in 32.299) between IMS Nodes and OCS
§ Diameter credit control application messages for the Debit / Reserve Unit Request operation is Credit-Control-Request (CCR) and for the Debit / Reserve Unit Response operation is Credit-Control-Answer (CCA) as specified in IETF RFC 4006
The Diameter Credit-Control Application (DCCA) specifies an approach based on a series of
§ Initial interrogation.
§ Zero, one or more interim interrogations.
§ Final interrogation.
5.6. Re Interface - PRQ/PRS, TRQ/TRS, SUQ/SUS:
1). The use of messages on the Re interface: (for Rating Function)
| Command-Name | Source | Destination | Abbreviation | Command-Code |
| PriceRequest | EBCF | RF | PRQ | N/A |
| PriceResponse | RF | EBCF | PRS | N/A |
| TariffRequest | SBCF | RF | TRQ | N/A |
| TariffResponse | RF | SBCF | TRS | N/A |
| ServiceUsageRequest | SBCF | RF | SUQ | N/A |
| ServiceUsageResponse | RF | SBCF | SUS | N/A |
§ The message flows for the Re Reference Point by explaining example online charging sessions: (i.e. credit control sessions on the Ro interface or CAP dialogues)
§ On the interface towards the serving network nodes (i.e. Ro, CAP) the generic message names
2). The mapping on the type of interfaces:
| Generic name | Ro Interface | CAP Interface |
| online charging request | Credit Control Request (CCR) | First message, initiating the charging dialogue: § Initial DP, § Initial DP GPRS, § Initial DP SMS § subsequent messages: § Apply Charging Report, Event Report BCSM, § Apply Charging Report GPRS, Event Report GPRS, § Event Report SMS |
| online charging response | Credit Control Answer (CCA) | § Apply Charging, Request Report BCSM Event (+ Connect / Continue), § Apply Charging GPRS, Request Report GPRS Event (+ Connect GPRS / Continue GPRS), § Request Report SMS Event, Connect SMS, Continue SMS |
§ For details on the CAP messages and message flows, refer to 3GPP TS 23.078
3). Event Based Charging Function (EBCF):
§ performs event based charging and credit control (e.g. content charging):
§ on the bearer level, based on bearer usage requests - controls the bearer usage, e.g. SMS.
§ on a subsystem level, based on session resource usage (e.g. the IMS MRFC) - controls the resource availability in network.
§ on service level, based on application server requests (e.g. an IMS application server or MMS relay server) - controls the application service availability.
4). Session Based Charging Function (SBCF)
§ performs session based charging and credit control:
§ on the bearer level, based on bearer usage requests received from the network. It controls the bearer usage in the network, e.g. in terms of time or volume granted.
§ on the subsystem level, based on session resource usage requests (e.g. the IMS CSCF) - controls sessions, e.g. it has the ability to grant or deny a session setup request and to terminate an existing session;
§ on the service level, based on service usage requests - controls service availability, e.g. it has the ability to grant or deny a usage of a service.
5). Rating Function (RF)
The Rating Function performs both monetary and non-monetary unit determination (rating). It provides the following functionalities:
§ Rating for network- and external services and applications (session, service, event) before and after service delivery;
§ Cross-product and cross-channel discounts, benefits and allowances.
The Rating Function must be able to handle a wide variety of rateable instances, such as:
§ Rating of volume (in terms of granted units or money, e.g. based on charging initiated by an access network entity);
§ Rating of time (in terms of granted units or money, e.g. based on charging initiated by a SIP application);
§ Rating of events (e.g. based on charging of web content or MMS)
6). Functionality for class
The following applies with respect to the Rating Interface:
§ The Rating Function will potentially cover all rating scenarios for all charging levels (bearer, session and service) and all payment channels (prepaid and postpaid).
§ The Rating Function will cover the methods PriceRequest and TariffRequest.
§ The Rating Function will operate in a stateless way on a per request basis. No context or state is stored internally.
§ The counter values are passed on to the Rating Function in the PriceRequest or TariffRequest method over the Re Reference Point.
§ The Rating Function will not modify accounts or bonus counters directly. Instead it passes the corresponding information (instruction how to modify counters) as part of the response.
§ The Rating Interface is an interface in a trusted environment. Session handling, transaction control or authentication / authorization are not required.
§ No records are written by the Rating Function. Thus billing relevant information is part of the response.
7). Functionality for class
If class
§ the Rating Function has to become statefull;
§ the Rating Function has to modify counters directly;
§ the Rating Function has to handle sessions / has to support transaction control;
§ the PriceRequest and TariffRequest have to support reservations;
5.6A. (Re) PriceRequest (EBCF) / Response (PRQ and PRS):
§ (Re for Rating Function) PRQ/PRS between EBCF and Rating Function (RF)
PRQ / PRS between EBCF and RF (EBCF à Rating Function)
§ This request type is used to determine the price for a given event.
§ The PriceRequest method is used only for event based charging, i.e. only the EBCF uses this method.
For PriceRequest:
§ Determination of a price for the execution of a service or the delivery of a good.
§ From the rating perspective this is the same method if run before delivery (e.g. for balance check or AoC), after delivery (post-rating for charging) or even later in a rerating process.
§ The same method applies for one-time or recurrent charges.
§ The PriceRequest is used by the EBCF.
According to 3GPP TS 32.299, two different scenarios need to be distinguished,
§ the Immediate Event Charging (IEC) and
§ the event charging with unit reservation (ECUR).
§ In both scenarios, EBCF invokes the PriceRequest method for charging or Advice of Charge.
Message Flow (N/A)
§ EBCF invokes the PriceRequest method in an Immediate Event Charging (IEC) scenario
§ EBCF invokes the PriceRequest method in an event charging with unit reservation (ECUR) scenario
| Name | Status in class | PriceRequest message Description | Example | |
| “A” | “B” | |||
| SessionID | M | M | Session identification, used to match the request / response. | |
| ActualTime | M | M | Actual timestamp of the current request. | |
| Subscription-Id | M | M | Identifies the Charged Party.
- IMSI (E.212 format) - SIP-URL - NAI (To be checked for 3GPP status) - private ID (i.e. operator specific). The Subscription-Id is described in subclause | |
| Service-Rating | M | M | One or more service elements. If several services are rated with one request, this grouped element is included several times. The structure of Service-Rating element is described in subclause | |
| Name | Status in class | PriceResponse message Description | Example | |
| “A” | “B” | |||
| SessionID | M | M | Session identification, used to match the request / response. | |
| Service-Rating | M | M | One or more service elements. If several services are rated with one request, this grouped element is included several times. The structure of Service-Rating element is described in subclause | |
5.6B. (Re) TariffRequest (SBCF) / Response (TRQ and TRS):
§ (Re for Rating Function) TRQ/TRS between SBCF and Rating Function (RF)
§ TRQ / TRS between SBCF and RF (SBCF à Rating Function)
For TariffRequest:
§ Determination of a tariff and price for a given session oriented service. This method is used, e.g., for voice calls, where tariff is returned by the Rating Function.
§ At the beginning or during the session, the Rating Function receives requested service units and returns the tariff information. The charging function can grant the requested units or recalculate the granted units based on the returned tariff and the account balance.
§ At the end of the session, the Rating Function returns the conclusive price of the consumed service. The method can also be used for various other services.
TariffRequest method
§ The TariffRequest method is used for bearer charging and IMS session charging, i.e. only the SBCF uses this TariffRequest method.
§ All scenarios in this section describe the case where the SBCF invokes the tariffRequest method for charging or Advice of Charge. All scenarios are valid independent of the type of applicable
§ In the context of bearer charging or session charging, only the Event charging with unit reservation (ECUR) (3GPP 32.299) is relevant
§ In the context of bearer charging or session charging, only the Session charging with unit reservation (SCUR) (3GPP 32.299) is relevant
§ The SBCF invokes the tariffRequest method for charging several times during the same session, with successful reservation and service delivery.
Message Flow: (N/A)
§ SBCF invokes the tariffRequest method for charging several times during the same session, with successful reservation and service delivery
§ SBCF invokes the tariffRequest method and the service delivery is denied
§ TariffRequest Scenario with multiple Tariff Switches and Expiry Time
§ TariffRequest Scenario with limited validity - i.e. the tariff is only valid for a limited number of used service units (e.g. seconds, Kbytes) or until a counter threshold is reached. This scenario applies e.g. for regressive tariffs or for the usage of free / discounted service units
§ TariffRequest Scenario with unsolicited changes of session parameters - for the tariff request method in a scenario, where the tariff depends on the Quality of Service (QoS)
| Name | Status in class | TariffRequest message Description | Example | |
| “A” | “ B” | |||
| SessionID | M | M | Session identification, used to match the request / response. | |
| FirstRequest | O | O | Indicates that this is the first TariffRequest within this rating dialogue. | |
| BeginTime | O | O | Event-timestamp of service activation request. | |
| ActualTime | M | M | Actual timestamp of the current request. | |
| Subscription-Id | M | M | Identifies the Charged Party.
- IMSI (E.212 format) - SIP-URL - NAI (To be checked for 3GPP status) - private ID (i.e. operator specific). The Subscription-Id is described in subclause | |
| Service-Rating | M | M | One or more service elements. If several services are rated with one request, this grouped element is included several times. The structure of Service-Rating element is described in subclause | |
| Name | Status in class | TariffResponse message Description | Example | |
| “A” | “B” | |||
| SessionID | M | M | Session identification, used to match the request / response. | |
| Service-Rating | M | M | One or more service elements. If several services are rated with one request, this grouped element is included several times. The structure of Service-Rating element is described in subclause | |
5.6C. (Re) ServiceUsageRequest (SBCF) / Response (SUQ and SUS):
§ (Re for Rating Function) SUQ/SUS between SBCF and Rating Function (RF)
§ SUQ / SUS between SBCF and RF (SBCF à Rating Function)
§ ServiceUsageRequest: This type of request, also called backward rating, determines the amount of units of a given service given the price.
§ The ServiceUsageRequest is useful (but not limited) in the case where the subscriber's price plan is formed in usage per monetary units amount (e.g. 45 seconds per 100 Yen).
§ Since the basic requirements are covered by the former requests, this request is optional
§ The ServiceUsageRequest Method is implemented only if Class B rating function is used
§ All message flows described in this ServiceUsageRequest are applicable for the SBCF.
§ In the context of bearer charging or session charging, only the Session charging with unit reservation (SCUR) is relevant. Therefore, only SCUR is considered in this method.
§ In the ServiceUsageRequest, a monetary quota is passed to the Rating Function and the response contains the allowed service units for this monetary quota.
| Name | Status in class | ServiceUsageRequest message Description | Example | |
| “A” | “B” | |||
| SessionID | - | M | Session identification, used to match the request / response. | |
| BeginTime | - | O | Event-timestamp of service activation request. | |
| ActualTime | - | M | Actual timestamp of the current request. | |
| Subscription-Id | - | M | Identifies the Charged Party.
- IMSI (E.212 format) - SIP-URL - NAI (To be checked for 3GPP status) - private ID (i.e. operator specific). The Subscription-Id is described in subclause | |
| Service-Rating | M | M | One or more service elements. If several services are rated with one request, this grouped element is included several times. The structure of Service-Rating element is described in subclause | |
| Name | Status in class | ServiceUsageResponse message Description | Example | |
| “A” | “B” | |||
| SessionID | - | M | Session identification, used to match the request / response. | |
| Service-Rating | M | M | One or more service elements. If several services are rated with one request, this grouped element is included several times. The structure of Service-Rating element is described in subclause | |
Message Flow: (N/A)
§ ServiceUsageRequest with reservation method
沒有留言:
張貼留言