Tdoc  S2-042781
`3GPP TSG-WG2 Meeting #41
`Montreal, Canada, August 16-20, 2004 Revised S2-042525 S2-02555
`
`CHANGE REQUEST
`
`CR-Form-v7.1
`
`
`
`23.125 CR 48
`
` rev 2
`
`
`
` Current version: 6.1.0
`
`
`
`For HELP on using this form, see bottom of this page or look at the pop-up text over the  symbols.
`
`
`
`
`
`
`
`
`Proposed change affects:  UICC apps
`
`
`
`
`ME
`
` Radio Access Network
`
` Core Network X
`
`
` Add CCF and/or OCS address to charging rule
`Title:
`
`
` Huawei, China Mobile, Lucent Technologies
`Source:
`
`
`Work item code:  CH
`
`
` B
`
`Category:
`Use one of the following categories:
`
`F (correction)
`A (corresponds to a correction in an earlier release)
`B (addition of feature),
`C (functional modification of feature)
`D (editorial modification)
`Detailed explanations of the above categories can
`be found in 3GPP TR 21.900.
`
`
`
`
`
`
`
`Date:  17/08/2004
`
`Release:  Rel-6
`Use one of the following releases:
`Ph2
`(GSM Phase 2)
`R96
`(Release 1996)
`R97
`(Release 1997)
`R98
`(Release 1998)
`R99
`(Release 1999)
`Rel-4
`(Release 4)
`Rel-5
`(Release 5)
`Rel-6
`(Release 6)
` Rel-7
`(Release 7)
`
`
`
`
`Reason for change: 
`
`In the current TS 23.125, the CRF indicates the charging mechanism is online or
`offline. In case of offline charging, the TPF shall provide charging records to a
`CCF. In case of online charging, the TPF shall trigger the credit request to the
`OCS. But in the specification the TPF how to get the suitable CCF and/or OCS
`address is not clear.
`
`For a real PLMN, as is already supported for IMS, there may be multiple CCFs
`and/or OCSs to distribute the subscriber data into several entities. In this case,
`the TPF shall contact the appropriate CCF or OCS basing on UE identity
`information. However, there might be no such information be pre-configured in
`the TPF to be used to find the correct CCF and/or OCS for a specified UE. A
`preferable approach is the CRF may provide the CCF and/or OCS address to the
`TPF.
`
`
`
`Summary of change:  The CCF and OCS addresses are sent to the TPFonly once per user session.
`Alternatively the CCF and OCS addresses are pre-configured in the TPF.
`
`The TPF how to obtain the CCF or OCS address is unclear.
`
`
`Consequences if 
`not approved:
`
`
`Clauses affected:  5.2, 6.2.2
`
`
`Y N
`
` X Other core specifications
`Other specs
` X Test specifications
`affected:
` X O&M Specifications
`
`
`
`
`
`
`
`
`
`
`
`
`
`CR page 1
`
`Commented [H1]: Document numbers are allocated by the
`Working Group Secretary.
`
`Formatted: Font: 10.5 pt
`
`Formatted: Font: 10.5 pt
`
`Formatted: Font: 10.5 pt
`
`Commented [H2]: Enter the specification number in this box.
`For example, 04.08 or 31.102. Do not prefix the number with
`anything . i.e. do not use "TS", "GSM" or "3GPP" etc.
`
`Commented [H3]: Enter the CR number here. This number is
`allocated by the 3GPP support team. It consists of at least three
`digits, padded with leading zeros if necessary.
`
`Commented [H4]: Enter the revision number of the CR here. If
`it is the first version, use a "-".
`
`Commented [H5]: Enter the version of the specification here.
`This number is the version of the specification to which the CR will
`be applied if it is approved. Make sure that the latest version of the
`specification (of the relevant release) is used when creating the CR.
`If unsure what the latest version is, go to
`http://www.3gpp.org/specs/specs.htm.
`
`Commented [H6]: For help on how to fill out a field, place the
`mouse pointer over the special symbol closest to the field in
`question.
`
`Commented [H7]: Mark one or more of the boxes with an X.
`
`Commented [H8]: SIM / USIM / ISIM applications.
`
`Commented [H9]: Enter a concise description of the subject
`matter of the CR. It should be no longer than one line. Do not use
`redundant information such as "Change Request number xxx to
`3GPP TS xx.xxx".
`
`Commented [H10]: Enter the source of the CR. This is either
`(a) one or several companies or, (b) if a (sub)working group has
`already reviewed and agreed the CR, then list the group as the
`source.
`
`Commented [H11]: Enter the acronym for the work item which
`is applicable to the change. This field is mandatory for category F, B
`& C CRs for release 4 and later. A list of work item acronyms can be
`found in the 3GPP work plan. See
`http://www.3gpp.org/ftp/information/work_plan/ .
`The list is also included in a MS Excel file included in the zip file
`containing the CR cover sheet template.
`
`Commented [H12]: Enter the date on which the CR was last
`revised. Format to be interpretable by English version of MS
`Windows ® applications, e.g. 19/02/2002.
`
`Commented [H13]: Enter a single letter corresponding to the
`most appropriate category listed below. For more detailed help on
`interpreting these categories, see the Technical Report 21.900 "TSG
`working methods".
`
`Commented [H14]: Enter a single release code from the list
`below.
`
`Commented [H15]: Enter text which explains why the change
`is necessary.
`
`Commented [H16]: Enter text which describes the most
`important components of the change. i.e. How the change is made.
`
`Commented [H17]: Enter here the consequences if this CR was
`to be rejected. It is necessary to complete this section only if the CR
`is of category "F" (i.e. correction).
`
`Commented [H18]: Enter the number of each clause which
`contains changes.
`
`Commented [H19]: Tick "yes" box if any other specifications
`are affected by this change. Else tick "no". You MUST fill in one
`or the other.
`
`Commented [H20]: List here the specifications which are
`affected or the CRs which are linked.
`
`NSN575-1014, Page 1
`
`

`
`
`
`
`Other comments: 
`
`How to create CRs using this form:
`Comprehensive information and tips about how to create CRs can be found at http://www.3gpp.org/specs/CR.htm.
`Below is a brief summary:
`
`
`
`Commented [H21]: Enter any other information which may be
`needed by the group being requested to approve the CR. This could
`include special conditions for it's approval which are not listed
`anywhere else above.
`
`1) Fill out the above form. The symbols above marked  contain pop-up help information about the field that they are
`closest to.
`
`Commented [H22]: This is an example of pop-up text.
`
`2) Obtain the latest version for the release of the specification to which the change is proposed. Use the MS Word
`"revision marks" feature (also known as "track changes") when making the changes. All 3GPP specifications can be
`downloaded from the 3GPP server under ftp://ftp.3gpp.org/specs/ For the latest version, look for the directory name
`with the latest date e.g. 2001-03 contains the specifications resulting from the March 2001 TSG meetings.
`
`3) With "track changes" disabled, paste the entire CR form (use CTRL-A to select it) into the specification just in front of
`the clause containing the first piece of changed text. Delete those parts of the specification which are not relevant to
`the change request.
`
`CR page 2
`
`NSN575-1014, Page 2
`
`

`
`3GPP TS aa.bbb vX.Y.Z (YYYY-MM)
`
`CR page 3
`
`<< First changed clause >>
`
`5.2
`
`Charging rules
`
`Charging rules contain information that allow for filtering of traffic to identify the packets belonging to a particular
`service data flow, and allow for defining how the service data flow is to be charged. The following apply to charging
`rules:
`
`- The charging rules for bearer charging are defined by the operator.
`
`- These charging rules are made available to the Traffic Plane function for both offline and online charging.
`
`- Multiple charging rules are supported simultaneously per user.
`
`- Filtering information within a charging rule is applied through filtering functionality at the Traffic Plane
`Function to identify the packets belonging to a particular service data flow.
`
`- Charging rules with dynamically provisioned filtering information (i.e. made available to the Traffic Plane
`Function) are supported in order to cover IP service scenarios where the filtering information is dynamically
`negotiated (e.g. negotiated on the application level (e.g. IMS)).
`
`- Pre-defined charging rules are supported. The pre-defined charging rules stored in the TPF shall have charging
`rule identifiers, which are different from the charging rule identifiers allocated by the CRF.
`
`- Elements of charging rules may be statically configured at the Traffic Plane Function, or dynamically
`provisioned.
`
`Note-i: The mechanism to support use of elements statically pre-defined in the TPF (e.g. filter information) is for
`stage 3 development.
`
`Note-ii: The stage 3 development may also evaluate providing an optimisation to support dynamic provisioning of
`an entire charging rule pre-defined in the TPF.
`
`- Pre-defined filters that are part of the pre-defined charging rules may support extended capabilities, including
`enhanced capabilities to identify packets associated with application protocols.
`
`- There may be overlap between the charging rules that are applicable. Overlap can occur between:
`
`- multiple pre-defined charging rules in the TPF;
`
`- charging rules pre-defined in the TPF and rules from the Service Data Flow Based Charging Rules
`Function, which can overlay the pre-defined rules in the TPF.
`
`The precedence identified with each charging rule shall resolve all overlap between the charging rules. When
`overlap occurs between a dynamically allocated charging rule and a pre-defined charging rule at the TPF, and
`they both share the same precedence, then the dynamically allocated charging rule shall be used.
`
`- Charging rules contain information on:
`
`- How a particular service data flow is to be charged: online/offline;
`
`-
`
`In case of offline charging whether to record volume- or time-based charging information;
`
`- Charging key;
`
`- Service data flow filter(s);
`
`- Precedence.
`
`- Charging rule identifier.
`
`- Event triggers and/or CCF/OCS addresses are associated with all charging rules for a user and IP network
`connection.
`
`CR page 3
`
`NSN575-1014, Page 3
`
`

`
`3GPP TS aa.bbb vX.Y.Z (YYYY-MM)
`
`CR page 4
`
`- The identifier of the charging rule allocated by the CRF shall be unique for a CRF/TPF instance.
`
`- Once the charging rule is determined it is applied to the service data flow at the Traffic Plane Function and
`packets are counted and categorised per the rule set in the charging rule.
`
`- Separate charging rules can be provided for downlink and uplink.
`
`- Charging rules can be configured for both user initiated and network initiated flows.
`
`- Charging rules can change and be overridden, e.g. for a previously established PDP context in the GPRS case,
`based on specific events (e.g. IM domain events or GPRS domain events, credit control events).
`
`- Different charging rules can be applied for different users.
`
`- The same charging rule can be applied for multiple users.
`
`- Different charging rules can be applied based on the location of the user (e.g. based on identity of the roamed to
`network).
`
`- Charging rule assignment can occur at bearer service establishment, modification and termination. For GPRS,
`charging rule assignment can occur at PDP context activation, modification and deactivation.
`
`\- For GPRS, the charging rules can be dependent on the APN used.
`
`<< Next changed clause >>
`
`6.2.2
`
`Service Data Flow Based Credit Control Function
`
`The Service Data Flow Based Credit Control Function performs online credit control functions together with the Online
`Charging System. It provides a new function within the Online Charging System.
`
`The Online Charging System is specified in 3GPP TS 32.200 [3]. The Service Data Flow Based Credit Control
`Function is considered as a new functional entity for release 6 within the Online Charging System.
`
`The OCS can interact with the CRF, by using the Ry interface. This allows the OCS to provide input to the CRF for
`charging rules selection.
`
`There may be several CCFs and/or OCSs in a PLMN. To allow for this case, CCF and/or OCS addresses (i.e. the
`primary address and secondary address) may be passed once per user and IP network connection from the CRF to the
`TPF. Alternatively this information may be locally pre-configured within the TPF. The addresses provided by the CRF
`have higher priority than the pre-configured ones.
`
`<< End of changed clause >>
`
`
`
`CR page 4
`
`NSN575-1014, Page 4