This file is raw output from pdftotext and may not be ideal for distribution. If you are a maintainer for Hackipedia, please sit down when you have time and clean this text version up. Source PDF: /mnt/main/jmc-storage/docs/SCTE/ANSI SCTE 024-09 IP Cablecom 1.0 Part 9 - Event Message Requirements (2009).pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- SOCIETY OF CABLE TELECOMMUNICATIONS ENGINEERS, INC. ENGINEERING COMMITTEE Data Standards Subcommittee AMERICAN NATIONAL STANDARD ANSI/SCTE 24-9 2009 IPCablecom 1.0 Part 9: Event Message Requirements NOTICE The Society of Cable Telecommunications Engineers (SCTE) Standards are intended to serve the public interest by providing specifications, test methods and procedures that promote uniformity of product, interchangeability and ultimately the long term reliability of broadband communications facilities. These documents shall not in any way preclude any member or non- member of SCTE from manufacturing or selling products not conforming to such documents, nor shall the existence of such standards preclude their voluntary use by those other than SCTE members, whether used domestically or internationally. SCTE assumes no obligations or liability whatsoever to any party who may adopt the Standards. Such adopting party assumes all risks associated with adoption of these Standards, and accepts full responsibility for any damage and/or claims arising from the adoption of such Standards. Attention is called to the possibility that implementation of this standard may require the use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. SCTE shall not be responsible for identifying patents for which a license may be required or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. Patent holders who believe that they hold patents which are essential to the implementation of this standard have been requested to provide information about those patents and any related licensing terms and conditions. Any such declarations made before or after publication of this document are available on the SCTE web site at http://www.scte.org. All Rights Reserved © Society of Cable Telecommunications Engineers, Inc. 2009 140 Philips Road Exton, PA 19341 Note: DOCSIS® and OpenCable™ are registered trademarks of Cable Television Laboratories, Inc., and are used in this document with permission. i Contents 1 INTRODUCTION ............................................................................................................................................... 1 1.1 IPCABLECOM OVERVIEW ............................................................................................................................... 1 1.2 IPCABLECOM EVENT MESSAGES.................................................................................................................... 1 1.3 IPCABLECOM REFERENCE ARCHITECTURE .................................................................................................... 2 1.4 IPCABLECOM, VOICE-OVER-IP OVER CABLE ................................................................................................. 2 1.5 DOCUMENT SCOPE ......................................................................................................................................... 3 1.6 DOCUMENT OVERVIEW .................................................................................................................................. 3 1.7 REQUIREMENTS SYNTAX ................................................................................................................................ 4 2 REFERENCES .................................................................................................................................................... 5 2.1 NORMATIVE REFERENCES .............................................................................................................................. 5 2.2 INFORMATIVE REFERENCES ............................................................................................................................ 5 3 TERMS AND DEFINITIONS ............................................................................................................................ 7 4 ABBREVIATIONS ............................................................................................................................................ 11 5 BACKGROUND ................................................................................................................................................ 18 5.1 TRADITIONAL TELEPHONY BILLING FORMATS ............................................................................................. 18 5.2 MOTIVATION FOR EVENT BASED BILLING .................................................................................................... 18 5.3 ORIGINATING/TERMINATING CALL MODEL TO SUPPORT CUSTOMER BILLING AND SETTLEMENTS.............. 18 5.4 REAL-TIME BILLING ..................................................................................................................................... 19 5.5 REAL-TIME AND BATCH EVENT MESSAGE DELIVERY .................................................................................. 19 5.6 TERMINOLOGY AND CONCEPTS .................................................................................................................... 19 5.6.1 Service ................................................................................................................................................. 20 5.6.2 IPCablecom Transaction ..................................................................................................................... 20 5.6.3 Call ...................................................................................................................................................... 21 5.6.4 Event Message ..................................................................................................................................... 21 5.6.5 Attribute ............................................................................................................................................... 21 5.7 SUPPORTING DOCUMENTATION .................................................................................................................... 21 6 IPCABLECOM OBJECTIVES........................................................................................................................ 22 6.1 IPCABLECOM 1.0 REQUIRED SERVICES AND CAPABILITIES .......................................................................... 22 6.2 ADDITIONAL IPCABLECOM SUPPORTED SERVICES AND CAPABILITIES ........................................................ 22 6.2.1 IPCablecom 1.1 Supported Services and Capabilities ........................................................................ 23 6.2.2 IPCablecom Multimedia ...................................................................................................................... 23 6.3 ASSUMPTIONS .............................................................................................................................................. 23 7 EVENT MESSAGES ARCHITECTURE ....................................................................................................... 25 7.1 IPCABLECOM EVENT MESSAGE COLLECTION .............................................................................................. 25 7.2 IPCABLECOM NETWORK ELEMENTS ............................................................................................................ 25 7.2.1 Call Management Server (CMS) .......................................................................................................... 26 7.2.2 Media Gateway Controller (MGC) ...................................................................................................... 26 7.2.3 Cable Modem Termination System (CMTS) ........................................................................................26 7.2.4 Record Keeping Server (RKS) ............................................................................................................. 27 7.3 GENERAL IPCABLECOM NETWORK ELEMENT REQUIREMENTS .................................................................... 28 7.4 EVENT MESSAGE INTERFACES...................................................................................................................... 29 7.4.1 CMS to CMTS (pkt-em1*).................................................................................................................... 29 7.4.2 CMS to MGC (pkt-em2) ....................................................................................................................... 30 7.4.3 CMS to RKS (pkt-em3) ......................................................................................................................... 30 7.4.4 CMTS to RKS (pkt-em4) ...................................................................................................................... 30 7.4.5 MGC to RKS (pkt-em5) ........................................................................................................................ 30 ii 7.4.6 CMS to CMS (pkt-em6) ........................................................................................................................ 30 7.4.7 Security Requirements ......................................................................................................................... 30 8 IPCABLECOM SERVICES AND THEIR ASSOCIATED EVENT MESSAGES ..................................... 31 8.1 IPCABLECOM CALL CONFIGURATIONS......................................................................................................... 31 8.1.1 On-Net to On-Net Call Configuration ................................................................................................. 31 8.1.2 On-Net to Off-Net Call Configuration (Outgoing PSTN Interconnect) ............................................... 32 8.1.3 Off-Net to On-Net Service (Incoming PSTN Interconnection) ............................................................. 32 8.2 SPECIFIC SERVICES ....................................................................................................................................... 33 8.2.1 911 Service........................................................................................................................................... 33 8.2.2 Other N11 Services (311, 411, 611)..................................................................................................... 33 8.2.3 Toll-Free Services ................................................................................................................................ 34 8.2.4 Operator Services ................................................................................................................................ 34 8.2.5 Call Block Service................................................................................................................................ 34 8.2.6 Call Waiting Service ............................................................................................................................ 35 8.2.7 Call Forwarding Service ..................................................................................................................... 36 8.2.8 Return Call Service .............................................................................................................................. 36 8.2.9 Repeat Call Service .............................................................................................................................. 37 8.2.10 Voice Mail Service ............................................................................................................................... 37 8.2.11 Message Waiting Indicator Service ..................................................................................................... 37 8.2.12 Three-Way Call Service ....................................................................................................................... 38 8.2.13 Customer Originated Trace Service .................................................................................................... 38 8.2.14 Account Code and Authorization Code Service ................................................................................... 38 9 IPCABLECOM EVENT MESSAGE STRUCTURE ..................................................................................... 39 9.1 EVENT MESSAGE STRUCTURE ...................................................................................................................... 42 9.2 SERVICE_INSTANCE ..................................................................................................................................... 42 9.3 SERVICE_ACTIVATION ................................................................................................................................. 43 9.4 SIGNALING_START ....................................................................................................................................... 44 9.5 SIGNALING_STOP ......................................................................................................................................... 47 9.6 SERVICE_DEACTIVATION ............................................................................................................................. 48 9.7 DATABASE_QUERY ...................................................................................................................................... 49 9.8 INTELLIGENT_PERIPHERAL_USAGE_START ................................................................................................. 50 9.9 INTELLIGENT_PERIPHERAL_USAGE_STOP ................................................................................................... 50 9.10 INTERCONNECT_START ................................................................................................................................ 50 9.11 INTERCONNECT_STOP .................................................................................................................................. 51 9.12 CALL_ANSWER ............................................................................................................................................ 51 9.13 CALL_DISCONNECT...................................................................................................................................... 52 9.14 QOS_RESERVE ............................................................................................................................................. 53 9.15 QOS_RELEASE ............................................................................................................................................. 54 9.16 TIME_CHANGE ............................................................................................................................................. 54 9.17 QOS_COMMIT .............................................................................................................................................. 55 9.18 RTP_CONNECTION_PARAMETERS EVENT MESSAGE ................................................................................... 56 9.19 MEDIA_ALIVE .............................................................................................................................................. 56 10 IPCABLECOM EVENT MESSAGE ATTRIBUTES ................................................................................ 59 10.1 EM_HEADER ATTRIBUTE STRUCTURE ......................................................................................................... 65 10.1.1 Billing Correlation ID (BCID) Field Structure ................................................................................... 67 10.1.2 Status Field Structure .......................................................................................................................... 68 10.2 CALL_TERMINATION_CAUSE ATTRIBUTE STRUCTURE ................................................................................ 70 10.3 TRUNK GROUP ID ATTRIBUTE STRUCTURE .................................................................................................. 71 10.4 QOS DESCRIPTOR ATTRIBUTE STRUCTURE .................................................................................................. 71 10.5 REDIRECTED-FROM-INFO ATTRIBUTE STRUCTURE ...................................................................................... 72 10.6 ELECTRONIC-SURVEILLANCE-INDICATION ATTRIBUTE STRUCTURE ............................................................ 72 10.7 ATTRIBUTES FOR CONFERENCE PARTIES ..................................................................................................... 72 iii 11 TRANSPORT INDEPENDENT EVENT MESSAGE ATTRIBUTE TLV FORMAT ........................... 73 12 IPCABLECOM EVENT MESSAGE FILE FORMAT .............................................................................. 74 12.1 FILE BIT / BYTE ORDER ................................................................................................................................ 74 12.2 FILE HEADER ................................................................................................................................................ 74 12.3 FILE NAMING CONVENTION ......................................................................................................................... 76 12.3.1 Filename Components ......................................................................................................................... 76 12.4 CONFIGURATION ITEMS ................................................................................................................................ 77 12.5 FILE EM STRUCTURE HEADER ..................................................................................................................... 77 13 TRANSPORT PROTOCOL ......................................................................................................................... 78 13.1 RADIUS ACCOUNTING PROTOCOL .............................................................................................................. 78 13.1.1 Reliability............................................................................................................................................. 78 13.1.2 RADIUS Client Reliability ................................................................................................................... 78 13.1.3 Authentication and Confidentiality ...................................................................................................... 79 13.1.4 Standard RADIUS Attributes ............................................................................................................... 79 13.1.5 IPCablecom Extensions ....................................................................................................................... 81 13.2 FILE TRANSPORT PROTOCOL (FTP) .............................................................................................................. 81 13.2.1 Required FTP Server Capabilities ....................................................................................................... 81 List of Figures FIGURE 1. IPCABLECOM NETWORK COMPONENT REFERENCE MODE ............................................................................ 2 FIGURE 2. TRANSPARENT IP TRAFFIC THROUGH THE DATA-OVER-CABLE SYSTEM....................................................... 2 FIGURE 3. IPCABLECOM TERMINOLOGY ...................................................................................................................... 20 FIGURE 4. REPRESENTATIVE IPCABLECOM EVENT MESSAGES ARCHITECTURE ........................................................... 25 FIGURE 5. EXAMPLE RKS ARCHITECTURE ................................................................................................................... 27 FIGURE 6. EVENT MESSAGE BILLING INTERFACES ....................................................................................................... 29 FIGURE 7. LONG DURATION CALL IDENTIFICATION ..................................................................................................... 57 iv List of Tables TABLE 1. IPCABLECOM EVENT REPORTING COMMON ELEMENTS ............................................................................... 26 TABLE 2. ON-NET TO ON-NET CALL CONFIGURATION ................................................................................................ 31 TABLE 3. ON-NET TO OFF-NET CALL CONFIGURATION ............................................................................................... 32 TABLE 4. OFF-NET TO ON-NET CALL CONFIGURATION ............................................................................................... 33 TABLE 5. TOLL-FREE SERVICES ................................................................................................................................... 34 TABLE 6. CALL BLOCK SERVICE .................................................................................................................................. 35 TABLE 7. CALL WAITING SERVICE ............................................................................................................................... 35 TABLE 8. CALL FORWARDING SERVICE ........................................................................................................................ 36 TABLE 9. RETURN CALL SERVICE ................................................................................................................................ 36 TABLE 10. REPEAT CALL SERVICE ............................................................................................................................... 37 TABLE 11. IPCABLECOM EVENT MESSAGE SUMMARY ................................................................................................ 39 TABLE 12. SERVICES SUPPORTED BY ON-NET TO ON-NET CALL CONFIGURATION ....................................................... 41 TABLE 13. SERVICES SUPPORTED BY ON-NET TO OFF-NET CALL CONFIGURATION. ..................................................... 41 TABLE 14. SERVICES SUPPORTED BY OFF-NET TO ON-NET CALL CONFIGURATION ...................................................... 42 TABLE 15. SERVICE_INSTANCE EVENT MESSAGE ........................................................................................................ 43 TABLE 16. SERVICE_ACTIVATION EVENT MESSAGE .................................................................................................... 44 TABLE 17. SIGNALING_START EVENT MESSAGE ......................................................................................................... 46 TABLE 18. SIGNALING_STOP EVENT MESSAGE ............................................................................................................ 48 TABLE 19. SERVICE_DEACTIVATION EVENT MESSAGE ................................................................................................ 49 TABLE 20. DATABASE_QUERY EVENT MESSAGE ......................................................................................................... 49 TABLE 21. INTERCONNECT_START EVENT MESSAGE................................................................................................... 50 TABLE 22. INTERCONNECT_STOP EVENT MESSAGE ..................................................................................................... 51 TABLE 23. CALL_ANSWER EVENT MESSAGE ............................................................................................................... 52 TABLE 24. CALL_DISCONNECT EVENT MESSAGE ........................................................................................................ 53 TABLE 25. QOS RESERVE TIMESTAMP GENERATION ................................................................................................... 53 TABLE 26. QOS_RESERVE EVENT MESSAGE ................................................................................................................ 54 TABLE 27. QOS_RELEASE EVENT MESSAGE ................................................................................................................ 54 TABLE 28. TIME_CHANGE EVENT MESSAGE ................................................................................................................ 55 TABLE 29. QOS COMMIT TIMESTAMP GENERATION .................................................................................................... 55 TABLE 30. QOS_COMMIT EVENT MESSAGE ................................................................................................................. 56 TABLE 31. MEDIA_ALIVE EVENT MESSAGE ................................................................................................................ 58 TABLE 32. IPCABLECOM ATTRIBUTES MAPPED TO IPCABLECOM EVENT MESSAGES.................................................. 59 TABLE 33. IPCABLECOM EVENT MESSAGE ATTRIBUTES ............................................................................................. 62 TABLE 34. EM_HEADER ATTRIBUTE STRUCTURE........................................................................................................ 65 TABLE 35. BCID FIELD DESCRIPTION .......................................................................................................................... 68 TABLE 36. STATUS FIELD DESCRIPTION ....................................................................................................................... 69 TABLE 37. CALL TERMINATION CAUSE DATA STRUCTURE .......................................................................................... 70 TABLE 38. TRUNK GROUP ID DATA STRUCTURE ......................................................................................................... 71 TABLE 39. QOS DESCRIPTOR DATA STRUCTURE.......................................................................................................... 71 TABLE 40. QOS STATUS BITMASK ............................................................................................................................... 72 TABLE 41. EVENT MESSAGE ATTRIBUTE TLV-TUPLE FORMAT .................................................................................... 73 TABLE 42. BIT / BYTE ORDER FOR THE EVENT MESSAGE FILE..................................................................................... 74 TABLE 43. FILE HEADER FOR IPCABLECOM EVENT MESSAGE FILE FORMAT .............................................................. 74 TABLE 44. FILENAME COMPONENTS ............................................................................................................................ 76 TABLE 45. REQUIRED CONFIGURATION ITEMS ............................................................................................................. 77 TABLE 46. FILE-BASED EM PACKET STRUCTURE ......................................................................................................... 77 TABLE 47. RADIUS MESSAGE HEADER ...................................................................................................................... 79 TABLE 48. MANDATORY RADIUS ATTRIBUTES .......................................................................................................... 80 TABLE 49. RADIUS ACCT_STATUS_TYPE .................................................................................................................. 80 TABLE 50. RADIUS VSA STRUCTURE FOR IPCABLECOM ATTRIBUTES ......................................................................... 80 v 1 INTRODUCTION 1.1 IPCablecom Overview IPCablecom identifies and defines specifications for delivery of enhanced communications services using packetized data transmission technology over the cable television hybrid fiber coax (HFC) data network running the DOCSIS® protocol. IPCablecom specifies a network superstructure that overlays the two-way data-ready broadband cable access network. While IPCablecom is initially focused on packet voice over cable, it will ultimately encompass additional voice services as well as other services such as data, video, and other real-time multimedia. 1.2 IPCablecom Event Messages This specification describes the concept of Event Messages used to collect usage for the purposes of billing within the IPCablecom architecture. It details a transport protocol independent Event Message attribute TLV format, an Event Message file format, mandatory and optional transport protocols, the various Event Messages, lists the attributes each Event Message contains, and lists the required and optional Event Messages associated with each type of end-user service supported. In order to support vendor interoperability, implementations must minimally support RADIUS as a transport protocol. It is issued to facilitate design and field-testing leading to manufacturability and interoperability of conforming hardware and software by multiple vendors. An Event Message is a data record containing information about network usage and activities. A single Event Message may contain a complete set of data regarding usage or it may only contain part of the total usage information. When correlated by the Record Keeping Server (RKS), information contained in multiple Event Messages provides a complete record of the service. This complete record of the service is often referred to as a Call Detail Record (CDR). Event Messages or CDRs 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 the Event Message data record is designed to be flexible and extensible in order to carry information about network usage for a wide variety of services. Examples of these services include IPCablecom voice, video and other multimedia services, OpenCable™ services such as Video-On-Demand, Pay-Per-View and DOCSIS high-speed data services. The IPCablecom Event Message specification defines a transport protocol independent Event Message attribute Type-Length-Value (TLV) format, an Event Message file format, as well as the mandatory RADIUS protocol and the optional FTP transport protocol. 1 1.3 IPCablecom Reference Architecture Figure 1 shows the reference architecture for the IPCablecom Network. Refer to the IPCablecom Architecture Document [10] for more detailed information on this reference architecture. Embedded MTA Client Call Management Server (CMS) Cable HFC Access E-MTA Network CMTS Call Agent (CA) Modem (DOCSIS) Gate Controller (GC) Public Media Gateway Controller (MGC) Switched Managed IP Network Telephone (QoS Features) Media Gateway (MG) Network (Headend, Local, Regional) Signaling Gateway (SG) - Key Distribution Center (KDC) - DHCP Servers Standalone MTA OSS - DNS Servers Client Back Office Servers - TFTP or HTTP Servers and Applications - SYSLOG Server - Record Keeping Server (RKS) HFC Access S-MTA Cable CMTS - Provisioning Server Network Modem (DOCSIS) Figure 1. IPCablecom Network Component Reference Mode 1.4 IPCablecom, Voice-over-IP over Cable Cable operators are deploying high-speed data communications systems and offering voice, video, and data services based on bi-directional transfer of Internet protocol (IP) traffic. The transfer takes place between the cable system headend and customer locations, over an all-coaxial or hybrid-fiber/coax (HFC) cable network, defined by the data over cable service interface specification (DOCSIS). This is shown in simplified form in the following diagram. Cable Modem Wide-Area Termination Network System (CMTS) Cable Network Cable Modem (CM) Customer Premises Equipment Transparent IP Traffic Through the System Figure 2. Transparent IP Traffic through the Data-Over-Cable System The transmission path over the cable system is realized at the headend by a cable modem termination system (CMTS) and at each customer location by a cable modem (CM). At customer locations, the interface is called the cable-modem-to-customer-premises-equipment interface (CMCI) and is specified in [9]. 2 One critical Operations Support System (OSS) function required to operate such a system is the capturing of usage on a call-by-call basis for each subscriber. Such functionality is critical in allowing MSOs to bill for services provided on a usage-sensitive basis, but also plays an important role in areas such as network usage monitoring and fraud management. The usage collection concept lies in requiring network elements involved in key portions of each call to notify a centralized Record Keeping Server (RKS) with what are termed Event Messages detailing the relevant data pertaining to the portion of the call handled by that given network element. This Event Message concept, and the architecture which underlies it, are described in greater detail in this document. 1.5 Document Scope The scope of this document encompasses the definition of the Event Message architecture; the services for which Event Messages are defined; the set of Event Messages defined for each supported service; the format and coding of the Event Messages; and finally the transport protocol used to pass Event Messages between IPCablecom network elements. The Event Messages are designed to be flexible and extensible in order to support new and innovative IPCablecom and value-added services. In an effort to describe some of these features and possible uses of these Event Messages, this document may describe interfaces and signaling protocols that are outside the scope of IPCablecom 1.0. It should be understood that the primary purpose of this document is to support the IPCablecom 1.x architecture and the IPCablecom 1.0 services as defined in this document. In order to support early deployment of IPCablecom networks, the IPCablecom project is developing specifications in a phased approach. In an effort to keep pace with the larger IPCablecom project and interface specification development effort, the Event Messages are also addressed in a phased approach. Possible future extensions to this document may include topics such as expanded support for fraud detection and other back office applications. From time to time this document refers to the voice communications capabilities of an IPCablecom network in terms of "IP Telephony." The legal/regulatory classification of IP-based voice communications provided over cable networks and otherwise, and the legal/regulatory obligations, if any, borne by providers of such voice communications, are not yet fully defined by appropriate legal and regulatory authorities. Nothing in this document is addressed to, or intended to affect, those issues. In particular, while this document uses standard terms such as "call," "call signaling," "telephony," etc., it should be recalled that while an IPCablecom network performs activities analogous to these PSTN functions, the manner by which it does so differs considerably from the manner in which they are performed in the PSTN by telecommunications carriers, and that these differences may be significant for legal/regulatory purposes. Moreover, while reference is made here to "IP Telephony," it should be recognized that this term embraces a number of different technologies and network architecture, each with different potential associated legal/regulatory obligations. No particular legal/regulatory consequences are assumed or implied by the use of this term. 1.6 Document Overview The document contains the following sections. Section 5 motivates the need for Event Messages. Section 6 describes objectives of the Event Message architecture followed by Section 7 describing the Event Message architecture itself. Section 8 describes the services IPCablecom 1.0 will support for which Event Messages need to be generated. Section 9 defines the Event Messages needed in order to bill these supported services. Section 10 defines the IPCablecom Event Message attributes. Section 11 describes the transport independent Event Message attribute TLV format. Section 12 describes the Event Message file format. Finally, Section 13 describes the mandatory and optional transport protocols. 3 1.7 Requirements Syntax Throughout this document, words that are used to define the significance of particular requirements are capitalized. These words are: "MUST" This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification. MUST NOT" This phrase means that the item is an absolute prohibition of this specification. "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore 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 behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. "MAY" This word or the adjective "OPTIONAL" 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 example; another vendor may omit the same item. Other text is descriptive or explanatory. The legal/regulatory classification of IP-based voice communications provided over cable networks and otherwise, and the legal/regulatory obligations, if any, borne by providers of such voice communications, are not yet fully defined by appropriate legal and regulatory authorities. Nothing in this specification is addressed to, or intended to affect, those issues. In particular, while this document uses standard terms such as "call," "call signaling," "telephony," etc., it will be evident from this document that while an IPCablecom network performs activities analogous to these PSTN functions, the manner by which it does so differs considerably from the manner in which they are performed in the PSTN by telecommunications carriers. These differences may be significant for legal/regulatory purposes. 4 2 REFERENCES 2.1 Normative References The following documents contain provisions, which, through reference in this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreement based on this standard are encouraged to investigate the possibility of applying the most recent editions of the documents listed below. [1] ANSI/SCTE 24-3 2009, IPCablecom 1.0 Part 3: Network Call Signaling Protocol for the Delivery of Time- Critical Services over Cable Television Using Data Modems. [2] ANSI/SCTE 24-10 2009, IPCablecom 1.0 Part 10: Security Specification. [3] ANSI/SCTE 24-4 2009, IPCablecom 1.0 Part 4: Dynamic Quality of Service for the Provision of Real-Time Services over Cable Television Networks Using Data Modem. [4] IETF RFC 2865, June 2000, C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)". [5] IETF RFC 2866, June 2000, C. Rigney, "RADIUS Accounting". [6] Telcordia GR-1100-CORE Bellcore Automatic Message Accounting Format (BAF) Requirements Terms and Definitions. [7] ITU-T Recommendation E.164, The International Public Telecommunication Numbering Plan, May 1997. [8] IETF RFC 1305, March 1992, David L. Mills, "Network Time Protocol (Version 3), Specification, Implementation and Analysis". 2.2 Informative References [9] Data-Over-Cable Service Interface Specifications, Cable Modem to Customer Premises Equipment Interface (CMCI) Specification, CM-SP-CMCI-C01-081104, November 4, 2008, Cable Television Laboratories, Inc., http://www.cablemodem.com [10] ANSI/SCTE 24-1 2009, IPCablecom 1.0 Part 1: Architecture Framework for the Delivery of Time-Critical Services Over Cable Television Networks Using Cable Modems. [11] ANSI/SCTE 23-1 2005, DOCSIS 1.1 Part 1: Radio Frequency Interface Specification, [12] PacketCable Architecture Call Flow Technical Report, On-Net MTA to On-Net MTA, PKT-TR-CF-ON-ON- C01-071129, November 29, 2007, Cable Television Laboratories, Inc., http://www.packetcable.com [13] PacketCable Architecture Call Flow Technical Report, On-Net MTA to PSTN, PKT-TR-CF-ON-PSTN-C01- 071129, November 29, 2007, Cable Television Laboratories, Inc., http://www.packetcable.com [14] PacketCable Architecture Call Flow Technical Report, PSTN to On-Net MTA, PKT-TR-CF-PSTN-ON-C01- 071129, November 29, 2007, Cable Television Laboratories, Inc., http://www.packetcable.com [15] GR-1298-CORE, AINGR: Switching Systems (GR-1298). [16] GR-1299-CORE, AINGR: Switch - Service Control Point (SCP)/Adjunct Interface (GR-1299). [17] GR-533-CORE, LSSGR: Database Services Service Switching Points - Toll-Free Service (FSD 31-01-0000), A Module of LSSGR, FR-64 (GR-533), Telcordia. [18] GR-2892-CORE, Switching and Signaling Generic Requirements for Toll-Free Service Using AIN (GR- 2892), Telcordia. [19] TRQ No. 2, Technical Requirements Number 2, Number Portability Switching Systems (ANSI T1S1.6 Working Group). 5 [20] IETF STD 9, Internet Protocol Standards, October 1985, J. Postel, J. Reynolds, File Transfer Protocol (TFP). [21] ANSI/SCTE 159-1 2008, IPCablecom Multimedia. [22] Telcordia GR-605-CORE – LSSGR: Authorization Codes for Automatic Flexible Routing (AFR) and Account Codes for Basic Business Group and AFR (FSD 02-02-1010) – Telecordia. [23] Telcordia GR-580-CORE LSSGR: Call Forwarding Variable, Telecordia. [24] Telcordia GR-586-CORE LSSGR: Call Forwarding Subfeatures, Telecordia. [25] Telcordia GR-317-CORE LSSGR: Switching System Generic Requirements for Call Control Using Integrated Services Digital Network User Part (ISDNUP). [26] GR-2936-CORE Local Number Portability Capability Specification, Telecordia. 6 3 TERMS AND DEFINITIONS This specification uses the following terms: Access Control Limiting the flow of information from the resources of a system only to authorized persons, programs, processes, or other system resources on a network. Active A service flow is said to be "active" when it is permitted to forward data packets. A service flow must first be admitted before it is active. Admitted A service flow is said to be "admitted" when the CMTS has reserved resources (e.g., bandwidth) for it on the DOCSIS network. A-link A-Links are SS7 links that interconnect STPs and either SSPs or SCPs. ‘A’ stands for "Access." Asymmetric Key An encryption key or a decryption key used in public key cryptography, where encryption and decryption keys are always distinct. Audio Server An Audio Server plays informational announcements in IPCablecom network. Media announcements are needed for communications that do not complete and to provide enhanced information services to the user. The component parts of Audio Server services are Media Players and Media Player Controllers. Authentication The process of verifying the claimed identity of an entity to another entity. Authenticity The ability to ensure that the given information is without modification or forgery and was in fact produced by the entity that claims to have given the information. Authorization The act of giving access to a service or device if one has permission to have the access. Cipher An algorithm that transforms data between plaintext and ciphertext. Ciphersuite A set which must contain both an encryption algorithm and a message authentication algorithm (e.g., a MAC or an HMAC). In general, it may also contain a key- management algorithm, which does not apply in the context of IPCablecom. Ciphertext The (encrypted) message output from a cryptographic algorithm that is in a format that is unintelligible. Cleartext The original (unencrypted) state of a message or data. Also called plaintext. Confidentiality A way to ensure that information is not disclosed to anyone other then the intended parties. Information is encrypted to provide confidentiality. Also known as privacy. Cryptanalysis The process of recovering the plaintext of a message or the encryption key without access to the key. Cryptographic An algorithm used to transfer text between plaintext and ciphertext. algorithm Decipherment A procedure applied to ciphertext to translate it into plaintext. Decryption A procedure applied to ciphertext to translate it into plaintext. Decryption key The key in the cryptographic algorithm to translate the ciphertext to plaintext. Digital certificate A binding between an entity’s public key and one or more attributes relating to its identity, also known as a public key certificate. Digital signature A data value generated by a public-key algorithm based on the contents of a block of data and a private key, yielding an individualized cryptographic checksum. Downstream The direction from the headend toward the subscriber location. Encipherment A method used to translate plaintext into ciphertext. Encryption A method used to translate plaintext into ciphertext. Encryption Key The key used in a cryptographic algorithm to translate the plaintext to ciphertext. 7 Endpoint A Terminal, Gateway or Multipoint Conference Unit (MCU). Errored Second Any 1-second interval containing at least one bit error. Event Message A message capturing a single portion of a connection. F-link F-Links are SS7 links that directly connect two SS7 end points, such as two SSPs. ‘F’ stands for "Fully Associated." Flow [DOCSIS Flow] (a.k.a. DOCSIS-QoS "service flow") A unidirectional sequence of packets associated with a Service ID (SID) and a QoS. Multiple multimedia streams may be carried in a single DOCSIS Flow. Flow [IP Flow] A unidirectional sequence of packets identified by OSI Layer 3 and Layer 4 header information. This information includes source/destination IP addresses, source/destination port numbers, protocol ID. Multiple multimedia streams may be carried in a single IP Flow. Gateway Devices bridging between the IPCablecom IP Voice Communication world and the PSTN. Examples are the Media Gateway, which provides the bearer circuit interfaces to the PSTN and transcodes the media stream, and the Signaling Gateway, which sends and receives circuit switched network signaling to the edge of the IPCablecom network. H.323 An ITU-T recommendation for transmitting and controlling audio and video information. The H.323 recommendation requires the use of the ITU-T H.225 and ITU-T H.245 protocol for communication control between a "gateway" audio/video endpoint and a "gatekeeper" function. Header Protocol control information located at the beginning of a protocol data unit. Integrity A way to ensure that information is not modified except by those who are authorized to do so. IntraLATA Within a Local Access Transport Area. Jitter Variability in the delay of a stream of incoming packets making up a flow such as a voice communication. Kerberos A secret-key network authentication protocol that uses a choice of cryptographic algorithms for encryption and a centralized key database for authentication. Key A mathematical value input into the selected cryptographic algorithm. Key Exchange The swapping of public keys between entities to be used to encrypt communication between the entities. Key Management The process of distributing shared symmetric keys needed to run a security protocol. Key Pair An associated public and private key where the correspondence between the two are mathematically related, but it is computationally infeasible to derive the private key from the public key. Keying Material A set of cryptographic keys and their associated parameters, normally associated with a particular run of a security protocol. Keyspace The range of all possible values of the key for a particular cryptographic algorithm. Latency The time, expressed in quantity of symbols, taken for a signal element to pass through a device. Link Encryption Cryptography applied to data as it travels on data links between the network devices. Network Layer Layer 3 in the Open System Interconnection (OSI) architecture that provides network information that is independent from the lower layers. Network The functions related to the management of data across the network. Management 8 Network The functions related to the management of data link layer and physical layer Management OSS resources and their stations across the data network supported by the hybrid fiber/coax system. Nonce A random value used only once that is sent in a communications protocol exchange to prevent replay attacks. Non-Repudiation The ability to prevent a sender from denying later that he or she sent a message or performed an action. Off-Net Call A communication connecting an IPCablecom subscriber out to a user on the PSTN. On-Net Call A communication placed by one customer to another customer entirely on the IPCablecom Network. One-way Hash A hash function that has an insignificant number of collisions upon output. IPCablecom 1.x The suite of IPCablecom specifications that support telephone service. Plaintext The original (unencrypted) state of a message or data. Also called cleartext. Pre-shared Key A shared secret key passed to both parties in a communication flow, using an unspecified manual or out-of-band mechanism. Privacy A way to ensure that information is not disclosed to any one other then the intended parties. Information is usually encrypted to provide confidentiality. Also known as confidentiality. Private Key The key used in public key cryptography that belongs to an individual entity and must be kept secret. Proxy A facility that indirectly provides some service or acts as a representative in delivering information, thereby eliminating the need for a host to support the service. Public Key The key used in public key cryptography that belongs to an individual entity and is distributed publicly. Other entities use this key to encrypt data to be sent to the owner of the key. Public Key A binding between an entity’s public key and one or more attributes relating to its Certificate identity, also known as a digital certificate. Public Key A procedure that uses a pair of keys, a public key and a private key, for encryption and Cryptography decryption, also known as an asymmetric algorithm. A user’s public key is publicly available for others to use to send a message to the owner of the key. A user’s private key is kept secret and is the only key that can decrypt messages sent encrypted by the user’s public key. Root Private Key The private signing key of the highest-level Certification Authority. It is normally used to sign public key certificates for lower-level Certification Authorities or other entities. Root Public Key The public key of the highest level Certification Authority, normally used to verify digital signatures generated with the corresponding root private key. Secret Key The cryptographic key used in a symmetric key algorithm, which results in the secrecy of the encrypted data depending solely upon keeping the key a secret, also known as a symmetric key. Session Key A cryptographic key intended to encrypt data for a limited period of time, typically between a pair of entities. Signed and Sealed An "envelope" of information which has been signed with a digital signature and sealed using encryption. Subflow A unidirectional flow of IP packets characterized by a single source and destination IP address and single source and destination UDP/TCP port. Symmetric Key The cryptographic key used in a symmetric key algorithm, which results in the secrecy of the encrypted data depending solely upon keeping the key a secret, also known as a secret key. 9 Systems Functions in the application layer related to the management of various Open Systems Management Interconnection (OSI) resources and their status across all layers of the OSI architecture. Transit Delays The time difference between the instant at which the first bit of a Protocol Data Unit (PDU) crosses one designated boundary, and the instant at which the last bit of the same PDU crosses a second designated boundary. Trunk An analog or digital connection from a circuit switch that carries user media content and may carry voice signaling (MF, R2, etc.). Tunnel Mode An IPsec (ESP or AH) mode that is applied to an IP tunnel, where an outer IP packet header (of an intermediate destination) is added on top of the original, inner IP header. In this case, the ESP or AH transform treats the inner IP header as if it were part of the packet payload. When the packet reaches the intermediate destination, the tunnel terminates and both the outer IP packet header and the IPsec ESP or AH transform are taken out. Upstream The direction from the subscriber location toward the headend. X.509 certificate A public key certificate specification developed as part of the ITU-T X.500 standards directory. 10 4 ABBREVIATIONS This specification uses the following abbreviations. AAA Authentication, Authorization and Accounting. AES Advanced Encryption Standard. A block cipher, used to encrypt the media traffic in IPCablecom. AF Assured Forwarding. This is a DiffServ Per Hop Behavior. AH Authentication header. An IPsec security protocol that provides message integrity for complete IP packets, including the IP header. AMA Automated Message Accounting. A standard form of call detail records (CDRs) developed and administered by Bellcore (now Telcordia Technologies). ASD Application-Specific Data. A field in some Kerberos key management messages that carries information specific to the security protocol for which the keys are being negotiated. AT Access Tandem. ATM Asynchronous Transfer Mode. A protocol for the transmission of a variety of digital signals using uniform 53-byte cells. BAF Bellcore AMA Format, also known as AMA. BCID Billing Correlation ID. BPI+ Baseline Privacy Plus Interface Specification. The security portion of the DOCSIS 1.1 standard that runs on the MAC layer. BSS Business Support System CA Certification Authority. A trusted organization that accepts certificate applications from entities, authenticates applications, issues certificates and maintains status information about certificates. CA Call Agent. The part of the CMS that maintains the communication state, and controls the line side of the communication. CBC Cipher Block Chaining mode. An option in block ciphers that combine (XOR) the previous block of ciphertext with the current block of plaintext before encrypting that block of the message. CBR Constant Bit Rate. CDR Call Detail Record. A single CDR is generated at the end of each billable activity. A single billable activity may also generate multiple CDRs. CIC Circuit Identification Code. In ANSI SS7, a two-octet number that uniquely identifies a DSO circuit within the scope of a single SS7 Point Code. CID Circuit ID (Pronounced "kid"). This uniquely identifies an ISUP DS0 circuit on a Media Gateway. It is a combination of the circuit’s SS7 gateway point code and Circuit Identification Code (CIC). The SS7 DPC is associated with the Signaling Gateway that has domain over the circuit in question. CIF Common Intermediate Format. CIR Committed Information Rate. CM DOCSIS Cable Modem. CMS Cryptographic Message Syntax. CMS Call Management Server. Controls the audio connections. Also called a Call Agent in MGCP/SGCP terminology. This is one example of an Application Server. CMTS Cable Modem Termination System. The device at a cable headend which implements the DOCSIS RFI MAC protocol and connects to CMs over an HFC network. 11 CMSS Call Management Server Signaling. Codec COder-DECoder. COPS Common Open Policy Service protocol. Defined in RFC2748. CoS Class of Service. The type 4 tuple of a DOCSIS configuration file. CRCX Create Connection. CSR Customer Service Representative. DA Directory Assistance. DE Default. This is a DiffServ Per Hop Behavior. DES Data Encryption Standard. DF Delivery Function. DHCP Dynamic Host Configuration Protocol. DHCP-D DHCP Default. Network Provider DHCP Server. DNS Domain Name Service. DOCSIS® Data-Over-Cable Service Interface Specifications. DPC Destination Point Code. In ANSI SS7, a 3-octet number which uniquely identifies an SS7 Signaling Point, either an SSP, STP, or SCP. DQoS Dynamic Quality-of-Service. Assigned on the fly for each communication depending on the QoS requested. DSA Dynamic Service Add. DSC Dynamic Service Change. DSCP DiffServ Code Point. A field in every IP packet that identifies the DiffServ Per Hop Behavior. In IP version 4, the TOS byte is redefined to be the DSCP. In IP version 6, the Traffic Class octet is used as the DSCP. DTMF Dual-tone Multi Frequency (tones). EF Expedited Forwarding. A DiffServ Per Hop Behavior. E-MTA Embedded MTA. A single node that contains both an MTA and a cable modem. EO End Office. ESP IPsec Encapsulating Security Payload. Protocol that provides both IP packet encryption and optional message integrity, not covering the IP packet header. ETSI European Telecommunications Standards Institute. F-link F-Links are SS7 links that directly connect two SS7 end points, such as two SSPs. ‘F’ stands for "Fully Associated." FEID Financial Entity ID. FGD Feature Group D signaling. FQDN Fully Qualified Domain Name. Refer to IETF RFC 2821 for details. GC Gate Controller. GTT Global Title Translation. HFC Hybrid Fiber/Coaxial. An HFC system is a broadband bi-directional shared media transmission system using fiber trunks between the headend and the fiber nodes, and coaxial distribution from the fiber nodes to the customer locations. HMAC Hashed Message Authentication Code. A message authentication algorithm, based on either SHA-1 or MD5 hash and defined in IETF RFC 2104. HTTP Hypertext Transfer Protocol. Refer to IETF RFC 1945 and RFC 2068. IANA Internet Assigned Numbered Authority. See www.ietf.org for details. 12 IC Inter-exchange Carrier. IETF Internet Engineering Task Force. A body responsible, among other things, for developing standards used on the Internet. See www.ietf.org for details. IKE Internet Key Exchange. A key-management mechanism used to negotiate and derive keys for SAs in IPsec. IKE– A notation defined to refer to the use of IKE with pre-shared keys for authentication. IKE+ A notation defined to refer to the use of IKE with X.509 certificates for authentication. IP Internet Protocol. An Internet network-layer protocol. IPsec Internet Protocol Security. A collection of Internet standards for protecting IP packets with encryption and authentication. ISDN Integrated Services Digital Network. ISTP Internet Signaling Transport Protocol. ISUP ISDN User Part. A protocol within the SS7 suite of protocols that is used for call signaling within an SS7 network. ITU International Telecommunication Union. ITU-T International Telecommunication Union–Telecommunication Standardization Sector. IVR Interactive Voice Response system. JIP Jurisdiction Information Parameter. The identity of the originating network element in ISUP. KDC Key Distribution Center. LATA Local Access and Transport Area. LD Long Distance. LIDB Line Information Database. Contains customer information required for real-time access such as calling card personal identification numbers (PINs) for real-time validation. LLC Logical Link Control. The Ethernet Packet header and optional 802.1P tag which may encapsulate an IP packet. A sublayer of the Data Link Layer. LNP Local Number Portability. Allows a customer to retain the same number when switching from one local service provider to another. LRN Location Routing Number. LSSGR LATA Switching Systems Generic Requirements. MAC Message Authentication Code. A fixed-length data item that is sent together with a message to ensure integrity, also known as a MIC. MAC Media Access Control. It is a sublayer of the Data Link Layer. It normally runs directly over the physical layer. MC Multipoint Controller. MCU Multipoint Conferencing Unit. MD5 Message Digest 5. A one-way hash algorithm that maps variable length plaintext into fixed- length (16 byte) ciphertext. MDCP Media Device Control Protocol. A media gateway control specification submitted to IETF by Lucent. Now called SCTP. MDCX Modify Connection. MDU Multi-Dwelling Unit. Multiple units within the same physical building. The term is usually associated with high-rise buildings. MEGACO Media Gateway Control IETF working group. See www.ietf.org for details. MF Multi-Frequency. 13 MG Media Gateway. Provides the bearer circuit interfaces to the PSTN and transcodes the media stream. MGC Media Gateway Controller. The overall controller function of the PSTN gateway. Receives, controls and mediates call-signaling information between the IPCablecom and PSTN. MGCP Media Gateway Control Protocol. Protocol follow-on to SGCP. Refer to IETF 2705. MIB Management Information Base. MIC Message Integrity Code. A fixed-length data item that is sent together with a message to ensure integrity, also known as a Message Authentication Code (MAC). MMC Multi-Point Mixing Controller. A conferencing device for mixing media streams of multiple connections. MSB Most Significant Bit. MSO Multi-System Operator. A cable company that operates many headend locations in several cities. MSU Message Signal Unit. MTA Multimedia Terminal Adapter. Contains the interface to a physical voice device, a network interface, CODECs, and all signaling and encapsulation functions required for VoIP transport, class features signaling, and QoS signaling. MTP The Message Transfer Part. A set of two protocols (MTP 2, MTP 3) within the SS7 suite of protocols that are used to implement physical, data link, and network-level transport facilities within an SS7 network. MWD Maximum Waiting Delay. NANP North American Numbering Plan. NANPNAT North American Numbering Plan Network Address Translation. NAT Network Network Address Translation. Layer 3 in the Open System Interconnection (OSI) architecture. Layer This layer provides services to establish a path between open systems. NCS Network Call Signaling. NPA-NXX Numbering Plan Area (more commonly known as area code) NXX (sometimes called exchange) represents the next three numbers of a traditional phone number. The N can be any number from 2-9 and the Xs can be any number. The combination of a phone number’s NPA- NXX will usually indicate the physical location of the call device. The exceptions include toll- free numbers and ported number (see LNP). NPDB Number Portability Data Base NTP Network Time Protocol. An internet standard used for synchronizing clocks of elements distributed on an IP network. NTSC National Television Standards Committee. Defines the analog color television broadcast standard used today in North America. OID Object Identification. OSP Operator Service Provider. OSS Operations Systems Support. The back-office software used for configuration, performance, fault, accounting, and security management. OSS-D OSS Default. Network Provider Provisioning Server. PAL Phase Alternate Line. The European color television format that evolved from the American NTSC standard. PCES IPCablecom Electronic Surveillance. PCM Pulse Code Modulation. A commonly employed algorithm to digitize an analog signal (such as a human voice) into a digital bit stream using simple analog-to-digital conversion techniques. 14 PDU Protocol Data Unit. PHS Payload Header Suppression. A DOCSIS technique for compressing the Ethernet, IP, and UDP headers of RTP packets. PKCROSS Public-Key Cryptography for Cross-Realm Authentication. Utilizes PKINIT for establishing the inter-realm keys and associated inter-realm policies to be applied in issuing cross-realm service tickets between realms and domains in support of Intradomain and Interdomain CMS-to-CMS signaling (CMSS). PKCS Public-Key Cryptography Standards. Published by RSA Data Security Inc. These Standards describe how to use public key cryptography in a reliable, secure and interoperable way. PKI Public-Key Infrastructure. A process for issuing public key certificates, which includes standards, Certification Authorities, communication between authorities and protocols for managing certification processes. PKINIT Public-Key Cryptography for Initial Authentication. The extension to the Kerberos protocol that provides a method for using public-key cryptography during initial authentication. PSC Payload Service Class Table, a MIB table that maps RTP payload Type to a Service Class Name. PSFR Provisioned Service Flow Reference. An SFR that appears in the DOCSIS configuration file. PSTN Public Switched Telephone Network. QCIF Quarter Common Intermediate Format. QoS Quality of Service. Guarantees network bandwidth and availability for applications. RADIUS Remote Authentication Dial-In User Service. An internet protocol (IETF RFC 2865 and RFC 2866) originally designed for allowing users dial-in access to the internet through remote servers. Its flexible design has allowed it to be extended well beyond its original intended use. RAS Registration, Admissions and Status. RAS Channel is an unreliable channel used to convey the RAS messages and bandwidth changes between two H.323 entities. RC4 Rivest Cipher 4. A variable length stream cipher. Optionally used to encrypt the media traffic in IPCablecom. RFC Request for Comments. Technical policy documents approved by the IETF which are available on the World Wide Web at http://www.ietf.cnri.reston.va.us/rfc.html. RFI The DOCSIS Radio Frequency Interface specification. RJ-11 Registered Jack-11. A standard 4-pin modular connector commonly used in the United States for connecting a phone unit into a wall jack. RKS Record Keeping Server. The device, which collects and correlates the various Event Messages. RSA A public-key, or asymmetric, cryptographic algorithm used to provide authentication and encryption services. RSA stands for the three inventors of the algorithm; Rivest, Shamir, Adleman. RSA Key Pair A public/private key pair created for use with the RSA cryptographic algorithm. RSVP Resource Reservation Protocol. RTCP Real-Time Control Protocol. RTO Retransmission Timeout. RTP Real-time Transport Protocol. A protocol for encapsulating encoded voice and video streams. Refer to IETF RFC 1889. SA Security Association. A one-way relationship between sender and receiver offering security services on the communication flow. SAID Security Association Identifier. Uniquely identifies SAs in the DOCSIS Baseline Privacy Plus Interface (BPI+) security protocol. 15 SCCP Signaling Connection Control Part. A protocol within the SS7 suite of protocols that provides two functions in addition to those provided within MTP. The first function is the ability to address applications within a signaling point. The second function is Global Title Translation. SCP Service Control Point. A Signaling Point within the SS7 network, identifiable by a Destination Point Code that provides database services to the network. SCTP Stream Control Transmission Protocol. SDP Session Description Protocol. SDU Service Data Unit. Information delivered as a unit between peer service access points. SF Service Flow. A unidirectional flow of packets on the RF interface of a DOCSIS system. SFID Service Flow ID. A 32-bit integer assigned by the CMTS to each DOCSIS Service Flow defined within a DOCSIS RF MAC domain. SFIDs are considered to be in either the upstream direction (USFID) or downstream direction (DSFID). Upstream Service Flow IDs and Downstream Service Flow IDs are allocated from the same SFID number space. SFR Service Flow Reference. A 16-bit message element used within the DOCSIS TLV parameters of Configuration Files and Dynamic Service messages to temporarily identify a defined Service Flow. The CMTS assigns a permanent SFID to each SFR of a message. SG Signaling Gateway. An SG is a signaling agent that receives/sends SCN native signaling at the edge of the IP network. In particular, the SS7 SG function translates variants ISUP and TCAP in an SS7-Internet Gateway to a common version of ISUP and TCAP. SGCP Simple Gateway Control Protocol. Earlier draft of MGCP. SHA – 1 Secure Hash Algorithm 1. A one-way hash algorithm. SID Service ID. A 14-bit number assigned by a CMTS to identify an upstream virtual circuit. Each SID separately requests and is granted the right to use upstream bandwidth. SIP Session Initiation Protocol. An application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. SIP+ Session Initiation Protocol Plus. An extension to SIP. S-MTA Standalone MTA. A single node that contains an MTA and a non-DOCSIS MAC (e.g., ethernet). SNMP Simple Network Management Protocol. SOHO Small Office/Home Office. SS7 Signaling System number 7. An architecture and set of protocols for performing out-of-band call signaling with a telephone network. SSP Service Switching Point. SSPs are points within the SS7 network that terminate SS7 signaling links and also originate, terminate, or tandem switch calls. STP Signal Transfer Point. A node within an SS7 network that routes signaling messages based on their destination address. This is essentially a packet switch for SS7. It may also perform additional routing services such as Global Title Translation. TCAP Transaction Capabilities Application Protocol. A protocol within the SS7 stack that is used for performing remote database transactions with a Signaling Control Point. TCP Transmission Control Protocol. TD Timeout for Disconnect. TFTP Trivial File Transfer Protocol. TFTP-D Default – Trivial File Transfer Protocol. TGS Ticket Granting Server. A sub-system of the KDC used to grant Kerberos tickets. TGW Telephony Gateway. TIPHON Telecommunications and Internet Protocol Harmonization Over Network. 16 TLV Type-Length-Value. A tuple within a DOCSIS configuration file. TN Telephone Number. ToD Time-of-Day Server. TOS Type of Service. An 8-bit field of every IP version 4 packet. In a DiffServ domain, the TOS byte is treated as the DiffServ Code Point, or DSCP. TSG Trunk Subgroup. UDP User Datagram Protocol. A connectionless protocol built upon Internet Protocol (IP). VAD Voice Activity Detection. VBR Variable Bit Rate. VoIP Voice-over-IP. 17 5 BACKGROUND 5.1 Traditional Telephony Billing Formats The telephony industry has traditionally recorded call detail transactions on telephone switches utilizing various standard and proprietary billing formats such as Automated Message Accounting (AMA), sometimes referred to as Bellcore AMA Format (BAF). The switches generate multiple transactions based upon the type of call the customer placed. These transactions are correlated and packaged into a single Call Detail Record (CDR) at the end of the service instance for billing purposes. In this traditional telephony model, services and awareness of "call state" is usually maintained in one or at most two nodes of the network, which makes such correlation relatively straightforward. The CDR is then delivered to the billing system for the purpose of placing a charge on the customer’s account. 5.2 Motivation for Event Based Billing The event-based approach to capturing information to be used for billing is necessary to accommodate the distributed architecture of IPCablecom. "Call state awareness" no longer resides in one or two network elements, but is instead spread out among many. Each network element MUST be responsible for generating Event Messages for the portion of the communication pertaining to them. The primary motivating factor behind articulating the structure and details of these various Event Messages is to support multi-vendor interoperability between network elements and record keeping servers. This specification defines the Event Message syntax and in addition it describes the transport protocols. Event based billing has the added advantage that it enables IPCablecom services to be billed in real-time, making the information about billable communications available as the network equipment processes them. This allows the system as a whole to be more responsive, allowing, for example, fraudulent behavior to be detected sooner, saving revenue for the provider. It also allows a more fully integrated solution, as it becomes possible for the billing system and the network equipment to exchange information about the availability of a service as the customer is requesting that service. With respect to the Event Message format, there are a large number of formats in use today. The most widely used formats carry the legacy of the traditional CDR, which is generated at the end of the call. While these formats capture much of the information content needed to bill for IPCablecom services, bringing along their full structure would make it difficult to support the real-time nature of certain enhanced IPCablecom services. This specification leverages the value of the information content from the existing billing formats, augmenting that with the distributed nature of the IPCablecom architecture. 5.3 Originating/Terminating Call Model to Support Customer Billing and Settlements The IPCablecom Event Messages contain sufficient per-call information to support customer billing for service as well as settlement between IPCablecom network providers for access. The information contained in the Event Messages supports a wide variety of billing and settlement models. IPCablecom does not mandate the use of specific billing or settlement models as these models are defined by and based on the specific business requirements of the individual MSOs. IPCablecom neither mandates nor precludes the use of a clearinghouse for settlements. 18 The IPCablecom Event Messages are based on a model where a call or service is divided into an originating half and a terminating half. The originating CMS or MGC MUST generate a unique Billing Correlation ID (BCID) to identify all Event Messages associated with the originating half of the call. The terminating CMS or MGC MUST generate a unique BCID to identify all Event messages associated with the terminating half of the call. For each half of the call or service, the set of IPCablecom network elements that generate Event Messages (CMS, MGC, CMTS) must provide all necessary information required for billing and/or settlements as appropriate based on the service. The information generated by the originating half MUST be sent to the RKS supporting the originating half. The information generated by the terminating half MUST be sent to the RKS supporting the terminating half. The IPCablecom network elements also generate Event Messages that are not associated with any call. For those cases, the network element generating the Event Message MUST generate a unique BCID for the event and send the Event Message to appropriate RKS supporting the network element. The IPCablecom Event Messages support billing and settlement for single-zone, intra-domain and inter-domain architectures. In most cases, the basic set of Event Messages, their associated attributes, and the triggers for the Event Message are identical for these three architectures. In the case of intra-domain and inter-domain architectures, additional triggers exist for a subset of the Event Messages. The IPCablecom Event Message specification details these requirements. For the purposes of settlements, each IPCablecom zone is divided into one or more logical Financial Entities. Settlements occur between Financial Entities. Each Financial Entity is identified by a Financial Entity ID (FEID). FEIDs are pre-assigned to every CMS and MGC in the IPCablecom network. A single CMS may be assigned at most one FEID. One or more CMSes may be assigned the same FEID. In the Intra-domain and Inter-domain cases, it is assumed that the originating and terminating CMSes exchange BCIDs and FEIDs through a vendor prioprietary signaling interface. For example, the originating CMS sends its BCID and FEID in the first session establishment signaling message while the terminating CMS sends its BCID and FEID in the first response to the first session establishment signaling message. 5.4 Real-Time Billing The billing system can be regarded as a functional block of the back office Operations Support System (OSS). The inputs to the billing system are the billing events and the outputs are the account balance and invoice. The billing system relates the billing events to the account balance by rating the events according to the pricing structure and other business logic. Real-time Billing Systems relate the billing events to the account balance as events occur. As the billing system receives these real-time billing events, its rating engine rates the events and immediately posts balances. Real-time Billing Systems may be required to support advanced IPCablecom features such as pre-paid calling card, real-time fraud prevention, and real-time credit enforcement. The IPCablecom Event Message architecture can be used to support both real-time and batch billing systems. 5.5 Real-Time and Batch Event Message Delivery Event Messages may be delivered to the RKS in real time as they are created. This enables support for a growing number of services that require purchase limits such as prepaid calling cards. As an alternative, Event Messages may be stored for some period of time and batched together before being sent to the RKS. This approach provides a more efficient use of network resources. 5.6 Terminology and Concepts This section defines terminology associated with usage data as it relates to IPCablecom Services. The concept of a "call" is well understood and used within the telecommunications marketplace today. A traditional telephony "call" involves establishing a dedicated, circuit-switched path between the calling and called parties. Packet-switched architectures, including IPCablecom, do not establish any such dedicated paths. To the contrary, the IPCablecom 19 architecture assumes a shared medium between the head-end and the customer, as compared to the dedicated loop plant in traditional telephony; and during a traditional telephone call, as noted above, a circuit-switched "connection" is established between the parties, whereas packet switching is inherently "connectionless." All that said, the term "call" is sufficiently well entrenched that it will be used in this document to refer to packet-mode voice communications between two parties over an IPCablecom network, even though in technical terms (as will be seen) there is little resemblance to a traditional telephone "call." It is envisioned that many new voice, video, data and other multimedia services will be developed to take advantage of the inherent extensibility of the IPCablecom architecture. These new services, which likely will not be derived from traditional telephony principals, will be based on the term transaction, which is more indicative of the data flows across the IPCablecom network. The Event Message structure is designed to be flexible and enable the addition of new IPCablecom services and features while maintaining backward compatibility with existing applications. Event Messages MAY support information required for billing of DOCSIS data services, OpenCable video services, and the encapsulation of vendor specific proprietary data. Service Call 1 or IPCa blec om Call 2 or IPCa blec om Call n or IPCablecom Tra nsaction 1 Tra nsaction 2 T ransaction n Event Event Event E vent Message 1 Message 2 Message 3 M essa ge n Figure 3. IPCablecom Terminology 5.6.1 Service A service is an individual or package of communications features a subscriber may select. A service is identified by a set of one or more "calls" or transactions that deliver the desired functionality to the subscriber. Examples of a service include: a voice communication between two local IPCablecom subscribers, a 3-way call, pay-per-view movie, and a web surfing session. A service may be instantaneous or persist over time. Service in the context of IPCablecom 1.0 implies voice communications only and may not necessarily apply to the variety of other services such as Data, traditional IP, E-Commerce, etc. 5.6.2 IPCablecom Transaction An IPCablecom transaction is a collection of events on the IPCablecom network when delivering a service to a subscriber. Event Messages for the same transaction are identified by one unique BCID (as described in Table 35). For some services, multiple transactions may be required to provide information that is necessary to collect the total usage for the service. Multiple Event Messages may be required to track resources for each individual service used. A Transaction may persist over time. 20 5.6.3 Call A call is an instance of user-initiated voice communication capabilities. In traditional telephony, a call is generally considered as the establishment of connectivity directly between two points: originating party and terminating party. In the IPCablecom context, as noted above, the communication between the parties is "connectionless" in the traditional sense. 5.6.4 Event Message An Event Message is a set of data, representative of an event in the IPCablecom architecture that could be indicative of usage of one or more billable IPCablecom capabilities. An Event Message by itself may not be fully indicative of a customer’s billable activities, but an Event Message correlated with other Event Messages builds the basis of a billable Usage Detail Record. 5.6.5 Attribute An Event Message Attribute is a predefined data element described by an attribute definition and attribute type. 5.7 Supporting Documentation A number of documents and specifications describe the IPCablecom project. The IPCablecom Architecture Framework [10] is the starting point for understanding the IPCablecom project and the various IPCablecom Interface Specifications, technical reports and other IPCablecom documents. 21 6 IPCABLECOM OBJECTIVES 6.1 IPCablecom 1.0 Required Services and Capabilities IPCablecom 1.0 provides basic voice capabilities and therefore MUST support Event Messages for the following services. These services are described in more detail in Section 8 of this document. • Interconnection with circuit-switched PSTN • Support for 911 emergency services • n11 (411, 611, etc.) assume outside directory service • Toll-free services (800, 888, 877…) • Operator services • Call block service • Call waiting service • Call forwarding/call redirection services • Return call service • Repeat call service • Voice mail service • Message waiting indicator service (email/voice mail notification) 6.2 Additional IPCablecom Supported Services and Capabilities The following represents a list of possible additional IPCablecom services that MAY be supported. The list, though meant as a rough guideline, is by no means comprehensive, and it is expected that as the scope of services grows, this list will be expanded. These services are not defined in more detail in this document. • Three-Way Call • Call transfer • Speed dialing • Caller name and number • Caller name and number privacy • Selective screening services • Pay-per-communication services (900, etc.) • Distinctive notification (to identify callee in a multiple-party household) • Priority notification (to prioritize incoming communications) • Customer Originated Trace • Selective forwarding • Rejection (activate and deactivate) 22 • Teletype translation services • Multi-line hunt group services • Virtual second line (multiple lines) • Alternate billing methods (collect, third number billed, credit card, pre-paid services, etc.) 6.2.1 IPCablecom 1.1 Supported Services and Capabilities The text in this section has been removed because it is not within the scope of IPCablecom 1.0. 6.2.2 IPCablecom Multimedia The text in this section has been removed because it is not within the scope of IPCablecom 1.0 6.3 Assumptions The following assumptions have been made which apply to the entire document: • IPCablecom 1.0 does not specify the interface between an RKS and a billing system. • All IP based Intelligent Peripherals (these include Announcement Servers, for example) will be connected to the originating CMS or MGC. • IPCablecom 1.0 does NOT support Line Information Database (LIDB) queries. Calls requiring LIDB determination, such as calling card personal identification number validation, are sent directly to the PSTN. • IPCablecom 1.0 supports local number portability (LNP). Following information and references are applicable to LNP: 1. Location Routing Number (LRN) identifies routing information for a ported called party number; and Jurisdiction Information Parameter (JIP) identifies the network element where the ported calling party number is currently getting the service from. The JIP parameter received in SS7 message is needed for billing settlement purpose. (References: GR-317-CORE, GR-2936-CORE, and GR-1100-CORE). 2. The originating half determines if the caller is ported-in and the terminating half determines if the called party is ported-in. The CMS or MGC determines if a number is ported based on different data including a) provisioned data, b) signaling messages c) Number Portability data base. The source of Number Portability information is specified in Technical Requirements on Number portability systems [26] Table 8. • Non-IPCablecom network elements, such as those residing in the public switched telephone network (PSTN) to which an IPCablecom system may interconnect with, will NOT generate and send Event Messages to the RKS. • PSTN Intelligent Peripheral Event Messages are generated by the originating CMS. • IPCablecom 1.0 Event Messages currently only support messages for actual billable events. This document does not specify messages related to provisioning of services by the operator of an IPCablecom network. This document does support Event Messages for Subscriber service activation. This document does not specify messages related to selection of an entity other than the IPCablecom network operator to handle off-network activities (e.g., inter-exchange communications). • The initiating party number and the terminating party number are the only two attributes defined in IPCablecom 1.0 that can be used to associate a subscriber with usage of network resources. • IPCablecom 1.0 supports interconnection to both Class 4 and Class 5 Switches. • IPCablecom supports a 911 Trunk Group. 23 • IPCablecom 1.0 trusted network elements are expected to be pre-provisioned with a minimum set of data using a vendor-proprietary mechanism. Examples of this data may include: a) Element Type, identifying the element as a CMTS, CMS, or MGC b) Element ID c) A list of which Event Messages are required and which Event Messages are optional as defined by the MSO. For each of these Event Messages, identify if the Event Messages are to: 1) be transported to the RKS as a single Event Message in real-time or 2) batched and transported to the RKS as multiple Event Messages at a later time; 3) provide capability to configure both how many Event Messages are batched before being sent to the RKS. d) Number of days to keep Event Messages for short-term storage e) Others • Enable or disable Media_Alive Event Message, configure the frequency of Media_Alive message (suggested 0 to 1440 minutes, with 0 being no Media_Alive Events). 24 7 EVENT MESSAGES ARCHITECTURE Figure 4 shows a representative IPCablecom Event Messages Architecture. By standardizing the transport, syntax and collection of appropriate Event Message attributes from a distributed set of network elements, the IPCablecom architecture provides a single reference point to interface to existing billing, settlement, reconciliation, and other systems. Note that only the shaded components are included within the scope of the IPCablecom 1.0 architecture. Interfaces between the RKS and the shaded IPCablecom network elements are within scope of IPCablecom 1.0. Interfaces between the RKS and back office servers or applications are NOT within the scope of IPCablecom 1.0. It should be understood that the back office servers and applications shown Figure 4 are representative, and are not mandated by the IPCablecom 1.0 architecture. IPCablecom Event Messages IPCablecom Non-IPCablec om • Inter-Carrier Settlements Event Network Element Mes sages • Batc h Billing Sys tems Network Element Event • Pre-Paid Servic es RKS Messages • Real-Time Billing Network Element Event Sys tems Mess ages • Fraud Detec tion Sys tems Figure 4. Representative IPCablecom Event Messages Architecture 7.1 IPCablecom Event Message Collection Event Message collection occurs as follows: when trigger events occur (such as call signaling starts, activation of QoS service resources, call signaling stops, etc.), the relevant IPCablecom network element generates an Event Message. These messages may be sent immediately to the RKS, or a group of messages may be collected and sent at a later time. In either case, the actual time of the trigger event is reported allowing the back office applications to accurately calculate time-based resource usage. As these Event Messages are accumulated within the RKS, the network operator can then export them into their billing systems based on their business requirements. The data from multiple network elements are linked to a transaction (e.g. call) via a unique BCID, which can be leveraged for reconciliation and non-repudiation purposes. 7.2 IPCablecom Network Elements The IPCablecom architecture supports a system capable of creating, collecting, and delivering usage data from a subset of IPCablecom network elements to a cable operator’s back office applications. Trusted IPCablecom 1.0 network elements that create Event Messages include the Call Management Server (CMS) and Cable Modem Termination System (CMTS), Media Gateway Controller (MGC). The IPCablecom architecture contains trusted and untrusted network elements. Trusted network elements are typically located within a MSO’s facility and are controlled by the MSO. Untrusted network elements are typically 25 located within the consumer’s home or outside of the MSO’s facility or exclusive control. In the IPCablecom 1.0 architecture, Event Messages are only accepted from trusted IPCablecome network elements. The IPCablecom Architecture Document [10] contains a detailed description of the IPCablecom network elements. A brief explanation of the IPCablecom network elements that will most likely generate IPCablecom Event Messages is listed in this section for completeness. 7.2.1 Call Management Server (CMS) The Call Management Server (CMS) provides signaling services necessary for voice communications. The primary purpose of the CMS is to establish standard "calls," as that term is used in the IPCablecom context. The media servers also provide support services for the media streams such as conference mixing bridges and announcement servers. The CMS MUST create a BCID: • on receipt of an NCS-signaling NTFY message from an MTA or • when an Event Message not associated with any call is generated. The CMS MUST send the BCID and other data as defined in Table 1 to the CMTS via the DQoS GateSet message as specified in the DQoS specification [3]. Table 1. IPCablecom Event Reporting Common Elements BCID (see Table 35) IP address and port number of the primary RKS IP address and port number of the secondary RKS Flag indicating if CMTS should send Event Messages to the RKS in real-time The CMS MUST generate the appropriate Event Messages as defined in this specification. 7.2.2 Media Gateway Controller (MGC) The Media Gateway Controller (MGC) is the overall controller function of the PSTN gateway. It receives, mediates, and routes call signaling information between the IPCablecom and PSTN domains and it maintains and controls the overall call state for all calls connecting to and from the PSTN. It controls the Media Gateway function and communicates with the Signaling Gateway function via the MGC-SG protocol defined for the major protocol family in question, i.e., ISUP, In-band or TCAP. The MGC MUST create a BCID on receipt of: • an SS7 IAM message or • when an Event Message not associated with any call is generated. The MGC MUST generate the appropriate Event Messages as defined in this specification. 7.2.3 Cable Modem Termination System (CMTS) The Cable Modem Termination System terminates the connection from the cable modem on the customer premises into the IPCablecom network. The CMTS generates QoS Event Messages. QoS event messages are generated individually for both upstream and downstream bandwidth. The CMTS MUST generate the appropriate Event Messages as defined in this specification. For all EM messages it generates other than Time_Change, the CMTS MUST use the unique Billing-Correlation-ID assigned by the CMS and received from the CMS in the Event-Generation-Info object of the DQoS Gate-Set message as defined in section 5.3.2.7 of DQoS [3]. See section 9.16 for the generation of BCID in Time_Change events. 26 7.2.4 Record Keeping Server (RKS) The Record Keeping Server (RKS) is a trusted network element function. In many cases, for simplicity reasons, the RKS is depicted in this document as a separate standalone element, but this specification does not preclude a CMS, Billing System, or other application from performing the RKS functionality. The RKS is the mediation layer between the call signaling and transport layer and the back-office applications. The RKS is expected to pre-process the data from the Call Signaling and Transport layer and present it to the back-office applications in the format and within the time constraints deemed necessary by the MSO. The RKS also, at a minimum, is a short-term repository for IPCablecom Event Messages. It receives Event Messages from various trusted IPCablecom network elements. The RKS assembles the Event Messages into coherent sets, which are then made available to a usage-processing platform and potentially to several other back office systems. It acts as the demarcation point between the IPCablecom network and the back office applications. Figure 5 gives a representative RKS deployment for information only and does not imply an implementation requirement. Legend: Vendor-Defined Interface PacketCable-Defined Interface RKS Hierarchy RKS RKS Regional Data Center Backup RKS Farm Zone 1 Zone 2 Zone N CMS RKS CMS RKS *** CMS RKS CMTS 1 CMTS 2 CMTS 3 CMTS K CMTS 1 CMTS 2 CMTS 3 CMTS K CMTS 1 CMTS 2 CMTS 3 CMTS K C C C C C C C C C C C C A A A A A A A A A A A A B B B B B B B B B B B B L L L L L L L L L L L L E E E E E E E E E E E E P P P P P P P P P P P P L L L L L L L L L L L L A A A A A A A A A A A A N N N N N N N N N N N N T T T T T T T T T T T T Figure 5. Example RKS Architecture The RKS is expected to perform the following functions: • The RKS MUST receive Event Messages. • The RKS MUST be capable of correlating all Event Messages related to an individual call and have an extensible output to meet the needs of the downstream applications. 27 • The RKS MUST assemble Events and Determine Completeness. This MUST include the capability to distinguish Event Messages, and recognize when a complete set, representing a coherent set of billing data is available for transport to the back office system. • The RKS MUST provide interface network functions that require real time or near real time based on priority and where messages are being sent, as defined in Section 9. For example, a call may be sent real-time and a report may be sent at night. The correlation process MUST be user definable to support the various call events defined herein and defined in the future. • The RKS MUST have the ability to store the Event Messages for at least one week or until sent to the other back office systems and successful receipt is acknowledged from those systems. • The RKS MUST have the ability to dump the Event Messages to some other type of offline storage device on a regular basis (CD, tape, or other media) for retrieval and regulatory purposes. The following list deals with other possible capabilities of an RKS. They are therefore beyond the scope of the requirements of this current document, and are included here for informational use only. Decisions on these optional requirements will be based upon the MSO response to many regulatory and business variables. • An RKS-RKS security interface MAY be required. IPCablecom 1.0 does not define this interface. The security interface between the RKS and other IPCablecom trusted network elements is defined in [2]. • The RKS MAY support Backup and Recovery. This includes a nominal ability to restore the state and contents of billing data in the event of application or platform failures. • The RKS MAY support distribution of billing data to all appropriate systems. This includes the implementation of a protocol that ensures data integrity and reliability on the usage collator interface. • The RKS MAY support monitoring and reporting. This includes the ability to produce and send alarms to a network management system, and create various audit and measurement reports. • The RKS MAY allow remote testing and maintenance capability. • The RKS MAY support a Service Creation Environment. • The RKS MAY support user defined fault handling in the case of incomplete Event Messages or other such anomalies. • The RKS MAY support multiple downstream applications, and various transport methodologies. • The RKS MAY support full auditability of data and processes. • The RKS MAY support a user definable long-term storage mechanism. • The RKS MAY support disaster planning and recovery processing. 7.3 General IPCablecom Network Element Requirements This section lists requirements placed on the IPCablecom network elements: The CMS, CMTS, and MGC MUST create a security relationship with each RKS that these network elements will send Event Messages as defined in the IPCablecom Security Specification [2]. The CMS MUST support multiple sets of primary and secondary RKSes, which might be required in cases in which total Event Message traffic exceeds the throughput capability of a single RKS. For each call, the CMS or the MGC MUST create a unique BCID, identify the primary and secondary RKS and determine whether the Event Messages are to be delivered in real time or batched and sent at a later time. 28 • The trusted IPCablecom network elements that generate Event Messages MUST timestamp Event Messages in 1 millisecond granularity +/- 100 milliseconds based on information reported by network time sources such as edge devices (Clients and Gateways). • All IPCablecom network elements that generate Event Messages MUST synchronize their clocks at least once per hour to a network clock source. This synchronization MUST assure the reporting device’s own clock remains within ±100 milliseconds real time of the last synchronization value. • IPCablecom network elements that generate Event Messages MUST support Network Time Protocol (NTP) time synchronization as defined in [8]. • The IPCablecom network elements MUST support transport to a primary RKS and failover to a secondary RKS when communication with the primary RKS fails for any reason (including situations where the primary RKS becomes inoperable). • IPCablecom network elements MUST support the transport of a single Event Message as well as a batch of Event Messages (batch mode = multiple Event Message per single Radium message). • Each trusted IPCablecom network element that generates an Event Message MUST identify itself with a static, unique element ID. • Implementations that combine CMS and MGC functionality MAY share a single element ID.Event Messages generated by a combined CMS/MGC MUST indicate which IPCablecom functional element (e.g. MGC or CMS) initiated the message using the Element_Type field in the EM_Header. 7.4 Event Message Interfaces This section describes the interfaces between the IPCablecom network elements that are involved in the Event Messages process. It should be noted that additional requirements are imposed on these by other IPCablecom specifications and that the requirements listed in this document are specific to Event Messages. It should also be noted that additional requirements are specified for these interfaces and these IPCablecom network elements in other sections of this document. MGC pkt-em5 pkt-em2 Record CMS pkt-em6 CMS pkt-em3 Keeping Server pkt-em1* Note: * indicates that the Billing pkt-em4 Correlation ID and other data defined CMTS in Table 1 is carried on an existing signaling interface. Figure 6. Event Message Billing Interfaces 7.4.1 CMS to CMTS (pkt-em1*) The CMS to CMTS interface is defined by the IPCablecom DQoS protocol [3]. 29 The CMS sends the BCID and other data as defined in Table 1 to the CMTS via the DQoS GateSet message as specified in the DQoS specification [3]. 7.4.2 CMS to MGC (pkt-em2) The CMS and MGC exchange originating/terminating information such as BCID, FEID, etc. across this interface. The protocol for this interface is undefined in IPCablecom 1.0. 7.4.3 CMS to RKS (pkt-em3) The CMS to RKS interface is defined by the IPCablecom Security Specification [2] and also by the Event Message transport and syntax rules defined in this document. 7.4.4 CMTS to RKS (pkt-em4) The CMTS to RKS interface is defined by the IPCablecom Security Specification [2] and by the Event Message transport and syntax rules defined in this document. 7.4.5 MGC to RKS (pkt-em5) The MGC to RKS interface is defined by the IPCablecom Security Specification [2] and by the Event Message transport and syntax rules defined in this document. 7.4.6 CMS to CMS (pkt-em6) The originating CMS and terminating CMS exchange originating/terminating information such as BCID, FEID, etc., across this interface. The protocol for this interface is undefined in IPCablecom 1.0 7.4.7 Security Requirements When the network IPSec Security Associations are established, security keys MUST be created and exchanged between each RKS (primary, secondary, etc) and every CMS, CMTS, and MGC that will send Event Messages to any of those RKSes. The Event Messages are sent from the CMS, CMTS, and MGC to the RKS using one of the supported transport mechanisms, each of which it must be possible to secure with IPSec. Refer to the IPCablecom Security Specification [2] for a detailed description of the security requirements for the IPCablecom Event Message interfaces. 30 8 IPCABLECOM SERVICES AND THEIR ASSOCIATED EVENT MESSAGES This section defines the supported IPCablecom 1.0 Services and their associated Event Messages. Although many of the IPCablecom 1.0 services can be billed using the Event Messages and attributes defined in this document, the services described in this section are currently limited to IPCablecom 1.0 services. In order to identify appropriate Event Messages required for each service, representative call flows were developed for IPCablecom 1.0 basic call configurations. The IPCablecom Call Flow documents [12], [13], [14], provide a description of the call configuration along with any assumptions made about a specific service and an example call flow. It is not the intention of these call flow documents to limit the realization of any of these services to any specific implementation. 8.1 IPCablecom Call Configurations This section describes the three basic IPCablecom 1.0 call configurations: On-Net to On-Net, On-Net to Off-Net, and Off-Net to On-Net. A required minimum set of Event Messages MUST be generated for each of these three basic call configurations. If specific services are initiated along with the basic call, then refer to Section 8.2 for a list of additional Event Messages for these specific services. 8.1.1 On-Net to On-Net Call Configuration A single-zone On-Net to On-Net call is within a single MSO’s network, using two different MTAs that are both connected to the same CMS. For IPCablecom 1.0, it is assumed that both the originating and terminating MTAs are using the same CMS and possibly two different CMTSes. Refer to the IPCablecom Call Flow document [12] for a complete description of an example single-zone On-Net to On-Net call configuration including an example call flow showing the triggers for these Event Messages. Both intra-domain and inter-domain On-Net to On-Net call configurations use two different MTAs that are both connected to two different CMSes. For any On-Net to On-Net call configuration, the originating half and the terminating half of the call MUST each generate a complete set of Event Messages. Table 2. On-Net to On-Net Call Configuration Event Message Required or Comments Optional Database_Query O If LNP is required Signaling_Start R CMS is starting signaling to support a call start QoS_Reserve R CMTS is reserving QoS QoS_Commit R CMTS is committing QoS Intelligent_Peripheral_Usage_Start O e.g. if an announcement is needed Intelligent_Peripheral_Usage_Stop O e.g., if an announcement is needed Call_Answer R Indicates start of media stream Call_Disconnect R Indicates termination of media steam QoS_Release R CMTS is releasing QoS Signaling_Stop R Signaling for the service is complete 31 8.1.2 On-Net to Off-Net Call Configuration (Outgoing PSTN Interconnect) The only Off-Net interconnection supported by IPCablecom 1.0 is to the PSTN. Therefore the CMS sends all Off- Net calls to the PSTN. The Interconnect_Start Event Message identifies the type of Off-Net trunk, for example SS7/FG-D trunks, Type 1/DTMF trunks or some other type of trunks as required. The Off-Net call (i.e. non-special access codes calls e.g. 800, 900, N11 etc.) may require an LNP query. The CMS MUST generate a database query Event Message each time a LNP database is accessed (regardless of whether this query is requested from a PSTN database or IP database). Refer to the IPCablecom Call Flow document [13] for a complete description of this call configuration including an example call flow showing the triggers for these Event Messages. For any On-Net to Off-Net call configuration, the originating half and the terminating half of the call MUST each generate a complete set of Event Messages. Table 3. On-Net to Off-Net Call Configuration Event Message Required or Comments Optional Database_Query O If LNP is Required Signaling_Start R Starting signaling to support a call start QoS_Reserve R CMTS reserves QoS QoS_Commit R CMTS commits QoS Intelligent_Peripheral_Usage_Start O e.g. if an announcement is needed Intelligent_Peripheral_Usage_Stop O e.g. if an announcement is needed Interconnect_Start R For call setup Call_Answer R Indicates start of media stream Call_Disconnect R Indicates termination of media steam Interconnect_Stop R For call tear-down QoS_Release R CMTS releases bandwidth Signaling_Stop R Indicates end of signaling 8.1.3 Off-Net to On-Net Service (Incoming PSTN Interconnection) The CMS receives calls that are incoming from other entities and establishes communications with the MTA on the MSO’s network. For IPCablecom Release 1.0, it is assumed that all incoming calls are from the PSTN. Refer to the IPCablecom Call Flow document [14] for a complete description of this call configuration including an example call flow showing the triggers for these Event Messages. For any Off-Net to On-Net call configuration, the originating half and the terminating half of the call MUST each generate a complete set of Event Messages. 32 Table 4. Off-Net to On-Net Call Configuration Event Message Required or Comments Optional Signaling_Start R Starting signaling to service a request to start a call Interconnect_Start R For call setup QoS_Reserve R CMTS reserves bandwidth QoS_Commit R CMTS commits bandwidth Intelligent_Peripheral_Usage_Start O e.g. if an announcement is needed Intelligent_Peripheral_Usage_Stop O e.g. if an announcement is needed Call_Answer R Indicates start of media stream Call_Disconnect R Indicates termination of media steam Interconnect_Stop R For call tear-down QoS_Release R CMTS releases bandwidth. Signaling_Stop R Indicates end of signaling 8.2 Specific Services A basic set of Event Messages MUST be generated based on the type of call configuration: On-Net to On-Net, On- Net to Off-Net, Off-Net to On-Net. The basic set of Event Messages is described in Section 8.1. This section describes additional Event Messages that MUST be generated along with the basic set in order to describe specific IPCablecom 1.0 services. This section also describes optional Event Messages that MAY be generated along with the basic set and any additional required Event Messages. These additional required and optional Event Messages are identified in the tables in this section. It is expected that these additional Event Messages will be able to be generated regardless of the particular implementation of the service. 8.2.1 911 Service A 911 call follows the standard On-Net to Off-Net Event Message flow described above in Section 8.1.2. 911 calls require special treatment. In IPCablecom Release 1.0, it is assumed that the MSO sends 911 calls to the PSTN on a special trunk. The Trunk Group ID is captured in the Interconnect_Start and Interconnect_Stop Event Messages, and it is assumed that the RKS or some element downstream of the RKS has the capability of inferring this trunk group type from that unique Trunk Group ID. No additional Event Messages are required beyond the basic ones listed for an On-Net to Off-Net call in Section 8.1.2. 8.2.2 Other N11 Services (311, 411, 611) These calls are identical to the 911 call both from a call flow and Event Message perspective. The determination of whether to bill or not can be performed at the Billing System based on the "Called Party Number" attribute. For example, charges for calls to 411 for directory assistance may be different than charges for 911 emergency calls, which are free, but the Event Messages, which capture the usage for both types of services, are the same. They would differ only in the content of specific attribute values such as the Called_Party_Number (411 vs. 911) within the Call_Answer Event Message. The billing system is expected to make a determination as to how much to bill the customer based on these attributes together with other factors such as whether the call is completed or not. 33 8.2.3 Toll-Free Services Toll-Free Services follow the standard On-Net to Off-Net Event Message flow described above in Section 8.1.2. In IPCablecom 1.0, toll-free calls can be handled two ways: • Send all Toll-free calls to the PSTN on a special trunk. The call is treated exactly like the 911 case discussed in Section 8.2.1 in terms of Event Messages, meaning that no additional Event Messages are required. • Initiate a query to the toll-free SCP (in IP or PSTN) and, depending on the specified Carrier Identification Code, route the call to the appropriate network. A Database_Query Event Message MUST be generated to record the query to the toll-free database. Table 5. Toll-Free Services Additional Event Messages Required or Comments Optional Database_Query R Not used for Scenario 1 but required for Scenario 2 8.2.4 Operator Services Operator Services follow the standard On-Net to Off-Net Event Message configuration described above in Section 8.1.2. There are no new additional Event Messages beyond those already described for the On-Net to Off-Net calls in that section. The CMS sends that call to the designated Operator Service Provider using the PSTN. There may be multiple Operator Service Providers with which the MSO has contracts. The caller just dials "0." The CMS generates an event identifying that call as 0- (denoting the single digit "0" dialed without any subsequent digits) with "0" in the Called number field. The CMS replaces the "0" in the Called Number field with the number of the Operator Service Provider (OSP). These parameters are sent to PSTN so that call can be sent via PSTN to the OSP. It is assumed dedicated private lines to the OSP from each IP-switch are impractical and expensive for MSO and not considered as an option. For the purposes of IPCablecom 1.0, it is assumed that operator services encompasses only 0- services. 0+ service, in which the customer keys the dialed number in together with the initial "0", is not supported in IPCablecom 1.0. 8.2.5 Call Block Service Event Messages are generated for Call Block Service only if the CMS blocks a call. Call Blocking is supported by all of the three basic call configurations: On-Net to On-Net, On-Net to Off-Net, and Off-Net to On-Net. The CMS can block calls depending on the policies laid out by the MSO. For example, the MSO may allow the end- user to block all 900 calls at the user’s request. As another example, the MSO may recognize some calls as fraudulent and block those fraudulent calls. In this case an Event Message needs to be generated with some reason attributes as to why the call was blocked. In addition, depending on the type of blockage, the MSO may desire to play an appropriate announcement (e.g. "Sorry your time is up …."). The CMS may initiate another call to the Announcement Server via the PSTN and play it to the caller. A series of Event Messages will be generated for this call, using the same BCID as the standard Event Messages associated with the off-hook, dialing, etc., which is not expected to be used for billing this call to the end-user. 34 Table 6. Call Block Service Additional Event Messages Required or Comments Optional Service_Instance R None Intelligent_Peripheral_Usage_Start O Intelligent_Peripheral_Usage_Stop O 8.2.6 Call Waiting Service At any given time the caller may be talking and will hear the call waiting tone when another call is incoming. It is understood that at some point prior to this call, the called party subscribed to call waiting service. The called party can switch back and forth between the two calls by using the flash hook. Call Waiting can be supported by any of the three basic call configurations: On-Net to On-Net, On-Net to Off-Net, and Off-Net to On-Net. The call flow is as follows: • There is an existing call to a number connected via the MTA/CMTS/CMS. Another call attempt is made to that number, the CMS: • Verifies that an existing call is already in progress, • Checks its internal database to verify whether the called party has subscribed to Call Waiting, if yes: • Establishes a voice connection to the Announcement Server (which will play the call waiting tone), • Creates a Event Message indicating that Call Waiting is being initiated, • Mixes the two voice calls (the currently established voice call and the Call Waiting tone voice call) so that the called party can hear the call waiting tone. It is assumed that Call Waiting only supports two calls (one active and the other on hold) in IPCablecom 1.0. The call on hold will not be connected to any announcement server. Both of the calls between which the subscriber is switching generate a complete set of Event Messages on their own as detailed in Sections 8.1.2 and 8.1.3, but there may also be three additional Event Messages associated with this instance of Call Waiting, as detailed below. If the Announcement Server is located on the PSTN, then the previously discussed Call_Answer and Call_Disconnect Event Messages are generated for this call. Table 7. Call Waiting Service Event Message Required or Comments Optional Interconnect_Start O Required only if Announcement Server for Call Waiting tone is Off-Net on PSTN Interconnect_Stop O Required only if Announcement Server for Call Waiting tone is Off-Net Intelligent_Peripheral_Usage_Start O Required only if Announcement Server On-Net Intelligent_Peripheral_Usage_Stop O Required only if Announcement Server On-Net Service_Instance R None 35 8.2.7 Call Forwarding Service Call Forwarding Service applies only to calls terminating On-Net as described in Sections 8.1.1 and 8.1.3. The CMS gets notification that a call needs to be completed to a specific dialed number/end device. The CMS checks its internal database and determines that the called number has subscribed to Call Forwarding, Call Forwarding is currently active, and the forwarding number is XYZ. The CMS initiates another call to the forwarded number on behalf of the original calling party. The CMS MUST generate a Service_Instance Event Message with the Calling_Party_Number attribute containing the original calling party number, the Charge_Number attribute containing the original called party number (the party number of the subscriber who has call forwarding service enabled), and the Called_Party_Number containing the forwarded number XYZ. Event Messages are generated for the fact that a Call Forwarding service instance was initiated. The BCID for this leg is different than the first call. The rationale for using the Related BCID as the common identifier for call forwarding is that it may be desirable to flag calls made automatically by invocation of call forwarding on the subscriber’s monthly statement in order to make it clear the reason those calls were placed. For all purposes the original call and the forwarded call are two different billable calls. This will require the RKS to replace the Calling Party Number with the value of the Charge Number for the forwarded call’s AMA record. The Calling_Party_Number attribute in the Service_Instance Event Messages is consistent with Telcordia Technologies' GR-580-CORE [23], GR-586-CORE [24] call forwarding specifications and the GR-317-CORE [25] specification. Table 8. Call Forwarding Service Event Message Required or Optional Comments Service_Instance R None 8.2.8 Return Call Service This service applies only to calls originating On-Net, described in Sections 8.1.1 and 8.1.2. The CMS MUST keep a register with the Calling Party Number of the last call. Return Call Service returns the last call that was made to an MTA. Upon instantiation of Return Call feature, the CMS initiates another call with the Calling Party Number of the last call, retrieved from the register just described, as the Dialed number. Event Messages are generated for the fact that the Return Call feature was initiated, using the BCID of this call. If the Calling Party Number of the last call had Caller ID privacy restrictions, then CMS may conference in a recording from an announcement server saying that this call cannot be completed. Table 9. Return Call Service Event Message Required or Comments Optional Service_Instance R None Interconnect_Start O Required only if Announcement Server for delivering the Message indicating reason Return Call cannot be activated is Off-Net on PSTN. Interconnect_Stop O Required only if Announcement Server for delivering the Message indicating reason Return Call cannot be activated is Off-Net on PSTN. Intelligent_Peripheral_Usage_Start O Required only if Announcement Server for delivering the Message indicating reason Return Call cannot be activated is On-Net. Intelligent_Peripheral_Usage_Stop O Required only if Announcement Server for delivering the Message indicating reason Return Call cannot be activated is On-Net. 36 8.2.9 Repeat Call Service Repeat Call Service applies only to calls terminating On-Net as described in Sections 8.1.1 and 8.1.3. Repeat Call can be initiated when the caller dials a number and gets a busy signal. With this feature the caller dials a special pre-determined string of digits (*66 in the United States of America) which then instructs the network to keep polling the called and calling party and when both free, establish the communication. In IPCablecom 1.0, the originating CMS will keep trying to establish communications to the called number for a pre-determined amount of time. Table 10. Repeat Call Service Event Message Required or Comments Optional Service_Instance R None Interconnect_Start O Required if Announcement Server for delivering the Message indicating reason Repeat Call cannot be activated is Off-Net on PSTN. Interconnect_Stop O Required only if the appropriate Interconnect_Start was activated. Intelligent_Peripheral_Usage O Required only if Announcement Server for delivering the _Start Message indicating reason Repeat Call cannot be activated is On-Net. Intelligent_Peripheral_Usage O Required only if Announcement Server for delivering the _Stop Message indicating reason Repeat Call cannot be activated is On-Net, Note: There may be multiple Interconnect_Start and Stops capturing the multiple different times the originating CMS tries to make an Off-Net call to try to complete a Repeat Call request. 8.2.10 Voice Mail Service Voice Mail Service only applies to calls terminating On-Net, described in Sections 8.1.1 and 8.1.3. It is assumed that the voice mail server will be located Off-Net for IPCablecom 1.0. It is therefore assumed if voicemail billing is usage sensitive, that connections to the Off-Net voicemail system will be counted in the same way whether they are voicemail messages being left for the subscriber (deposit) or calls to retrieve the messages on the voicemail server. Voice mail deposit and retrieval scenarios are treated as separate transactions that have associated Event Messages. Event Messages for voice mail deposit look like a standard On-Net to Off-Net call. When the call is transferred to the Voice Mail Server, the Routing Number MUST be captured and populated with the Voice Mail Server Address. The connection time to the Voice Mail Server MAY also be derived through the standard On-Net to Off-Net Event Messages. Since the Voice Mail Server is located Off-Net, Event Messages for voice mail retrieval MAY only be generated if the retrieval is initiated from a device within the MSO’s network (e.g., On-Net to Off-Net call). 8.2.11 Message Waiting Indicator Service It is assumed that an Off-Net voicemail system is used as described in Section 8.2.10. Because it seems unreasonable for the CMS to have to place a separate call to the Off-Net system each time a voicemail subscriber goes off-hook, it is assumed that a mechanism exists which allows the Off-Net voicemail system pass the information to the CMS indicating which subscribers have voicemail waiting. A further assumption is that the MTA 37 is capable of delivering the audible stutter-tone message-waiting indicator to the subscriber’s MTA port going off- hook, on the command of the CMS. Under the scenario described in the assumptions section, and given the fact that billing is not based on any per use delivery of the stutter tone, there are no Event Messages required for this service. Billing is based on a combination of information obtained from the Voicemail send/retrieve Event Messages discussed in Section 8.2.10 and provisioning information indicating when a subscriber has signed up for voicemail services. 8.2.12 Three-Way Call Service The text in this section has been removed because it is not within the scope of IPCablecom 1.0. 8.2.13 Customer Originated Trace Service The text in this section has been removed because it is not within the scope of IPCablecom 1.0. 8.2.14 Account Code and Authorization Code Service The text in this section has been removed because it is not within the scope of IPCablecom 1.0. 38 9 IPCABLECOM EVENT MESSAGE STRUCTURE This section describes the various Event Messages, together with their associated list of attributes. Refer to Section 10 for a detailed description of the attributes described in this section. Refer to Section 8 for a detailed description of the services and their associated Event Messages. The description of each event message in this Section includes: • A summary of the EM purpose and conditions under which it is sent. • Mandatory requirements for triggers that cause the EM to be created and time-stamped during a call that is completely set up and terminates normally. Throughout Section 9, the time-stamp triggers for each EM are clearly defined. When a time-stamp requirement exists for an Event Message, there is an assumption that the event message will be generated as well, however when the message is actually transmitted depends on whether the NE is operating in immediate or batch mode (see Section 7.1). • A table showing mandatory and optional attributes in the EM. Note that, even though only mandatory EM trigger requirements for normal completed calls are specified, the NEs are expected to implement reasonable triggers for all call and exception scenarios. Additionally, NEs are expected to implement reasonable triggers if they have not implemented all IPCablecom interfaces (for example, if CMS-to- CMS signaling is not used for CMS to MGC communication). The following tables show the association between IPCablecom 1.0 services, supported by the aforementioned call configurations, and proposed Event Messages that may be generated for each service. Voice communications services that IPCablecom 1.0 provides are based on three main call configurations: • On-Net to On-Net • On-Net to Off-Net • Off-Net to On-Net Table 11 provides a list of IPCablecom Event Messages defined in this document. More than one set of Event Messages MAY be generated during a particular service instance. Table 11. IPCablecom Event Message Summary Event IPCablecom Event Message Description Message ID 0 Reserved 1 Signaling_Start Start of signaling for originating or terminating part of the call 2 Signaling_Stop Stop of signaling for originating or terminating part of the call 3 Database_Query An inquiry into an external database; for example a toll- free number database 4 Intelligent_Peripheral_Usage_Start Deferred 5 Intelligent_Peripheral_Usage_Stop Deferred 6 Service_Instance Indicates an occurrence of a service 7 QoS_Reserve Reservation of QoS for originating or terminating part of the call 39 Event IPCablecom Event Message Description Message ID 8 QoS_Release Release of QoS for originating or terminating part of the call 9 Service_Activation Indicates a subscriber has activated a service 10 Service_Deactivation Indicates a subscriber has deactivated a service 11-12 Reserved Reserved for IPCablecom 1.5 13 Interconnect_(Signaling)_Start Start of network interconnect signaling (between IPCablecom and PSTN) for originating or terminating part of the call 14 Interconnect_(Signaling)_Stop Stop of network interconnect signaling (between IPCablecom and PSTN) for originating or terminating part of the call 15 Call_Answer Indicates that all network resources for have been allocated for originating or terminating part of the call 16 Call_Disconnect Indicates that all network resources for have been released for originating or terminating part of the call 17 Time_Change Indicates time change on a network element 19 QoS_Commit Commitment of QoS for originating or terminating part of the call 20 Media_Alive Indicates if the call is still active 21-30 Reserved Reserved for IPCablecom 1.5 31-39 Reserved Reserved for IPCablecom Multimedia The Signaling_Start, Signaling_Stop, Call_Answer, and Call_Disconnect messages are important for accounting purposes and tracking the signaling overhead for media session establishment. The following are some assumptions on how these messages will be used: • Signaling_Start and Signaling_Stop messages bracket the timeframe during which the CMS or MGC is processing dialed digits, performing signaling, and maintaining state for a call. Thus, the time-stamp on a Signaling_Start is time-stamped as early in the flow as possible on both the originating and terminating side after the message containing routable digits from the originator. A routable set of digits can be defined as a set of digits that are collected by the MTA matching the digit map, and will trigger call routing processing (e.g., *69 would not be considered routable digits, but 00 would). The time-stamp on the Signaling_Stop is time stamped when signaling for the call is completed, generally when a DLCX is sent to an endpoint. • A Signaling_Stop is generated if and only if a Signaling_Start was generated. Under normal circumstances, an RKS can expect a Signaling_Start and Signaling_Stop message for each set of event messages it receives for a specific BCID. • Call_Answer and Call_Disconnect messages bracket the time-frame during which 2-way media path is active. The time-stamps on these messages are used to calculate call time and duration for any calls that have usage billing. The time-stamp on the Call_Answer will closely match the time at which the terminating party goes off- hook, and the time-stamp on the Call_Disconnect will closely match the time at which the media path is torn down. • A Call_Disconnect is generated if and only if a Call_Answer was generated. Existence of these two EMs in a set of EMs for a BCID indicates that all the conditions for a 2-way media path were met. • The Called_Party_Number in Signaling_Start is the E.164 number of the terminating party. This number is intended to capture the destination of the call as specified by the originator. It often indicates the dialed-digits 40 from the originator (e.g., for the 3 digit calls like 911, 411, this attribute captures this 3 digit number). However, there are several cases in which this field does not reflect the actual input of the user (e.g., in case of features like speed dial, it is populated with the digits configured for the speed dial digits). A few examples: • Subscriber is in area code 972 and has 7 digit dial plan. When the subscriber dials 234-1234, the Called_Party_Number in Signaling_Start is populated with the 10 digit number including the area code, 9722341234. • Subscriber has speed dial feature and configured 11 to 972-234-1234. When the subscriber dials 11#, the Called_Party_Number in Signaling_Start is populated with the 10 digit number configured for the speed dial 11, 9722341234. • When a subscriber dials 911 for emergency call, the Called_Party_Number in Signaling_Start is populated with 3 digit 911. • When the subscriber dials 1-919-234-1234, the Called_Party_Number in Signaling_Start is populated with the 10 digit number without the prefix, 9192341234. • When the subscriber dials a dial around code, 1010288, and then dials 919-234-1234, the Called_Party_Number in Signaling_Start is populated with the 10 digit number without the dial around code, 9192341234. • When the subscriber dials 1-800-228-8288, the Called_Party_Number in Signaling_Start is populated with 8002888288, and the Routing_Number is populated with the translated number after the database dip. Table 12. Services supported by On-Net to On-Net call configuration Service Event Message ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 19 20 21 Basic X X X X X X X X X X X X X Call Block X X X X X X X X X X X X X X Call Waiting X X X X X X X X X X X X X X Call Forwarding X X X X X X X X X X X X X X Return Call X X X X X X X X X X X X Repeat Call X X X X X X X X X X X X Voice Mail X X X X X X X X X X X Table 13. Services supported by On-Net to Off-Net call configuration. Service Event Message ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 19 20 21 Basic X X X X X X X X X X X X X X X Call Block X X X X X X X X X X X X X X X X Call Waiting X X X X X X X X X X X X X X X X Return Call X X X X X X X X X X X X X X Repeat Call X X X X X X X X X X X X X X 911 X X X X X X X X X X X X X X N11 X X X X X X X X X X X X X X Toll-Free X X X X X X X X X X X X X X Operator X X X X X X X X X X X X X 41 Table 14. Services supported by Off-Net to On-Net call configuration Service Event Message ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 19 20 21 Basic X X X X X X X X X X X X X X X Call Block X X X X X X X X X X X X X X X X Call Waiting X X X X X X X X X X X X X X X X Repeat Call X X X X X X X X X X X X X X Call Forwarding X X X X X X X X X X X X X X Voice Mail X X X X X X X X X X X X X 9.1 Event Message Structure An Event Message contains a header followed by attributes. The header is required on every Event Message. The attributes vary based on the type of service the Event Message is describing. Refer to Table 34 for a description of the Event Message Header (EM_Header Attribute Structure). 9.2 Service_Instance This event captures the fact that a service event has happened. The Event_Time attribute in the EM_Header Structure (see Table 34) MUST contain the time at which the service occurred. This Event Message indicates the time at which the CMS provides an instance of a call control/feature service. For example, the time at which a call is put on hold, the time at which a call is forwarded, the time at which a last call return service is provided, the time at which a call-waiting service is provided, etc. The CMS MUST timestamp these messages immediately upon operation of the service instance being reported. The following generic call scenarios and BCIDs are used to specify the call leg for which the CMS sends the Service_Instance Event Message for Call Forwarding and Call Waiting Services: For Call Forwarding, Subscriber A (BCID-A) calls Subscriber B (BCID-B1), Subscriber B (BCID-B2) forwards to Subscriber C (BCID-C). In this case, the CMS managing Subscriber B MUST generate a Service_Instance Event Message with the BCID (BCID-B2) in the EM_Header attribute and the Related_Call_Billing_Correlation_ID attribute MUST be BCID(BCID-B1). For Call Waiting, Subscriber A (BCID-A) calls Subscriber B (BCID-B1) and after the call is established, Subscriber C (BCID-C) calls Subscriber B (BCID-B2), who uses call waiting to talk to Subscriber C. In this case, the CMS managing Subscriber B MUST generate the Service_Instance Event Message with the BCID (BCID-B2) in the EM_Header attribute and the Related_Call_Billing_Correlation_ID attribute MUST be BCID (BCID-B1). 42 Table 15. Service_Instance Event Message Attribute Name Required or Comment Optional EM_Header (see Table 34) R The EM_Header attribute MUST be present as the first attribute of the EM. Service_Name R The Service_Name attribute MUST be present. Class Service Name: Call_Block Call_Forward Call_Waiting Repeat_Call Return_Call Call_Termination_Cause O The Call_Termination_Cause attribute MUST be present if the Service_Name is Call_Block or Acct_Auth_Code. If the Service_Name is Acct_Auth_Code, the Source_Document field of the Call_Termination_Cause attribute MUST indicate that the source document is GR- 1100-CORE - Table 235 and the Cause_Code field MUST include the Call Completion Code as defined in GR-1100-CORE - Table 235. Related_Call_Billing_Correlation_ID O The Related_Call_Billing_Correlation_ID attribute MUST be present if Service_Name is Call_Forward or Call_Waiting. Charge_Number O The Charge_Number attribute MUST be present if Service_Name is Call_Forward, Call_Waiting, or Repeat_Call Return_Call or Three_Way_Call. First_Call_Calling_Party_Number O The First_Call_Calling_Party_Number attribute MUST be present if Service_Name is Call_Waiting. Second_Call_Calling_Party_Number O The Second_Call_Calling_Party_Number attribute MUST be present if Service_Name is Call_Waiting. Called_Party_Number O The Called_Party_Number attribute MUST be present if Service_Name is Call_Waiting. Routing_Number O The Routing_Number attribute MUST be present if Service_Name is Repeat_Call or Return_Call Calling_Party_Number O The Calling_Party_Number attribute MUST be present if Service_Name is Repeat_Call or Return_Call. 9.3 Service_Activation This event captures a subscriber activating a service. The Event_Time attribute in the EM_Header Structure (see Table 34) MUST contain the time when the service was activated. This Event Message indicates the time at which the CMS records an attempt to activate a service. For example, the time at which call-forwarding is activated by the MTA user, the time at which the call-waiting service is activated by the MTA user, etc. These service activations are typically requested via a ∗XX dial-string. 43 The CMS MUST timestamp this message immediately upon successful activation of the requested service.1 The CMS MUST create a new BCID for this Event Message even if a service is activated during an existing call. Table 16. Service_Activation Event Message Attribute Name Required or Comment Optional EM_Header (see Table 34) R The EM_Header attribute MUST be present as the first attribute of the EM. Service_Name R The Service_Name attribute MUST be present. Class Service Name: Call_Block Call_Forward Call_Waiting Calling_Party_Number R The Calling_Party_Number attribute MUST be present if the Service_Name is Call_Forward. The Calling_Party_Number attribute MUST be present if the Service_Name is Call_Waiting or Call_Block or and if the calling party number is known. Otherwise, this attribute may be omitted. Charge_Number R The Charge_Number attribute MUST be present. Forwarded_Number O The Forwarded_Number attribute MUST be present if Service_Name is Call_Forward. 9.4 Signaling_Start This Event Message indicates the time at which signaling starts. It is intended to capture the point at which the NE starts processing a call once a routable set of digits have been obtained from the originator. The CMS or MGC MUST timestamp this message prior to digit translation. Note that the attributes contained in this Event Message contain information that is obtained after digit translation. In the event that a database dip is required, then the Signaling_Start message MUST be generated after the response from the database dip. Originating CMS In all scenarios, the originating CMS MUST timestamp this message immediately upon receipt of an NCS-signaling NTFY message with a routable set of digits that indicate a call attempt. Terminating CMS In the single-zone scenario, the terminating CMS MUST timestamp this Event Message based on a vendor- proprietary trigger. In the intra-domain and inter-domain scenarios, the terminating CMS MUST timestamp this Event Message based on a vendor-proprietary trigger. The proprietary trigger MAY be based on when the first NCS-signaling message is transmitted to the terminating E-MTA. Originating MGC (off-on) The originating MGC MUST timestamp this message immediately upon receipt of an SS7 IAM message. Terminating MGC (on-off) 1 Failed activation attempts are not reported at this time. 44 The terminating MGC MUST timestamp this message. based on vendor proprietary trigger. The proprietary trigger MAY be based on when the IAM is transmitted. The Trunk_Group_Number in the Trunk_Group_ID attribute in this message is the trunk group number used to formulate the first IAM transmitted to the Signaling Gateway that communicates with PSTN SS7 network for this call. It is referenced to the first IAM because potentially due to reattempt handling another IAM may be attempted to complete the same call. 45 Table 17. Signaling_Start Event Message Attribute Name Required or Comment Optional EM_Header (see Table 34) R The EM_Header attribute MUST be present as the first attribute of the EM. Direction_Indicator R The Direction_Indicator attribute MUST be present. MTA_Endpoint_Name R If the originating CMS generates this message, MTA_Endpoint_Name attribute MUST contain the endpoint name of the originating MTA. If the terminating CMS generates this message, MTA_Endpoint_Name attribute MUST contain the endpoint name of the terminating MTA. If the originating MGC generates this message, MTA_Endpoint_Name attribute MAY contain the endpoint ID of the originating MG. If the terminating MGC generates this message, the MTA_Endpoint_Name attribute MAY contain the endpoint ID of the terminating MG. Calling_Party_Number O The Calling_Party_Number attribute MUST be included in the Signaling_Start Event Message whenever it is available in SS7. For example, in the off-net to on-net scenario, this attribute may not be present when the Originating MGC and Terminating CMS do not have the Calling Party Number attribute available from SS7 signaling. Called_Party_Number R The Called_Party_Number attribute MUST be present, it holds the formatted digits (E.164 [7] format) dialed by the subscriber. Refer to section 9 for examples of how to populate this field. Routing_Number R The Routing_Number attribute MUST be present, it indicates a routable number Location_Routing_Number O The Location_Routing_Number attribute MUST be included for local number portability use. Carrier_Identification_Code O The Carrier_Identification_Code attribute MUST be included in MGC generated messages in which the call is being routed to an inter-exchange carrier and the information is available. Trunk_Group_ID O The Trunk_Group_ID attribute MUST be included when the MGC generates this message. Intl_Code O The Intl_Code attribute MUST be included for call origination of an internationally routed call. Dial_Around_Code O The Dial_Around_Code attribute MUST be included for call origination where the inter-exchange carrier was specified by keying in a dial-around code (e.g., 1010288). 46 Attribute Name Required or Comment Optional Jurisdiction_Information_Para O If the originating MGC generates this messages, the meter Jurisdiction_Information_Parameter (JIP) MUST be included when JIP was received in SS7 message (reference: GR-317- CORE) or if the incoming trunk group is provisioned with LRN of remote end. If the originating CMS generates this messages, the Jurisdiction_Information_Parameter MUST be included when the calling party number is ported-in number. In this case, JIP is per CMS provisioning. Note that this may be present even if the calling party is not ported in number. If the terminating CMS generates this messages, the Jurisdiction_Information_Parameter MUST be included when JIP is received from the originating MGC. Called_Party_NP_source O Number Portability source. The Called_Party_NP_Source indicates how CMS or MGC obtained LRN of called party. Calling_Party_NP_source O Number Portability source. The Calling_Party_NP_Source indicates how CMS or MGC obtained local number portability information for calling party. Ported_In_Calling_Number O If the originating CMS generates this messages, the Ported_In_Calling_Number attribute MUST be included when the calling party number is ported-in number. Ported_In_Called_Number O If the terminating CMS generates this messages, the Ported_In_Called_Number attribute MUST be included when the called party number is ported-in number. Billing_Type O The Billing_Type attribute MUST be included for call origination where the originating endpoint is a measured rate subscriber. 9.5 Signaling_Stop This Event Message indicates the time at which signaling terminates. It is intended to capture the point at which the NE processes the final signaling message for the call. A Signaling_Stop message MUST NOT be generated unless a Signaling_Start message with the same BCID has been generated for the call. A Signaling_Stop message MUST be generated if a Signaling_Start message with the same BCID has been generated for the call (in exception cases, this may be the result of a proprietary time-out or clean-up process). Originating CMS In the single-zone scenario, the originating CMS MUST timestamp this EM message immediately upon transmission of the NCS-signaling DLCX message. In the intra-domain or inter-domain scenarios, the originating CMS MUST timestamp this message upon transmission/receipt of the NCS-signaling DLCX message, or based on a vendor-proprietary trigger. Terminating CMS In the single-zone scenario, the terminating CMS MUST timestamp this EM message immediately upon transmission of the NCS-signaling DLCX message. In the intra-domain or inter-domain scenarios, the terminating CMS MUST timestamp this message upon transmission/receipt of the NCS-signaling DLCX message, or based on a vendor-proprietary trigger. 47 Originating MGC (off-net to on-net) The originating MGC MUST timestamp this EM message immediately upon the last signaling event in the following list: • transmission/receipt of an RLC to/from the Signaling Gateway that communicates with the SS7 network, • transmission of the MGC-issued TGCP DLCX message, • receipt of an MG-issued TGCP DLCX, or Terminating MGC (on-net to off-net) The terminating MGC MUST timestamp this EM message immediately upon transmission of the TGCP-signaling DLCX message. Table 18. Signaling_Stop Event Message Attribute Name Required or Comment Optional EM_Header (see Table R The EM_Header attribute MUST be present as the first attribute 34) of the EM. Related_Call_Billing_Cor O If the originating CMS or MGC generates this message, the relation_ID Related_Call_Billing_Correlation_ID attribute MUST contain the BCID of the terminating CMS or MGC when terminating CMS or MGC is known. If the terminating CMS or MGC is not known, this attribute may be omitted. If the terminating CMS or MGC generates this message, the Related_Call_Billing_Correlation_ID attribute MUST contain the BCID of the originating CMS or MGC. FEID O If the originating CMS or MGC generates this message, the FEID attribute MUST contain the FEID of the terminating CMS or MGC when terminating CMS or MGC is known. If the terminating CMS or MGC is not known, this attribute may be omitted. If the terminating CMS or MGC generates this message, the FEID attribute MUST contain the FEID of the originating CMS or MGC. Call_Termination_Cause R The Call_Termination_Cause code MUST be present. 9.6 Service_Deactivation This Event Message indicates the time at which the CMS records an attempt to deactivate a service. For example, the time at which call-forwarding is deactivated by the MTA user, the time at which the call-waiting service is deactivated by the MTA user, etc. These service deactivations are typically requested via a ∗XX dial-string. The CMS MUST timestamp this message immediately upon successful deactivation of the requested service. Failed Deactivation attempts are not reported at this time. The CMS MUST create a new BCID for this Event Message even if a service is deactivated during an existing call. 48 Table 19. Service_Deactivation Event Message Attribute Name Required or Comment Optional EM_Header (see Table 34) R The EM_Header attribute MUST be present as the first attribute of the EM. Service_Name R The Service_Name attribute MUST be present. Class Service Name: Call_Block Call_Forward Call_Waiting Calling_Party_Number R The Calling_Party_Number attribute MUST be present. Charge_Number R The Charge_Number attribute MUST be present. Note that in the case of the Call_Waiting Service, the service deactivation or cancellation only applies to the duration of one call. If the subscriber has Call_Waiting Service, by default, any call placed or received after the Call_Waiting Service deactivation will have call waiting enabled. As a consequence, no Service_Activation Event Message is generated to activate this service again. 9.7 Database_Query This Event Message indicates the time at which a one-time request/response transaction or database dip is completed by an intelligent peripheral (800 number database, LNP database, etc.). The CMS originating the call MUST timestamp this message immediately upon a receipt of the response from the Intelligent Peripheral. Table 20. Database_Query Event Message Attribute Name Required or Comment Optional EM_Header, R The EM_Header attribute MUST be present as the first attribute of see (Table 34) the EM Database_ID R None Query_Type R Toll Free Number Lookup, LNP lookup, etc. Called_Party_Number R None Returned_Number R Note 1: In the PSTN, only a single number is returned per a query for Toll-free/LNP/Calling Name service ([17], [18], [19]). There may be multiple numbers returned such as the 800 translation results in a ported number in an optimized response available in AIN 0.2 ([15], [16]). This is optional for use in TCAP query of these services. If multiple numbers are returned, this attribute SHOULD reflect the result associated with the original query as indicated in the attribute Query_Type in this message. Any additional database dip result SHOULD be included in the corresponding specific attribute. In the case of LNP as a bundled response to the toll free query, the Location_Routing_Number SHOULD be included to convey the additional returned number result from a single database query to the SCP. As an alternative, the Returned_Number MAY be included for each number returned, but SHOULD be included as a pair with Query_Type in an ordered sequence. The first pair denotes the returned number associated with the original query type. The next 49 Attribute Name Required or Comment Optional pair denotes the next returned number of the next bundled database dip of the same original query. This repeats until the last returned number is conveyed. Note 2: For a calling name database query, this field should contain the calling party number provided to the database for which the name is being requested. Location_Routing_Number O See note above. Query_Type O As a pair with Returned_Number for each of the subsequent database dip result within a single original database query. See note in the Returned_Number comment column above. Returned_Number O As a pair with Query_Type for each of the subsequent database dip result within a single original database query. See note above. 9.8 Intelligent_Peripheral_Usage_Start Deferred. 9.9 Intelligent_Peripheral_Usage_Stop Deferred. 9.10 Interconnect_Start This Event Message indicates the time at which the start of network interconnect occurs. Only the MGC is permitted to issue this Event Message. The MGC MUST timestamp this message immediately upon transmission/receipt of an IAM to/from the Signaling Gateway that communicates with the SS7 network. The terminating MGC MUST generate this message only after the ACM/ANM is received. This is so that if another IAM is attempted due to reattempt handling with a different trunk group number before the ACM/ANM is received, the Interconnection_Start reports the latest trunk group number along with the latest timestamp of the final IAM used to complete the call. (The Signaling_Start reports the first IAM attempted trunk group number of the same call.) The originating MGC MAY generate this message when the ACM is transmitted although it is timestamp upon receipt of an IAM. Table 21. Interconnect_Start Event Message Attribute Name Required or Comment Optional EM_Header R The EM_Header attribute MUST be present as the first attribute (see Table 34) of the EM. Carrier_Identification_Code O CIC Code of connecting operator. This attribute MUST be present when the call is routed off-net to an inter-exchange carrier. For example, this attribute can be omitted for operator and emergency (911) trunks. Trunk_Group_ID R TGID of the trunk over which the interconnection is occurring. 50 Attribute Name Required or Comment Optional Routing_Number R None 9.11 Interconnect_Stop This Event Message indicates the termination of bandwidth between the IPCablecom network and the PSTN. Only the MGC is permitted to issue this Event Message. The MGC MUST timestamp this message immediately upon transmission/receipt of an RLC to/from the Signaling Gateway that communicates with the SS7 network. Table 22. Interconnect_Stop Event Message Attribute Name Required or Comment Optional EM_Header (seeTable 34) R The EM_Header attribute MUST be present as the first attribute of the EM. Carrier_Identification_Code O CIC Code of connecting operator. This attribute MUST be present when the call is routed off-net to an inter-exchange carrier. For example, this attribute can be omitted for operator and emergency (911) trunks. Trunk_Group_ID R TGID of the trunk over which the interconnection is occurring. 9.12 Call_Answer This Event Message indicates that the media connection is open because answer has occurred. It is intended to capture the earliest point at which the NE can determine that the termination side has gone off-hook, resulting in a 2- way media path. Originating CMS In the single-zone scenario, the originating CMS MUST timestamp this Event Message based on its knowledge of media connection establishment. This trigger should correspond as closely as possible to the time at which the terminating side has determined that off-hook has occurred. In the multi-zone scenario, the originating CMS MUST timestamp this Event Message message immediately upon receipt of the CMSS signaling 200 OK sent in response to the original INVITE message indicating call answer. Terminating CMS The terminating CMS MUST timestamp this message immediately upon receipt of the NCS-signaling NTFY message indicating off-hook at the terminating MTA. Originating MGC (off-on) The originating MGC MUST timestamp this message immediately upon transmission of an SS7 ANM message to the PSTN via the SG. Terminating MGC (on-off) The terminating MGC MUST timestamp this message immediately upon receipt of an SS7 ANM message from the PSTN via the SG. 51 Table 23. Call_Answer Event Message Attribute Name Required or Comment Optional EM_Header R The EM_Header attribute MUST be present as the first (see Table 34) attribute of the EM. Charge_Number R The Charge_Number attribute MUST contain the charge number in the appropriate cases such as collect call, calling-card call, call billed to a 3rd party, or others. Related_Call_Billing_Correlation_ID O If the originating CMS or MGC generates this message, the Related_Call_Billing_Correlation_ID attribute MUST contain the BCID of the terminating CMS or MGC when terminating CMS or MGC is known. If the terminating CMS or MGC is not known, this attribute may be omitted. If the terminating CMS or MGC generates this message, the Related_Call_Billing_Correlation_ID attribute MUST contain the BCID of the originating CMS or MGC. FEID O If the originating CMS or MGC generates this message, the FEID attribute MUST contain the FEID of the terminating CMS or MGC when terminating CMS or MGC is known. If the terminating CMS or MGC is not known, this attribute may be omitted. If the terminating CMS or MGC generates this message, the FEID attribute MUST contain the FEID of the originating CMS or MGC. 9.13 Call_Disconnect This Event Message indicates the time at which the media connection is closed because the calling party has terminated the call by going on-hook, or that the destination party has gone on-hook and the called-party’s call- continuation timer2 has expired. The call termination cause attribute must be included as an attribute in a Call_Disconnect message; its structure is defined in Table 37 and its Cause_Code sub-field is normatively defined in [6] Table 411. Call_Disconnect should be time-stamped by the NE as closely as possible to the time that the media connection is torn down. A Call_Disconnect message MUST NOT be generated unless a Call_Answer message with the same BCID has been generated for the call. A Call_Disconnect message MUST be generated if a Call_Answer message with the same BCID has been generated for the call (in exception cases, this may be the result of a proprietary time-out or clean-up process). Originating CMS The originating CMS MUST timestamp this EM message immediately upon transmission of the NCS-signaling DLCX message (for calls that have reached the state where the terminating party has gone off-hook and the Call_Answer message was sent). Terminating CMS The terminating CMS MUST timestamp this message immediately upon transmission of the DLCX or upon expiration of the terminating MTA’s call-continuation timer. 2 In the current telephony network, when the called party goes on-hook, a 10-11 second timer is started. If the calling party remains off-hook, and the called party goes off-hook again within that time period, the call continues. 52 Originating MGC (off-net to on-net) The originating MGC MUST timestamp this EM message upon receipt of an SS7 REL message from the PSTN via the SG, or upon sending a CMSS-signaling 200-OK message in response to a BYE message from the terminating CMS. Terminating MGC (on-net to off-net) The terminating MGC MUST timestamp this message upon receipt of an SS7 RLC message from the PSTN via the SG, an indication from the MG that an operator services trunk has disconnected, or upon sending a 200-OK message in response to a BYE message from the originating CMS. Table 24. Call_Disconnect Event Message Attribute Name Required or Optional Comment EM_Header (see Table 34) R The EM_Header attribute MUST be present as the first attribute of the EM. Call_Termination_Cause R Normal Termination 9.14 QoS_Reserve This Event Message indicates the time at which the CMTS reserves bandwidth on the IPCablecom access network. The CMTS MUST also generate this event if the Reserved bandwidth changes or if the service flow is authorized by another gate (through the association of a different Gate than originally authorized the flow). The originating and terminating CMTS MUST timestamp this message immediately upon: Table 25. QoS Reserve Timestamp Generation Client initiated CMTS initiated Client initiated DSA-REQ CMTS initiated DSA-REQ reception of a DSA-ACK acknowledging a successful transmission of a DSA-ACK acknowledging a DSA-RSP (confirmation code == success). successful DSA-RSP (confirmation code == success) If a DSA-ACK is not received, the CMTS MUST NOT If a DSA-ACK is not transmitted, the CMTS MUST generate this message. NOT generate this message. If the DSA-RSP confirmation code is not successful, the CMTS MUST NOT generate this message. 53 Table 26. QoS_Reserve Event Message Attribute Name Required or Comment Optional EM_Header (see Table 34) R The EM_Header attribute MUST be present as the first attribute of the EM. QoS_Descriptor O None MTA_UDP_Portnum R None SF ID R None Flow_Direction R None 9.15 QoS_Release This Event Message indicates the time at which the CMTS released its bandwidth commitment on the IPCablecom access network. The originating and terminating CMTS MUST timestamp this message immediately upon: • transmission of a DSC-RSP that indicates that authorization and admission control for a DSC-REQ against an existing service flow have succeeded against a separate Gate, indicating that the previous Gate will be deleted, or • transmission of a DSD-RSP that indicates the request to delete bandwidth contained in the DSD-REQ from the MTA was successful. Table 27. QoS_Release Event Message Attribute Name Required or Comment Optional EM_Header (see Table 34 ) R The EM_Header attribute MUST be present as the first attribute of the EM. SF_ID R None Flow Direction R None 9.16 Time_Change This event captures an instance of a time change. Whenever the (IPCablecom) clock on the network element (CMS, MGC or CMTS) is changed by more than 200 milliseconds, the network element MUST generate a Time Change message. This includes time shift events (Daylight savings time), step adjustments to synchronize with the NTP reference clock and manual time setting changes, The Event_Time attribute in the EM_Header Structure (Table 34) MUST reflect the new (adjusted) notion of time. Note that Time_Change message is not required for slew adjustments performed by NTP. 54 The network element (CMS, MGC and CMTS) MUST send the Time Change event message to the active (current primary) RKS. The Time Change event message MUST be generated when one or more calls are active or in the process of being set up. For the CMS and MGC active or in process is after a Signaling Start event has been generated. For the CMTS active or in process is indicated by the presence of a DQoS gate. The Time Change event message need not be generated when calls are not active or in the process of being set up. Only one Time Change event message is sent to each primary RKS (if there is more than one primary RKS) regardless of how many calls may be active. The BCID in the EM_Header of the Time Change event message MUST be generated locally by the network element at the time of the event. The BCID is not associated with any call related BCID, it is a unique BCID for this event. Table 28. Time_Change Event Message Attribute Name Required or Comment Optional EM_Header (see Table 34) R The EM_Header attribute MUST be present as the first attribute of the EM. Time_Adjustment R None 9.17 QoS_Commit This Event Message indicates the time at which the CMTS commits bandwidth on the IPCablecom access network. The CMTS MUST also generate this event if the Committed bandwidth changes or if the service flow is authorized by another gate (through the association of a different Gate than originally authorized the flow). The originating and terminating CMTS MUST timestamp this message immediately upon: Table 29. QoS Commit Timestamp Generation Client initiated CMTS initiated Client initiated DSC-REQ or a DSA-REQ (when the CMTS initiated DSC-REQ or a DSA-REQ (when the CMTS reserves and commits the bandwidth in one- CMTS reserves and commits the bandwidth in one- step). step). reception of a DSA/DSC-ACK acknowledging a transmission of a DSA/DSC-ACK acknowledging a successful DSA-RSP/DSC-RSP (confirmation code == successful DSA/DSC-RSP (confirmation code == success). success). If a DSA/DSC-ACK is not received, the CMTS MUST If a DSC-ACK is not transmitted, the CMTS MUST NOT generate this message. NOT generate this message. If the DSA/DSC-RSP confirmation code is not successful, the CMTS MUST NOT generate this message. 55 Table 30. QoS_Commit Event Message Attribute Name Required or Comment Optional EM_Header (see Table 34) R The EM_Header attribute MUST be present as the first attribute of the EM. QoS_Descriptor O None MTA_UDP_Portnum R None SF_ID R None Flow_Direction R None 9.18 RTP_Connection_Parameters Event Message Deferred. 9.19 Media_Alive If the IPCablecom architecture is expected to support this Media_Alive Event Message, then it is recommended that all CMS, CMTS, and MGC be pre-configured with the same Media_Alive generation time. This Event Message indicates that service is active due to the continued existence of a bearer connection. This Event Message MAY be generated by any trusted IPCablecom network element (CMS, CMTS, MGC) as as defined below. If a NE is configured to generate the optional Media_Alive event message, it must check for the status of all calls at the configured Media_Alive generation time. At the configured Media_Alive generation time, (e.g. 00:00 means midnight, 23:59 means 11:59 PM) the NE checks if any of the active calls are equal to or older than 1440 minutes. (24 hours). Only if a call is equal to or older than 1440 minutes, a Media_Alive event message for that call MUST be generated. The call starting time for different NE types are specified by: • CMTS: the first QoS_Commit event message EM_Header attribute Event_time for a gate. • CMS: the Call_Answer event message EM_Header attribute Event_time. The EM_Header attribute Event_time is time stamped as per Section 9.12 Call_Answer. • MGC: the Call_Answer event message EM_Header attribute Event_time. The EM_Header attribute Event_time is time stamped as per Section 9.12 Call_Answer. NEs MUST (when configured to generate the Media_Alive EMs) generate the Media_Alive EMs at the Media_Alive EM generation time. Even though the Media_Alive EM generation time is configurable, the default value for the Media_Alive EM generation time MUST be midnight. Thus a service provider can have a synchronized network simply by accepting the default value from all NEs. If a service provider wants different time for Media_Alive EM generation time, it is up to the service provider to configure the different Media_Alive EM generation time. The following diagram illustrates how a long duration call is identified. Assumption: the Media_Alive EM generation on the NE has been configured to midnight (00:00) (the default value). Call A is not a long duration call because its duration is less than 24 hours (or 1440 minutes) long. Call B is not a long duration call because its duration is longer than 24 hours but it is less than 1440 minutes long at the Media_Alive EM generation time (midnight). 56 Call C is a long duration call because at the second midnight after the call was established, its duration is longer than 1440 minutes. (actually 2340 minutes long). Only one Media_Alive is generated because it is terminated prior to the next Media_Alive EM generation time (midnight). Call D is also a long duration call because it meets the same criterion as Call C. Because it stays up across the midnight boundary after becoming a long duration call, two Media_Alive EMs are generated. midnight midnight midnight midnight midnight Call A: duration < 24 hours. Call_Disconnect Not a long duration call Call_Answer Call B: duration > 24 hours. Not a long duration call. Call_Disconnect Call_Answer Call C: A long duration call. Media_Alive Call_Disconnect Call_Answer Call D: Media_Alive Media_Alive Call_Disconnect A long duration call. Call_Answer t0 t1 t2 t3 Figure 7. Long Duration Call Identification From the above diagram, Call D will be used to illustrate the contents of the long duration call records belonging to a same call id (BCID). In above scenario, there will be three records generated from Call D, let’s identify these as record 1, 2, and 3. The Call D starts on day 0 at 9:00:00 AM. (t0 July 27, 2001). At first midnight crossing, the call is 900 minutes long (or 5400 seconds). So no record is generated. At second midnight crossing (t1), the call is 2340 minutes long (or 140400 seconds). So a Media_Alive Event Message is generated with the following value: EM Header.Event_time = 20010729000000.000 At third midnight crossing (t2), the call is 3780 minutes long (or 226800 seconds). A Media_Alive event message with the following value is generated: EM Header.Event_time = 20010730000000.000 At 5:00pm, following the third midnight, the call is terminated. (t3). The overall duration of the call is 4800 minutes long ( or 288000 seconds ). A Call_Disconnect event message with the following value is generated for this call BCID. EM Header.Event_time = 20010730170000.000 57 Table 31. Media_Alive Event Message Attribute Name Required or Comment Optional EM_Header, see (Table 34) R The EM_Header attribute MUST be present as the first attribute of the EM. 58 10 IPCABLECOM EVENT MESSAGE ATTRIBUTES This section describes the IPCablecom attributes included in the IPCablecom Event Messages. Table 32 shows a mapping of the IPCablecom Event Messages and their associated IPCablecom attributes. Table 33 contains a detailed description of the IPCablecom attributes. Table 32. IPCablecom Attributes Mapped to IPCablecom Event Messages Attribute ID EM EM Attribute Name Event Message ID 10 – Service_Deactivation 13 – Interconnect_Start 14 – Interconnect_Stop 9 – Service_Activation 16 – Call_Disconnect 6 – Service_Instance 3 – Database_Query 1 – Signaling_Start 17 – Time_Change 2 – Signaling_Stop 19 – QoS_Commit 15 – Call_Answer 7 – QoS_Reserve 20 – Media Alive 8 – QoS_Release 11 - Reserved 12 - Reserved 4 – Deferred 5 – Deferred 21-Reserved 0 Reserved 1 EM_Header X X X X X X X X X X X X X X X 2 Undefined 3 MTA_Endpoint_Name X 4 Calling_Party_Number X X X X 5 Called_Party_Number X X X 6 Database_ID X 7 Query_Type X 8 Undefined 9 Returned_Number X 10 Undefined 11 Call_Termination_Cause X X X 12 Undefined 13 Related_Call_Billing_ X X X Correlation_ID 14 First_Call_Calling_Party_ X Number 15 Second_Call_Calling_ X Party_Number 16 Charge_Number X X X X 17 Forwarded_Number X 18 Service_Name X X X 19 Undefined 20 Intl_Code X 59 Attribute ID EM EM Attribute Name Event Message ID 10 – Service_Deactivation 13 – Interconnect_Start 14 – Interconnect_Stop 9 – Service_Activation 16 – Call_Disconnect 6 – Service_Instance 3 – Database_Query 1 – Signaling_Start 17 – Time_Change 2 – Signaling_Stop 19 – QoS_Commit 15 – Call_Answer 7 – QoS_Reserve 20 – Media Alive 8 – QoS_Release 11 - Reserved 12 - Reserved 4 – Deferred 5 – Deferred 21-Reserved 21 Dial_Around_Code X 22 Location_Routing_ Number X X 23 Carrier_Identification_ X X* X X Code 24 Trunk_Group_ID X X X 25 Routing_Number X X X 26 MTA_UDP_Portnum X X 27 Undefined 28 Undefined 29 Channel_State 30 SF_ID X X X 31 Error_Description 32 QoS_Descriptor X X 33 Undefined 34 Undefined 35 Undefined 36 Undefined 37 Direction_indicator X 38 Time_Adjustment X 39 - Reserved for 48 IPCablecom 1.5 49 FEID X X 50 Flow_Direction X X X 51 - Reserved for 57 IPCablecom 1.5 61- Reserved 79 80 - Reserved for 81 IPCablecom 1.5e 82 Jurisdiction_Information_P X arameter 83 Called_Party_NP_Source X 60 EM Attribute ID 88 – Reserved for 87 Billing_Type 92 IPCablecom 1.5 EM Attribute Name 84 Calling_Party_NP_Source 86 Ported_In_Called_Number 85 Ported_In_Calling_Number 1 – Signaling_Start X X X X 2 – Signaling_Stop 3 – Database_Query 4 – Deferred 5 – Deferred 6 – Service_Instance 61 7 – QoS_Reserve 8 – QoS_Release 9 – Service_Activation 10 – Service_Deactivation 11 - Reserved 12 - Reserved Event Message ID 13 – Interconnect_Start 14 – Interconnect_Stop 15 – Call_Answer 16 – Call_Disconnect 17 – Time_Change 19 – QoS_Commit 20 – Media Alive 21-Reserved Table 33 provides a detailed list of the IPCablecom Event Message attributes. A data value of an attribute may be represented by a simple data format (one data field) or by a more complex data format (Data Structure). Data Structure formats of the appropriate attributes are detailed in Table 34 through Table 40. It should be noted that Event Message 17 is not service dependent. Table 33. IPCablecom Event Message Attributes EM EM EM Attribute EM Attribute Attribute Data Description Attribute Attribute Name Value Type ID Length 0 Reserved 1 76 bytes EM_Header Data structure Common data required on every IPCablecom Event (SeeTable 34) Message 2 Undefined 3 variable MTA_Endpoint_ ASCII character Physical Port name (aaln/#) as defined in the length, Name string IPCablecom NCS Spec [1]. maximum of 247 bytes (247 is maximum length of vendor specific attribute) 4 20 bytes Calling_Party_ Right justified, IPCablecom 1.0 will use E.164 [7] formatted address Number space padded specifying the number of the Originating party. In the ASCII character future other numbering plans will be addressed. string 5 20 bytes Called_Party_ Right justified, IPCablecom 1.0 will use E.164 [7] formatted address Number space padded specifying the number of the terminating party. In the ASCII character future other numbering plans will be addressed. string 6 Variable Database_ID Right justified, A unique identifier of the referenced database length, space padded maximum of ASCII character 247 bytes string (247 is maximum length of vendor specific attribute) 7 2 bytes Query_Type Unsigned integer Query type: 0=Reserved 1=Toll Free Number Lookup 2=LNPNumberLookup 3=Calling Name Delivery Lookup 8 Undefined 9 20 bytes Returned_Number Right justified, IPCablecom 1.0 will use E.164 [7] formatted address space padded specifying the number resulting from a database query. ASCII character In the future other numbering plans will be addressed. string 10 Undefined 11 6 bytes Call_Termination Data structure Termination code identifier _Cause (See Table 37) 62 EM EM EM Attribute EM Attribute Attribute Data Description Attribute Attribute Name Value Type ID Length 12 Undefined 13 24 bytes Related_Call_ Data structure. BCID for possible use in value added services or to Billing_ (See Table 35) identify the matching originating/terminating half of Correlation_ID the service. 14 20 bytes First_Call_Callin Right justified, IPCablecom 1.0 will use E.164 [7] formatted address g_Party_Number space padded specifying the number of the calling party. In the ASCII character future other numbering plans will be addressed. string 15 20 bytes Second_Call_ Right justified, IPCablecom 1.0 will use E.164 [7]formatted address Calling_Party_ space padded specifying the number of the calling party. In the Number ASCII character future other numbering plans will be addressed. string 16 20 bytes Charge_Number Right justified, IPCablecom 1.0 will use E.164 [7] formatted address space padded specifying the number of the billable party. In the ASCII character future other numbering plans will be addressed. string 17 20 Bytes Forwarded_ Right justified, IPCablecom 1.0 will use E.164 [7] formatted address Number space padded specifying the number of the Forwarded Number. In ASCII character the future other numbering plans will be addressed. string 18 32 Bytes Service_Name Right justified, Class Service Name. Allowed names are: space padded Call_Block ASCII character Call_Forward string Call_Waiting Repeat_Call Return_Call 19 Undefined 20 4 Bytes Intl_Code Right justified, International Country Code space padded ASCII character string 21 8 Bytes Dial_Around_Co Right justified, Dial-around code used for per-call selection of inter- de space padded exchange carrier ASCII character string 22 20 bytes Location_Routing Right justified, For LNP uses IPCablecom 1.0 will use E.164 [7] _Number space padded formatted address specifying the number of the ASCII character terminating party. In the future other numbering plans string will be addressed. 23 8 bytes Carrier_ Right justified, If the MSO provides a service for a Identification_ space padded telecommunications operator, the Carrier Identification Code ASCII character Code (CIC) or other identification is recorded in this string field. 24 6 bytes Trunk_Group_ID Data structure Trunk group identification (See Table 38) 25 20 bytes Routing_Number Right justified, IPCablecom 1.0 will use E.164 [7] formatted address space padded specifying the number of the terminating party. In the ASCII character future other numbering plans will be addressed. string 63 EM EM EM Attribute EM Attribute Attribute Data Description Attribute Attribute Name Value Type ID Length 26 4 bytes MTA_UDP_ Unsigned MTA Endpoint UDP Port Number. Destination port Portnum Integer field value in DQoS Gate-spec object received in DQoS Gate-Set message. 27 Undefined 28 Undefined 29 2 bytes Channel_State Unsigned Channel State: Integer 0=Not Used/Reserved 1=Open 2=Change 3=Close 30 4 bytes SF_ID Unsigned integer Service Flow ID, a 32-bit integer assigned by the CMTS to each DOCSIS Service Flow defined within a DOCSIS RFMAC domain. SFIDs are considered to be in either the upstream direction (USFID) or downstream direction (DSFID). USFIDs and DSFIDs are allocated from the same SFID number space. 31 32 bytes Error_Description Right justified, A user-defined description of the error conditions. (See space padded Table 36) ASCII character string. 32 Variable; QoS_Descriptor Data structure QoS parameters data Min 8 bytes See Table 39. (See Appendix C of [11]) 37 2 bytes Direction_ Unsigned integer Specifies if a device acts on behalf of an originating or indicator terminating part of the call at the time an Event Message is being generated. 0=undefined 1=Originating 2=Terminating 38 8 bytes Time_Adjustment signed integer Time adjustment of an element’s (CMS, CMTS, MGC) clock. This time is in milliseconds, detailing the amount of the time change. 39 - 48 Reserved for IPCablecom 1.5 49 Variable FEID ASCII character Financial Entity ID. The first 8 bytes constitute MSO length, string. defined data. By default, the first 8 bytes are zero maximum of filled. From the 9th byte on the field contains the 247 bytes MSO’s domain name which uniquely identifies the MSO for billing and settlement purposes. The MSO’s domain name is limited to 239 bytes. 50 2 bytes Flow Direction Unsigned integer Flow direction: 0=Reserved 1=Upstream 2=Downstream 51 - 57 Reserved for IPCablecom 1.5 61 - 79 Reserved for IPCablecom Multimedia 80 - 81 Reserved for IPCablecom 1.5 82 6 bytes Jurisdiction_Infor Right justified, The originating network element’s JIP as per GR-317- mation_Paramete space padded CORE. r ASCII character string 64 EM EM EM Attribute EM Attribute Attribute Data Description Attribute Attribute Name Value Type ID Length 83 2 bytes Called_Party_NP Unsigned integer 1. Provisioned data _Source 2. Signaling Information 3. NPDB 84 2 bytes Calling_Party_N Unsigned integer 1. Provisioned data P_Source 2. Signaling Information 3. NPDB 85 2 bytes Ported_In_Callin Unsigned integer Value: g_Number 0= Not ported In 1= ported In 86 2 bytes Ported_In_Called Unsigned integer Value: _Number 0= Not ported In 1= ported In 87 2 bytes Billing_Type Unsigned integer Indicates if the call is measured rate or flat rate. Value: 1 = Measured rate (aligned with BAF call type 1 that indicates a local message rate call or a measured call) 3 = Flat rate (aligned with BAF call type 3 that indicates local message rate that is not timed) 88 - 110 Reserved for IPCablecom 1.5 10.1 EM_Header Attribute Structure Table 34 contains a detailed description of the fields in the EM_Header attribute structure. This Event Message Header attribute MUST be the first attribute in every IPCablecom Event Message. Table 34. EM_Header Attribute Structure Field Name Semantics Value Type Length Version_ID Identifies version of this structure. Unsigned integer 2 bytes 1 = IPCablecom 1.0 BCID Unique identifier for a transaction within a network. Data Structure 24 bytes See following section. (See Table 35) Event_Message_Type Identifies the type of Event Message. Unsigned integer 2 bytes Refer to Table 11 for a listing of Event message types. Element_Type Identifies Type of Originating Element: Unsigned integer 2 bytes 0 = Reserved 1 = CMS 2 = CMTS 3 = Media Gateway Controller Element_ID Network wide unique identifier Right justified, 8 bytes 5 digits (statically configured element number unique space padded within an IPCablecom domain in the range of 0- ASCII Character 99,999) String 65 Field Name Semantics Value Type Length Time_Zone Identifies daylight savings time and offset from ASCII character universal time (UTC). string Daylight Savings Time: 0 = Standard Time 1 byte 1 = Daylight Savings The Daylight-Savings Time indicator MUST be set to a value of 1 if the network element is in a region that implements DST and then only during the daylight- saving-time period (usually the summer months). Since there may be areas in which the daylight-saving- time offset indicates a time-change other than 1 hour, the receiving system (e.g. RKS) needs to correctly calculate local time based on knowledge of the area(s) in which the subscriber and the network element reside. UTC offset: + HHMMSS 7 bytes The offset is reported from the network element (CMS/MGC/CMTS) point of view; not based on the subscriber point of view. The UTC offset represents the time offset from universal time (formerly called Greenwich Mean Time, or GMT) when standard time is in effect and MUST NOT change on transition into or out of daylight- saving-time. For example: The Time_Zone field of a network element in Boston in December is "0-050000". The same network element in Boston in July is "1-050000" Sequence_Number Each network element MUST assign a unique and Unsigned integer 4 bytes monotonically increasing unsigned integer for each Event Message sent to a given RKS pair (primary/secondary). For the purpose of this specification, monotonically increasing is to be interpreted as increasing by 1. This is used by the RKS to determine if Event Message are missing from a given network element. Event_time Event generation time and date. Millisecond ASCII character 18 bytes granularity. This specifies the local time. i.e.after string applying Time_Zone UTC offset and Daylight Savings Time adjustment to UTC time. Format: yyyymmddhhmmss.mmm Status Status indicators See Table 36 4 bytes 66 Field Name Semantics Value Type Length Priority Indicates the importance to assign relative to other Unsigned integer 1 byte event messages. The processing of event message priority is defined as: • as long as there are higher priority messages within the system, lower priority messages SHOULD NOT be processed. • arrival of a higher priority message will not interrupt current lower priority message processing. Only after the completion of the message processing, the newly arrived higher message will be processed. For IPCablecom Release 1.0, values for this field will be service provider assigned. 255 = highest priority 0 = lowest priority 128 = default. Attribute_Count Indicates the number of attributes that follow (or are Unsigned integer 2 bytes appended to) this header in the current Event Message. Event_Object This field is not used in IPCablecom 1.0, and MUST be Unsigned integer 1 byte set to 0. 10.1.1 Billing Correlation ID (BCID) Field Structure Table 35 describes the Billing Correlation ID field (BCID). The RKS, or some other back office application, uses the BCID to correlate Event Messages that are generated for a single transaction. It is one of the fields in the Event Message Header attribute. The BCID is unique for each transaction in the network. All Event Messages with the same BCID SHOULD be sent to the same primary RKS except in failover circumstances in which case the Event Messages MUST be sent to secondary RKS. 67 Table 35. BCID Field Description Field Name Semantics Value Type Length Timestamp High-order 32 bits of NTP time reference Unsigned integer 4 bytes Element_ID Network wide unique identifier Right justified, space 8 bytes 5 digits (statically configured element number unique padded ASCII within an IPCablecom domain in the range of 0-99,999) character string Time_Zone Identifies daylight savings time and offset from ASCII character string universal time (UTC). Daylight Savings Time: 1 byte 0 = Standard Time 1 = Daylight Savings The Daylight-Savings Time indicator MUST be set to a value of 1 if the network element is in a region that implements DST and then only during the daylight- saving-time period (usually the summer months). Since there may be areas in which the daylight-saving-time offset indicates a time-change other than 1 hour, the receiving system (e.g. RKS) needs to correctly calculate local time based on knowledge of the area(s) in which the subscriber and the network element reside. UTC offset: + HHMMSS 7 bytes The offset is reported from the network element (CMS/MGC/CMTS) point of view; not based on the subscriber point of view. The UTC offset represents the time offset from universal time (formerly called Greenwich Mean Time, or GMT) when standard time is in effect and MUST NOT change on transition into or out of daylight-saving-time. For example: The Time_Zone field of a network element in Boston in December is "0-050000". The same network element in Boston in July is "1-050000". Event_Counter Monotonically increasing for each transaction. For the Unsigned integer 4 bytes purpose of this specification, monotonically increasing Event_Counter is to be interpreted as a increasing number that is greater than the preceding number. The Related_Call_Billing_Correlation_ID attribute structure is shown in Table 35. 10.1.2 Status Field Structure The Status field of the Event Message Header attribute is a 32-bit mask. Bit 0 is the low-order bit; the field is treated as a 4 byte unsigned integer. Table 36 presents Status field description. 68 Table 36. Status Field Description Bit Semantics Bit Count 0-1 Error Indicator: 2 0 = No Error 1 = Possible Error 2 = Known Error 3 = Reserved Notes: a) If the Error Indicator bit of the Status field is set to 2 (Known Error), the Error_Description attribute (EM attribute ID 31) MUST be included in the Event Message corresponding to this header. b) If the Error Indicator bit of the Status field is set to 1 (Possible Error), the Error_Description attribute (EM attribute ID 31) MAY be included in the Event Message corresponding to this header. 2 Event Origin: 1 0 = Trusted Element 1 = Untrusted Element 3 Event Message Proxied: 1 0 = Not proxied, all data known by sending element 1 = proxied, data sent by a trusted element on behalf of an untrusted element 4-31 Reserved. 28 The Status field bits 4 to 31 MUST be set to 0. 69 10.2 Call_Termination_Cause Attribute Structure Table 37 describes the data structure of the Call_Termination_Cause attribute. It is important to note that in some cases, the Call_Termination_Cause attribute may include a Call Completion Code that may indicate a successful call completion. Table 37. Call Termination Cause Data Structure Field Name Semantics Value Type Length Source_Document Identifies the source Document of the Cause Codes: Unsigned integer 2 bytes 0 = Reserved 1 = Telcordia Technologies Generic Requirements GR-1100-CORE, Section 2.9, Table 411 [6] 2 = Telcordia Technologies Generic Requirements GR- 1100-CORE, section 2.9, Table 235 [6]. A Source_Document value of 2 must only be used with the Service_Instance Event Message. 3 and above for future use. Cause_Code Cause Code Identifier. Meaning determined by Unsigned integer 4 bytes Source_Document defined in previous field. The Cause_Code attribute is a 4 byte value. • In the case where Source_Document = 1, the IPCablecom Cause_Code is populated based only on the GR-1100-CORE [6] (Table 411) definition of character 2 (Cause Category) and characters 3-5 inclusive (Cause Indication), and encoding these 4 characters as an unsigned integer. Characters 1 and 6 of Table 411 are not relevant. For example, the encoding of a Cause_Code with Cause Category of ITU Standard (0) and a Cause Indication of "Normal Call Clearing" (016) is the unsigned integer value 0016. • In the case where Source_Document = 2, the IPCablecom Cause_Code is populated based on the GR-1100-CORE [6] - Table 235 character 1. For example, the encoding of a Cause_Code with a Call Completion Code "Not completed: Invalid authorization code" (3) is the unsigned integer value of 0003. 70 10.3 Trunk Group ID Attribute Structure Table 38 describes the Trunk Group ID Data Structure. Table 38. Trunk Group ID Data Structure Field Name Semantics Value Type Length Trunk_Type 1 = Not Used Unsigned integer 2 bytes 2 = Not Used Value is the Trunk Group 3 = when an SS7 signaling trunk is directly Signaling Type Indicator as connected to IC/INC, SS7 direct trunk group defined in Telcordia GR- number 1100-CORE [6], Table 83. 4 = when an SS7 signaling trunk is connected to IC via AT and SS7 from AT to EO 5 = Not Used 6 = Not Used 9 = Signaling type not specified Trunk_Group_ ASCII Identifier. Values in the range 0000-9999. Right justified, space 4 bytes Number padded ASCII character string 10.4 QoS Descriptor Attribute Structure Table 39 describes the QoS Descriptor Data Structure. Table 39. QoS Descriptor Data Structure Field Name Semantics Value Type Length Status_Bitmask Bitmask describing structure Bit map 4 bytes contents. (See Table 34) Service_Class_Name Service profile name Right justified, space padded 16 bytes ASCII character string QoS_Parameter_Array QoS Parameters. Contents Unsigned integer array Variable length array of determined by Status Bitmask. 32-bit unsigned integers Table 40 describes the QoS Status Bitmask field of the QoS Descriptor attribute. Bits 2-17 describe the contents of the QoS_Parameter_Array. Each of these bits indicates the presence (bit=1) or absence (bit=0) of the named QoS parameter in the array. The location of a particular QoS parameter in the array matches the order in which that parameter’s bit is encountered in the bitmask, starting from the low-order bit. Each QoS parameter present in the QoS_Parameter_Array must occupy four bytes. The definition and encoding of the QoS parameters can be found in Appendix C of [11]. QoS parameters whose definition specifies less than four bytes must be right-justified (where the 4 bytes are to be treated as an unsigned integer) in the four bytes allocated for the array element. 71 Table 40. QoS Status Bitmask Start Bit Semantics Bit Count 0 State Indication: 2 0 = Illegal Value 1 = Resource Reserved but not Activated 2 = Illegal Value 3 = Resource Reserved & Activated 2 Service Flow Scheduling Type 1 3 Nominal Grant Interval 1 4 Tolerated Grant Jitter 1 5 Grants Per Interval 1 6 Unsolicited Grant Size 1 7 Traffic Priority 1 8 Maximum Sustained Rate 1 9 Maximum Traffic Burst 1 10 Minimum Reserved Traffic Rate 1 11 Minimum Packet Size 1 12 Maximum Concatenated Burst 1 13 Request/Transmission Policy 1 14 Nominal Polling Interval 1 15 Tolerated Poll Jitter 1 16 IP Type of Service Override 1 17 Maximum Downstream Latency 1 10.5 Redirected-From-Info Attribute Structure The text in this section has been removed because it is not within the scope of IPCablecom 1.0. 10.6 Electronic-Surveillance-Indication Attribute Structure The text in this section has been removed because it is not within the scope of IPCablecom 1.0. 10.7 Attributes For Conference Parties The text in this section has been removed because it is not within the scope of IPCablecom 1.0. 72 11 TRANSPORT INDEPENDENT EVENT MESSAGE ATTRIBUTE TLV FORMAT Every Event Message Attribute is defined by a Type Length Value (TLV) tuple. An attribute TLV tuple has the following format: Table 41. Event Message Attribute TLV-tuple format Field Name Semantics Field Length Attribute_Type IPCablecom Attribute Type 1 byte (refer to Table 33) Attribute_Length IPCablecom Attribute Length 1 byte (refer to Table 33) Note: Value is Attribute Length + 2 Attribute_Value IPCablecom Attribute Value Attribute Length bytes 73 12 IPCABLECOM EVENT MESSAGE FILE FORMAT The IPCablecom Event Message File Format has the following basic structure: 12.1 File Bit / Byte Order The following table defines the Bit / Byte order for the Event Message file. For fields that span multiple bytes, the high-order bit of the field is the highest order bit of the lowest-numbered byte. Conversely, the low-order bit of a multi-byte field is the lowest-order bit of the highest-numbered byte. Table 42. Bit / Byte Order for the Event Message File Bit / Byte Order High-order Bit Low-order Bit Binary 7 6 5 4 3 2 1 0 High-order Byte Byte 1 … … Low-order Byte Byte n 12.2 File Header The following header MUST be written at the start of a file formatted using the IPCablecom Event Message File Format: Table 43. File Header for IPCablecom Event Message File Format Field Name Semantics Length Type Format_Version Identifies the version of this file format. The 4 bytes Unsigned int value must be 1 to comply this version of the EM specification. EM_Count Number of EMs in File 8 bytes Unsigned int File_Creation_Timestamp YYYYMMDDHHMMSS.MMM 18 bytes ASCII File_Sequence_Number Monotonically increasing for each new file. 8 bytes Unsigned int For the purpose of this specification, monotonically increasing is to be interpreted as increasing by 1. Element_ID Network wide unique identifier 8 bytes Right justified, 5 digits (statically configured element space padded number unique within an IPCablecom ASCII character domain in the range of 0-99,999) string Time_Zone Identifies daylight savings time and offset ASCII character from universal time (UTC). string Daylight Savings Time: 0 = Standard Time 1 byte 1 = Daylight Savings The Daylight-Savings Time indicator MUST be set to a value of 1 if the network element is in a region that implements DST and then only during the daylight-saving-time period 74 Field Name Semantics Length Type (usually the summer months). Since there may be areas in which the daylight-saving- time offset indicates a time-change other than 1 hour, the receiving system (e.g. RKS) needs to correctly calculate local time based on knowledge of the area(s) in which the subscriber and the network element reside. UTC offset: +HHMMSS The UTC offset represents the time offset 7 bytes from universal time (formerly called Greenwich Mean Time, or GMT) when standard time is in effect and MUST NOT change on transition into or out of daylight- saving-time. For example: The Time_Zone field of a network element in Boston in December is "0-050000". The same network element in Boston in July is "1-050000". File_Completion_Timestamp YYYYMMDDHHMMSS.MMM 18 bytes ASCII Note: There is no checksum included in the file header. It is assumed that the transport mechanism is responsible for delivery of damage-free files. For example, both of the IP transport protocols, UDP and TCP, contain a checksum to protect against damaged messages. 75 12.3 File Naming Convention Files created using the IPCablecom Event Message File Format MUST use the following naming convention: "PKT- EM_yyyymmddhhmmss_pri_type_elementid_seq.bin." 12.3.1 Filename Components The following table describes each of the components of the filename: Table 44. Filename Components Component Semantics Type Length File_ID Identifies this file as containing Literal string ‘PKT-EM’ 6 characters IPCablecom Event Messages Timestamp Time at which file was opened by the yyyymmddhhmmss 14 network element characters Priority Priority of this file Integer in the range 1-4 1 character When processing multiple files with 4 is the highest differing priorities, files of higher 1 is the lowest priority must be processed before the lower priority files. A default value of 3 is recommended. File priority should be established by the application creating the file. Record_Type This flag identifies the record type Binary 1 characters contined in the file. Primary records If the file contains primary usage indicate new, while secondary data this will be a 0 (zero) if it records indicate previously contains a 1 (one) the file contains transmitted secondary data. Element_ID Network wide unique identifier Right justified, zero padded ASCII 5 characters 5 digits (statically configured character string element number unique within an IPCablecom domain in the range of 0-99,999) with leading zeros for padding. e.g. element id = 99 PKT- EM_yyyymmddhhmmss_pri_type_0 0099_seq.bin Sequence_Number Monotonically increasing sequence A fixed length character string that 6 characters number for each new file. For the allows only the characters 0-9, purpose of this specification, with an interger range of 000001- monotonically increasing is to be 999999. interpreted as increasing by 1. Left most positions are always padded with zero. 76 Each element of the filename components is separated by an underscore "_" character. The segment delimiter will also enable segments to be distinguishable simply by a parsing process. 12.4 Configuration Items The following items MUST be configurable by the IPCablecom network element creating the file: Table 45. Required Configuration Items Name Semantics Type Length Maximum File Maximum size of file, in bytes, to which flat file Unsigned integer 4 octets Length can grow before being closed for transport. Maximum Open Maximum amount of time, in seconds, before file Unsigned integer 4 octets Time must be closed for transport. The IPCablecom Network Element that created the file MUST close any currently open flat file at the first occurrence of either of the following events: • The file size exceeds the Max File Length • The file open duration exceeds the Maximum Open Time 12.5 File EM Structure Header When an EM is written out to a file, each event message MUST be identified by a structure header. The following identifies the File-based EM Packet Structure: Table 46. File-based EM Packet Structure Field Name Semantics Description ID Indicates an EM structure 2 byte, value of 0xAA 55. The value 0xAA 55 is chosen to enable synchronization of the EM boundary if there are any errors within an event message. Length Indicate the length of the entire EM structure 2 bytes, length of all attributes + 4 attributes Refer to Table 41. Event Message Attribute Event Message attributes TLV-tuple format. 77 13 TRANSPORT PROTOCOL This section specifies the possible transport protocols used between the IPCablecom network elements that generate Event Messages (CMS, CMTS, MGC) and the Record Keeping Server (RKS). These network elements MUST support RADIUS Accounting (RFC2866) with IPCablecom extensions as defined in this document. The optional transport protocol is FTP as defined in this document. The following are the IPCablecom transport requirements: • The transport protocol MAY support confidentiality of Event Messages. • End-to-end security across multiple administrative domains is not required. • RADIUS protocol parameters: • Retry interval and Retry count • For each RKS that may receive Event Messages, its IP address and UDP port • The IP address of each RADIUS server with which it may communicate 13.1 RADIUS Accounting Protocol The RADIUS Accounting protocol is a client/server protocol that consists of two message types: Accounting- Request and Accounting-Response. IPCablecom network elements that generate Event Messages are RADIUS clients that send Accounting-Request messages to the RKS. The RKS is a RADIUS server that sends Accounting- Response messages back to the IPCablecom network elements indicating that it has successfully received and stored the Event Message. The Event Messages are formatted as RADIUS Accounting-Request and Accounting-Response packets as specified in RFC2866 [5]. Although IPCablecom 1.0 specifies RADIUS as the transport protocol, alternate transport protocols MAY be supported in future IPCablecom releases. 13.1.1 Reliability The RADIUS messages are transported over UDP, which does not guarantee reliable delivery of messages, hence the request/response nature of the protocol (see RFC2865 [4] for the technical justification of choosing UDP over TCP for the transport of Authentication, Authorization, and Accounting messages). When an RKS receives and successfully records all IPCablecom Event Messages in a RADIUS Accounting-Request message, it MUST send an Accounting-Response message to the client. If the IPCablecom network element does not receive an Accounting-Reponse within the configured retry interval, it MUST re-send the same Accounting Request either to the same RKS or the alternate RKS (retries may alternate between primary and secondary RKS in a vendor-specific way). The IPCablecom network element MUST continue resending the Accounting-Request until it receives an acknowledgement from an RKS or the maximum number of retries is reached. The RADIUS server MUST NOT transmit any Accounting-Response reply if it fails to successfully record the Event Message. Once a Network Element succeeds in sending event messages to the secondary RKS server, a failover to the secondary RKS should occur. This is a non-revertive failover, meaning that the secondary RKS becomes active, and is the new primary RKS. For calls in progress, all subsequent event messages should be sent to the now active secondary RKS. For all new calls, the CMS should instruct the CMTS and MGC to use the new active RKS as the primary (ie, the previous secondary RKS becomes the new primary for subsequent calls). 13.1.2 RADIUS Client Reliability All Network Elements MUST store Event Messages until they have received an Acknowledgement (Ack) from an RKS that the data was correctly received and stored, or until the maximum number of retries has been reached. 78 Only when an Ack is received or the maximum retries reached are the NEs allowed to delete these Event Messages. If the maximum retries is reached, the NEs SHOULD write the Event Messages to an error file before deleting these Event Messages. In order to guarantee the reliable transfer of the data, the Radius Client should implement a user configurable Radius message Ack interval and the number of times the client needs to retransmit the event or message. The time interval should be configurable (suggested: 10msec to 10 sec), the number of retries should be configurable (suggested: 0 to 9). The number of retries should be attempted on both the primary RKS and secondary RKS. After exhausting the number of retries, the event message SHOULD be written to an error file and the event message can then be deleted from the network element. Notes: 1) The Radius Client MIB (RFC2620) does not contain these parameters. 2) This requirement implies that the RKSes use highly reliable storage media and are also highly available. 13.1.3 Authentication and Confidentiality Refer to the IPCablecom Security Specification [2] for details concerning the use of IPSec to provide both authentication and confidentiality of the RADIUS messages, and the details of the correct usage of the RADIUS shared secret. 13.1.4 Standard RADIUS Attributes Each RADIUS message starts with the standard RADIUS header shown in Table 47. Table 47. RADIUS Message Header Field Name Semantics Field Length Code Accounting-Request = 4 1 byte Accounting-Response = 5 Identifier Used to match accounting-request and accounting-response messages. 1 byte Length Total length of RADIUS message 2 bytes min value = 20 max value = 4096 Authenticator Computed as per RADIUS Specification [5] 16 bytes Two standard RADIUS attributes MUST follow the RADIUS Message Header: NAS-IP-Address and Acct_Status_Type. These two fields are included to improve interoperability with existing RADIUS server implementations since they are mandatory attributes in a RADIUS Accounting-Request packet. The NAS-IP-Address indicates the originator of the Accounting-Request message and MUST contain the IP address of the originating IPCablecom network element. The Acct-Status-Type attribute typically indicates whether the Accounting-Request marks the beginning of the user service (Start) or the end (Stop). Since an IPCablecom Accounting-Request message may contain multiple Event Message Packets, it could contain Event Messages which mark both the beginning and end of the user service. For this reason, an Acct-Status-Type value of Interim-Update is used to represent IPCablecom Event Messages. 79 Table 48. Mandatory RADIUS Attributes Name Type Length Value NAS-IP-Address 4 6 IP address of originating IPCablecom network element Acct-Status-Type 40 6 Interim-Update=3 Table 49. RADIUS Acct_Status_Type Type Length Value 40 6 bytes Interim-Update = 3 IPCablecom attributes are defined in Section 10 of this document. IPCablecom attributes are encoded in the RADIUS Vendor Specific Attributes (VSA) structure as described in this section. Additional IPCablecom or vendor- specific attributes can be added to existing Event Messages by adding additional RADIUS VSAs to the message. The Vendor-Specific attribute includes a field to identify the vendor, and the Internet Assigned Numbers Authority (IANA) has assigned IPCablecom an SMI Network Management Private Enterprise Number of 4491 for the encoding of these attributes. The RKS server SHOULD ignore Event Messages where the IPCablecom "Event Message type" is unidentified. The RKS server SHOULD also ignore IPCablecom event attributes where the event attribute type is unidentified. Table 50. Radius VSA Structure for IPCablecom Attributes Field Name Semantics Field Length Type Vendor Specific = 26 1 byte Length Total Attribute Length 1 byte Note: value is Vendor Length + 8 Vendor ID CableLabs = 4491 4 bytes Vendor Attribute Type IPCablecom Attribute Type 1 byte (refer to Table 33) Vendor Attribute Length IPCablecom Attribute Length 1 byte (refer to Table 33) Note: value is Vendor Length +2 Vendor Attribute Value IPCablecom Attribute Value Vendor Length bytes 80 13.1.5 IPCablecom Extensions 13.1.5.1 IPCablecom RADIUS Accounting-Request Packet Syntax < ::== ::== < IPCablecom EM> | < IPCablecom EM List> < IPCablecom EM> ::== < IPCablecom EM Attribute List> ::== | < IPCablecom EM Attribute List> The potential of a high Event Message volume raised the concern that the RADIUS mechanism for ensuring reliability via request/response may consume too much bandwidth or be too computationally intensive. This led to the requirement that it be possible to transmit multiple IPCablecom Event Messages in a single RADIUS message. The use of this ‘batch mode’ is left to the discretion of the IPCablecom network element and will likely depend on the latency requirements of the particular event type. The number of Event Messages encapsulated in a single RADIUS message is still subject to the maximum RADIUS message length restriction of 4096 bytes. The Event Message Header MUST be the first attribute within a given Event Message. If multiple Event Messages are sent in a single RADIUS Accounting-Request, the Event Message Header attribute indicates the start of a new Event Message. The order of the Event Message attributes which follow the Event Message Header is arbitrary. IPCablecom extends RADIUS Accounting, by introducing new attributes and new values for existing attributes. Since the RADIUS protocol is extendable in this manner, it is expected that existing RADIUS server implementations will require minimal modifications to support the batch collection of IPCablecom Event Messages. 13.1.5.2 Concatenation of Attributes The text in this section has been removed because it is not within the scope of IPCablecom 1.0. 13.2 File Transport Protocol (FTP) The File Transfer Protocol (FTP) [20] MAY be used by an IPCablecom network element to transport Event Messages to the RKS. The RKS MUST have FTP Server support. If this transport protocol is used, the RKS hosts an FTP server to accept files transferred by the IPCablecom network element. The IPCablecom network element acts as the FTP client, pushing the files to the RKS for processing. If FTP is used as a transport protocol, then the file MUST be formatted using the IPCablecom Event Message File Format. 13.2.1 Required FTP Server Capabilities The FTP Server at the RKS MUST have at minimum the following capabilities: • Minimum implementation as described in Internet Protocol Standards - STD9 [20] section 5.1. • PASV Mode (passive mode) command 81 • Data Type I, Image (binary) • Authentication support (PASS command) • File Transfer logging The FTP client SHOULD listen for the 226 response to the STOR (close data connection) to indicate the file was successfully transferred and excepted by the RKS before marking the file as transferred. The NE SHOULD attempt to resend the file during the next scheduled FTP session if a response other than 226 is received. 82