Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 32.296  Word version:  16.0.0

Top   Top   Up   Prev   Next
1…   4…   6…

 

4  Required functionality of the OCSWord‑p. 12

The OCS shall support mechanisms for:
  • online bearer charging towards access / core network entities (e.g. SGSN, PCEF, TDF). Online charging interfaces to be supported are Ro and CAP;
  • online charging of applications/services that are provided to subscribers via service nodes (outside the core network) e.g. MMS and LCS. The online charging interface to be supported is Ro;
  • IMS online charging. Online charging interface to be supported is Ro;
  • account balance management towards external account management servers e.g. recharge server, hot billing server;
  • generation of Charging Data Records (CDRs) and their transfer to the operator's post-processing system;
  • spending limit and balance monitoring and reporting based on subscription or configuration within OCS, towards Policy and Charging Rule Function.
The OCS may optionally support mechanisms for:
  • correlation of bearer, service and IMS charging.
To support these requirements, the functions listed below are necessary in the OCS:
  1. rating (before and/or after service consumption):
    • unit determination: calculation and reservation of a number of session-related non-monetary units (service units, data volume, time and events);
    • price determination: calculation of monetary units (price) for a given number of non-monetary units;
    • tariff determination: determination of tariff information based on the subscribers contractual terms and service being requested (e.g. information for AoC);
    • get/set counters applicable for rating (alternatively these counters can be here or in the subscriber account balance management; for further details refer to clause 5.2.2).
  2. subscriber account balance management:
    • check account balance;
    • account balance update (credit/debit);
    • account balance reservation;
    • get/set counters;
    • get/set expiry date of the (pre-paid) account (optional).
  3. charging transaction control:
    • perform charging control on request basis for bearer and events/services;
    • immediate charging and charging with reservation;
    • generation of charging information/CDR per charging transaction.
  4. advice of charge support (defined in TS 32.280):
    • receive tariff information from external system;
    • provide Advice of Charge (AoC) information (tariff and/or cost).
To support the correlation requirements, the functions listed below are possible in the OCS:
  1. correlation function:
    • context handling of bearer, service and IMS charging events related to a given subscriber;
    • generation of a combined multiple event and session requests to the Rating Function.
  2. notification management:
    • monitor account balance and/or counters thresholds;
    • session management of notification subscriptions for a given subscriber;
    • mapping of account balance and/or counters thresholds to notification statuses (e.g. policy counter statuses);
    • report changes in notification statuses for a given subscriber;
    • respond to queries of notification status values for a given subscriber.
Up

5  Architectural conceptWord‑p. 13

5.1  Architecture reference model for online charging

Figure 5.1.1 shows the OCS in the framework of the overall charging architecture as defined in TS 32.240. The present document covers only the OCS internal architecture (i.e. the blue box in figure 5.1.1).
[not reproduced yet]
Figure 5.1.1: OCS architecture
Up
Towards the SGSN, the OCS or a separate function could provide a translation between CAP and Ro. This is beyond the scope of the present document.
In case of Flow Based Charging (FBC), the PCEF is used for all PCC interactions between P-GW and OCS, for details refer to TS 32.251.
In case of Application Based Charging (ABC), the TDF is used for interactions with the OCS, for details refer to TS 32.251.
The architecture details on the Ro reference point used for IMS (IMS CSCF, IMS Application Server and IMS MRFC) specified in TS 32.260.
The service specific architecture details on the Ro reference point are specified for the MMS Relay/Server in TS 32.270, for the GMLC in TS 32.271, for the PoC Server in TS 32.272 , for the MBMS Server in TS 32.273, for the SMS Node in TS 32.274 , for the IMS Application Server in TS 32.275 , for the Proxy Function in TS 32.276 and for the ProSe Function in TS 32.277.
The Session Based Charging Function (SBCF) performs session based charging on the bearer level using the CAP interface towards MSC and SGSN, and the Ro reference point towards other network elements. The Session Based Charging Function (SBCF also performs session based charging on the subsystem level (i.e. IMS session charging) using the Ro reference point towards the IMS CSCF. Whether the CSCF is directly connected to the OCS or via a gateway (IMS Gateway Function) is beyond the scope of the present document.
The Event Based Charging Function (EBCF) performs event-based charging using the CAP interface towards MSC and SGSN (e.g. for charging of SMS), and the Ro reference point towards other network elements.
The Rating Function (RF) and the Account Balance Management Function (ABMF) are described in clause 4.
The Re reference point allows the interaction between the online charging functions (SBCF, EBCF) and the RF.
The Rc reference point allows the interaction between the online charging functions (SBCF, EBCF) and the ABMF to access the subscribers account balance.
The Ga reference point allows the collection and transfer of charging information from the Charging Data Functions (CDF) to the Charging Gateway Function (CGF). In the context of online charging, the CDFs are always integrated into the online charging functions (SBCF, EBCF). Whether the CGF is also integrated into the Online Charging Function (OCF), or whether it is a separate function inside the OCS, or whether it is an external function outside the OCS is not defined in this 3GPP release.
The Bo reference point allows the transfer of charging information from the CGF to the operator's post-processing system as the OCS variant of the Bx interface description in TS 32.297.
The Rr reference point allows the interaction between the ABMF and an external recharging server.
The policy and charging control architecture is specified in TS 23.203 and the Sy protocol details are specified in TS 29.213 and TS 29.219. The Sy reference point allows the interaction between the OCS and Policy and Charging Rules Function (PCRF) for obtaining information from the OCS for policy decision purposes.
There may be other external systems connected to the OCS (e.g. hot billing server). These systems are not considered in the present document.
Up

5.2  Functions within the OCSWord‑p. 16

5.2.1  Online Charging Functions

5.2.1.1  Event Based Charging Function

The EBCF performs event based charging and Credit-Control (e.g. content charging):
  • on the bearer level, based on bearer usage requests received from the network. It controls the bearer usage in the network, e.g. SMS;
  • on a subsystem level, based on session resource usage requests received from the network (e.g. the IMS MRFC). It controls the resource availability in network, e.g. it has the ability to grant or deny the resource usage;
  • on service level, based on application server requests received from the network (e.g. an IMS application server or MMS relay server). It controls the application service availability in the network, e.g. it has the ability to grant or deny the service usage in the network.
It communicates with the RF in order to determine the value of the requested service usage. It communicates with the ABMF to query and update the subscribers' account and counters status (counters are not applicable if a class "B" RF is used).
When a correlation process is enabled a correlation context may be consulted or created. If multiple chargeable events exist in the correlation context a combined request is issued for the RF.
Up

5.2.1.2  Session Based Charging Function

The 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 received from the network (e.g. the IMS CSCF). It controls sessions in the network, 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 received from the network. It controls service availability in the network, e.g. it has the ability to grant or deny a usage of a service.
It communicates with the RF in order to determine the value of the requested bearer resources or the requested session. It communicates with the ABMF to query and update the subscribers' account and counters status (counters are not applicable if a class "B" RF is used).
When a correlation process is enabled a correlation context may be consulted or created. If multiple chargeable events exist in the correlation context a combined request is issued for the RF.
Up

5.2.2  Rating FunctionWord‑p. 17

The RF performs both monetary and non-monetary unit determination (rating). It provides the following functionalities:
  • Rating for network- and external services and applications (session, service and event) before and after service delivery and based on dynamic credit limit update;
  • Rating considering the cross-product, cross-channel, counter-based, rental-based and recharge-based discounts, benefits and allowances.
The RF shall 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).
The RF includes the determination of the tariff or the price of a chargeable event or of multiple chargeable events (correlation scenario); examples include the price of a call minute, data volume, multimedia session, Web content, etc.
Upon receipt of a rate request (price or TariffRequest) from the OCF, the RF:
  • Evaluates the request. Rate requests include various rating parameters such as service identifier, subscriber reference, network identification, user location, service usage time, transferred data volume, etc. Note that the rate request may contain multiple service identifiers that reflect the list of active services contained in the context handled by the OCF.
  • Determines the applicable price or tariff model and returns it to the OCF, according to rate requests, subscriber contractual terms, the rating rules configured by operators and billing related information. Note that in case of multiple service requests received, the RF may apply a special price or tariff which can be different to the price or tariff applied to the related services handled separately. For example when sending an MMS, the rating of volume associated with the bearer usage can be free of charge while the rating of the event and/or volume associated with the service level MMS submission is greater than zero. This correlation procedure depends on the operator configurable rating rules. Note that in case of tax should be taken into consideration configured by operators, the tax may be included in the determined and returned applicable price or tariff.
To support the online rating process, the RF needs counters. The counters may be maintained by the RF or by the ABMF. The RF that does not maintain counters are marked as class "A" RF. The RF that maintains counters are marked as class "B" RF.
Up

Up   Top   ToC