1、 International Telecommunication Union ITU-T J.204TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (06/2008) SERIES J: CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS Application for Interactive Digital Television Metrics gathering specification Recommendat
2、ion ITU-T J.204 Rec. ITU-T J.204 (06/2008) i Recommendation ITU-T J.204 Metrics gathering specification Summary Recommendation ITU-T J.204 defines a data format and transmission protocol for the collection of service delivery metrics on customer premises equipment, such as digital cable set top boxe
3、s Source Recommendation ITU-T J.204 was approved on 13 June 2008 by ITU-T Study Group 9 (2005-2008) under Recommendation ITU-T A.8 procedure. ii Rec. ITU-T J.204 (06/2008) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunicat
4、ions, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunicatio
5、ns on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure la
6、id down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunic
7、ation administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these manda
8、tory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws a
9、ttention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or ot
10、hers outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represe
11、nt the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2009 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T J.204 (06/2008)
12、 iii CONTENTS Page 1 Scope 1 1.1 Introduction and Purpose 1 2 References. 1 2.1 Normative References 1 2.2 Informative References 1 3 Terms and Definitions 2 4 Abbreviations and acronyms 2 5 Overview 2 5.1 General Context 2 6 Metrics Requirements. 3 6.1 Transmission Protocol 3 6.2 Data Model . 5 Ann
13、ex A Metrics Data Model Schema . 7 Annex B Schema Data Element Requirements. 16 B.1 protocolVersionMajor 16 B.2 protocolVersionMinor 16 B.3 hostID . 16 B.4 hostType . 16 B.5 createTime 16 B.6 transmitTime. 16 B.7 privateData . 16 B.8 serviceSelection 16 B.9 tuning 17 B.10 SDV 17 B.11 servicePresenta
14、tion. 17 B.12 segmentPresentation. 17 B.13 DPI 17 B.14 inputEvent. 18 B.15 applicationLoadRequested . 18 B.16 applicationLoaded 18 B.17 applicationLifecycle . 18 B.18 environmentSelection. 18 B.19 applicationMode. 19 B.20 application 19 Rec. ITU-T J.204 (06/2008) 1 Recommendation ITU-T J.204 Metrics
15、 gathering specification 1 Scope This Recommendation defines a data format and transmission protocol for the collection of service delivery metrics on customer premises equipment, such as digital cable set top boxes. Metrics are records generated by relevant service delivery events, such as a servic
16、e selection event. Each metrics record includes a timestamp of the event. This technology provides a means to accurately and efficiently collect metrics for the purpose of measuring service delivery. NOTE The structure and content of this Recommendation have been organized for ease of use by those f
17、amiliar with the original source material; as such, the usual style of ITU-T Recommendations has not been applied. 1.1 Introduction and Purpose The purpose of this Recommendation is to specify metrics collection and transmission mechanisms and interfaces on receiver platforms. The data formats and t
18、ransmission protocols may also be adopted by proprietary systems. For the purposes of this Recommendation, the term “metrics“ refers to specific data, defined herein, that is generated by a receiver and transmitted to a cable headend. Metrics, as defined in this Recommendation, are intended to compl
19、ement other measurement systems that may be employed by cable operators. 2 References 2.1 Normative References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication,
20、the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the curren
21、tly valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ATIS Usage Data Management For Packet-Based Services Service-Neutral Protocol Specification For Billing Applicat
22、ions, ATIS-0300075.1.2006, August 2006. https:/www.atis.org/docstore/product.aspx?id=22606 IPDR/SP IPDR/SP Protocol Specification Version 2.2, August 25, 2006. http:/www.ipdr.org/public/DocumentMap/SP2.2.pdf IPDR/XDR IPDR/XDR File Encoding Format, Version 3.5.1, November 2004. http:/www.ipdr.org/pub
23、lic/DocumentMap/XDR3.5.1.pdf 2.2 Informative References OCAP 1.1 OpenCable Applications Platform, Profile 1.1, OC-SP-OCAP1.1-I01-061229, December 29, 2006, Cable Television Laboratories, Inc. http:/ ETV Enhanced TV Binary Interchange Format, OC-SP-ETV-BIF1.0-I04-070921, September 21, 2007, Cable Tel
24、evision Laboratories, Inc. http:/ 2 Rec. ITU-T J.204 (06/2008) IPDR/SSDG IPDR/SSDG Service Specification Design Guide, Version 3.5.1, November 2004. http:/www.ipdr.org/public/DocumentMap/SSDG3.5.1.pdf 3 Terms and Definitions This Recommendation defines the following terms: 3.1 authorized collector:
25、An Event Tracking API-compliant server that implements the receiving side of the IPDR Streaming Protocol, and which has been authorized to participate in the overall Collection System. 3.2 data message: A message transmitted between an IPDR Exporter and Collector across the Streaming Protocol, conta
26、ining a common Streaming Protocol header and an optional payload consisting of control and Data Records. 3.3 data record: The binary encoding of an IPDR record. 3.4 Internet Protocol Detail Record (IPDR): The fundamental unit of data transferred between an Exporter and a Collector. It is defined by
27、a Template and contains Fields. 3.5 IPDR-Type: A constraint on the value and format of an individual Field within a Data Record; e.g., dateTime. 3.6 Internet Protocol Detail Record/Streaming Protocol (IPDR/SP): The protocol used to transfer Data Messages and Data Records between Exporter and Collect
28、ors. 3.7 IPDR/SP collector functionality: An implementation on the data-receiving side of the IPDR/SP. It enables the reception and collection of Data Records from IPDR/SP Exporters. It is typically part of an OSS/BSS, or a mediation system. 3.8 IPDR/SP exporter functionality: An implementation on t
29、he data-producing side of the IPDR/SP. It enables formatting and sending of Data Records to an interested consumer system, e.g., at a cable headend using the IPDR/SP. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations: CPE Customer Premises Equipment IPDR Internet Prot
30、ocol Detail Record IPDR/SP Internet Protocol Detail Record Streaming Protocol 5 Overview 5.1 General Context Metrics are a set of well-defined data that are reported to a cable network by a receiver, for the purpose of measuring certain aspects of cable service delivery. This Recommendation specifie
31、s a data model and transmission protocol. Platforms that support this Recommendation are expected to define the semantics for the data points that are syntactically defined herein. The means for metrics collection on the receiver is composed of a log, which contains log records. A log and log record
32、s are created and stored in a format determined by an implementer. Log records are created by the receiver in response to well-defined events, such as operations performed by a receiver on behalf of applications, or generated directly by applications. A log and its log records are transmitted from t
33、he receiver in a well-known format, under control of logic implemented by the network operator. Rec. ITU-T J.204 (06/2008) 3 There are three logical metrics components: a so-called “metrics engine“ implemented within a receiver; one or more privileged applications that configure and manage the metri
34、cs engine, collectively called the “metrics controller“; and any other “metrics logging“ applications that interface with the metrics engine to generate application-specific log records. This Recommendation defines requirements for a metrics engine and the interface between a metrics engine and a ca
35、ble headend. Metrics data is considered private to the cable network. Functions such as storage, aggregation, and reporting are the responsibility of a network operator. This interface provides a well-known data format and protocol to ensure that metrics are comparable across cable networks. The met
36、rics engine is a component of the system software that includes the operating system and middleware, such as OCAP that communicates with the controller and logging applications as well as the cable headend (see Transmission Protocol clause below). The middleware (e.g., OCAP), is a logical software l
37、ayer between the operating system and the applications that abstracts the functionality of the hardware and other functions and provides an interoperable application programming interface layer. The controller application informs the metrics engine which metrics data are of interest Figure 1 Logical
38、 Model of Metrics System Interfaces between metrics controller and logging applications and the metric engine are currently not defined within this Recommendation. We expect to include definition of a Java API for this purpose in a subsequent revision to this Recommendation. The metrics engine incor
39、porates IPDR/SP Exporter functionality. A cable headend that supports metrics implements IPDR/SP Collector functionality. See https:/www.atis.org/docstore/product.aspx?id=22606 IPDR/SP for details. 6 Metrics Requirements This clause defines requirements for metrics and the interface between a metric
40、s engine and a cable headend. 6.1 Transmission Protocol IPDR/SP is the protocol for transmitting metrics data to a cable headend. It is an American National Standard ATIS-0300075.1.2006 ATIS. The IPDR/SP utilizes a light-weight, session-oriented, real-time streaming protocol to quickly and reliably
41、deliver metrics data, a.k.a. IPDRs, from an “Exporter“ to a “Collector“ (typically a type of mediation system). Receivers that support this 4 Rec. ITU-T J.204 (06/2008) metrics Recommendation SHALL implement IPDR/SP Exporter functionality. For brevity, the term “metrics engine“ is to be understood t
42、o include IPDR/SP Exporter functionality. The “Collector“ is an implementation on the data receiving side of the IPDR/SP and is typically part of a back-office system. The IPDR/SP utilizes a slightly augmented version of the XDR protocol, described in IETF RFC 1832, to encode IPDRs. IPDR/SP uses man
43、y of the primitive types defined by the IETF XDR protocol to encode as much information as possible in a compact binary representation. The IPDR/SP uses TCP as its transport layer protocol. The transport layer acknowledgements are used to ensure the reliable delivery of data packets and detection of
44、 lost Exporters. In addition, IPDR/SP allows another level of application reliability as described below. 6.1.1 IPDR/SP Templates The IPDR/SP uses a highly-efficient encoding scheme, where only the values for each field of a particular type of IPDR are encapsulated and sent in a Data Message from th
45、e Exporter to the Collector. The field names, types, and lengths are not included in the IPDRs; instead, the field names, types, and lengths are specified indirectly by referring to a session-specific Template that describes contents of that type of IPDR. Within the IPDR/SP, IPDRs are always exchang
46、ed within the context of a particular session that exists between a particular Exporter and a particular Collector. During the session establishment phase, the Exporter provides the Collector with a list of Templates, where each Template describes the layout of a particular type of Data Record (a Da
47、ta Record is a binary encoding of an IPDR record) that can be sent to the Collector. Data Records are always packaged into a Data Message before being sent to the Collector. Each Template definition contains a TemplateID, an IPDR-Type name, an explicit reference to the XML Schema which describes the
48、 IPDR-Type referred to by the Template, and an ordered list of triplets, where each triplet consists of a field name, field ID, and type. These field names and types must correspond to those defined in the corresponding IPDR Schema for the particular IPDR-Type referred to by the Template. A particul
49、ar Template not only specifies an IPDR-Type and corresponding XML Schema, but also specifies the particular subset of fields, and the order in which those fields will be laid out within Data Records referencing that Template. A Template for a particular IPDR-Type does not have to contain all possible fields defined in the XML Schema for that IPDR-Type; it might exclude certain optional or conditional fields. As such, there could b
