Scheduled Polling Mechanism Seung Kwon Lee KT History

Scheduled Polling Mechanism Seung. Kwon Lee(KT)

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

Discussion Issue My contribution can be splitted into 2 sub-contributions 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 102 690 v 1. 1. 1. - 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. Sub-contribution #2 propose to add the scheduled polling to the notification. Channel management - this is open issue in in ETSI TS 102 690 2

Sub-contribution #1 propose to add the scheduled polling as a client-2 -server communication in clause 9. 3. 1. 4 - change 1 : change Table 9. 61 in 9. 4. 1. 4 Table 9. 61 Mechanism Description Client-2 -Server (Semiasynchronous) Issuer type (client/server) by actively fetching the information (short polling mechanism). 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: • 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. by actively polling for the • The issuer shall be a client. information (long polling • The issuer may also be server capable. mechanism). In this case the • This mechanism is mainly used for request shall contain an subscribing to changes of a resource then indication that the issuer is not able to receive performing a long polling. notification and therefore is mainly when the issuer is only a client. by scheduled polling mechanism. • The issuer shall be a client. In this case the request shall • The issuer may also be server contain an indication that the capable. issuer is performing a scheduled • This mechanism is useful in case that polling. the receiver knows the time when the resource will change. Receiver type (client/server) Figure number Figures 9. 40 and 9. 42 The receiver shall be a server 3

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

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

Sub-contribution #2 propose to add the scheduled polling to the notification. Channel management - change 4 : change the attribute of notification. Channel resource in 9. 2. 3. 35 Table 9. 59 Attribute. Name Mandatory /Optional Type Description channel. Type M RW The type of the notification. Channel. Currently only long. Polling is supported. The type of the notification. Channel. Currently long. Polling and scheduled. Polling are supported contact. URI M RO The URI that is used in subscriptions. channel. Data M RO The data associated with the channel. The type of data may differ depending on the channel. Type. For the long. Polling channel. Type, the channel. Data includes a URI on which the client can do the long polling request in order to get the notifications that were sent to the contact. URI. For the scheduled. Polling channel. Type, the channel. Data includes schedule time. creation. Time M RO See clause 9. 2. 2 Common attributes. last. Modified. Time M RO See clause 9. 2. 2 Common attributes. 　 6

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