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 Release: N/A Work Item:
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
Chair (email@example.com) Contact Person Name: Julian MITCHELL
E-mail Address: firstname.lastname@example.org
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
Y.ngn-account. 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 confusion.
â€¢ 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