ATIS 0300075-2018 Usage Data Management Architecture and Protocols Requirements for Packet-Based Application Services.pdf

《ATIS 0300075-2018 Usage Data Management Architecture and Protocols Requirements for Packet-Based Application Services.pdf》由会员分享，可在线阅读，更多相关《ATIS 0300075-2018 Usage Data Management Architecture and Protocols Requirements for Packet-Based Application Services.pdf（26页珍藏版）》请在麦多课文档分享上搜索。

1、ATIS-0300075.2018 Revision of ATIS-0300075.2012 American National Standard for Telecommunications Usage Data Management Architecture and Protocols Requirements for Packet-Based Application Services Alliance for Telecommunications Industry Solutions Approved March 2018 American National Standards Ins

2、titute, Inc. Abstract This document describes a functional architecture and provides requirements intended for usage data management to be applied to various business applications for accounting and charging of packet-based telecommunications services. ATIS-0300075.2018 ii Foreword The Alliance for

3、Telecommunication Industry Solutions (ATIS) serves the public through improved understanding between carriers, customers, and manufacturers. The Telecom Management and Operations Committee (TMOC) formerly T1M1 -develops operations, administration, maintenance and provisioning standards, and other do

4、cumentation related to Operations Support System (OSS) and Network Element (NE) functions and interfaces for communications networks - with an emphasis on standards development related to U.S.A. communication networks in coordination with the development of international standards. ANSI guidelines s

5、pecify two categories of requirements: mandatory and recommendation. The mandatory requirements are designated by the word shall and recommendations by the word should. Where both a mandatory requirement and a recommendation are specified for the same criterion, the recommendation represents a goal

6、currently identifiable as having distinct compatibility or performance advantages. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, TMOC Secretariat, 1200 G Street NW, Suite 500, Washington, DC 20005. At the time

7、 it approved this document, TMOC, which is responsible for the development of this Technical Report, had the following leadership: P. Galarza, TMOC Chair (iconectiv) ATIS-0300075.2018 iii Table of Contents 1 Introduction 1 1.1 Background 1 1.2 Scope or User-to-network communication (e.g., service pr

8、ofile administration); or Inter-network communication (e.g., transferring calls, signalling, or short messages); or Mobility (e.g., roaming or inter-system handover); and Any other types of service activities the network operator may want to charge for. At a minimum, this event not only characterize

9、s the resource/service usage, but also indicates the identity of the involved end user(s). 2.1.6 Charging Event: Set of charging information forwarded by the Charging Trigger Function (CTF) towards the Charging Collection Function (CCF) (Offline Charging) or towards the Online Charging Function (OCF

10、). 2.1.7 Correlation: The capability to generate an aggregated CDR by combining and analyzing chargeable events collected from the same transport/service session. 2.1.8 Error File: The logging of usage data records that cannot be processed in the normal way. The reasons records may not be processed

11、include, but are not limited to, the following: missing mandatory data elements, attribute values outside of permitted range, and correlation failures. Error files allow subsequent processing to perform root cause analysis on high volume and high revenue impacting failures. 2.1.9 Network Element: An

12、 element in the transport stratum that is responsible for delivering bearer traffic associated with NGN services. Examples include: routers, gateways, network, and attachment systems. 2.1.10 Offline Charging: Charging mechanism where charging information does not affect, in real-time, the service re

13、ndered. 2.1.11 Online Charging: Charging mechanism where charging information can affect, in real-time, the service rendered and therefore a direct interaction of the charging mechanism with resource/session/service control is required. 2.1.12 Pull Mode: A file transfer delivery method where a “coll

14、ector” requests the transfer of records from a CAF component. ATIS-0300075.2018 4 2.1.13 Push Mode: A file transfer delivery method where one CAF component transmits records to another “collector/s” on a fixed, predictable schedule, or in response to an event. 2.1.14 Record Type: Indicates the purpo

15、se of the record. For example, session origination, interim recording, or session termination can be considered record types. Stand-alone events provide another example. 2.1.15 Service Element: An element in the service stratum that is responsible for providing end-users and applications with the NG

16、N services they request. Examples include: application servers, web servers, and proxy servers. 2.1.16 Service Provider: An enterprise that provides communications-based services. 2.1.17 Service Type: Designates an NGN service category. For example, VoIP, IPTV, content delivery service, telepresence

17、, virtual desktop, and virtual private network can be considered service types. 2.1.18 Session: From the SDP specification: “A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia

18、 session.“122.1.19 Template: A metadata expression defining a data structure. 2.1.20 Usage Record: The information associated with a charging event or CDR. 2.2 Abbreviations Charging management; Charging Architecture and Principles.54 3GPP TS 32.295, Telecommunication management; Charging management

19、; Charging Data Record (CDR) transfer.5 5 3GPP TS 32.297, Telecommunication management; Charging management; Charging Data Record (CDR) file format and transfer.56 ITU-T Recommendation Y.2012, Functional requirements and architecture of the NGN.3 7 RFC 6733, Diameter Base Protocol.68 IETF RFC 3261,

20、Session Initiation Protocol June 2002.6 9 RFC 4006, Diameter Credit Control Application. 610 ATIS-0300276, A Baseline of Security Requirements for the Management Plane.711 3GPP TS 32.251, Telecommunication management; Charging management; Packet Switched (PS) domain charging.512 3GPP TS 32.296, Tele

21、communication management; Charging management; Online Charging System (OCS) applications and interfaces.513 IETF RFC 4566, Session Description Protocol.614 IETF RFC 2228, FTP Security Extensions.615 TMF875-IPDR-IIS-PS, Business Solution Requirements: Network Data Management Usage.416 TMF8001-IPDR-II

22、S-PS, IPDR/XDR Encoding Format.417 ITU-T Recommendation M.3020, Management interface specification methodology.318 ITU-T Recommendation M.3010, Principles for a telecommunications managed network.319 ATIS-1000018, NGN Architecture.6 20 3GPP TS 32.260, Telecommunication management; Charging managemen

23、t; IP Multimedia Subsystem (IMS) charging.43This document is available from the International Telecommunications Union. 4This document available from the TM Forum. . 5This document is available from the Third Generation Partnership Project (3GPP) at . 6This document is available from the Internet En

24、gineering Task Force (IETF). 7This document is available from the Alliance for Telecommunications Industry Solutions (ATIS), 1200 G Street N.W., Suite 500, Washington, DC 20005. ATIS-0300075.2018 7 5 Architecture Model 5.1 Architecture Components Figure 5.1 presents the ATIS NGN Charging and Account

25、ing Functions (CAF), architecture.8The NGN Service combined functionality can be implemented in a single system. ATIS-0300075.2018 9 In addition to these Functional Entities, revision 1 of Y.2233 (06/2010) provides further definition of logical entities that provide input to or receive information f

26、rom the charging and accounting functions. These include the Billing Domain, other NGN accounting functions and policy functions. For example, the policy functions consist of policy enforcement, functional entity, policy decision functional entity, service user profile functional entity, and recharg

27、ing applications. 5.2 Architecture Interfaces The key reference points that define interfaces between the CAF entities are: A. Reference point Ct The Ct reference point is required to support interaction between the CTF and the CCF. The protocols crossing this reference point are required to support

28、 real-time transactions in stateless mode (“event-based charging“) and stateful mode (“session-based charging“) of operation. The following information flows across this reference point in real-time: Charging events for offline charging from the CTF to the CCF. Flow-based charging events for offline

29、 charging from the CTF to the CCF. Acknowledgements for these events from the CCF to the CTF. B. Reference point Co The Co reference point is required to support interaction between the CTF and the OCF. The protocols crossing this reference point are required to support real-time transactions in sta

30、teless mode (“event-based charging“) and stateful mode (“session-based charging“) of operation. The following information flows across this reference point in real-time: Charging events for online charging from the CTF to the OCF. Flow-based charging events for online charging from the CTF to the OC

31、F. Response for these events from the OCF to the CTF. The response grants or rejects the network resource usage requested in the charging event, according to the decision taken by the OCF. C. Reference point Cc The Cc reference point supports interaction between the CCF and the CGF. The protocols cr

32、ossing this reference point are required to support near real-time transactions by transferring one or more CDRs in a single message. The protocols should also support changeover to secondary destinations (alternate CGFs) in case of the primary CGF not being reachable. The following information flow

33、s across this reference point: CDRs are sent from the CCF to the CGF. Acknowledgements for these CDRs are returned from the CGF to the CCF. The CDRs generated by the CCF contain the required charging information to be used for billing the customer. D. Reference point Cg The Cg reference point suppor

34、ts interaction between the OCF and the CGF. The protocols crossing this reference point are required to support near real-time transactions by transferring one or more CDRs in a single message. The protocols should also support changeover to secondary destinations (alternate CGFs) in case of the pri

35、mary CGF not being reachable. The following information flows across this reference point: CDRs are sent from the OCF to the CGF. Acknowledgements for these CDRs are returned from the CGF to the OCF. The CDRs generated by the OCF contain archival information intended to complement the real-time char

36、ging that has already occurred for the customer. E. Reference point Cr The Cr reference point supports interaction between the OCF and the RF in order to determine the value of chargeable events in terms of monetary or non-monetary units. The protocols crossing this reference point are required to s

37、upport real-time transactions. The following information flows across this reference point: Price request message is sent from the OCF to the RF. Reply including price and usage counter information is returned from the RF to the OCF. ATIS-0300075.2018 10 F. Reference point Ca The Ca reference point

38、supports the interaction between the OCF and the ABMF in order to access the account balance of the subscriber on the OCF. G. Reference point Cb The Cb reference point supports interaction between a CGF and the billing domain. The information crossing this reference point is comprised of CDR files.

39、A common, standard file transfer protocol (e.g., FTP) is required to be used, including the transport mechanisms specified for the selected protocol. H. Reference point Cp The Cp reference point is required to support interaction between the CGF and the IPCGF. The protocols crossing this reference p

40、oint are required to support near real-time transactions in stateful mode (“session-based charging“) of operation. The following information flows across this reference point in real-time: CDRs are sent from the CGF to the IPCGF. Acknowledgements for these CDRs are returned from the IPCGF to the CGF

41、. I. Reference point Ci The Ci reference point supports interaction between two IPCGFs in different service provider domains. The information crossing this reference point is comprised of CDR files, which are additionally processed for inter-provider settlement. A common, standard file transfer prot

42、ocol or real-time protocol is required to be used, including the transport mechanisms specified for the selected protocol. All usage accounting protocols crossing these reference points shall provide secure and reliable transport. 6 Usage Accounting Requirements Beyond Architecture Considerations Se

43、ctions 6 and 7 of ITU-T Recommendation Y.2233 provide critical functional requirements and objectives that the reader should consider to be part of this specification. The following functional requirements and objectives are provided as additional enhancements to those already contained in ITU-T Rec

44、ommendation Y.2233. 6.1 Information Content I-M-R001: Information models shall be used to characterize usage attributes metered and collected on NGN Transport and Service Control resources10. I-M-R002: The information specification shall indicate, for all usage attributes, if the information is requ

45、ired, optional, or conditional. 6.2 Data Modeling sent from CTF CCF. After detecting a chargeable event, the CTF sends an ACR to the CCF. o Accounting Answer (ACA); sent from CCF CTF. After receiving an ACR, the CCF sends an ACA to the CTF to inform the CTF that charging data was received. The ACR a

46、nd ACA correspond to the 3GPP Charging Data Request and Charging Data Response operations, as specified in TS 32.299. Ct-I-C-E-R002: For offline charging purposes (Ct reference point), two cases of Charging shall be supported: o Session based charging; and o Event based charging. Ct-I-C-E-R003: The

47、Diameter Accounting Request (ACR) types START, INTERIM, and STOP shall be used for accounting data related to successful sessions. Ct-I-C-E-R004: The Diameter EVENT ACR type shall be used for all event based charging. EVENT accounting data, which is unrelated to sessions, is used e.g., for a simple

48、registration or interrogation and successful service event triggered by a network element. In addition, EVENT accounting data is also used for unsuccessful session establishment attempts. The following requirements (Ct-I-C-E-R005 through Ct-I-C-E-R007) describe key data elements to be included in AC

49、R messages. Ct-I-C-E-R005: The following Diameter Accounting Attribute Value Pairs (AVPs) shall be present in each ACR message, as required per IETF RFC 6733: Session-Id (This field identifies the operation session.) Origin-Host (This field contains the identification of the source point of the operation and the realm of the operation originator.) Origin-Realm (This field contains the realm of the operation originator.) ATIS-0300075.2018 14 Destination-Realm (This fiel