+
+One xApp generated REST subscription message can contain multiple E2 subscriptions. For every E2 subscription in the message there is also
+xApp generated xApp instance id. In E2 interface there can be only one ongoing E2 subscription or subscription delete procedure towards
+E2 Node at any time. That is because Subscription Manager is able to merge new E2 subscriptions only which those it has already received
+successful response from E2 Node. E2 subscriptions and delete subscriptions may be therefore queued in Subscription Manager.
+
+Subscription Manager may need to do reties towards E2 Node during subscribe or subscription delete procedure. Retries will increase completion
+time of the procedure. This needs to be considered in xApp's implementation. Subscription Manager sends REST notification to xApp for every
+completed E2 subscription procedure regardless is the E2 subscription successful or not. Notification is not sent for E2 subscription delete
+procedures. Subscription Manager allocates globally unique REST request id for each new REST subscription request. That is returned to xApp in
+response. When xApp wants to delete REST subscription, xApp need to use the same id in deletion request.
+
+Subscription Manager allocates unique id also for the E2 subscriptions (E2 instance id). The id called 'InstanceId' in E2 specification.
+In successful case the REST notification contains the id generated for the REST request, xApp instance id and E2 instance id. From xApp point
+of view xApp instance id identifies received REST notification for the E2 subscription in the REST request. REST notification contains also Subscription
+Manager generated E2 instance id. xApp can use that to map received E2 Indication message to E2 subscription. If E2 subscription procedure is unsuccessful
+then E2 instance id is 0 and the notification contains non-zero error cause string.
+
+xApp need to be able preserve Subscription Manager allocated REST request id over xApp restart. The id is needed for deletion of the REST
+subscription and if there is need to resend the same REST request.
+
+Three different type of subscriptions are supported. REPORT, POLICY and INSERT. REPORT and INSERT works the same way from subscription point of view.
+REPORT and INSERT type REST subscription request can contain content for multiple E2 subscriptions. POLICY subscription can also contain content for multiple
+E2 subscriptions but using in that way may not be feasible. REPORT, POLICY and INSERT type subscriptions in the same REST request are not supported supported
+in Subscription Manager.
+
+REPORT and INSERT type subscription can contain content for multiple E2 subscriptions. If there is need to resend the same REST request, the request must
+contain Subscription Manager allocated id for the REST request, which was returned to xApp when the request was sent first time. The request must also
+contain the same content as first time. Reason for xApp to resend the same request could be timeout or some failure which is not permanent in E2 Node or
+xApp restart. In retry cases Subscription Manager retries the E2 subscriptions which does not exist in its records. For others Subscription Manager
+returns successful REST notification without sending any messages to E2 Node. One REST Subscription request can contain E2 subscriptions to only one E2 Node.
+
+If there is need to change REPORT or INSERT type subscription then previously made subscription need to be deleted first. If there are any REPORT or INSERT
+type E2 subscription which need to change frequently, it is not good idea to bundle them with other REPORT or INSERT type E2 subscriptions in the same REST
+subscription request.
+
+POLICY type subscription can contain content for multiple E2 subscriptions but it may not be feasible as POLICY subscription may change. Idea in POLICY
+subscription is that xApp can send changed contend to E2 Node without making new subscription but just send update. In such case it is not good idea to bundle
+the POLICY type E2 subscription with any other POLICY type E2 subscriptions in the same REST subscription request.
+
+In xApp restart case only mandatory thing what is required xApp to be able preserve is the Subscription Manager allocated REST requests ids. That is if xApp
+can generate the equal requests otherwise as were done first time before restart. xApp can resent the same REST requests to Subscription Manager as first time
+before restart. REST request id must be placed in the REST request. That is the only way for Subscription Manager to identify already made subscriptions in it
+records and work as expected, i.e. not run into problems and return successful REST notifications to xApp without sending any messages to E2 Node.
+