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 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
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 102 690 v1.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. 2 Sub-contribution #2 propose to add the scheduled polling to the notificationChannel management - this is open issue in in ETSI TS 102 690 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 188.8.131.52 - change 1 : change Table 9.61 in 184.108.40.206 3 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 220.127.116.11 - 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 18.104.22.168.7 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 22.214.171.124 6 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 9.2.2 Common attributes. lastModifiedTimeMRO See clause 9.2.2 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 102 690 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
Your consent to our cookies if you continue to use this website.