Protocol discussion Document Number: IEEE 802.16-13-0187-00-03R0 Date Submitted: 2013-11-14 Source: Antonio Bovo Voice: +390497623908 TEKCOMMS E-mail: antonio.bovo@tekcomms.com *<http://standards.ieee.org/faqs/affiliationFAQ.html> Re: 16-13-0187-00-03R0 Base Contribution: Purpose: WG discussion Notice: This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein. Copyright Policy: The contributor is familiar with the IEEE-SA Copyright Policy <http://standards.ieee.org/IPR/copyrightpolicy.html>. Patent Policy: The contributor is familiar with the IEEE-SA Patent Policy and Procedures: <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and <http://standards.ieee.org/guides/opman/sect6.html#6.3>. Further information is located at <http://standards.ieee.org/board/pat/pat-material.html> and <http://standards.ieee.org/board/pat >.

Summary of functional entities relationships Functionalities to be provided Note Client – Controller REGISTRATION AUTHENTICATION [ENCRYPTION] CONFIGURATION COMMANDS/NOTIFICATIONS Registration is initiated by CLIENT  CONTROLLER Authentication and optionally encryption allow to setup a secure dialogue. Configuration is needed for test session parameters. As already said in the architecture document, it can include measurements’ scheduling and/or triggers to activate the measurements. Commands/Notifications (as test session activation, stop and abort) can be also possible functionalities in the relation. To be discussed: why there is not a “Private Controller”? Client – Data Collector MEASUREMENTS TRANSFER [AUTHENTICATION] Measurements are transferred to “Data Collector” for storage. The strategy to send the measurements is discussed in the next slide. To be discussed: the option that Data Collector and Controller reside physically into the same host. Server – Data Collector To be discussed: In Table 2 - section 7.1 of architecture document there is not a relation from Private Server to Private Data Collector.

Strategy for measurements transfer Meas. Config. “POLL” mode: Client Controller / Data Collector Meas. polling Meas. Results (either stream of measurements or single meas.) Meas. Config. Client Controller / Data Collector “PUSH” mode: Triggered/Scheduled Meas. Results (either stream of measurements or single meas.) “POLL” mode: measurements are transferred only when Controller/Data Collector asks for them. Pros: server can control the measurement flow Cons: more radio overhead than push mode (e.g. possible paging) “PUSH” mode: measurements are transferred when the configured criteria is met (schedule based, trigger based, …) Pros: less radio overhead Cons: asynchronous receiving of measurements by the Controller/Data Collector, risk of overload. It has to be properly configured the Test Session to minimize this risk.

Strategy for identifying the suitable protocol(s) The protocol(s) to be adopted has/have to support the following functionalities: Registration Authentication Encryption Measurements transfer Configuration Commands/Notifications Other basic requirements are related to the mobile device domain: Simplicity, to minimize the resources dedicated to communication tasks. Possibly already adopted even for other purposes on UE devices. There are currently several options that will be discussed during next teleconference.