1. Protocol discussion Document Number: IEEE 802.16-13-0187-00-03R0
Date Submitted:
Source:
Antonio Bovo Voice:
TEKCOMMS
*<
Re: R0
Base Contribution:
Purpose: WG discussion
Notice:
This document does not represent the agreed views of the IEEE 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 <
Patent Policy:
The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
< and <
Further information is located at < and < >.

2. 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.

3. 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.

4. 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.