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

2. Introduction
PRO R03-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

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

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

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

6. 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)

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

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

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