SeungKwon Lee(KT)

Scheduled Polling Mechanism

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.

2

E-mail on June 13th 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.

3

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 9.3.1.4

- change 1 : change Table 9.61 in 9.4.1.4

4

Mechanism Description Issuer type(client/server)

Receiver type(client/server)

Figurenumber

Client-2 -Server(Semi-

asynchronous)

the issuer sendsa request and itshall only get a

confirmation thatthe request hasbeen received

and will beprocessed. The issuer

shallbe informed ofthe result of therequest in one

of the followingways:

by actively fetching the information (short pollingmechanism).

• 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 receivershall be a

server

Figures 9.40

and 9.42

by actively polling for the information (long pollingmechanism). In this case therequest 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 servercapable.• 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 9.3.1.4

- change 2 : add the procedure for scheduled polling

5

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 9.3.2.26.7 for scheduled polling

6

001: Issuer requests to create thenotificationChannel (CREATE)

Issuer(D’A/DA/GA/NA/SCL)

Hosting SCL(SCL)

003: Response

005: Issuer requests to retrieve theSCL 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 9.2.3.35

7

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

8