Notification Target Discussion Group Name: ARC#36, ARC-2018-0193 Source: Youngjin Na, Min-Byeong Lee, Joon-Young Kim / HYUNDAI Motor (TTA) yjra@hyundai.com, minbyeong.lee@hyundai.com, jkim@hyundai.com Meeting Date: 2018-07 (ARC#36)

Introduction Related resource - <subscription> Attribute of <subscription> defines notification target and notification policy notification target notification policy notificationURI - targets that the Hosting CSE shall send notification to notificationForwardingURI - group related subscription, forwarding aggregated notifications subscriberURI - when the subscription is deleted pendingNotification batchNotify rateLimit presubscriptionNotify latestNotify notificationEventCat Current attributes may not be enough to handle notification failure.

Possible Case (1) Case - Gas leakage notification service in Home IoT Sample Scenario (1) CREATE <subscription> – notify measured value of Gas meter (2) Gas leakage happens : “emergency situation” (3) Notification is not delivered to Notification Target - inactive status of notification target and/or network failure, etc. subscription subscription Gas meter (via Home Gateway) Server (Hosting CSE) Subscriber & Notification Target notification notification After “notification failure” - try to notify again and again → It may be too late - are other notification policies enough to handle this? pendingNotification? oneM2M system needs to provide other method to handle this.

Possible Case (2) Case - 12V battery status notification service in vehicle IoT Similar Scenario to Case (1) - 12V battery in vehicle provides power to operate electric devices in the vehicle - If 12V battery is discharged, then jump start is needed. - The driver wants to know battery status before the battery is discharged. - Notification failure can cause battery discharge subscription subscription Battery sensor (via Vehicle Gateway) Server (Hosting CSE) Subscriber & Notification Target notification notification After “notification failure” - try to notify again and again → It may be too late - are other notification policies enough to handle this? pendingNotification? oneM2M system needs to provide other method to handle this.

Multiple notification target Delegated notification target Possible Solution In case of notification failure situation, what the subscriber really wants is to have plan B - Having current multiple notification target may cause useless notification. Multiple notification target Delegated notification target Noti. Noti. 1 Noti.2 Noti.3 Noti.4 delegated Noti. failure success useless GrandPa Dad Mom Kid GrandPa Dad Mom Kid

Multiple notification target Delegated notification target Possible Solution Having delegated notification target can minimize useless notification Multiple notification target Delegated notification target Who & When All notification target shall receive the notifications in case of both notification success and failure. Delegated notification target shall receive the notifications in case of only notification failure. Example In Case (1) and (2) - All family members will get the notification - Only delegated member will get notification only in case of notification failure into parents. Problem In case of successful notification, the other members do not want to get every single useless notifications. Null

Possible specific Solution (1) notificationURI may have delegated notificaion target that the Hosting CSE send notifications to only when the notifications can not be delivered to main target. Attributes of <subscription> Multiplicity RW/ RO/ WO Description notificationURI 1 (L) RW This attribute shall be configured as a list consisting of one or more targets that the Hosting CSE shall send notifications to. The list can include one or more delegated targets that the Hosting CSE shall send the notifications to only when the notifications can not be delivered to the other target. A target shall be formatted as a oneM2M compliant Resource-ID as defined in clause 7.2 or as an identifier compliant with a oneM2M supported protocol binding (e.g. http, coap, mqtt). If a target is formatted as a oneM2M compliant Resource-ID, then the target shall be formatted as a structured or unstructured CSE-Relative-Resource-ID, SP-Relative-Resource-ID, and/or Absolute-Resource-ID of an <AE> or <CSEBase> resource. A Hosting CSE shall use this information to determine proper pointOfAccess, requestReqchability and/or pollingChannel information needed to send a notification to the target. The following is an example. ….

Possible specific solution (2) To define new attribute Attributes of <subscription> Multiplicity RW/ RO/ WO Description delegated notificationURI 1 (L) RW This attribute shall be configured as a list consisting of one or more delegated targets that the Hosting CSE shall send notifications to only when the notifications can not be delivered to the notificationURI.

Thank you