1 / 8

Scheduled Polling Mechanism

Scheduled Polling Mechanism. SeungKwon Lee(KT). 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.

tevin
Download Presentation

Scheduled Polling Mechanism

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Scheduled Polling Mechanism SeungKwon Lee(KT)

  2. History • M2M#20 Meeting (June 4th ~ June 8th) • Contribution : M2M(12)20_066 Scheduled Polling Mechanism • Agreed in WG2 on June 7th - 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 8th - Further discussion required. • E-mail on June 13th from Erik (Ericsson) • the need for server initiated scheduling • See how to best integrate this into the REST architecture

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

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

  5. Issuer Receiver method_request_A(…, corr) decide scheduled time method_response_A(…) scheduled time method_request_B(…, corr) method_response_B(…) 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

  6. Sub-contribution #2 • propose to add the scheduled polling to the notificationChannel 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 notificationChannel (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 mIa/dIa/mId Figure 9.xxx Procedures for scheduled polling

  7. Sub-contribution #2 • propose to add the scheduled polling to the notificationChannel management - change 4 : change the attribute of notificationChannel resource in 9.2.3.35 • Table 9.59

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

More Related