docs/user-guide.rst

   1 ..
   2 ..  Copyright (c) 2019 AT&T Intellectual Property.
   3 ..  Copyright (c) 2019 Nokia.
   4 ..
   5 ..  Licensed under the Creative Commons Attribution 4.0 International
   6 ..  Public License (the "License"); you may not use this file except
   7 ..  in compliance with the License. You may obtain a copy of the License at
   8 ..
   9 ..    https://creativecommons.org/licenses/by/4.0/
  10 ..
  11 ..  Unless required by applicable law or agreed to in writing, documentation
  12 ..  distributed under the License is distributed on an "AS IS" BASIS,
  13 ..  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  14 ..
  15 ..  See the License for the specific language governing permissions and
  16 ..  limitations under the License.
  17 ..
  18
  19 User-Guide (new)
  20 ================
  21
  22 .. contents::
  23    :depth: 3
  24    :local:
  25
  26 Overview
  27 --------
  28 Subscription Manager is a basic platform service in RIC. It is responsible for managing E2 subscriptions from xApps to the
  29 E2 Node (eNodeB or gNodeB).
  30
  31 xApp can make subscriptions to E2 Node through Subscription Manager. xApp can subscribe REPORT, INSERT, CONTROL and POLICY type services
  32 from E2 Node. For some of those subscription types E2 Node sends E2 Indication messages back to xApp. For those messages there need to be
  33 created route between E2 Termination and xApp. Subscription Manager manages E2 subscriptions and message request routing of the subscribed
  34 messages from Routing Manager. If one xApp has already made a subscription and then another xApp initiates identical subscription, Subscription
  35 Manager does not forward the subscription to E2 Node but merges the subscriptions internally and request Routing Manager to create route also
  36 for the second xApp and sends response to xApp. xApp can indicate in the request should Subscription Manager send request for Routing Manager
  37 to create route for the E2 subscription in the request.
  38
  39 Interface between xApp and Subscription Manager is HTTP based REST interface. Interface codes are generated with help of Swagger from a
  40 yaml definition file. REST interface is used also between Subscription Manager and Routing Manager. Subscription Manager and E2 Termination
  41 interface is based on RMR messages. xApp should use also Swagger generated code when it implements subscription REST interface towards Subscription
  42 Manager.
  43
  44     .. image:: images/PlaceInRICSoftwareArchitecture.png
  45       :width: 600
  46       :alt: Place in RIC's software architecture picture
  47
  48
  49 One xApp generated REST subscription request message can contain multiple E2 subscriptions. For every E2 subscription in the message there must be
  50 also xApp generated xApp instance id. In E2 interface there can be only one ongoing E2 subscription or subscription delete procedure towards
  51 E2 Node at any time. That is because Subscription Manager is able to merge new E2 subscriptions only which those it has already received
  52 successful response from E2 Node. E2 subscriptions and delete subscriptions may be therefore queued for a moment in Subscription Manager.
  53
  54 Subscription Manager may need to do reties towards E2 Node during subscribe or subscription delete procedure. Retries will increase completion
  55 time of the procedure. This needs to be considered in xApp's implementation. Subscription Manager sends REST notification to xApp for every
  56 completed E2 subscription procedure. That is regardless was the E2 subscription successful or not. Notification is not sent for E2 subscription delete
  57 procedures. Subscription Manager allocates globally unique REST request id for each new REST subscription request. That is returned to xApp in
  58 response. When xApp wants to delete REST subscription, xApp need to use the same id in deletion request.
  59
  60 Subscription Manager allocates also unique id for every E2 subscriptions (E2 instance id). The id called 'InstanceId' in E2 specification.
  61 In successful case the REST notification contains the id generated for the REST request, xApp instance id and E2 instance id. From xApp point
  62 of view xApp instance id identifies response REST notification for the E2 subscription in the REST request. REST notification contains also Subscription
  63 Manager generated E2 instance id. xApp can use that to map received E2 Indication message to E2 subscription. If E2 subscription procedure is unsuccessful
  64 then E2 instance id is 0 and the notification contains non-zero error cause string and source of that error information.
  65
  66 xApp need to be able preserve Subscription Manager allocated REST request id over xApp restart. The id is needed for deletion of the REST
  67 subscription and if there is need to resend the same REST request.
  68
  69 Three different type subscriptions are supported. REPORT, POLICY and INSERT. REPORT and INSERT works the same way from subscription point of view.
  70 REPORT and INSERT type REST subscription request can contain multiple E2 subscriptions. POLICY subscription can also contain multiple E2 subscriptions but
  71 using it 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.
  72
  73 REPORT and INSERT type subscription can contain multiple E2 subscriptions. If xApp needs to resend the same REST request, the request must contain Subscription
  74 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
  75 first time. Reason for xApp to resend the same request could be timeout or some failure which is not permanent like E2 interface connection break or xApp restart.
  76 In retry case Subscription Manager retries the E2 subscriptions towards to E2 Node in the request message which it does not have record. For subscriptions
  77 which record is found Subscription Manager returns successful REST notification to xApp without forwarding request to E2 Node. One REST Subscription request can
  78 contain E2 subscriptions only for one E2 Node.
  79
  80 Subscription Manager indicates to xApp in response notification if there has happened any error or timeout. xApp can send retry based on that information but
  81 resending should happen after Subscription Manager has processed the previous request completely, otherwise xApp will get successful response for the new request
  82 without that the request is actually retried. If timeout happens, response notification contains information where it happened. Timeout can happen in E2, Routing
  83 Manager and SDL interface.
  84
  85 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
  86 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
  87 subscription request.
  88
  89 POLICY type subscription can contain multiple E2 subscriptions but it may not be feasible as POLICY subscription may change. Idea in POLICY subscription is that
  90 xApp can send changed contend to E2 Node without making new subscription but just send update. Message contend can be changed frequently. In such case it may not
  91 be good idea to bundle the POLICY type E2 subscription with any other POLICY type E2 subscriptions in the same REST subscription request.
  92
  93 xApp must be able to preserve is the Subscription Manager allocated REST requests ids over restart or send the same request as was sent restart. If xApp is able
  94 to send exactly the same requests then Subscription manager can identify the request and send same responses back to xApp. This way xApp can restore the identifies
  95 related to existing subscriptions. Another alternative is store needed information in database. Subscription manager calculates md5 sum over the REST Subscription
  96 request message. That is how it can detect identical request coming from a specific xApp.
  97
  98 xApp can set in the request how many times Subscription Manager will retry subscription in E2 interface if there is timeout. xApp can also set time Subscription
  99 Manager Will wait response from E2 Node. xApp may need to update POLICY type subscription frequently. In such case it is not necessary feasible that
 100 Subscription Manager retries outdated subscription. By default Subscription Manager retries twice and response waiting time is two seconds.
 101
 102 In error case REST notification contains source of error. Source of error can be Subscription Manager, Routing Manager, E2 Node, ASN1 encoding/decoding and DBAAS/SDL.
 103 The error information received from these sources is directly copied in the response.
 104
 105 Architecture
 106 ------------
 107
 108   * Message routing
 109
 110       Subscribed messages from E2 Node are transported to RIC inside RIC Indication message. RIC Indication message is transported to xApp
 111       inside RMR message in Payload field of the RMR message. RMR message is routed to xApp based on SubId field (E2 instance id) in
 112       the RMR header.
 113
 114       Subscription Manager allocates unique E2 instance id for every E2 subscription during subscription procedure. Subscription Manager
 115       puts allocated E2 instance id to InstanceId field in the ASN.1 packed RIC Subscription Request message which is sent to E2 Node. That
 116       E2 instance id is then used for the E2 subscription in RIC and E2 Node as long the E2 subscription lives. xApp gets the
 117       allocated E2 instance id in REST notification message when E2 subscription procedure is completed.
 118
 119       Subscribed messages are routed to xApps based on InstanceId in E2 Indication message. InstanceId is placed in the SubId field of the RMR
 120       message header when E2 Termination sends the subscribed message to xApp.
 121
 122       RIC Subscription Request and RIC Subscription delete Request messages are pre configured to be routed to E2 Termination and responses
 123       to those messages back to Subscription Manager.
 124
 125       Subscription Manager allocates RIC Requestor Id for E2 interface communication. Currently the id value is always 123. E2 Node gets the Request
 126       of the xApp who makes the first subscription. E2 Node uses Subscription Manager allocated RIC Requestor ID in all RIC Indication messages it sends
 127       to RIC for the subscription. In merge case subscription in E2 Node is created only for the first requestor.
 128
 129       More information about Routing manager, how routes are created and related signaling can be found from here (Note that there is still
 130       RMR based interface between xApp and Subscription Manager in the pictures on those pages):
 131
 132       `<https://wiki.o-ran-sc.org/display/RICP/Routing+Manager+Architecture>`_
 133
 134       `<https://wiki.o-ran-sc.org/display/RICP/Routing+Manager+and+Subscription+Manager>`_
 135
 136
 137   * REST Subscription Request message
 138
 139     .. image:: images/REST_Subscription_Request.png
 140       :width: 600
 141       :alt: REST Subscription Request message
 142
 143
 144   * REST Subscription Response message
 145
 146     .. image:: images/REST_Subscription_Response.png
 147       :width: 600
 148       :alt: REST Subscription Response message
 149
 150
 151   * REST Subscription Notification message
 152
 153     .. image:: images/REST_Subscription_Notification.png
 154       :width: 600
 155       :alt: REST Subscription Notification message
 156
 157   * Routing Manager REST interface messages
 158
 159     .. image:: images/Routing_Manager_REST_interface_messages.png
 160       :width: 600
 161       :alt: Routing Manager REST interface messages
 162
 163
 164   * Subscription procedure
 165
 166     * Successful case
 167
 168       xApp sends REST Subscription Request message to Subscription Manager. The request can contain multiple E2 subscriptions. It contains also
 169       xApp generated xApp instance id for every E2 subscription. Subscription Manager checks does the message contain Subscription Manager allocated
 170       REST request id for the request. When xApp sends the request first time there is no REST request id and Subscription Manager allocates it.
 171
 172       Then Subscription Manager makes simple validation for data in the request and copies data to Golang data types. When all data is copied successfully
 173       Subscription Manager sends successful respond to the REST request. Response contains Subscription Manager allocated REST request id.
 174       Then Subscription Manager sends route create request to Routing Manager over REST interface. When route is created successfully, Subscription Manager
 175       ASN.1 encodes the E2 messages and forwards those to E2 Termination. When RIC Subscription Response arrives from E2 Termination
 176       Subscription Manager forwards REST notification to xApp. The notification contains REST request id, xApp instance id and E2 instance id.
 177
 178       Subscription Manager supervises route creation and RIC Subscription Request with a timer.
 179
 180       RIC Indication messages which are used to transport subscribed messages from E2 Node are routed from E2 Termination to xApps directly using
 181       the routes created during Subscription procedure.
 182
 183       Subscription Manager supports REPORT, POLICY and INSERT type subscriptions (E2 RICActionTypes). CONTROL is not supported. POLICY type
 184       subscription can be updated. In update case signaling sequence is the same as above, except route is not created to Routing manager.
 185       xApp uses initially allocated REST request id, xApp instance id in update case. Route in POLICY type subscription case is needed
 186       only that Error Indication could be to xApp, but it is not used currently. RIC Subscription Request message contains list of ActionsToBeSetup
 187       information elements. The list cannot have REPORT, POLICY or INSERT action types at the same time. Subscription Manager checks actions types
 188       in the message. If different action types is found the REST request is not accepted.
 189
 190
 191     .. image:: images/Successful_Subscription.png
 192       :width: 600
 193       :alt: Successful subscription picture
 194
 195
 196     * Failure case
 197
 198       Failure can happen already before REST request reaches Subscription Manager. Swagger make value checks for the message passed to it.
 199       If values are does not accepted then send function returns "unknown error".
 200
 201       If failure happens when Subscription Manager validates the REST request then error is returned instantly and processing of request is
 202       stopped. xApp receives "Bad Request" (HTTP response code 400) response.
 203
 204       If failure happens when xApp resends the same request including REST request id but the subscription is not found from Subscription Manager's
 205       records, then xApp receives "Not Found" (HTTP response code 404) response.
 206
 207       If failure response is received from E2 Node then REST notification is forwarded to xApp with appropriate error cause. The notification
 208       contains REST request id, xApp instance id and zero E2 instance id.
 209
 210     .. image:: images/Subscription_Failure.png
 211       :width: 600
 212       :alt: Subscription failure picture
 213
 214     * Timeout in Subscription Manager
 215
 216       In case of timeout in Subscription Manager, Subscription Manager may resend the RIC Subscription Request to E2 Node. By default Subscription
 217       Manager retries twice. If there is no response after retries, Subscription Manager sends unsuccessful REST notification to xApp. The notification
 218       contains REST request id, xApp instance id and zero E2 instance id.
 219
 220     * Timeout in xApp
 221
 222       xApp can resend the same REST Subscription Request if request timeouts.
 223
 224       xApp may resend the same request if it does not receive expected notification in expected time. If xApp resends the same request while Subscription
 225       Manager is still processing previous request then Subscription Manager responds accepts the request and continues processing previous request.
 226
 227     .. image:: images/Subscription_Timeout.png
 228       :width: 600
 229       :alt: Subscription timeout picture
 230
 231   * Subscription delete procedure
 232
 233     * Successful case
 234
 235       xApp sends REST Subscription Delete Request message to Subscription Manager. xApp must use the same REST request id which it received in REST Subscription
 236       Response. REST delete request will delete all successfully subscribed E2 subscriptions which was subscribed earlier when the REST request id was created.
 237       When Subscription Manager receives REST Subscription Delete Request it check has it such REST subscription. If it has then Subscription Manager sends successful
 238       response to xApp and starts sending E2 delete requests to E2 Termination one by one. When RIC Subscription Delete Response arrives from E2 Termination to
 239       Subscription Manager, Subscription Manager request route deletion from Routing Manager. xApp does not get any notification about deleted E2 subscriptions.
 240
 241       Subscription Manager supervises RIC Subscription Deletion Request and route delete with a timer.
 242
 243     .. image:: images/Successful_Subscription_Delete.png
 244       :width: 600
 245       :alt: Successful subscription delete picture
 246
 247     * Failure case
 248
 249       Delete procedure cannot fail from xApp point of view. Subscription Manager always responds with successful REST Subscription Response to xApp.
 250       E2 Node could respond with delete failure in case the subscription which Subscription Manager wants to delete does not exist. In this case delete procedure
 251       ends there.
 252
 253     .. image:: images/Subscription_Delete_Failure.png
 254       :width: 600
 255       :alt: Subscription delete failure picture
 256
 257     * Timeout in Subscription Manager
 258
 259       In case of timeout in Subscription Manager, Subscription Manager may resend the RIC Subscription Delete Request to E2 Node. By default Subscription Manager
 260       retries twice. If there is no response after retry, Subscription Manager stops trying.
 261
 262     * Timeout in xApp
 263
 264       xApp can resend the same REST Subscription Delete Request if request timeouts.
 265
 266     .. image:: images/Subscription_Delete_Timeout.png
 267       :width: 600
 268       :alt: Subscription delete timeout picture
 269
 270     * Unknown REST request id
 271
 272       If Subscription Manager receives RIC Subscription Delete Request for a REST request id which does not exist, Subscription Manager sends
 273       successful REST response to xApp.
 274
 275   * Subscription merge procedure
 276
 277     * Successful case
 278
 279       Merge is possible only for REPORT type subscription. It is possible only when Action Type and Event Trigger Definition of subscriptions are equal.
 280
 281       xApp sends REST Subscription Request message to Subscription Manager. The request can contain multiple E2 subscriptions as in normal Subscription
 282       procedure but some of the E2 subscriptions in the list are already subscribed from E2 Node. For those which are not yet subscribed Subscription Manager
 283       applies normal Subscription procedure. E2 subscriptions in the list which are already subscribed are just assigned to existing subscriptions and Subscription
 284       Manager just sends route create to Routing Manager and then forwards successful REST notification to xApp for the E2 subscriptions. The notification
 285       contains REST request id, xApp instance id and E2 instance id.
 286
 287       One thing to note! REST Subscription request and returned REST notification goes through different TCP ports. For that reason there is no guarantee that
 288       response for REST Subscription request arrives to xApp before first REST notification. That is possible mostly in merge case where subscription already exist
 289       in Subscription Manager records. Successful REST notification is returned to xApp without making subscription from E2 Node which would cause some delay before
 290       REST notification can be sent.
 291
 292       Route create is supervised with a timer.
 293
 294       ``Only REPORT type subscriptions can be be merged.``
 295
 296     .. image:: images/Successful_Subscription_Merge.png
 297       :width: 600
 298       :alt: Successful subscription merge picture
 299
 300     * Failure case
 301
 302       Failure can happen already before REST request reaches Subscription Manager. Swagger make value checks for the message passed to it.
 303       If values are does not accept then send function returns "unknown error".
 304
 305       If failure happens when Subscription Manager validates the REST request then error is returned instantly and processing of request is
 306       stopped. xApp receives bad request (HTTP response code 400) response.
 307
 308       If error happens during route create then Subscription Manager forwards REST notification toxApp with appropriate error cause. The notification contains
 309       also REST request id, xApp instance id and zero E2 instance id.
 310
 311     * Timeout in Subscription Manager
 312
 313       Timeout can come only in route create during merge operation. If error happens during route create then Subscription Manager forwards REST
 314       notification toxApp with appropriate error cause. The notification contains also REST request id, xApp instance id and zero E2 instance id.
 315
 316     * Timeout in xApp
 317
 318       xApp can resend the same REST Subscription Request if request timeouts.
 319
 320   * Subscription delete merge procedure
 321
 322     * Successful case
 323
 324       xApp sends REST Subscription Delete Request message to Subscription Manager. If delete concerns merged subscription, Subscription Manager
 325       responds with REST Subscription Delete Response to xApp and then sends route delete request to Routing manager.
 326
 327       Subscription Manager supervises route delete with a timer.
 328
 329     .. image:: images/Successful_Subscription_Delete_Merge.png
 330       :width: 600
 331       :alt: Successful subscription delete merge picture
 332
 333     * Failure case
 334
 335       Delete procedure cannot fail from xApp point of view. Subscription Manager always responds with successful REST Subscription Delete Response to xApp.
 336
 337     * Timeout in Subscription Manager
 338
 339       Timeout can only happen in route delete to Routing manager. Subscription Manager always responds with successful REST Subscription Delete Response to xApp.
 340
 341     * Timeout in xApp
 342
 343       xApp can resend the same REST Delete Request if request timeouts.
 344
 345   * xApp restart
 346
 347      When xApp is restarted for any reason it may resend REST subscription requests for subscriptions which have already been subscribed. If REPORT or INSERT type
 348      subscription already exists and RMR endpoint of requesting xApp is attached to subscription then successful response is sent to xApp directly without
 349      updating Routing Manager and E2 Node. If POLICY type subscription already exists, request is forwarded to E2 Node and successful response is sent to xApp.
 350      E2 Node is expected to accept duplicate POLICY type requests. In restart IP address of the xApp may change but domain service address name does not.
 351      RMR message routing uses domain service address name.
 352
 353   * Subscription Manager restart
 354
 355      Subscription Manager stores REST request ids, E2 subscriptions and their mapping to REST request ids in db (SDL). In start up Subscription Manager restores REST request
 356      ids, E2 subscriptions and their mapping from db. For E2 subscriptions which were not successfully completed, Subscription Manager sends delete request to E2 Node and
 357      removes routes created for those. In restart case xApp may need to resend the same REST request to get all E2 subscriptions completed.
 358
 359      Restoring subscriptions from db can be disabled via submgr-config.yaml file by setting "readSubsFromDb": "false".
 360
 361   * E2 connection break
 362
 363      Subscription Manager subscribes E2 connection status notifications from RNIB. Whenever E2 interface goes up or down Subscription Manager gets notifies. When interface is down
 364      subscription is not possible. Subscription Manager rejects new request for the E2 node. Http Reject cause is 503 Subscribe Service Unavailable. When interface goes down
 365      Subscription Manager deletes all subscriptions related to the RanName from its memory and database. E2 node and XApp are expected to do the same.
 366
 367 Metrics
 368 -------
 369  Subscription Manager adds following statistic counters:
 370
 371  Subscription create counters:
 372                 - SubReqFromXapp: The total number of SubscriptionRequest messages received from xApp
 373                 - SubRespToXapp: The total number of SubscriptionResponse messages sent to xApp
 374                 - SubFailToXapp: The total number of SubscriptionFailure messages sent to xApp
 375                 - RestSubReqFromXapp: The total number of Rest SubscriptionRequest messages received from xApp,
 376                 - RestSubRespToXapp: The total number of Rest SubscriptionResponse messages sent to xApp,
 377                 - RestSubFailToXapp: The total number of Rest SubscriptionFailure messages sent to xApp
 378                 - RestReqRejDueE2Down: The total number of Rest SubscriptionRequest messages rejected due E2 Interface down
 379                 - RestSubNotifToXapp: The total number of successful Rest SubscriptionNotification messages sent to xApp
 380                 - RestSubFailNotifToXapp: The total number of failure Rest SubscriptionNotification messages sent to xApp
 381                 - SubReqToE2: The total number of SubscriptionRequest messages sent to E2Term
 382                 - SubReReqToE2: The total number of SubscriptionRequest messages resent to E2Term
 383                 - SubRespFromE2: The total number of SubscriptionResponse messages from E2Term
 384                 - PartialSubRespFromE2: The total number of partial SubscriptionResponse messages from E2Term
 385                 - SubFailFromE2: The total number of SubscriptionFailure messages from E2Term
 386                 - SubReqTimerExpiry: The total number of SubscriptionRequest timer expires
 387                 - RouteCreateFail: The total number of subscription route create failure
 388                 - RouteCreateUpdateFail: The total number of subscription route create update failure
 389                 - MergedSubscriptions: The total number of merged Subscriptions
 390                 - DuplicateE2SubReq: The total number of same E2 SubscriptionRequest messages from same xApp,
 391
 392  Subscription delete counters:
 393                 - SubDelReqFromXapp: The total number of SubscriptionDeleteResponse messages received from xApp
 394                 - SubDelRespToXapp: The total number of SubscriptionDeleteResponse messages sent to xApp
 395                 - RestSubDelReqFromXapp: The total number of Rest SubscriptionDeleteRequest messages received from xApp
 396                 - RestSubDelRespToXapp: The total number of Rest SubscriptionDeleteResponse messages sent to xApp
 397                 - RestSubDelFailToXapp: The total number of Rest SubscriptionDeleteFailure messages sent to xApp
 398                 - SubDelReqToE2: The total number of SubscriptionDeleteRequest messages sent to E2Term
 399                 - SubDelReReqToE2: The total number of SubscriptionDeleteRequest messages resent to E2Term
 400                 - SubDelRespFromE2: The total number of SubscriptionDeleteResponse messages from E2Term
 401                 - SubDelFailFromE2: The total number of SubscriptionDeleteFailure messages from E2Term
 402                 - SubDelReqTimerExpiry: The total number of SubscriptionDeleteRequest timer expires
 403                 - RouteDeleteFail: The total number of subscription route delete failure
 404                 - RouteDeleteUpdateFail: The total number of subscription route delete update failure
 405                 - UnmergedSubscriptions: The total number of unmerged Subscriptions
 406
 407  SDL failure counters:
 408                 - SDLWriteFailure: The total number of SDL write failures
 409                 - SDLReadFailure: The total number of SDL read failures
 410                 - SDLRemoveFailure: The total number of SDL remove failures
 411
 412  E2 interface state counters
 413     - E2StateChangedToUp: The total number of E2 interface change connected state
 414     - E2StateChangedToDown: The total number of E2 interface change disconnected state
 415
 416 Configurable parameters
 417 -----------------------
 418  Subscription Manager has following configurable parameters.
 419    - Retry timeout for RIC Subscription Request message
 420       - e2tSubReqTimeout_ms: 2000 is the default value
 421
 422    - Retry timeout for RIC Subscription Delete Request message
 423       - e2tSubDelReqTime_ms: 2000 is the default value
 424
 425    - Waiting time for RIC Subscription Response and RIC Subscription Delete Response messages
 426       - e2tRecvMsgTimeout_ms: 2000 is the default value
 427
 428    - Try count for RIC Subscription Request message
 429       - e2tMaxSubReqTryCount: 2 is the default value
 430
 431    - Try count for RIC Subscription Delete Request message
 432       - e2tMaxSubDelReqTryCount: 2 is the default value
 433
 434    - Shall Subscription Manager check is E2 interface up before new SubscriptionRequest is processed
 435       - checkE2State: true is the default value
 436
 437    - Are subscriptions read from database in Subscription Manager startup
 438       - readSubsFromDb: "true" is the default value
 439
 440     - How many times Subscription Manager tries to read database in start up before it continues startup procedure
 441       - dbTryCount: 200 is the default value
 442
 443     - Shall Subscription Manager try to read data base forever in start up before it continues startup procedure
 444       - dbRetryForever: true is the default value
 445
 446
 447  The parameters can be changed on the fly via Kubernetes Configmap. Default parameters values are defined in Helm chart
 448
 449  Use following command to open Subscription Manager's Configmap in editor. First change parameter and then store the
 450  change. The change is visible in Subscription Manager's log after some 20 - 30 seconds. Note that some of the parameters
 451  maybe be useful only for testing purpose.
 452
 453  .. code-block:: none
 454
 455   Open in default editor:
 456
 457   kubectl edit cm configmap-ricplt-submgr-submgrcfg -n ricplt
 458
 459   Open in Nano editor:
 460
 461   KUBE_EDITOR="nano" kubectl edit cm configmap-ricplt-submgr-submgrcfg -n ricplt
 462
 463
 464 REST interface for debugging and testing
 465 ----------------------------------------
 466  Give following commands to get Subscription Manager pod's IP address
 467
 468  .. code-block:: none
 469
 470   kubectl get pods -A -o wide | grep submgr
 471   ricplt        submgr-6d5f487777-2bc4t        1/1     Running   0       6d13h   10.244.0.181   my-ubuntu-18   <none>       <none>
 472
 473  Give following commands to get xApp's service names. xApp's Http Service Name is needed in some of the below commands.
 474
 475  .. code-block:: none
 476
 477   kubectl get services -n ricxapp | grep ueec
 478   service-ricxapp-ueec-http   ClusterIP   10.101.161.66   <none>        8080/TCP            20s
 479   service-ricxapp-ueec-rmr    ClusterIP   10.110.67.7     <none>        4560/TCP,4561/TCP   21s
 480
 481  Get metrics
 482
 483  .. code-block:: none
 484
 485   Example: curl -X GET "http://10.244.0.181:8080/ric/v1/metrics"
 486
 487  Get all E2Nodes in subscription manager
 488
 489  .. code-block:: none
 490
 491   Example: curl -X GET "http://10.244.0.181:8080/ric/v1/get_all_e2nodes"
 492
 493  Get all REST subscriptions of one E2Node in Subscription manager
 494
 495  .. code-block:: none
 496
 497   Syntax: curl -X GET "10.244.0.181:8080/ric/v1/get_e2node_rest_subscriptions/{ranName}"
 498
 499   Example: curl -X GET "10.244.0.181:8080/ric/v1/get_e2node_rest_subscriptions/gnb_208_092_303030"
 500
 501  Get all xApps in subscription manager
 502
 503  .. code-block:: none
 504
 505   Example: curl -X GET "http://10.244.0.181:8080/ric/v1/get_all_xapps"
 506
 507  Get all subscriptions of a xApp in Subscription manager
 508
 509  .. code-block:: none
 510
 511   Syntax: curl -X GET "http://10.244.0.181:8080/ric/v1/get_xapp_rest_restsubscriptions/{xappHttpServiceName.ricxapp}"
 512
 513   Example: curl -X GET "http://10.244.0.181:8080/ric/v1/get_xapp_rest_restsubscriptions/service-ricxapp-ueec-http.ricxapp"
 514
 515  Get all E2 subscriptions of a REST subscription
 516
 517  .. code-block:: none
 518
 519   Syntax: curl -X GET "http://10.244.0.181:8080/ric/v1/get_e2subscriptions/{restSubId}"
 520
 521   Example: curl -X GET "http://10.244.0.181:8080/ric/v1/get_e2subscriptions/22znlx1XCYqhD0tDHIIqSauBCf3"
 522
 523  Delete all subscriptions of one E2Node. Deletion is done the same way as xApp would request deletion, i.e. subscription is tried to
 524  delete also from E2 node and route(s) created for subscription is deleted. xApp will not get any information about subscription
 525  deletion as it is not notified anyway!
 526
 527  .. code-block:: none
 528
 529   Syntax: curl -X DELETE "10.244.0.181:8080/ric/v1/delete_all_e2node_subscriptions/{ranName}"
 530
 531   Example: curl -X DELETE "10.244.0.181:8080/ric/v1/delete_all_e2node_subscriptions/gnb_208_092_303030"
 532
 533  Delete all subscriptions of a xApp. Deletion is done the same way as xApp would request deletion, i.e. subscription is tried to
 534  delete also from E2 node and route(s) created for subscription is deleted. xApp will not get any information about subscription
 535  deletion as it is not notified anyway!
 536
 537  .. code-block:: none
 538
 539   Syntax: curl -X DELETE "http://10.244.0.181:8080/ric/v1/delete_all_xapp_subscriptions/{xappHttpServiceName.ricxapp}"
 540
 541   Example: curl -X DELETE "http://10.244.0.181:8080/ric/v1/delete_all_xapp_subscriptions/service-ricxapp-ueec-http.ricxapp"
 542
 543  Delete one REST subscription like xApp does it. Note that port number is 8088 in this command! Deletion is done the same way as xApp
 544  would request deletion, i.e. subscription is tried to delete also from E2 node and route(s) created for subscription is deleted. xApp
 545  will not get any information about subscription deletion as it is not notified anyway!
 546
 547  .. code-block:: none
 548
 549   Syntax: curl -X DELETE "http://10.244.0.181:8088/ric/v1/subscriptions/{restSubId}" -H "accept: application/json"
 550
 551   Example: curl -X DELETE "http://10.244.0.181:8088/ric/v1/subscriptions/22znlx1XCYqhD0tDHIIqSauBCf3" -H "accept: application/json"
 552
 553  Below commands are mostly useful only for testing Subscription Manager, except the last command to get Subscription Manager's log writings.
 554
 555  Get all REST subscriptions.
 556
 557  .. code-block:: none
 558
 559   Example: curl -X GET "http://10.244.0.181:8080/ric/v1/restsubscriptions"
 560
 561  Get all E2 subscriptions.
 562
 563  .. code-block:: none
 564
 565   Example: curl -X GET "http://10.244.0.181:8088/ric/v1/subscriptions"
 566
 567  Delete single E2 subscription from db. Note that the subscription is not deleted from Subscription Manager's RAM memory!
 568  Subscription Manager pod restart is required for that.
 569
 570  .. code-block:: none
 571
 572   Syntax: curl -X POST "http://10.244.0.181:8080/ric/v1/test/deletesubid={SubscriptionId}"
 573
 574   Example: curl -X POST "http://10.244.0.181:8080/ric/v1/test/deletesubid=1"
 575
 576  Remove all subscriptions from db. Note that the subscription is not deleted from Subscription Manager's RAM memory!
 577  Subscription Manager pod restart is required for that.
 578
 579  .. code-block:: none
 580
 581   Example: curl -X POST "http://10.244.0.181:8080/ric/v1/test/emptydb"
 582
 583  Make Subscription Manager restart. Code executes Exit command and then Kubernetes restarts the pod.
 584
 585  .. code-block:: none
 586
 587   Example: curl -X POST "http://10.244.0.181:8080/ric/v1/test/restart"
 588
 589  Use this command to get Subscription Manager's log writings.
 590
 591  .. code-block:: none
 592
 593    Example: kubectl logs -n ricplt submgr-75bccb84b6-n9vnt
 594
 595  Logger level in configmap.yaml file in Helm chart is by default 1. It means that only info logs are printed.
 596  To see debug log writings it has to be changed to 4.
 597
 598  .. code-block:: none
 599
 600     "logger":
 601       "level": 4
 602
 603 RAN services explained
 604 ----------------------
 605   RIC hosted xApps may use the following RAN services from a RAN node:
 606
 607   *  REPORT: RIC requests that RAN sends a REPORT message to RIC and continues further call processing in RAN after each occurrence of a defined SUBSCRIPTION
 608   *  INSERT: RIC requests that RAN sends an INSERT message to RIC and suspends further call processing in RAN after each occurrence of a defined SUBSCRIPTION
 609   *  CONTROL: RIC sends a Control message to RAN to initiate or resume call processing in RAN
 610   *  POLICY: RIC requests that RAN executes a specific POLICY during call processing in RAN after each occurrence of a defined SUBSCRIPTION
 611
 612 Supported E2 procedures and RAN services
 613 ----------------------------------------
 614     * RIC Subscription procedure with following RIC action types:
 615
 616       - REPORT
 617       - POLICY
 618       - INSERT
 619
 620     * RIC Subscription Delete procedure
 621
 622     * Merge and delete of equal REPORT type subscriptions.
 623
 624 Recommendations for xApps
 625 -------------------------
 626
 627    * Recommended retry delay in xApp
 628
 629      Subscription Manager makes two retries for E2 subscriptions and E2 subscription deletions. xApp should not retry before it has received REST notification for
 630      all E2 subscriptions sent in REST subscription request. Maximum time to complete all E2 subscriptions in Subscription Manager can be calculated like this:
 631      t >= 3 * 2s * count_of_subscriptions in the REST request. Length of supervising timers in Subscription Manager for the requests it sends to E2 Node is by
 632      default 2 seconds. There can be only one ongoing E2 subscription request towards per E2 Node other requests are queued in Subscription Manager.
 633
 634 Special notes
 635 -------------
 636  According to E2 specification E2Node may accept subscription partially. This in not properly supported in REST interface between xApp and Subscription Manager.
 637  The interface specification yaml lacks ActionNotAdmittedList IE for RICSubscriptionResponse and RICSubscriptionFailure messages. That information in now embedded as
 638  workaround in the descriptive error string as a valid JSON string. Missing ActionNotAdmittedList will be added in the REST interface in some coming update.
 639
 640  Example descriptive error string for RICSubscriptionResponse:
 641
 642    Error cause RICSubscriptionResponse partially accepted: ActionNotAdmittedList: [{\"ActionId\":1,\"Cause\":{\"Content\":1,\"Value\":8}}]
 643
 644  Example descriptive error string for RICSubscriptionFailure:
 645
 646    Error cause RICSubscriptionFailure: ActionNotAdmittedList: [{\"ActionId\":1,\"Cause\":{\"Content\":5,\"Value\":1}}]