ITU-T J 363-2006 IPCablecom2 data collection to support accounting (Study Group 9)《IPCablecom2数字收集支持结算 研究组9》.pdf

1、 International Telecommunication Union ITU-T J.363 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (11/2006) SERIES J: CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS IPCablecom IPCablecom2 data collection to support accounting ITU-T Recommendation J.363 I

2、TU-T Rec. J.363 (11/2006) i ITU-T Recommendation J.363 IPCablecom2 data collection to support accounting Summary This Recommendation defines the requirements and functionality needed to support Accounting functions within this release of the IPCablecom2 Architecture. The main focus is to define how

3、the collection of usage data is done to assure that the required billing functions can be supported, though usage data may also be used for other purposes (e.g., network or service trend analysis, network planning, and traffic engineering). In addition, this Recommendation details the various accoun

4、ting events and their associated attributes. Source ITU-T Recommendation J.363 was approved on 29 November 2006 by ITU-T Study Group 9 (2005-2008) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. J.363 (11/2006) FOREWORD The International Telecommunication Union (ITU) is the United Nation

5、s specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunicatio

6、ns on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure la

7、id down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunic

8、ation administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these manda

9、tory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws a

10、ttention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or ot

11、hers outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represe

12、nt the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2007 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. J.363 (11/2006)

13、 iii CONTENTS Page 1 Scope 1 2 References. 1 3 Terms and definitions . 2 4 Abbreviations and acronyms 2 5 Conventions 3 6 Technical overview. 3 6.1 IMS charging architecture 4 6.2 IPCablecom2 accounting architecture 5 6.3 Relationship to IPCablecom Multimedia Event Messages 8 6.4 Relationship to IPC

14、ablecom Event Messages 8 7 IPCablecom2 extensions to IMS charging . 9 7.1 Required Subset of IMS Charging . 9 7.2 Charging identification information in the pkt-qos-1 interface 9 7.3 Extensions to the SIP P-Charging-Vector header 10 7.4 Extensions for IMS Charging Reporting 10 Appendix I IPCablecom2

15、 Accounting functionality example 12 Bibliography. 15 ITU-T Rec. J.363 (11/2006) 1 ITU-T Recommendation J.363 IPCablecom2 data collection to support accounting 1 Scope This Recommendation defines the requirements and functionality needed to support Accounting functions within this release of the IPC

16、ablecom2 Architecture. The main focus is to define how the collection of usage data is done to assure that the required billing functions can be supported, though usage data may also be used for other purposes (e.g., network or service trend analysis, network planning, and traffic engineering). In a

17、ddition, this Recommendation details the various accounting events and their associated attributes. An Accounting Event message is a data record containing information about network usage and activities. A single Accounting Event may contain a complete set of data regarding usage or it may only cont

18、ain part of the total usage information. When correlated by the Charging Data Function (CDF), information contained in multiple Accounting Events provides a complete record of the service. This complete record of the service is often referred to as a Call Detail Record (CDR). Accounting Events or CD

19、Rs may be sent to one or more back-office applications such as a billing system, fraud detection system, or pre-paid services processor. The structure of an Accounting Event Message data record is designed to be flexible and extensible in order to carry information about network usage for a wide var

20、iety of services. It needs to support the correlation of accounting events generated in the session and bearer domains and to seamlessly interwork with the cable-specific access network. It is an important objective of this work that interoperability between IPCablecom 2.0 and 3GPP IMS is provided.

21、IPCablecom 2.0 is based upon 3GPP IMS, but includes additional functionality necessary to meet the requirements of cable operators. Recognizing developing converged solutions for wireless, wireline, and cable, it is expected that further development of IPCablecom 2.0 will continue to monitor and con

22、tribute to IMS developments in 3GPP, with the aim of alignment of 3GPP IMS and IPCablecom 2.0. 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the

23、 editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently

24、 valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T J.366.4 ITU-T Recommendation J.366.4 (2006), IPCablecom2 Multimedia Subsystem (IMS): Session Initiation Proto

25、col (SIP) and Session Description Protocol (SDP); Stage 3 Specification. TS 32.240 ETSI TS 132.240 V6.3.0 (2005-09), Charging Architecture and Principles, Release 6. TS 32.260 ETSI TS 132.260 V6.4.0 (2005-09), IP Multimedia Subsystem (IMS) charging, Release 6. TS 32.299 ETSI TS 132.299 V6.5.0 (2005-

26、12), Diameter charging applications, Release 6. 2 ITU-T Rec. J.363 (11/2006) 3 Terms and definitions The terms and definitions defined in the 3GPP Technical Specification TS 32.260 TS 32.260 are generally applicable; please refer to clause 3 of TS 32.260. In addition, this Recommendation uses the fo

27、llowing terms: 3.1 accounting: The process of collecting usage data. 3.2 billing correlation ID (BCID): A Billing Correlation ID (BCID) is an IPCablecom-defined term created for the multimedia session, which uniquely identifies the session within the IPCablecom Multimedia billing domain. 3.3 DIAMETE

28、R: The DIAMETER protocol provides an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. 3.4 charging: The process of applying rating to usage data for a given session for the generation of a subscribers bill. 3.5 HFC access network: T

29、he Hybrid-Fibre Coax Network, which provides physical transport of video and high-speed data services via DOCSIS. 3.6 usage data: A collection of data representing the usage of network resources for a given session. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations: 3

30、GPP Third Generation Partnership Project AM Application Manager BCID Billing Correlation ID BSS Business Support Systems CCF Charging Collection Function CDF Charging Data Function CDR Call Detail Record CGF Charging Gateway Function CM Cable Modem CMS Call Management Server CMTS Cable Modem Termina

31、tion System CSCF Call Session Control Function EM Event Messages E-MTA Embedded Multimedia Terminal Adapter GPRS General Packet Radio Service ICID IMS Charging Identity IMS IP Multimedia Subsystem IOI Inter-Operator Identifier IP Internet Protocol IP-CAN IP Connectivity Access Network ITU-T Rec. J.3

32、63 (11/2006) 3 P-CSCF Proxy CSCF PS Policy Server RADIUS Remote Authentication Dial-In User Service RKS Record Keeping Server S-CSCF Serving CSCF UE User Equipment 5 Conventions Throughout this Recommendation, the words that are used to define the significance of particular requirements are capitali

33、zed. These words are: “MUST“ This word means that the item is an absolute requirement of this Recommendation. “MUST NOT“ This phrase means that the item is an absolute prohibition of this Recommendation. “SHOULD“ This word means that there may exist valid reasons in particular circumstances to ignor

34、e this item, but the full implications should be understood and the case carefully weighed before choosing a different course. “SHOULD NOT“ This phrase means that there may exist valid reasons in particular circumstances when the listed behaviour is acceptable or even useful, but the full implicatio

35、ns should be understood and the case carefully weighed before implementing any behaviour described with this label. “MAY“ This word means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for e

36、xample; another vendor may omit the same item. 6 Technical overview The IMS architecture, as defined and standardized by the Third Generation Partnership Project (3GPP) can be found in b-TS 23.228. This clause provides an overview of the IMS Charging Architecture, how it enables the IPCablecom2 Acco

37、unting Architecture, and defines any needed extensions to the IMS. In this clause, information is also provided on how this Accounting architecture relates to IPCablecom Multimedia Event Messages and, to a lesser extent, IPCablecom Event Messages specifications. The general 3GPP Charging Architectur

38、e and Principles are defined in TS 32.240, and the IMS Charging Subsystem is specified in TS 32.260. IPCablecom2 network elements involved in the IMS Charging Architecture are required to implement the 3GPP requirements defined in TS 32.240 and TS 32.260. Additional IPCablecom2 requirements are also

39、 defined in this Recommendation to allow for better integration of the IPCablecom2 accounting model with the existing IPCablecom Multimedia Recommendation. The IPCablecom2 charging requirements for IMS are covered in 6.2.1, and fully defined in subsequent clauses. Note that the IMS online charging i

40、s currently out of scope for IPCablecom2. 4 ITU-T Rec. J.363 (11/2006) 6.1 IMS charging architecture GSM and UMTS networks provide functions that implement various charging mechanisms based on three levels: bearer usage (e.g., GPRS packet services), service usage (e.g., SMS and MMS), or a service su

41、bsystem (e.g., IMS). 3GPP IMS provides the means to implement offline and/or online charging mechanisms on these levels. In order to support these charging mechanisms, the network performs real-time monitoring of resource usage on the above three levels in order to detect the relevant chargeable eve

42、nts. The IMS also defines intra- and inter-domain charging operations. In particular, IMS defines mechanisms for identifying the originating and terminating networks. In addition to defining the charging mechanisms for the bearer, subsystem and service levels, the IMS also defines an extensible mech

43、anism for correlating charging events from the bearer and subsystem. This is accomplished through the use of the Access-Network-Charging-Info parameter in the P-Charging-Vector SIP header. Such an approach allows the IMS to support non-GPRS based access networks with their own charging architecture

44、as long as they generate a unique billing correlation identifier. The following clauses describe the various IMS charging concepts. 6.1.1 Offline charging As defined by 3GPP, offline charging is a mechanism where charging occurs after the usage collection is complete: the usage information does not

45、affect, in real time, the service rendered. The final result of this charging mechanism is the forwarding of Call Detail Records (CDR) files to the Billing Domain. The offline charging functionality relies on the IMS network nodes reporting accounting information upon reception of various SIP method

46、s or ISUP messages, as most of the accounting- relevant information is contained in these messages. This reporting is achieved by sending Accounting Requests (ACR) using the IETF DIAMETER protocol from the IMS network elements to the Charging Data Function (CDF) which correlates the accounting event

47、s and provides CDRs to the billing applications. Information used for IMS charging is passed between IMS nodes in the SIP P-Charging-Vector header. ITU-T J.366.4 describes the IMS control messages in detail, including the use of the P-Charging-Vector SIP header b-IETF RFC 3455. This header contains

48、the following information parameters: The IMS Charging Identity (ICID), mandatory parameter (icid-value): The ICID is the primary information element used to correlate records across the various IMS elements. The details of how correlation is done based on ICID are covered in TS 32.260. The ICID pro

49、vides a similar function to the Billing Correlation Identifier (BCID) used in IPCablecom Event Messaging. The Inter-Operator Identifier (IOI) parameters (orig-ioi and term-ioi): The IOI parameters may include the originating and/or terminating interoperator identifiers which are used to correlate charging records between different operators. IOI parameters identify the networks handling the IMS session. ITU-T Rec. J.363 (11/2006) 5 The Access Network Charging Information parameter (access-network-charging- info): The access-network-charging-info paramet