Discussion to clarify online/offline behavior Group Name: PRO Source: Shingo Fujimoto,FUJITSU Meeting Date: 2016-07-15 Agenda Item: TS-0004

Introduction PRO-2016-0134R03-STE_Update_AE_remoteCSE_on_reconnect proposed necessary changes to support bi-directional & buffer-enabled communication channel for WebSocket binding This document is prepared to build common understanding about behavior on switching online/offline status among PRO members

Basic Assumptions CSEs must have PoA to accept incoming request, but AE may not have PoA. In case of PoA is not available but transport layer provides bi-directional communication, Registrar has to use a channel established by its Registree for forwarding message. Registrar MAY support buffering to enable delayed-delivery of forwarding message to the registrar during it was offline status.

Identified Issues How can Registrar determine the channel is ‘bidirectional’ ? How can Registrar detect communication channel is re-connected ? What kind of procedure is needed for Registrar on receiving primitive message ? What PoA value should be used for bi-directional communication channel ?

Bi-directional communication Channel Bi-directional communication channel can be (has to be ?) use to receive not only incoming response primitives but also incoming request primitives. <pollingChannel> is used when the channel was not ‘bi-directional’. Definition of ‘bi-directional communication channel’ to be added in Terminology-TS

Determination of bidirectional communication channel Opt-1: provisioned in advance PoA information is shared between Registrar and Registree as part of provisioning Registrar can know which protocol is in use. Opt-2: dynamically determined Registration procedure requires to CREATE <AE> or <remoteCSE> on registrar CSE. Registrar CSE can determine the source of incoming message (as internal information) (Or, some indication as attribute value is needed)

Detection of re-connect How Registrar can know disconnection ? Failure on delivery of forwarding primitives Internal event (socket closed ?) Then, how Registrar can know re-connect ? Opt-1: Keep retry to deliver forwarding primitives  When it success, re-connect is detected Opt-2: Internal event (new socket established) When PoA is not available, Opt-1 is not possible. How to associate the buffer of primitives with established socket is not clear for Opt-2.

Procedure on Notify re-targeting If the Operation Excution Time is given in the request, the Hosting CSE should perform the following procedures at the time and shall not perform the procedures before the time. When the Hosting CSE receives a Notify request primitive targeting (i.e., To parameter) its <AE> resource, the Hosting CSE re-targets the primitive to the AE if the <AE> resource does not have any <pollingChannel> resource as a child. Get pointOfAccess attribute value of the corresponding <AE> resource. If there is no available pointOfAccess address then the Hosting CSE shall send the Notify response primitive with a Response Status Code indicating "TARGET_NOT_REACHABLE" error. Forward the Notify request primitive to the first address retrieved from pointOfAccess value If the forwarding is failed due to "Target not reachable", iterate 2) with the next address. If the Hosting CSE cannot forward it in the end, then it send the Notify response primitive with a Response Status Code indicating "TARGET_NOT_REACHABLE" error. Check <pollingChannel> first, then falling down into try to reach PoAs When Registrar failed to deliver Notification to the PoAs, it will give up and retrun error (CMDM will not be triggered)

Possible solution Opt-1: Adding condition check of bidirectional channel is in use, just after check of existence of <pollingChannel> Opt-2: Insert following step between (3)&(4): If the Hosting CSE can buffer Notification(s), then Hosting CSE can retry through step (1) to (3) until success on delivery or Request Expiration Timestamp of message is reached. Opt-2 requires to define ‘faked’ value of PoA for indicating use of bidirectional WebSocket