[itu-sg16] Meeting documents
Paul E. Jones
paulej at packetizer.com
Wed Mar 23 07:23:39 EDT 2011
Dear all
Just as a reminder, for future reference, all documents circulated in the reflector for the Q13 electronic meeting discussions (AM and otherwise) between July 2010 and March 2011 are found in the SG 16 IFA at:
http://ifa.itu.int/t/2009/sg16/exchange/wp2/q13/Emeetings/1007-to-1103/
(TIES or enabled Guest account required)
Cheers,
Simao
From: Philip Jacobs (phjacobs) [mailto:phjacobs at cisco.com]
Sent: Wednesday, 09 March 2011 20:28
To: miao.chuanyang at zte.com.cn; bubble at etri.re.kr; lij1024 at etri.re.kr; Kawamori, Masahito (TIES); myhuh at etri.re.kr; ohky at tta.or.kr; sg9and16-iptv at lists.itu.int; sgkang at etri.re.kr; Xian Bertin; Hideki Yamamoto; zhangchuxiong at huawei.com; Vishwas Patil; Seong Yin WONG (IDA)
Subject: [T9&16IPTV] Summary notes of AM conf call 8 Mar 2011
<< Post Pune AM0 v10.zip >>
This meeting was attended by Vishwas, Christian, Mr Miao, and Phil
We discussed
1 – T09-IPTV.GSI-C-0hhh!!MSW-E[1] Cisco sample value definition
- rejected
- It was agreed that we would need data structures which include elements to be sampled, for use in measurement requests and in measurement reports.
- The elements to be sampled should be indirectly referenced by using the name of the data structure.
2 - T09-IPTV.GSI-C-0iii!!MSW-E[1] Cisco table 1 modification
- accepted
- Mr Miao volunteered to provide more information about STB Id
3 - T09-IPTV.GSI-C-0lll!!MSW-E[1] Cisco Target Content
- accepted modified
- specifying content to filter measurements at TD-AMF may prevent un-necessary network traffic, but could be done at aggregation functions
- if permits support permissions by content then permits also need content information, at TD-AMF or at aggregation functions if content filtering is done there
- if permits support permissions by content then for case of external permits, measurement request needs content information
- it was agreed to include content class exceptions e.g. not religion, for both measurement requests and permits.
- further discussion is needed to decide upon inclusion of listing content classes to be measured, add Editor’s note
- it was noted that gaps between two measured sessions could be inferred, this is similar for measured/unmeasured channels and/or content, etc.
- new issue: what action is to be taken when filtering by content class is configured but class is not available to TD-AMF?
4 - T09-IPTV.GSI-C-0kkk !! IDA Security - Cryptographic library support
- accepted modified
- the content should be written in ITU-T recommendation form, and included in clause 10.1.1
5 - T09-IPTV.GSI-C-0kkk !! IDA AMFs
- needs further discussion about how to modify proposed text
Please comment if these notes omit or incorrectly summarize our discussions
I suggest that during our Geneva meeting, we continue with today’s unfinished agenda then work through the Geneva contributions
Attached are the integrated changes of today’s discussions as Post Pune AM0 v10, please check. This document and Post Pune AM1 v4 should be used as the output from conference call meetings, and input for Geneva.
A conference meeting summary for Geneva will follow.
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Tuesday, March 08, 2011 5:51 PM
To: miao.chuanyang at zte.com.cn; bubble at etri.re.kr; lij1024 at etri.re.kr; Masahito Kawamori; myhuh at etri.re.kr; ohky at tta.or.kr; sg9and16-iptv at lists.itu.int; sgkang at etri.re.kr; Xian Bertin; Hideki Yamamoto; zhangchuxiong at huawei.com; Vishwas Patil; Seong Yin WONG (IDA)
Subject: Tentative agenda for AM conf call 9 Mar 2011
Dear All,
Thank you for your contributions and engagement
I suggest the following agenda:
1 – Complete discussion of T09-IPTV.GSI-C-0hhh!!MSW-E[1] Cisco sample value definition
2 - Review and discuss T09-IPTV.GSI-C-0iii!!MSW-E[1] Cisco table 1 modification
3 - Review and discuss T09-IPTV.GSI-C-0lll!!MSW-E[1] Cisco Target Content
4 - Review and discuss T09-IPTV.GSI-C-0kkk !! IDA Security - Cryptographic library support
5 - Review and discuss T09-IPTV.GSI-C-0kkk !! IDA AMFs
6 - Review and discuss T09-IPTV.GSI-C-0ppp!!MSW-E[1] Cisco Channel surfing
7 - Review and discuss T09-IPTV.GSI-C-0xxx!Huawei_message_ack_or_response
Is this OK?
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Thursday, March 03, 2011 4:02 PM
To: miao.chuanyang at zte.com.cn; bubble at etri.re.kr; lij1024 at etri.re.kr; Masahito Kawamori; myhuh at etri.re.kr; ohky at tta.or.kr; sg9and16-iptv at lists.itu.int; sgkang at etri.re.kr; Xian Bertin; Hideki Yamamoto; zhangchuxiong at huawei.com; Vishwas Patil; Seong Yin WONG (IDA)
Subject: [T9&16IPTV] Summary notes of AM conf call 3 Mar 2011
This meeting was attended by Vishwas, Christian, Kiyoshi, and Phil
1 – We discussed and accepted T09-IPTV.GSI-C-0eee!!MSW-E[1] Cisco acknowledgements
- Add MessageID in both structures
- Omit MessageType from messages headers, keep for ack/nak messages headers
- Add MessageBody following message header elements
- No default needed for ErrorCode
- Use string of message names for MessageType in ack/nak header
- another error example is “event not supported”
- Add Editor’s note: there may be an issue if multiple elements have the same name, then the problem element may not be identified
2 - We discussed and accepted T09-IPTV.GSI-C-0xxx!Huawei_config_pack_request_response
- Modify “available” to “currently in use”
- Add Editor’s note to indicate that the response may be integrated with ack/nak message – TBD
- Rename Version as PackageVersion
- Omit configpackinfo element
3 - We discussed and accepted T09-IPTV.GSI-C-0eee!!MSW-E[1] Cisco permission levels
- remove 3 types of permission message, and add Ed note to explain that there may be more types
- clarify about “controlled” information
- In App XII, add Editor’s note to say that example should use finalized elements only.
4 - We discussed T09-IPTV.GSI-C-0hhh!!MSW-E[1] Cisco sample value definition
- Using the same values for Sample and Event needs more discussion, the values for Sample including any defaults still need clarification
Please comment if these notes omit or incorrectly summarize our discussions and continue to contribute by email
It was agreed to hold the last meeting before Geneva next Wednesday if possible
It is believed that contributions not discussed during the next conference call are discussable in Geneva since Simao has posted conference call contributions to the ITU-T web site.
There appear to be six additional contributions relating to AM submitted for Geneva: 633 OKI, 641 Cisco, 642 Cisco, 645 ZTE, 646 Huawei, 648 Huawei – please reply if any are missed
Attached is AM0 v9, please check changes.
Thank you
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Wednesday, March 02, 2011 4:59 PM
To: 'miao.chuanyang at zte.com.cn'; 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Xian Bertin'; 'Hideki Yamamoto'; 'zhangchuxiong at huawei.com'; 'Vishwas Patil'; 'Seong Yin WONG (IDA)'
Subject: Tentative agenda for AM conf call 3 Mar 2011
Dear All,
Thank you for your contributions and engagement
I suggest the following agenda:
1 – Review and discuss T09-IPTV.GSI-C-0eee!!MSW-E[1] Cisco acknowledgements
2 – Review and discuss T09-IPTV.GSI-C-0eee!!MSW-E[1] Cisco permission levels
3 – Review and discuss T09-IPTV.GSI-C-0xxx!Huawei_config_pack_request_response
4 - Review and discuss T09-IPTV.GSI-C-0ggg!!MSW-E[1] Cisco user info change
5 - Review and discuss T09-IPTV.GSI-C-0hhh!!MSW-E[1] Cisco sample value definition
6 - Review and discuss T09-IPTV.GSI-C-0iii!!MSW-E[1] Cisco table 1 modification
7 - Review and discuss T09-IPTV.GSI-C-0lll!!MSW-E[1] Cisco Target Content
8 – Geneva meeting
Is this OK?
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Friday, February 25, 2011 10:19 AM
To: Philip Jacobs (phjacobs); 'miao.chuanyang at zte.com.cn'; 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Xian Bertin'; 'Hideki Yamamoto'; 'zhangchuxiong at huawei.com'; 'Vishwas Patil'; 'Seong Yin WONG (IDA)'
Subject: Summary notes of AM conf call 24 Feb 2011
This meeting was attended by Vishwas, Dr Yamamoto, Christian, Kiyoshi, Mr Miao and Phil (did anyone else join?).
1 – We discussed and accepted T09-IPTV.GSI-C-0ddd!!MSW-E[1] Cisco service independent request with modification
- modify reference to note to match note title
2 -We discussed and accepted AM0 section 9.1. T09-IPTV.GSI-C-0xxx!Huawei_measurement_data_section _review with modifications
- There were many modifications and additions, several suggested as documented in Phil’s emails. The results are changes to newly numbered Tables 1, 2 and 3.
- We should consider a location change event
- We agreed to use the terminology “user information” instead of “user profile”, and “user device information” instead of “system environment”. Changes to be made throughout document.
- Table 3 summary – AMFsource deleted, receiver config need to add specifics, AV service capability deleted, user status deleted, user viewing history deleted, userIDconf value is out of scope
- Add Note: Last remote button push may be a useful element
- Table 5 summary – Rename Element as Event, remove support column
3 – We discussed and accepted T09-IPTV.GSI-C-0xxx!Huawei_Config_package_examples & T09-IPTV.GSI-C-0aaa!!MSW-E[1]Revised AM0 example v2 with modifications
- Add element “Event” in table Measurement schedule metadata for "Measurement request"
- Since we remove EventList also remove SampList and add element “Sample” in table Measurement schedule metadata for "Measurement request"
- We agreed to use the 59th second in end time examples
- We need to add descriptive text with examples
- We need to explain defaults for samples
- There was much discussion regarding the choice of time format, xs:time was proposed in the contribution, other fixed suggestions were UTC or GMT. We accepted xs:time for now, and agreed to add a note to confirm this before consent.
- The description of the abnormal case modified should be “Audience measurement function misses the reporting time point in a delayed reporting configuration”.
- Add Editor’s note: There may be an issue if many STBs wake-up having stored measurements that need to be sent immediately
- MeasurementScheduleItem is an Element of MeasurementScheduleList. Container for time period for measurement
- MeasurementRequestSet is an Element of MeasurementRequestSection. Container for an individual measurement request set.
- MeasurementRequest element to be added. Container. In table First part of Metadata elements in "Measurement request"
- DefaultDeliveryAddressSet is an Element of "GeneralDefault". Container for list of default URL addresses to be used to send measurement reports from the AMF
- We should document that when events and periodic samples cover the same elements, an event which occurs between 2 sample times will delay the next sample time until the subsequent scheduled sample time.
- The definition of the values of Sample are TBD, they could be an element, a newly defined collection of elements or an event. This needs further analysis.
4 - We discussed and accepted T09-IPTV.GSI-C-0xxx!Huawei_User_permit_examples without modification
5 – Discussed application level ACK/NAKs – This is a management of AM function and our focus has been on AM functions, but if this is made optional and low overhead it could be helpful to operationally monitor the health and to debug AM systems. A contribution would be considered.
Phil to incorporate agreements into new versions of AM0 and AM1 (attached) – since several agreements were verbal, please check the tables!
Please comment if these notes omit or incorrectly summarize our discussions and continue to contribute by email until next week’s AM conference call meeting which will be on Thursday 3rd Mar.
Reminder: The deadline for contributions for Geneva is next Tuesday 1st March
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Wednesday, February 23, 2011 6:00 PM
To: Philip Jacobs (phjacobs); 'miao.chuanyang at zte.com.cn'; 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Xian Bertin'; 'Hideki Yamamoto'; 'zhangchuxiong at huawei.com'; 'Vishwas Patil'; 'Seong Yin WONG (IDA)'
Subject: Tentative agenda for AM conf call 24 Feb 2011
Dear All,
Thank you for your contributions and engagement
I suggest the following agenda:
1 – Review and discuss T09-IPTV.GSI-C-0ddd!!MSW-E[1] Cisco service independent request
2 – Review and discuss AM0 section 9.1. T09-IPTV.GSI-C-0xxx!Huawei_measurement_data_section _review
3 – Review and discuss T09-IPTV.GSI-C-0xxx!Huawei_Config_package_examples & T09-IPTV.GSI-C-0aaa!!MSW-E[1]Revised AM0 example v2
4 - Review and discuss T09-IPTV.GSI-C-0xxx!Huawei_User_permit_examples
5 – Review and discuss un-discussed requirements of AM0 Annex A
6 - Review and discuss Appendices II and III – do we support all possibilities?
7 - New questions raised during the week – application level acks/naks, event count
Is this OK?
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Friday, February 18, 2011 5:44 PM
To: 'miao.chuanyang at zte.com.cn'; 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Xian Bertin'; 'Hideki Yamamoto'; 'zhangchuxiong at huawei.com'; 'Vishwas Patil'; 'Seong Yin WONG (IDA)'
Subject: Summary Notes of AM conf call 17 Feb 2011
This meeting was attended by Vishwas, Young Sic Young, Christian, Aaron, Kiyoshi, Mr Miao and Phil.
1 – We discussed and accepted T09-IPTV.GSI-C-0xxx!Huawei_IPTV-SP-ID_user_permission with modifications
- Add UserPermit as the first element
- We need a mechanism to permit all service providers’ services to be measured
- The term “permit” is agreed to be used at the top level for the collection of permissions granted by a user
2 – We discussed and accepted T09-IPTV.GSI-C-0yxy!!MSW-E[1]Cisco sampling with the following modifications
- ToBeReported and SampleList are to be combined under the name SampleList
- Adjust alternative representation
- We need to explain how the relative priorities between Event and Sample priorities work (table 7)
- Remove paragraph regarding “catch-up” from text to go in appendix.
3- We discussed and accepted T09-IPTV.GSI-C-0xxx!Huawei_measurement_report with the following modifications
- add CaptionLanguage type
- PeriodicMeasurement element needs description
- discussions of WindowId, Rank, and what is a “main” service regarding display of multiple video channels.
4 - We discussed and accepted T09-IPTV.GSI-C-0bbb!!MSW-E[1] Cisco - User change event
- Add a requirement… “AM may optionally support presence detection”
- Walking through some use cases would help decide if this event’s data structure needs changing
5 - We discussed and accepted T09-IPTV.GSI-C-0zzz!Modification_For_Clause_11_Abnormal_Situation proposal 1 with the following exceptions
- The action for Requested_Info_Not_Available is TBD
- Discussion about what is an abnormal situation?
- Proposal 2 was not implemented since it differed from existing AM0 v6a Appendix – this was discovered after the meeting - needs further discussion
6 - We discussed and accepted T09-IPTV.GSI-C-0xxx!Huawei_config_pack_request
Christian volunteered to provide modified Huawei updates
Phil to integrate accepted Huawei and Cisco modifications into AM0 v7 and AM1 v3.
Note that Christian made a few further improvements to the updates which are incorporated in these new versions.
We momentarily have no pending contributions, so next week we can start on reviewing requirements, tables 3 and 4, appendices and the updated example.
Please comment if these notes omit or incorrectly summarize our discussions and continue to contribute by email until next week’s AM conference call meeting which will be on Thursday 24th Feb.
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Wednesday, February 16, 2011 6:27 PM
To: Philip Jacobs (phjacobs); 'miao.chuanyang at zte.com.cn'; 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Xian Bertin'; 'Hideki Yamamoto'; 'zhangchuxiong at huawei.com'; 'Vishwas Patil'; 'Seong Yin WONG (IDA)'
Subject: Tentative agenda for AM conf call 17 Feb 2011
Dear All,
Thank you for your contributions and engagement
I suggest the following agenda:
1 – Review and discuss T09-IPTV.GSI-C-0xxx!Huawei_schema issue
2 – Review and discuss T09-IPTV.GSI-C-0xxx!Huawei_IPTV-SP-ID_user_permission
3 – Review and discuss T09-IPTV.GSI-C-0yxy!!MSW-E[1]Cisco sampling
4- Review and discuss T09-IPTV.GSI-C-0xxx!Huawei_measurement_report
5 - Review and discuss T09-IPTV.GSI-C-0bbb!!MSW-E[1] Cisco - User change event
6 - Review and discuss T09-IPTV.GSI-C-0xxx!Huawei_config_pack_request
7 - New questions raised during the week
Is this OK?
Attached is a revised version of AM0 v6
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Monday, February 14, 2011 10:40 AM
To: Philip Jacobs (phjacobs); 'miao.chuanyang at zte.com.cn'; 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Xian Bertin'; 'Hideki Yamamoto'; 'zhangchuxiong at huawei.com'; 'Vishwas Patil'; 'Seong Yin WONG (IDA)'
Subject: Summary Notes of AM conf call 11 Feb 2011
This meeting was attended by Vishwas, Young Sic Young, Christian, Aaron, Mr Miao and Phil.
We noted that the tentative agenda omitted the contribution T09-IPTV.GSI-C-0xxx!Huawei_measurement_report – which will be added to next week’s agenda
1 - We discussed and accepted T09-IPTV.GSI-C-0xyz!!MSW-E[1] v3 (reference points) for AM0
2 – We discussed the 2 AM0 requirements contributions T09-IPTV.GSI-C-0xxy!!MSW-E[1]v3 (requirements) and T09-IPTV.GSI-C-0xxy!!CISCO_requirements_v2_Xian
- made modifications to requirements
- agreed to consolidate requirements
- we briefly discussed that the system should react immediately to a change in user permission, we should decide if we mean ~200ms (min time between pushing 2 buttons on a remote) or 1 hour
- agreed to highlight the requirements that we did not yet review
- Christian volunteered to clarify “The architecture can optionally support the ability to ask for the end-user’s permission or to check with already captured user permission prior to starting measurements.”
3 – We discussed modifications regarding Post Pune AM1 V1_Huawei_cleaning
- agreed to completely delete clause 7 – Locations of audience measurement and aggregation functions
- agreed to completely delete clause 8 – OK up to the figure “High-level Procedural flow of Audience measurement in Linear TV”
- agreed to completely delete Appendix “Distributed content services in IPTV”
- agreed to completely remove non linear services from Appendix table, and remove CableLabs “ContentId”information
- accepted Post Pune AM1 V1_Huawei_cleaning with the above modifications
- regarding the LinearTV procedural diagram, we agreed that we should ask for a contribution in the next phase to add this back in.
4 – We had been discussing AM0 “API” and “Location of end-user measurement functions and delivery mechanism“ clauses via email, and agreed to remove them. We will consider adding these kinds of clauses again in the next phase.
Christian volunteered to update how contribution regarding LinearTVQualifier
Phil will integrate accepted changes into AM0 and AM1
The resulting AM0 version 6 and AM1 version 2 are attached. (There is an issue with AM1 clause numbering of clause 7.)
Please comment if these notes omit or incorrectly summarize our discussions and continue to contribute by email until next week’s AM conference call meeting on which will be on next Thursday 17th Feb.
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Thursday, February 10, 2011 3:34 PM
To: Philip Jacobs (phjacobs); 'miao.chuanyang at zte.com.cn'; 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Xian Bertin'; 'Hideki Yamamoto'; 'zhangchuxiong at huawei.com'; 'Vishwas Patil'; 'Seong Yin WONG (IDA)'
Subject: Tentative agenda for AM conf call 11 Feb 2011
Dear All,
Thank you for your contributions and engagement
I suggest the following agenda:
1 – Complete the discussion of revised T09-IPTV.GSI-C-0xyz!!MSW-E[1] v3 (reference points)
2 – Review and discuss revised T09-IPTV.GSI-C-0xxy!!MSW-E[1]v3 (requirements) and T09-IPTV.GSI-C-0xxy!!CISCO_requirements_v2_Xian
3 – Ratify Phil’s email re: acceptance with modifications regarding Post Pune AM1 V1_Huawei_cleaning
4 – Review and discuss T09-IPTV.GSI-C-0xxx!Huawei_schema issue
5 – Review and discuss T09-IPTV.GSI-C-0xxx!Huawei_IPTV-SP-ID_user_permission
6 – Review and discuss T09-IPTV.GSI-C-0yxy!!MSW-E[1]Cisco sampling
7 - New questions raised during the week
Is this OK?
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Friday, February 04, 2011 3:26 PM
To: Philip Jacobs (phjacobs); 'miao.chuanyang at zte.com.cn'; 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Xian Bertin'; 'Hideki Yamamoto'; 'zhangchuxiong at huawei.com'; 'Vishwas Patil'; 'Seong Yin WONG (IDA)'
Subject: Summary Notes of AM conf call 3 Feb 2011
This meeting was attended by Vishwas, Dr. Yamamoto, Christian, and Phil.
We discussed
- T09-IPTV.GSI-C-0xxx!Huawei_report_delivery
- Proposal 1 – accepted with following modifications
- note C1 regarding the 4 values MeasurementDeliverySchedule should be moved to notes column
- modify “StartDeliveryTime” and EndDeliveryTime” to include “window” rename as -> “StartDeliveryWindowTime” and “EndDeliveryWindowTime”
- multiple delivery periods are to be supported
- Add Ed note under table “multiple mechanisms to define delivery opportunities have been discussed, final selection is TBD”
- Proposal 2 – accepted with the addition of the word “window” and addition of “end delivery time allows any measurement report message already in process of delivery to complete”.
- Proposal 3 – accepted with additions of support for pull mode below
- when AMF is out of storage (storage overload) while waiting a pull mode report measurement request message, the meaning of this indicator is to turn pull mode into push mode in order to delivery currently stored measurement data. To be determined by context in measurement request.
- New Issue: We should say something about the requirement for non-volatile storage for TD-AMF
- New Issue: We should say something about the minimum TD-AMF storage required to support profile 0. Vishwas volunteered to look into this.
- T09-IPTV.GSI-C-0xxx!Huawei_AM_request_set
- Proposal 1 – accepted with modifications below
- indicate that multiple AMF request sets may be present in a configuration package
- Proposal 2 – we should include a list of delivery periods instead
- Proposal 3 - time format of 12am and all other representation of time in AM recommendations should use standard time format instead
- Proposal 4 - accepted
- T09-IPTV.GSI-C-0xxx!Huawei_config_package
- Accepted with modifications below
- add of “effectivity time” element with “immediate” as default
- add “list of AMF request sets” element
- rename AM to AMF in multiple places
- New Issue: what happens to stored data when new configuration becomes effective?
- New Issue: Management in general needs to be considered broadly, both for the management of normal operations and for abnormal situations
- T09-IPTV.GSI-C-0xxx!Huawei_user_permission
- Accepted with following modifications
- Add list of services element
- Add list of device type ID
- Modify name to UserPermissionLevel
- T09-IPTV.GSI-C-0xyz!!MSW-E[1] (reference points)
- Should we include sources of measurement data (“B” reference points)? This would provide a check on whether specified metadata is available, and inform implementers where to get specified metadata. We agreed that this would be helpful information, and that we should work on this after initial consent.
- Phil will submit a modified contribution.
- T09-IPTV.GSI-C-0xxy!!MSW-E[1]v2 (requirements) and T09-IPTV.GSI-C-0xxy!!CISCO_requirements_v2_Xian
- Christian has partially reviewed Phil’s v2 contribution, Phil to review comments, Christian to complete review of contribution. Christian’s review is a very good format for commenting. All are encouraged to use for feedback.
- Post Pune AM1 V1_Huawei_cleaning
- Rather than use conference call time for individual comments, please review and provide comments on whole contribution by email. Will address during next conference call.
- Regarding the need for sampling – per Phil’s email regarding the need for sampling for “checkpointing” in order to not lose data due to device “power-down” or “sleep-mode” – it seems that sampling is needed, unless we can devise other mechanisms – further input is requested. If sampling is to be supported we need to add one or more elements.
Christian to update contributions, Phil to integrate into AM0.
The revised AM0 version 5 is attached. During editing some new issues became apparent so notes were added and further minor modifications were made to the contributions. Also a couple of formatting issues crept in which will be resolved in a future revision.
Please continue to contribute by email until next week’s AM conference call meeting on which will be on either next Thursday or Friday – to be confirmed by Tuesday.
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Wednesday, February 02, 2011 5:27 PM
To: Philip Jacobs (phjacobs); 'miao.chuanyang at zte.com.cn'; 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Xian Bertin'; 'Hideki Yamamoto'; 'zhangchuxiong at huawei.com'; 'Vishwas Patil'; 'Seong Yin WONG (IDA)'
Subject: Tentative agenda for AM conf call for 3 Feb 2011
Dear All,
Thank you for your contributions and engagement
I suggest the following agenda:
1 – Continue discussion regarding T09-IPTV.GSI-C-0xyz!!MSW-E[1] specifically “what should be included in a reference diagram”
2 – Review of T09-IPTV.GSI-C-0xxx!Huawei_report_delivery
3 – Review of T09-IPTV.GSI-C-0xxx!Huawei_AM_request_set
4 – Review of T09-IPTV.GSI-C-0xxx!Huawei_config_package
5 - Review of T09-IPTV.GSI-C-0xxx!Huawei_user_permission
6 – Review of Post Pune AM1 V1_Huawei_cleaning
7 - New questions raised during the week
Is this OK?
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Friday, January 28, 2011 12:23 PM
To: Philip Jacobs (phjacobs); miao.chuanyang at zte.com.cn; bubble at etri.re.kr; lij1024 at etri.re.kr; Masahito Kawamori; myhuh at etri.re.kr; ohky at tta.or.kr; sg9and16-iptv at lists.itu.int; sgkang at etri.re.kr; Xian Bertin; Hideki Yamamoto; zhangchuxiong at huawei.com; Vishwas Patil; Seong Yin WONG (IDA)
Subject: Summary Notes of AM conf call for 27 Jan 2011
This meeting was attended by Aaron, Kiyoshi, Christian, Soyoung, Mr Miao and Phil.
We reviewed and discussed T09-IPTV.GSI-C-0zzz!Modification_Against_Apendix_VIII
- omit “or by AMF” in 1.1.1
- the tern “error recovery” is accepted
- “audience permission function” should not be referred to in body.
- “mission identifiers” is replaced by measurement request identifier
- 1.1.2.1 should list all additional qualifiers of deleted references
- add note to remind us to add description of random AMF transmit time
- add note that we need configuration for cryptographic and transport protocols in Phase 1
- remove clause regarding white-list since this is for non TD-AMFs
- Aaron will revise for future review
We reviewed and discussed T09-IPTV.GSI-C-0yyy!AM1_LinearTV
- Proposals 1,2 and 3 accepted
- Proposal 4 - add note to remind us that AM0 says Content Identifier is mandatory, and we need to harmonise this
- Proposal 5 - add note to consider if audio and caption language are service independent
- should “time to measure” be in Linear Event table since it is service independent?
- new issue – need to better understand why we have time sampling
- new issue – should time sampling be reset when an event occurs?
- keep support column in table until consent, remove if not needed
- Proposal 6 - in 9.1.1 use channel identifier term consistently, remove “tuned”
- Need “view mode” description added to description of linear services in AM1 clause 8.1
- Need “PIP” explanation added to description of linear services in AM1 clause 8.1
- Need to add big/small parameter for PIP view mode
- We can use channel start and stop to indicate events of small channel
- need configuration of report on PIP – viewmode
- Proposal 7 – Add note to AllChannelsExceptList indicate that we mean All subscribed channels
- Add default to AllChannelsExceptList to indicate empty list means all channels
- Accepted when modified by Christian for next revision of AM1
We reviewed and discussed T09-IPTV.GSI-C-0xxx!AM_profiles
- Add text in AM0 to introduce profiles.
- Proposal 1 – omit first sentence
- Should we include permission mechanism options? yes
- Storage option is not needed
- Proposal 2 – modify AMFCapabilityProfile values to indicate support for more profiles
- Proposal 3 – add qualifier to 10.4 to indicate this is the AMF capability profile communication mechanism for the “Audience measurement function with user permission management by IPTV SP” permission mechanism
- Add to 10.4 note: need more messages to support exchange of AMF capability profile between AMF and aggregation functions
- Accepted when modified by Christian for next revision of AM1
We reviewed and discussed T09-IPTV.GSI-C-zzz!!MSW-E[1]
- Note for RequestId should say: indicates that an AMF should respond with available data from this specific measurement request.
- Accepted when modified by Phil for next revision of AM0
We reviewed and discussed T09-IPTV.GSI-C-0xyz!!MSW-E[1]
- We will keep figure 2 “as is” showing all AMFs and move dotted lines to white space between Y.1910 functions
- In proposed new reference diagram, some Y.1910 blocks do not have a direct connection to “IPTV applications” in Y.1910, modify to show line to edge of main functions
- We will not define B interfaces, but we should identify any needed improvements to existing B interfaces if already defined
- Phil will revise for a future review
Please email this group if there are mis-statements or omissions above.
Phil will integrate new contributions and send new revisions of AM0 and AM1 out soon.
Please continue to contribute by email until next week’s AM conference call meeting on Feb 3 (Happy Chinese New Year!)
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Friday, January 21, 2011 10:44 AM
To: Philip Jacobs (phjacobs); 'miao.chuanyang at zte.com.cn'; 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Xian Bertin'; 'Hideki Yamamoto'; 'zhangchuxiong at huawei.com'; 'Vishwas Patil'; 'Seong Yin WONG (IDA)'
Subject: Summary Notes of AM conf call for 20 Jan 2011
This meeting was attended by Aaron, Kiyoshi, Vishwas, Christian, Dr. Yamamoto, Mr Miao and Phil.
We reviewed and discussed T09-IPTV.GSI-C-0zzz!MRandUP_structuresR2
- This helps map metadata across AM0 and AM1 and proposes metadata clauses structure for AM1
- It introduces the new concept of a common group of metadata within a configuration package, that applies to all included measurement requests
- It introduces the new concept that user profile and device configuration may be thought of as “user profile service” and “device configuration service”
- It is accepted with selected parts to be integrated into a new AM0 appendix.
We reviewed and discussed T09-IPTV.GSI-C-0yyy!!AM_request_metadata. This has been further developed since the clause was proposed before Pune, the main points discussed were as follows:
- It is not yet agreed whether ServiceTypeID can be 1 or more, each service will be given an integer value, each service must be clearly defined, e.g. Does Linear service include trick-mode?
- “ToBeMeasured” is a misleading term, maybe something like serviceQualifiers would be clearer
- “ToBeReported” includes service independent events so the note should change
- “Measurementschedulelist” = 1
- Add note to indicate the higher integers indicate higher priority
- Delivery address – may be useful to send to multiple addresses for multiple purposes, this could be used as an update to the destination after the original address was initially found using discovery process. New issue: can an URL define all security and transport protocols?
- Delivery “eventlist” not needed since any measured event will trigger delivery if EventTrigger is set.
- random number parameter is not needed to be sent to STBs as a seed, the STB should use an internal seed to randomize the delivery time around the specified periodicity
- RequestId can serve the same purpose as the previously proposed missionID, therefore missionID(s) no longer need to be sent to AMFs.
- New issue: we need to consider if multiple delivery periods are needed.
- New topic – should we support use case where delivery period is not the same as measurement period? Yes. It seems that existing use of metadata supports this. Has storage and offline STB implications
- New Issue – how should the impacts of “offline” STBs be handled? Introduction of an intermediate database was discussed. Not resolved.
- other editorial changes
Please email this group if there are mis-statements or omissions above
Christian will revise these two contributions then Phil will check and integrate into a revised AM0 version (3) and distribute.
Please continue to contribute by email until next week’s AM conference call meeting on Jan 27, when we will start the agenda with item “c” below
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Wednesday, January 19, 2011 3:39 PM
To: 'miao.chuanyang at zte.com.cn'; 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Xian Bertin'; 'Hideki Yamamoto'; 'zhangchuxiong at huawei.com'; 'Vishwas Patil'; 'Seong Yin WONG (IDA)'
Subject: Tentative agenda for AM conf call for 20 Jan 2011
Dear All,
Thank you for your contributions and engagement
I suggest the following agenda:
1 – Outstanding contributions (as distributed on this email list)
a) Review of T09-IPTV.GSI-C-0zzz!MRandUP_structuresR2
b) Review of T09-IPTV.GSI-C-0yyy!!AM_request_metadata
c) Review of T09-IPTV.GSI-C-0zzz!Modification_Against_Apendix_VIII
d) Merging figures 14 and 2
e) Review of T09-IPTV.GSI-C-0yyy!AM1_LinearTV
f) Review of T09-IPTV.GSI-C-0xxx!AM_profiles
g) New questions raised during the week
Is this OK?
I hope that there is confirmation of the time of this meeting before it starts, otherwise please try 8am USA, 2pm Geneva, 9pm China/Singapore, 10pm Japan
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Friday, January 14, 2011 11:02 AM
To: 'miao.chuanyang at zte.com.cn'; 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Xian Bertin'; 'Hideki Yamamoto'; 'zhangchuxiong at huawei.com'; 'Vishwas Patil'; 'Seong Yin WONG (IDA)'
Subject: RE: Summary Notes of AM conf call for 13 Jan 2011
Dear All,
I mistakenly omitted some changes in “Post Pune AM0 v1” which are now incorporated into “Post Pune AM0 v2”.
Please delete “Post Pune AM0 v1” and use “Post Pune AM0 v2” instead.
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Thursday, January 13, 2011 5:57 PM
To: 'miao.chuanyang at zte.com.cn'; 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Xian Bertin'; 'Hideki Yamamoto'; 'zhangchuxiong at huawei.com'; 'Vishwas Patil'; 'Seong Yin WONG (IDA)'
Subject: Summary Notes of AM conf call for 13 Jan 2011
This meeting was attended by Aaron, Kiyoshi, Vishwas, Christian, Dr. Yamamoto and Phil. Mr Miao sent his regrets.
We discussed/decided the following:
1 - The published meeting time for China was incorrect. We will poll group members to see if a 3 hour meeting starting 1 hour earlier would be OK. That is 8am USA, 2pm Geneva, 9pm China/Singapore.
2 - 1a – Pune output document – - Christian explained the rationale for the changes was to move both informative text and text that was not ready for the main body to appendices. The text that was not ready would be moved to the body when ready. The document was accepted as the new base AM0 document, many further contributions needed
3 - 1b- T09-IPTV.GSI-C-0498!!Huawei_AM0_user_permissionsR1 accepted “as is” for integration into base, as clause 12.1.2.3. Associated text needs to be modified/added.
4 - 1c – Discussions of C500 and C501 were deferred, they will be resubmitted. C502 is already in the base document appendix. C503 has been superseded with the exception of the configuration package metadata which will be resubmitted. C521 was accepted as the new base AM1 document, many further contributions needed. C520 was accepted with the addition of a note regarding the following two issues.
5 - issue – Regarding the situation with multiple services in a single measurement request (or multiple measurement requests), will this result in duplicate information being reported?
6 - issue – Regarding specifying measurement by specific content, e.g. a show. If many (thousands) of shows are listed to be measured, then the complexity and processing requirements may increase beyond what a STB with AM software may support. If this is a retail STB, then it may not be clear to the SP what its capabilities are. (Maybe published profiles will help identify the STB capabilities to an SP)
7 - issue list – to track issues we will generate and use an issue list, the figure from C520 Figure VI-4.1e will be included with the above issues.
8 - 2a – There is a 4th option, which is to delete material without saving it in a holding document
9 - 2a and 2b - Rather than set a predetermined strategy for AM0 and AM1, we will just use contributions
10 – 3a - We accepted the revised scope to match Pune discussions per email discussions
11 – 3b - We accepted the revised emailed A1 description after deleting the first point and removing the word “federated”.
12 – next meeting we will continue discussions starting with items 3d, 3c, 3e and 3f
Please email this group if there are mis-statements or omissions above.
Attached is “Post Pune AM0 v1” which includes the agreed changes above, the “Post Pune AM1 v0” base document and issues list will follow.
The next meeting will be on Thursday 20 Jan, at a time at be confirmed.
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Wednesday, January 12, 2011 11:34 AM
To: Philip Jacobs (phjacobs); 'miao.chuanyang at zte.com.cn'; 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Xian Bertin'; 'Hideki Yamamoto'; 'zhangchuxiong at huawei.com'; 'Vishwas Patil'; 'Seong Yin WONG (IDA)'
Subject: Tentative agenda for AM conf call for 13 Jan 2011
Dear All,
Thank you for your contributions and engagement
I suggest the following agenda:
1 – Outstanding Pune Items
a) Discussion of updated_TD-GEN-0383!!AM0_7_2
b) Acceptance of T09-IPTV.GSI-C-0498!!Huawei_AM0_user_permissionsR1
c) Review of other Pune contributions if author(s) wish, C500, C501, C502, C503, C520 and C521
2 - Strategy for Phase 1 AM0 and AM1
a) How to handle existing text related to subsequent phases (e.g. Depricate existing body text, move existing text to Appendix, and/or move to a new holding document)
b) Agree on criteria to include text in body (e.g. If it is needed for implementation interoperability, if it supports concepts needed for implementation, if it is an ITU mandatory section)
3 - New AM0 contributions (as distributed on this email list)
a) Review of Scope
b) Review of A1 description
c) Review of T09-IPTV.GSI-C-0yyy!!AM_request_metadata
d) Review of T09-IPTV GSI-C-0zzz!MRandUP_structures
e) Review of T09-IPTV.GSI-C-0zzz!Modification_Against_Apendix_VIII
f) Merging figures 14 and 2
Is this OK?
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Thursday, January 06, 2011 5:46 PM
To: 'miao.chuanyang at zte.com.cn'; bubble at etri.re.kr; lij1024 at etri.re.kr; Masahito Kawamori; myhuh at etri.re.kr; ohky at tta.or.kr; sg9and16-iptv at lists.itu.int; sgkang at etri.re.kr; Xian Bertin; Hideki Yamamoto; zhangchuxiong at huawei.com; Vishwas Patil; Seong Yin WONG (IDA)
Subject: Unofficial notes and output from Pune and summary notes of AM conf call for 6 Jan 2011
This meeting was attended by Christian, Mr Miao, Kiyoshi, Dr Yamamoto, Dr. Vishwas and Phil
1 - Christian presented his Pune meeting notes and the Pune-accepted revision of AM0 which re-organized the order of content from T09-IPTV.GSI-101213-TD-GEN-0383 and integrated IPTV-GSI-C-502. These two documents are expected to be posted on the ITU-T site with the minor modification of a new TD number for the revised AM0.
2 – It is proposed to use the attached Pune version of AM0 as the basis for further work. Please review this document fully.
3 - Regarding a liaison received from DTG, their AM solution was due to be published 5 Jan. The latest version available to DTG members on DTG’s site today is DTG D-Book 7 Part B 0.6, DTG AM is described in clause 8.
4 – Regarding the organization of AM0, It was suggested that the body of AM0 should focus on the a1 interface, and should only include descriptions of concepts, and supporting text to fully describe communications across a1. Specifically there is a missing specification and examples of measurement responses which should be included in AM0.
5 – Regarding organization of AM0, there was discussion regarding if requirements should be moved to an Annex in order to keep the focus in the main body on the solution.
6 - We reviewed T09-IPTV.GSI-C-0498 and agreed on some modifications. One remaining question is whether the flow chart should include SP connection and User disconnect arrows. 0498 will be integrated in AM0 after agreeing on this point, and review of AM0.
7 – There was discussion of reporting/non-reporting of the special case when a user switches from allowed measurement service to an un-allowed measurement service. For example, a linear channel change from an allowed measurement channel to an un-allowed measurement channel. The question is whether a report should be made to report this change.
8 – The flow in 0498 includes a user login, which leads to that single user’s permissions being used. The broader question of what permissions to use when multiple users simultaneously watch a shared TV was asked. AM0 currently says that the most restrictive permission of users watching should be used, but this topic needs further discussion.
[Note: when 0498 is integrated, there will be associated text that needs to be added in at least two clauses, 1 - informative, guidance for when an SP should use this method compared to the other two permission methods, and 2 - normative, in the description of reference points.]
Until the next meeting, please
a- review the attached AM0
b- review the other Pune contributions.
c- consider the unresolved points above
d- email this list with your suggestions and further contributions
Please correct or add to anything substantial that I either mis-stated or missed.
The next meeting will be held on Thursday 13 Jan
https://www1.gotomeeting.com/join/891923233 <https://www1.gotomeeting.com/join/891923233>
Meeting Password: am
Meeting ID: 891-923-233
Regards
Phil
From: miao.chuanyang at zte.com.cn [mailto:miao.chuanyang at zte.com.cn]
Sent: Thursday, November 25, 2010 8:10 PM
To: Philip Jacobs (phjacobs)
Cc: bubble at etri.re.kr; lij1024 at etri.re.kr; Masahito Kawamori; myhuh at etri.re.kr; ohky at tta.or.kr; sg9and16-iptv at lists.itu.int; sgkang at etri.re.kr; Xian Bertin; Hideki Yamamoto; zhangchuxiong at huawei.com
Subject: Summary Notes of AM conf call for 25 Nov 2010
This meeting was attended by Mr.Christian and Miao,
The discussion was based on Mr.Christian's informative clarification on use of User Permissions. The results are following:
1 - modify the proposal from christian from all AMF to TD-AMF and aggregation functions as follows:
"This proposal aims at illustrating how the AM user permissions are used by TD-AMF and aggregation functions."
2 - about the proposed Figure2, it was agreed to generate another solution which is to generate a message after User login from IPTV SP to AM SP to provide UserID and AM user permissions. TO remove the AM config package request. This request push mechanism between IPTV SP and AM SP.
3 - Reference points B1 and B2 are the interface to User database. We have to identify what is the really need by AM Aggregation functions. E.G. age, location, gender, etc. When we know that, we should defined a unique enter point for exchange between Aggregation functions and All other IPTV functions. This is a suggestion. we should make clear description on B1 and B2 - how to obtian User profile from serive User profile FB and Application profile FB.
There is not more comments for AM.0 v7.1 which is the lastest change. And the document which integrated all modification based on the last Singapore meeting TD will be issued before Pune meeting as the CC's draft recommendation and a meeting report will be attached.
And Mr.Christian, please add something if I missed or there is error.
Thanks and Best Regards!
Miao
ZTE
This meeting was attended by Christian, Mr Miao and Phil
Since the November 11th,, the accepted changes were integrated into version 6. Several documents were produced for further discussion.
A revision of the introductory diagram for Aggregation functions configuration was documented (see « About the harmonise modification » attachment) and discussed.
1 – We agreed to accept the new drawing with modifications as follows :
2 - Modify lables « Measurement metadata » to « Measurement data » and Measurement report decompose » to « Measurement report »
3 – We agreed to add a description under the figure with examples.
4 – We noted that Supplementary IPTV data relates to figure 1’s « Other IPTV functions ». This might include for example, the actual name of a channel instead of channelId.
5 - We noted that in figure 1, there are two instances of « Other IPTV functions » which may not be identical, and need to have some description added.
6 – Regarding the accompanying text, we agreed that instead of a single defintiion of « configuration package », we need two definitions, one should be generic for « configuration package », the second should be specific to « AMF configuration package »
7 – We noted that the new figure is related to the outstanding topic of permissions that needs to be resolved.
A revision of the introductory diagram for AMF configuration was documented (see « About the AMF architecture » attachment) and discussed.
1- We agreed that the third figure needs to be modified as follows, approved then should replace the existing figure
2- Remove the Transmission Timing Configuration Function Block
3- Show 1 green arrow from AM Data Delivery Functions to Configuration Package Process Functions
4- Show 1 green arrow from CPPF to AM Data delivery and one to Application Event Handling Functions
5- Add a new optional function in the path of green Local permission configuration arrow named « Permission Acquisition Function »
6- Add a description of the figure under the figure.
7- We noted that the internal partitioning of AMF and Aggregation functions is provided as an example, implementations may differ in their partition of functions and still be compliant to the reccomendation. A sentence regarding this should be added to aggregation functions and AMF clauses.
Configuration object figures and new permissions method were documented (see « AMF Configuration Objects » attachment) and discussed
1 – Christian described the slide “IPTV Operation mode with AM » which is a new proposed method of configuring TD-AMFs in real-time based upon user identification. (This is Phil’s way of summarising it, Christian please correct if mis-stated)
2 – This proposed method has similarities to the « configuration » method (per clause 6.5.2.1), we need to discuss further, it may be a third permission method option.
3 – The three configuration object figures were not discussed.
Phil proposed via email, an approach for « Support for Network Functions Audience Measurement Functions (NF-AMF) » by email, this was not discussed in the meeting. However during email discussions an important aspect was raised which may impact AM broadly, and needs further discussion. Which is the relationship between one or more IPTV SPs, Network providers, and Measurement providers.
We discussed preparations for the Pune meeting.
1- The version of AM0 which includes the agreed changes will be the output document from the conference call meetings.
2- A document regarding meeting notes will be generated with Phil listed as acting chairman.
3- Individual company contributions regarding permissions and configuration examples are expected.
4- During email discussions, we raise the question of being ready for consent in March and if we should limit detailed work on AMFs to TD-AMF, or to a sub-set of AMFs, and if so then how to handle the other AMFs in the docuument. We did not discuss this in the phone conference meeting. This is an open question.
Mr. Miao, Christian, please correct or add to anything substantial that I either mis-stated or missed.
We will continue email discussions and have the next conference call on Thursday 25th Nov (which is Thanksgiving holiday in USA – Phil will likely not attend)
https://www1.gotomeeting.com/join/536391448
Meeting Password: q13iptv
Meeting ID: 536-391-448
3pm Geneva time
Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Thursday, November 11, 2010 2:08 PM
To: Philip Jacobs (phjacobs); 'Xian Bertin'; 'miao.chuanyang at zte.com.cn'; 'zhangchuxiong at huawei.com'
Cc: 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Hideki Yamamoto'
Subject: Summary Notes of AM conf call for 11 Nov 2010
This meeting was attended by Mr Miao and Phil
We discussion Mr. Miao’s figure to introduce configuration, showing orders and management input and how configuration packages are delivered to AMFs.
1 – We agreed to harmonise terms with other diagrams
2 – We agreed that more discussion was needed about inputs to the permissions block, pending discussion of the whole permissions topic.
3 – we agreed to split Data delivery functions into sender and receiver function blocks and add descriptions
After modification the figure and text should be integrated into the combined contribution.
We discussed figure 1 in draft v4 and agreed to move the dotted line of scope to align with the left side of the aggregation functions box (and also to similarly modify all other similar drawings).
We discussed adding a figure to the introduction of AMF configuration similar to Mr Miao’s figure above for Aggregation functions.
1) We agreed to add an AMF configuration figure as attached.
2) We agreed that we should indicate which kinds of configuration information go to which functional blocks.
3) We agreed that the association between configuration information and functional blocks should also be included in the text.
We discussed the need to review all blocks to determine which ones should be considered as “optional”. Given our workload we should then focus on the mandatory blocks.
We discussed Phil’s T09-IPTV.GSI-C-0xx9!!MSW-E[1] contribution
1 – We agreed that we need a figure for AMF configuration objects, but that we do not have a good one yet, this is also pending discussion of the whole permissions topic.
2 – We agreed that the harmonization changes in naming metadata are OK
3 – We agreed that the targeting by content class text is OK for now – however we should consider that several metadata will all have ID and type associated with them, and it would be better to have a single place where this is described.
4 – We agreed that the 2 RequestDriven parameters are OK to add for now – however we should consider whether the null report idea is useful
We discussed the “requirements for AMF table”
1 – We agreed that some requirements need revising now that we are considering 5 different AMFs. It is clear that it is not possible to support some existing requirements
2 – It seems that user profile storage should apply to SC-AMF
3 – It seems that “Sample usage of interactive services” is a missing requirement (to help answer questions such as “how many hours a day do users use the guide or play a game?” )
4 - It seems that “Ask for permission, store response, report status“ should apply to TD-AMF and maybe HG-AMF, but not NF-AMF, DC-AMF and CD-AMF
5 – We agreed that a consolidated table of AMF requirements would be better than the distributed and inconsistent list of requirements currently in AM0
This table needs further consideration. Marked up version attached.
We further discussed if service specific details should be included in AM0, agreed that for the “filter and summarization” configuration clause,
1 – Since the only detail is for linear (channel surfing) – we should replace the linear detail with an explanation that details are service specific and can be found in AM1.
Mr Miao volunteered to modify the figures 3, 13 (which needs new Home Network reference point A5), and VI of v4, and to add his new configuration overview figure and text, to create a new v5.
Phil volunteered to subsequently modify v5 to v6 with the other agreed to changes listed above.
Mr. Miao, please correct or add to anything substantial that I either mis-stated or missed.
We will continue to discuss further by email, with the next conference call next Thursday 18th November
https://www1.gotomeeting.com/join/536391448
Meeting Password: q13iptv
Meeting ID: 536-391-448
3pm Geneva time
Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Friday, November 05, 2010 11:04 AM
To: 'Xian Bertin'; 'miao.chuanyang at zte.com.cn'; 'zhangchuxiong at huawei.com'
Cc: 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Hideki Yamamoto'
Subject: Summary Notes of AM conf call for 4 Nov 2010
This meeting was attended by Christian, Mr Miao and Phil
Christian presented his « comments on configuration » contribution.
1 – We agreed to rename MES with »measurement request » and to modify the term « measurement data request » thoughout AM0 with either configuration package or « measurement request » as appropriate. We should rename PMES but did not discuss this yet.
2 – We agreed to move services first in the examples
3- We have yet to agree on whether multiple services should be included in a single « measurement request » or if they must each have their own.
4 – The linear term allChannels is not an integer like channelID, we agreed to use -1 to indicate all channels should be measured. (pending further analysis)
5 – We agreed that examples in AM0 should contain only high level references to service specific measurements. We should complete a representative set of examples in order to work out the issues, but the complex service specific exmaples should be included only in AM1.
6 – We agreed to add the keyword ServicesToBeMeasured in the examples (pending item 3)
7 – we agreed that all available contentIDs will be reported when contentID is requested. Program name is not a contentID but may be used as a proxy. We have no solution yet for conditional reporting for examples such as no contentID available so report programID.
8 – Should we be able to specify which type of contentID is to be reported ? unresolved.
9 – There may be optimisations that we can use e.g. for long lists, we agreed to will table them for later.
10 – How should we handle non-terminal EUMFs which may not have channelID but only multicast address ?
11 – We agreed that we need the equivalent of Christian’s new configuration metadata for AM1
12 – We agreed to add a note regarding State & Use plus AV Service Capability elemets to indicate that we need a better definition or we should delete.
13 - We did not come to a conclusion regarding if we can ask for one element to be measured and expect multiple data to be reported e.g. asking for device configuration which returms many data
14 – We agreed that an end user changing terminal configuration is to be considered an event to be measured. An example should show this with time period based reporting.
We did not have time to discuss Phl’s revised configuration examples or configuration object drawing. We agreed to pursue renaming of the term EUMF.
We have 2 more weeks to make contributions to the combined Pune contribution, on 25th November we will review the proposed contribution for submission by 30 November. If you were not able to make this call, please consider if you can help for the next 2 weeks.
Specifically we need more contributions on non-terminal EUMFs, and metadata.
Please email this distribution to correct any substantial errors/omissions in this summary.
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Friday, October 29, 2010 2:34 PM
To: Xian Bertin; miao.chuanyang at zte.com.cn; zhangchuxiong at huawei.com
Cc: bubble at etri.re.kr; lij1024 at etri.re.kr; 'Masahito Kawamori'; myhuh at etri.re.kr; ohky at tta.or.kr; sg9and16-iptv at lists.itu.int; sgkang at etri.re.kr; 'Hideki Yamamoto'
Subject: Summary Notes of AM conf call for 27 Oct 2010
This meeting was attended by Soyoung Park, Christian, Aaron, Dr Kang, Mr Miao and Phil
Christian presented his proposal for a new section on AM configuration metadata. The discussion that ensued was very helpful.
1- We agreed that this is going in the right direction and should be added as a new clause
2- There is some misalignment with the EUMF configuration clause, we need better explanation in the EUMF configuration clause regarding objects.
3- This new clause will be modified to track the EUMF configuration clause, and expanded to cover more config metadata.
We discussed supporting measurement by specifying content type, user type, event type and/or user context. The main points were
1- Adding methods of specifying measurements could increase STB resource requirements, but could reduce the BW required to transmit measurements to aggregation functions
2- It may be better to measure and report more (using BW) than required, and have the aggregation functions filter out un-necessary data .
3- If both techniques are available to SPs, then this is an implementation choice.
Conclusion: Further consider the implications of these methods and add if technically supportable.
Phil presented one simple configuration example for a “sampled linear” scenario, but had to leave the call before discussion, Christian’s proposal will lead to some modifications of the examples. The second example was not reviewed. More examples are needed.
We did not get to discuss Christian’s proposal regarding terminology.
Please consider progressing the above work, plus the work on missions, during the coming week, in preparation for discussion at next week’s conference call.
As usual, please respond if there are substantial errors or omissions in this summary.
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Wednesday, October 27, 2010 2:06 PM
To: 'Xian Bertin'; 'miao.chuanyang at zte.com.cn'; 'zhangchuxiong at huawei.com'
Cc: 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Hideki Yamamoto'
Subject: Suggested topic for AM conf call for 27 Oct 2010
I would like to suggest that we try to cover the following three topics during this week’s call
1 – Review of Christian/Aaron’s contribution
2 - Decision whether to support measurement by specifying content type, user type, event type and/or user context
3 – Review of two linear configuration examples attached.
Thanks
Phil
From: Philip Jacobs (phjacobs)
Sent: Wednesday, October 27, 2010 9:09 AM
To: 'Xian Bertin'; miao.chuanyang at zte.com.cn; zhangchuxiong at huawei.com
Cc: bubble at etri.re.kr; lij1024 at etri.re.kr; 'Masahito Kawamori'; myhuh at etri.re.kr; ohky at tta.or.kr; sg9and16-iptv at lists.itu.int; sgkang at etri.re.kr; 'Hideki Yamamoto'
Subject: RE: Summary Notes of AM conf call for 21 Oct 2010
Dear Christian,
You raise a good point about whether aggregation functions should modify stakeholder orders to reduce STB processing, and still deliver upon stakeholders’ orders.
For example, if too much STB processing is required to examine a list of content to see if the current content should be measured, then instead, the aggregation functions could
1 – look up times when the linear content of interest is scheduled, and simply request time-bound measurements
2 – Select by content type e.g. genre which may be easier for STBs to recognize than contentID
3 – maybe use non-STB EUMFs
4 – other techniques
I suggest that we add some text regarding this function into the aggregation functions, plus put some examples into the appendix for implementation considerations.
For more powerful STBs or Gateways, should we include any of the option(s) to support measurement (and permission) as specified by
a) content type (e.g. children’s TV, adult TV, religious, political, all “CSI” programs, all Disney programs, etc),
b) user type (e.g. child under 13, adult, etc.)
c) event type (e.g. channel change, record, etc.)
d) user context (e.g. at work, location, etc.)
Best Regards
Phil
From: Xian Bertin [mailto:Xian.bertin at huawei.com]
Sent: Wednesday, October 27, 2010 4:04 AM
To: Philip Jacobs (phjacobs); miao.chuanyang at zte.com.cn; zhangchuxiong at huawei.com
Cc: bubble at etri.re.kr; lij1024 at etri.re.kr; 'Masahito Kawamori'; myhuh at etri.re.kr; ohky at tta.or.kr; sg9and16-iptv at lists.itu.int; sgkang at etri.re.kr; 'Hideki Yamamoto'
Subject: RE: Summary Notes of AM conf call for 21 Oct 2010
Dear Phil,
My comments below.
My major point is this one: we should not necessarily forward content provider AM orders to EUMF. What could be an order from a content provider: AM for a specific content viewed by any service (LinearTV, VoD, PVR) could be translated/included in LinearTV AM for any content, VoD for any content, PVR for any content orders for EUMF configuration.
STBs have limited CPU power and memory more dedicated to services visible to end users than to unvisible functions like AM.
It seems to me unrealistic to configure EUMF AM for each individual ContentId (in terms of dedicated configuration memory and CPU process, but however this information could be generated by the aggregation function from more general AM requests such as the one listed above.
See other comments below.
Best regards,
Christian
________________________________
De : Philip Jacobs (phjacobs) [mailto:phjacobs at cisco.com]
Envoyé : mardi 26 octobre 2010 00:02
À : Xian Bertin; miao.chuanyang at zte.com.cn; zhangchuxiong at huawei.com
Cc : bubble at etri.re.kr; lij1024 at etri.re.kr; Masahito Kawamori; myhuh at etri.re.kr; ohky at tta.or.kr; sg9and16-iptv at lists.itu.int; sgkang at etri.re.kr; Hideki Yamamoto
Objet : RE: Summary Notes of AM conf call for 21 Oct 2010
Dear All,
Further to the configuration question of whether content to be measured should be independent metadata from serviceId, or a parameter of serviceId. (Ignoring the contentIdType here).
1- If separate, when contentID is specified and serviceId’s are specified, then a program e.g. “CSI Miami” would be measured whenever it was seen across any specified serviceID e.g. any linear channel, DVR, or VoD . Christian: This looks more like a content provider order not necessarily to be forwarded identically included in an EUMF configuration order, as explained above.
2- If separate, when contentID is not specified and serviceId is also specified, then measurements are not driven by contentIDs
3- If contentID is a parameter of serviceId, e.g. Linear (CSI-Miami), then measurements would be specific to content on a particular service. All serviceId’s that need measurement would need to have “CSI-Miami” as a parameter. Christian: This seems to me unrealistic. If such an order would be possible, I think that we will end up with at least two AM profiles (basic profile where this is not allowed and a full profile where this will be allowed)
4- If contentID is a parameter associated with another parameter, e.g. Linear (channel 56, csi-miami), Linear (channel 57, csi-miami) etc then the contentID may need to be replicated many times.
The trade-off appears to be size and readability of the configuration vs. possibly measuring and reporting of the content of interest on services where the service/content combination is not required. Unless there is an objection, can we say that a specified program of interest will be measured across all specified serviceIDs? i.e. #1 above.
What do you think?
Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Thursday, October 21, 2010 2:02 PM
To: Philip Jacobs (phjacobs); 'Xian Bertin'; 'miao.chuanyang at zte.com.cn'; 'zhangchuxiong at huawei.com'
Cc: 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Hideki Yamamoto'
Subject: RE: Summary Notes of AM conf call for 21 Oct 2010
This meeting was attended by Christian, Aaron, Mr. Miao, and Phil, lasting 2 hours
We discussed a new example diagram for clause 12.1.1, configuration on Aggregation Functions (attached)
1 – Some configuration is from management rather than from input order, modify to show management input (ref point c3), and which blocks it configures.
2 – If it does not complicate the diagram, and there is room, add sequence numbers to the diagram
3 – Need to add all existing aggregation blocks from figure 3 into this diagram
4 – The new block for permissions is noted, and may be combined with another after further work.
5 - We agreed that the Directive Decomposition block would be better named Order Decomposition block
6 – Need to modify to distinguish between two instances of “configuration package” since they may not be the same
7 – After these changes are made, this diagram will need further analysis and accompanying documentation (especially for permission block)
8 – We also agreed that an introduction in clause 1.2 needs to be written, and that a similar drawing needs to be created for clause 12.1.2
We discussed the revised EUMF configuration clause 12.1.2, previously circulated
1 – The way to specify which content to be measured was added – it was pointed out that this may be better described as a parameter of the serviceId element which specifies linear, dvr, vod, etc. More consideration is needed to determine the best way.
2 – It was pointed out that linear channels to be measured may also be included as a parameter of the serviceId element when it is linear, this is agreed.
3 – We need to decide whether to support measurement (and permission) as specified by
a) content type (e.g. children’s TV, adult TV, religious, political, all “CSI” programs, all Disney programs, etc),
b) user type (e.g. child under 13, adult, etc.)
c) event type (e.g. channel change, record, etc.)
d) user context (e.g. at work, location, etc.)
4 – a new clause focusing on non home-EUMFs was added, we agreed that IP addresses were needed at the network EUMF, and generally that non home-EUMFs may not be able to duplicate all the functions of home-EUMFs. The example of per user permissions is documented, but it was pointed out that control function EUMF would not know about contentId. We need to decide where to document the differences in EUMF capabilities. Maybe in config, or appendix or both.
5 – The use case for end-users asserting permissions among their devices was discussed due to the added complexity of supporting sets of permitted devices. Further discussion is needed.
We unfortunately did not have time to discuss the contribution from Christian and Aaron, « Metadata elements for EUMF configuration". We agreed to email regarding this during the week and will start with this next week. Mr. Miao volunteered to work on the 12.1.1 diagram, Phil volunteered to work on the configuration appendix. The next meeting will be at 3pm European time
https://www1.gotomeeting.com/join/536391448 <https://www1.gotomeeting.com/join/536391448>
Meeting Password: q13iptv
Meeting ID: 536-391-448
Please comment on any significant error or omission
Best Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Thursday, October 14, 2010 3:45 PM
To: Philip Jacobs (phjacobs); 'Xian Bertin'; 'miao.chuanyang at zte.com.cn'
Cc: 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'Masahito Kawamori'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sg9and16-iptv at lists.itu.int'; 'sgkang at etri.re.kr'; 'Hideki Yamamoto'
Subject: Summary Notes of AM conf call for 14 Oct 2010
This meeting was attended by Christian, Mr Miao and Phil, lasting 2.5+ hours
We discussed 1- Mission/directives/ID/addressing/recombination.
1a – the first diagram is noted to be an example showing information flow from stakeholders to EUMF. It also shows information intended for aggregation functions (which are not shown)
1b – the terminology in the diagram does not exactly match that used in AM0.
1c – the action resulting from this discussion, is that a simplified diagram should be included in the introduction to the aggregation functions, each aggregation block should include appropriate inputs, plus a detailed information flow should be created for an appendix. The terminology used will be made consistent.
1d – the mission ID# is key to routing messages, it will need to be taken into account in EUMF configuration.
We discussed 2 – Configuration examples and issues raised
2a – Reference is made to AM1 metadata and events, we agreed that this is OK if the reference is brief, any details should be kept in AM1.
2b – All examples will be moved to a new appendix.
2c - addition description should be added as necessary to each configuration section
2d – configuration syntax and metadata parameters need checking
2e – request driven reporting needs more text
2f – storage priority needs more text
2g – now we see the configuration, it may be better to re-factor the metadata tables in AM0 to classify them by configuration metadata and report metadata.
2h – contentID metadata description in AM0 needs to match AM1
2i – eventId metadata description needs to be expanded to reflect both sampled and event times.
2j – EUMF configuration in network, control and content delivery are missing – we will work on network EUMF for now. Maybe Control and content delivery EUMF will be for future study – needs more discussion.
2k – missing configuration to cover functions listed in AM0 need to be added.
We agreed to generate a single contribution for Pune which would include this conference call group’s work. Further contributions outside of these are of course welcomed.
The ITU-T posted version of AM0 from Singapore appears to be in Word2007, and presents difficulties to be read, we will ask for a word2003 version to be posted.
For next week, Christian and Phil will work on configuration, Mr Miao will work on Mission/directives/ID/addressing/recombination and start editing the AM0 contribution.
Christian, Mr Miao, please review the above summary, and add/modify any missing or incorrect points.
The next call will be on Thursday.
Regards
Phil
From: Philip Jacobs (phjacobs)
Sent: Wednesday, October 13, 2010 11:49 AM
To: 'Xian Bertin'; miao.chuanyang at zte.com.cn
Cc: bubble at etri.re.kr; lij1024 at etri.re.kr; 'Masahito Kawamori'; myhuh at etri.re.kr; ohky at tta.or.kr; sg9and16-iptv at lists.itu.int; sgkang at etri.re.kr; 'Hideki Yamamoto'
Subject: Proposed AM agenda for 14 Oct 2010
Hi All,
I suggest we address the following as much as possible on this week’s conf call.
1 - Mr Miao’s discussion document, and if/how/where the concepts should be integrated into AM0 (see posted doc)
2 - Phil’s configuration examples and the issues working through them raised (see posted doc and below)
3 - Resolution of Christian’s points
4 – Volunteers for work items for next week
Regarding “2” – and the question of how to configure user permissions in EUMFs which are not in end-user functions. If we take one situation at a time, and start with network function based EUMF. There appears to be two main elements of a solution
A – The identity of the end-user traffic must be identifiable to the network EUMF.
Given a subscriber ID, a mapping function to current IP address could be used by the network EUMF. Questions regarding such a subscriber ID or User ID need addressing.
B – The end-user permission must be associable to that traffic in the network EUMF
A “white-list” of subscribers or users permitting (within certain parameters) measurement is created and loaded into network functions, which consult the white-list before measurements occur. Questions regarding which network functions are sent which “white-list” need to be addressed (is there an existing IPTV function which can be consulted to map subscribers to network EUMFs?)
Regards
Phil
From: Xian Bertin [mailto:Xian.bertin at huawei.com]
Sent: Tuesday, October 12, 2010 8:51 AM
To: miao.chuanyang at zte.com.cn
Cc: bubble at etri.re.kr; lij1024 at etri.re.kr; 'Masahito Kawamori'; myhuh at etri.re.kr; ohky at tta.or.kr; Philip Jacobs (phjacobs); sg9and16-iptv at lists.itu.int; sgkang at etri.re.kr; 'Hideki Yamamoto'
Subject: RE: RE: Summary report of Audience measurement conf call discussion 7 Oct 2010
Dear Miao,
I agree that the discussion already lasted too long but this is because new things are introduced which then require discussion to make them consistent with the other parts of the draft Rec; to be acceptable.
If you go back in the draft Rec; and stop at the boundary of the IPTV AM system with just orders, this would be fine. But for the output I think that "report" is not the only solution to communicate "audience data" to the outside world, alternatives to be considered as well could be to offer an SQL interface or a web solution.
I think that we have enough work to focus on with the specification of the relations between aggregation functions and all measurement functions inside the IPTV domain, if we want to have a meaningful draft Rec. on AM by March 2011 for consent.
Best regards,
Christian
________________________________
De : miao.chuanyang at zte.com.cn [mailto:miao.chuanyang at zte.com.cn]
Envoyé : mardi 12 octobre 2010 05:20
À : Xian Bertin
Cc : bubble at etri.re.kr; lij1024 at etri.re.kr; 'Masahito Kawamori'; myhuh at etri.re.kr; ohky at tta.or.kr; 'Philip Jacobs (phjacobs)'; sg9and16-iptv at lists.itu.int; sgkang at etri.re.kr; 'Hideki Yamamoto'
Objet : 答复: RE: Summary report of Audience measurement conf call discussion 7 Oct 2010
Dear Christian
Thanks for your comments.
As we have been discussing for a long time, we are agreed that first step and last step in AM system is only needed to concern 1) to input order which is able to be read by AM system and 2) output the report to a destination which could be out of IPTV systme or internal use. Thus, AM system itself would not care about what the requester role it is and what report receiver role it is. i.e, AM doesn't care if it is disney or Nielsen send the order and how the report will be further processed.The only thing AM needs to concern is to allocate a ID for them in order to arrange AM implementation and indicates where the report should go.
But I agree with that if we are talking the whole ecosphere of AM, it is strange not to show them on the figure. But descirption is sufficient, detailed standardization work is not necessary.
So we can draw such a kind of function blocks and give them a term which are wildly used in ITU-T. and those should be remained in introduction sections.
Best regrads.
Miao
Dear Phil,
Thank you for the clarification about Nielsen. You are right, Nielsen is not a Content Provider, it is a kind of second level AM aggegater (aggregation of AM from different AV Content delivery platforms), so this is clearly another function than content provider, so they should not be put in the same box. Nielsen provides a service which is not an IPTV service. We can not use the simple term "service provider" for Nielsen as it means in ITU-T implicitly "IPTV Service provider".
If we want to illustrate the or an AM architecture behind the Aggregation function (although this is out of scope), we have to show explicitly Content Providers, as the main interest to have AM is for Content Providers. It would be strange not to see them on the figure. If there are sometimes/potentially other players/roles/functions in between the "Content Providers" and the "IPTV AM aggregation function" they should identified and appear explicitly as specific blocks outsite the "Content Providers" block.
Best regards,
Christian
________________________________
De : Philip Jacobs (phjacobs) [mailto:phjacobs at cisco.com]
Envoyé : lundi 11 octobre 2010 13:53
À : Xian Bertin; miao.chuanyang at zte.com.cn; Hideki Yamamoto; Masahito Kawamori
Cc : bubble at etri.re.kr; lij1024 at etri.re.kr; myhuh at etri.re.kr; ohky at tta.or.kr; sgkang at etri.re.kr; sg9and16-iptv at lists.itu.int
Objet : RE: Summary report of Audience measurement conf call discussion 7 Oct 2010
Thank you Christian,
As also discussed on the conf call, one of the main stakeholders for audience measurement is the market/audience research industry, which includes many companies e.g. Nielsen. Since these companies provide statistical, ratings and other services, we may include them as service providers. However it seems inappropriate to classify them as content providers. Therefore we should not replace “stakeholder” by “Content Provider” alone, we could replace “stakeholder” with “Content and Service providers” if there is an objection to the term “stakeholder” which includes these 2 providers.
Any further thoughts on this? We can also discuss your other points on this Thursday’s call, along with the two other discussion documents.
Regards
Phil
From: Xian Bertin [mailto:Xian.bertin at huawei.com]
Sent: Friday, October 08, 2010 10:39 AM
To: Philip Jacobs (phjacobs); miao.chuanyang at zte.com.cn; 'Hideki Yamamoto'; 'Masahito Kawamori'
Cc: bubble at etri.re.kr; lij1024 at etri.re.kr; myhuh at etri.re.kr; ohky at tta.or.kr; sgkang at etri.re.kr; sg9and16-iptv at lists.itu.int
Subject: RE: Summary report of Audience measurement conf call discussion 7 Oct 2010
Dear all,
Some additional remarks on Figure 1 as a contribution for next AM subgroup meeting:
- I would like to propose to replace "stakeholder" by "Content provider" because of the definition given for stakeholders "Stakeholders such as content providers, advertisers, and service providers"
"content provider" is a generic term used everywhere in ITU-T IPTV for providers of AV contents, of content metadata (without content), so as advertisers also provide AV contents, they are content providers.
Concerning "service providers", if sometimes we hear that they may provide also their own contents, this should be rephrased as follows: a company may play two or more roles, e.g.: a content provider role and a service provider role but we should not mixed the two roles. Service provider is not a content provider but a company can run both businesses.
- to align Figure 1 with the other architecture figure showing interfaces C2 and C3, we should have an arrow between Content Provider and Aggregation function to show the C2 interface or we have to explain why an identified interface has disappeared from an example of function distribution.
In addition to this, my comments inline in the below report
Best regards,
Christian
________________________________
De : Philip Jacobs (phjacobs) [mailto:phjacobs at cisco.com]
Envoyé : vendredi 8 octobre 2010 00:10
À : miao.chuanyang at zte.com.cn; Hideki Yamamoto; Masahito Kawamori
Cc : bubble at etri.re.kr; lij1024 at etri.re.kr; myhuh at etri.re.kr; ohky at tta.or.kr; sgkang at etri.re.kr; sg9and16-iptv at lists.itu.int; Xian.bertin at huawei.com
Objet : Summary report of Audience measurement conf call discussion 7 Oct 2010
Mssrs. Christian, Miao and Phil attended this conf call.
There were three items for consideration
1 - Christian – Scope of AM0 as it pertains to c2 and c3 reference points
2 - Miao – consideration of mission/directives/data requests
3 - Phil – configuration examples
During the week, AM0 and AM1 excerpts were created and posted (as 375 and 376) for the liaison to AAAA, MRC and Esomar. The liaison statement has not yet been modified.
We spent most of the meeting on item 1, summarizing the discussion
a. Reference points c2 and c3 have been part of AM for several months at least. Yes they have been identified since a long time and there is no question about this, but it was decided in the full Q13/16 group that their specifications were out of scope.
b. Recent progress of AM0 has included some more detail on c2 and c3, but it is incomplete . Recent progress has started to detail something decided to be out of scope by the full Q13/16 group .
c. Figure 1 was added in Singapore, it currently shows the scope as including inputs to and outputs from AM, which map to reference points c2 and c3.
d. For figure 1, it was proposed that it may be more appropriate to show the scope as cutting through the aggregation function rather than the inputs and outputs – this was not resolved.
e. For figure 1, it was pointed out that by showing the out-of-scope “stakeholder” and “Measurements provision manager” blocks, it may be interpreted that this is the only and correct way to architect a solution. It was agreed that we should make a contribution to note that this is an example.
f. It is clear that AM0 will not describe the functions outside of the currently shown scope of AM0
g. It is proposed that the description of c2 and c3 be limited to only the information model which impacts the functions within the aggregation and end user measurement functions. Aspects such as security and transport protocols would not be in scope. What do you mean by "information model"? If it is the list of elements with semantic and syntax, the command and report formats then this is out of scope.
h. It was agreed that further definition of c2 and c3 and the functions on their far ends may be suitable for a separate recommendation in the future.
i) the AM situation was declared similar to the distribution of AV contents with the same boundary who gave two recommendations: one for the interface between service provider and terminal and another one for the interface between content providers and service providers. For AM, the same approach seems relevant
Christian, Miao, please review the above, and “reply to all” with comments if you believe it is materially incorrect or missing main points.
For the coming week, please use email to continue the discussion of items 1,2 and 3, and if time allows, further address the high priority items listed below. We will have another conference call next week.
Thank you – Phil
From: Philip Jacobs (phjacobs)
Sent: Thursday, September 30, 2010 10:28 AM
To: 'miao.chuanyang at zte.com.cn'; 'Hideki Yamamoto'; 'Masahito Kawamori'
Cc: 'bubble at etri.re.kr'; 'lij1024 at etri.re.kr'; 'myhuh at etri.re.kr'; 'ohky at tta.or.kr'; 'sgkang at etri.re.kr'; 'sg9and16-iptv at lists.itu.int'; 'xian.bertin at huawei.com'
Subject: Summary report of Audience measurement conf call discussion 30 Sept 2010
Mssrs. Christian, Miao and Phil attended this conf call.
1 We agreed that excerpts of AM0 (clauses 1-8, 14) and AM1 (clause 9) should be sent to 3 organizations - AAAA, MRC and Esomar. With some word-smithing of the liaison agreed to in Singapore to reflect these excerpts. In addition, it was pointed out that since interactivity is more important to IPTV than for traditional broadcast, that we should add our request for input regarding audience measurement of interactivity. Phil volunteered to modify the liaison statement.
2 At the Singapore meeting we generated a priority list of AM work items. The high priority items are:
a. Aggregation functional block might be having some additional function blocks.
b. EUMF description in SCF, network, CDF.
c. More configuration and examples.
d. Metadata section should be reviewed, including fig 12.
e. Mission/directives/ID/addressing/recombination
Phil volunteered to start on “c”. Mr Miao volunteered to start on “e”. Christian will be emailed the Singapore output by Mr. Miao and volunteered to come up to speed on AM0. The Singapore output also needs to be posted on the ITU-T web site.
We propose to use this email list to keep everyone informed, please send all comments and suggestions to this list. We will have the next meeting next week at the same time. Thank you – Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20110310/389de636/attachment-0001.htm>
More information about the sg16-avd
mailing list