3GPP TSG-SA5 (Telecom Management) S5-071300
Meeting SA5#54, 25 - 29 June 2007, Orlando, FL USA
Title: LS on Y.ngn-account
Response to: LS (COM13-LS178-E / S5-071122) on â€˜Sharing the latest
version of Y.ngn-accountâ€™ from ITU-T Study Group 13
Work Item: N/A
Source: 3GPP SA5
To: ITU-T SG13 Question 2
Cc: ATIS TMOC, ETSI TISPAN WG2, ITU-T SG3, SG4 and NGNMFG
Cc: 3GPP/IETF & 3GPP/ITU-T Co-ordinator, Hannu HIETALAHTI - 3GPP TSG CT
Name: Julian MITCHELL
E-mail Address: email@example.com
Approval Date: 29 June 2007
Reply by (if required): None
1. Overall Description:
3GPP SA5 thanks ITU-T SG13 for their liaison informing SA5 of the
latest version of Y.ngn-account.
3GPP SA5 also thanks ITU-T Q8/4 for inviting SA5 to participate in
their teleconferences held in early June 2007 for review of
SA5 has reviewed the latest version of Y.ngn-account and has the
following comments (some of these have been discussed on the Q8/4 call,
but are included here for completeness):
â€¢ 8.2.1 â€“ SA5 fully agrees with the need to be able to configure
policy on the CTF, however SA5 takes the view that the CCF should not
be the functional entity responsible for configuring policy on the CTF.
The Ct reference point should be for the purpose of extracting charging
data from the CTF, not pushing policy to the CTF.
â€¢ 8.2.2 - The n:1 relationship of CTF to CCF (i.e. each CTF has to
duplicate its charging information to multiple CDFs) is of concern to
SA5. SA5 uses IETF-defined Diameter between its CTF and CCF equivalent
functions, and Diameter does not support an n:1 relationship, yet
despite this, the SA5 charging solution has been widely deployed with
no concerns about lack of 'backup and high availability' as other
mechanisms can address these issues. The duplication of data to
multiple destinations also raises concerns about excessive usage of
network resources (bandwidth and processing power). The n:1 should at
most be made an option if it needs to be mentioned at all.
â€¢ 8.2.2 - The reference to the CCF performing analysis functions
needs to be clarified to confirm that the analysis is concerned with
correct packaging for data with any more detailed analysis, including
correlation, being performed in the CGF or Billing System. 3GPP SA5
suggests that changing the name of the function from Charging
Collection Function (defined in 3GPP Release 5) to Charging Data
Function (defined in 3GPP Release 6 onwards) would help to reduce the
â€¢ 8.2.4 - The last two paragraphs about why a rating function is part
of billing domain and why it's only used for online charging are
confusing and unnecessary and should be removed.
â€¢ 8.2.7 - The Inter-provider Charging Gateway Function is not a
function that exists in SA5â€™s charging solution as such data is
transferred using GSMA-defined TAP procedures in the billing domain. It
is suggested that the requirements for the IPCGF be analyzed in more
depth to confirm if it is really needed as a function in the charging
domain or if the functions it provides would be better included as part
of the billing domain. It should be noted that TISPAN have been looking
at providing dynamic inter-operator rating information in the SIP
signalling between Online Charging Functions.
â€¢ 8.3.2 â€“ The on-line charging reference point needs to allow data
to be transferred from the OCF to the CTF in addition to from the CTF
to OCF. As such, it is suggested that the term â€˜acknowledgementâ€™ be
replaced by â€˜responseâ€™ in this section.
â€¢ 9.1 â€“ This call flows in this section show a PCRF. This is in
line with the 3GPP Policy and Charging Control (PCC) solution, so is
welcomed by 3GPP SA5. The PCRF functionality is not defined elsewhere
within the document, so it is recommended to add references to the PCC
architecture specified in 3GPP TS 23.203.
To ITU SG13
ACTION: 3GPP SA5 asks ITU-T SG13 to take into account the comments in
this liaison when updating Y ngn-account.
3. Date of Next SA5 Meetings:
TITLE TYPE DATES LOCATION CTRY
3GPPSA5#55 OR 27 - 31 Aug 2007 Bucharest RO
3GPPSA5#56 OR 22 - 26 Oct 2007 Guangzhou CN