SeungKwon Lee(KT) Scheduled Polling Mechanism

History  M2M#20 Meeting (June 4 th ~ June 8 th )  Contribution : M2M(12)20_066 Scheduled Polling Mechanism  Agreed in WG2 on June 7 th - Agreed in principal as an optional feature. - Also minor editorial modifications needed. work offline with Omar.  Contribution revised : M2M(12)20_066r1 - work with Omar Elloumi(Alcatel-Lucent) for editorial modifications  Plenary on June 8 th - Further discussion required. 1  on June 13 th from Erik (Ericsson)  the need for server initiated scheduling  See how to best integrate this into the REST architecture

Discussion Issue  Sub-contribution #1  propose needs for the scheduled polling as a client-2-server communication(asynchronous) - currently the short polling and long polling are specified in ETSI TS v The short polling mechanism is simple but causes the network traffic overhead - The long polling mechanism is better than the short polling but it needs to be repeated until a notification is received. Even though it is suitable for event-based reporting, it is inefficient in the case that the notification is delayed for a long time. It is also inefficient for periodic reporting which requires some waiting time. ☞ scheduled polling is efficient in the periodic reporting environment. 2  Sub-contribution #2  propose to add the scheduled polling to the notificationChannel management - this is open issue in in ETSI TS My contribution can be splitted into 2 sub-contributions

Sub-contribution #1  propose to add the scheduled polling as a client-2-server communication in clause change 1 : change Table 9.61 in MechanismDescriptionIssuer type (client/server) Receiver type (client/server) Figure number Client-2 -Server (Semi- asynchronous) the issuer sends a request and it shall only get a confirmation that the request has been received and will be processed. The issuer shall be informed of the result of the request in one of the following ways: by actively fetching the information (short polling mechanism). The issuer shall be a client. The issuer may also be server capable. This mechanism may not be very efficient due to the possible high signalling. However it may be useful in case that the receiver requires some computation and it might not be able to process the request in a short time. The receiver shall be a server Figures 9.40 and 9.42 by actively polling for the information (long polling mechanism). In this case the request shall contain an indication that the issuer is performing a long polling. The issuer shall be a client. The issuer may also be server capable. This mechanism is mainly used for subscribing to changes of a resource then the issuer is not able to receive notification and therefore is mainly when the issuer is only a client. by scheduled polling mechanism. In this case the request shall contain an indication that the issuer is performing a scheduled polling. The issuer shall be a client. The issuer may also be server capable. This mechanism is useful in case that the receiver knows the time when the resource will change. Table 9.61

Sub-contribution #1  propose to add the scheduled polling as a client-2-server communication in clause change 2 : add the procedure for scheduled polling 4 method_request_A(…, corr) method_response_A(…) scheduled time Issuer Receiver method_request_B(…, corr) method_response_B(…) decide scheduled time

Sub-contribution #2  propose to add the scheduled polling to the notificationChannel management - change 3 : add the new clause for scheduled polling 5 001: Issuer requests to create the notificationChannel (CREATE) Issuer (D’A/DA/GA/NA/SCL) Hosting SCL (SCL) 003: Response 005: Issuer requests to retrieve the SCL resource on the scheduled time(RETRIEVE) 006: Response Figure 9.xxx Procedures for scheduled polling mIa/dIa/mId 004: select polling method 002: decide schedule time and create resource

Sub-contribution #2  propose to add the scheduled polling to the notificationChannel management - change 4 : change the attribute of notificationChannel resource in AttributeName Mandatory /Optional TypeDescription channelTypeMRW The type of the notificationChannel. Currently only longPolling is supported. The type of the notificationChannel. Currently longPolling and sc heduledPolling are supported contactURIMROThe URI that is used in subscriptions. channelDataMRO The data associated with the channel. The type of data may differ depending on the channelType. For the longPolling channelType, the channelData includes a URI on which the client can do the long polling request in order to get the notifications that were sent to the contactURI. For the scheduledPolling channelType, the channelData includes schedule time. creationTimeMROSee clause Common attributes. lastModifiedTimeMRO See clause Common attributes. Table 9.59

Opinion & discussion  My Opinion  sub-contribution #1 (change 1 ~ change 2) ☞ I propose that sub-contribution #1 be adopted in TS because the scheduled polling was agreed in principal as an optional feature in the M2M#20 meeting,  sub-contribution #2 (change 3 ~ change 4) ☞ Further discussion required  Discussion and Q&A 7