(1) This is triggered by the operator via REST API, e.g. with something like "ping gNB g1 (or list of gnbs, or all gnbs), once and report back how quickly it responded).

We might have to create a new xApp component for this (2020-01-28: option now rejected) or it could be the E2 manager itself (option that we wan to do).

To be decided if teh work is managed in RICAPP or in RIC platform. RICAPP has a similar item under RICAPP-17 subitems RICAPP-31 and RICAPP-32. 2020-01-28:Matti-to-delete-RICAPP-17as we now handle-viaRIC-95

Suggestion: provide a E2SM for health check (get this to WG3) - the option of using something in E2AP is still to be disucssed with Alistair. One option discussed was E2 Service update query.

Need: gNB simulator supporting this E2SM,  E2 adapter supporting it, WG3-agreed E2SM.

This item DOES NOT include automatic continuous pings, i.e. not this: "If 3 pings in a row is not responded to within 10 seconds, then we tear down the connections. We report any disconnect that wasn't planned as alarm event (RMR message to functionality in RIC-56).  Also clearing the alarm needs some thought."

NOT INCLUDED IN THIS ITEM (support for  this is in RIC-124):

(2) report for loss conncection (e.g. because of SCTP loss or because of misisng ping)

(3) report "RAN is connected" events.

In early discussion we decided that in Bronze we use RIC SERVICE QUERY and RIC SERVICE UPDATE for this kind of healthcheck.

For open-src simulation (of the E2 node) we might have to talk to Bharath on how to adapt the open-src simulator to be able to handle these messages.

Note that currently E2M REST interfaces are generally returning without waiting for a reply (and instead communicate results via RNIB). We need to decide whether this is a first synchronous call (positive reply or negative reply after 10 second timeout) or if it is async call that replies differently via REST patterns.