There can be only one ongoing RIC Subscription or RIC Subscription Delete procedure towards RAN at any time. That is because Subscription
Manager is able to merge new subscriptions only which those it has already received successful response from RAN. Subscriptions
and delete subscriptions are therefore queued in Subscription Manager. Subscription Manager may need to do reties during subscribe or
-unsubscribe procedure. As it can increase completion time of the procedure, this needs to be considered when retries are implemented
-in xApp side. xApp's retry delay should not be too short.
+unsubscribe procedure. This needs to be considered when retries are implemented in xApp side, as it can increase completion time of the
+procedure. xApp's retry delay should not be too short.
.. image:: images/PlaceInRICSoftwareArchitecture.png
:width: 600
header when E2 Termination sends the subscribed message to xApp. When xApp wants to delete the subscription, the same sequence number
must be included in the ASN.1 encoded RIC Subscription Delete Request message sent to Subscription Manager.
- Subscription Manager responds to xApp with xApp allocated RIC Requestor ID. In merge case subscription is created only for the first
- requestor. RAN gets the Requestor ID of the xApp who makes the first subscription. RAN uses that Requestor ID in all RIC Indication
- messages it sends to RIC for the subscription. Therefore xApp may get Requestor ID in RIC Indication message that belongs to another xApp.
- The xApp whose subscription is merged into the first subscription will also get Requestor ID of the first subscribed xApp in the RIC
- Subscription Response and RIC Subscription Delete Response messages.
+ Subscription Manager allocates RIC Requestor ID. Currently the ID value is always 123. In merge case subscription is created only for
+ the first requestor. RAN gets the Request of the xApp who makes the first subscription. RAN uses Subscription Manager allocated Requestor
+ ID in all RIC Indication messages it sends to RIC for the subscription.
TransactionId (Xid) in RMR message header is used to track messages between xApp and Subscription Manager. xApp allocates it. Subscription
Manager returns TransactionId received from xApp in response message to xApp. xApp uses it to map response messages to request messages
RIC Indication messages which are used to transport subscribed messages from RAN are routed from E2 Termination to xApps
directly using the routes created during Subscription procedure.
- ``Routing manager has 1 second delay in routing create in R3 release before it responds to Subscription Manager. That is because of delay in route create to RMR.``
-
- Subscription Manager supports REPORT and POLICY type subscriptions (RICActionTypes). CONTROL and INSERT are not supported. POLICY type
+ Subscription Manager supports REPORT, POLICY and INSERT type subscriptions (RICActionTypes). CONTROL is not supported. POLICY type
subscription can be updated. In update case signaling sequence is the same as above, except route is not created to Routing manager.
xApp uses initially allocated TransactionId and RIC Request Sequence Number in update case. Route in POLICY type subscription case is needed
only that Subscription Manager can send response messages to xApp. RIC Subscription Request message contains list of RICaction-ToBeSetup-ItemIEs.
- The list cannot have both REPORT and POLICY action types at the same time. Subscription Manager checks actions types in the message.
+ The list cannot have REPORT, POLICY, INSERT action types at the same time. Subscription Manager checks actions types in the message.
If both action types is found the message is dropped.
:width: 600
:alt: Subscription failure picture
- * Timeout case
+ * Timeout in Subscription Manager
In case of timeout in Subscription Manager, Subscription Manager may resend the RIC Subscription Request to RAN. If there is no response
after retry, Subscription Manager shall NOT send any response to xApp. xApp may retry RIC Subscription Request, if it wishes to do so.
Subscription Manager does no handle the retry if Subscription Manager has ongoing subscription procedure for the same subscription.
Subscription just drops the request.
+ * Timeout in xApp
+
+ xApp may resend the same request if there is no response in expected time. If xApp resends the same request while processing of previous
+ request has not been completed in Subscription Manager then Subscription Manager drops the new request, makes a log writing and continues
+ processing previous request.
+
.. image:: images/Subscription_Timeout.png
:width: 600
:alt: Subscription timeout picture
:width: 600
:alt: Subscription delete failure picture
- * Timeout case
+ * Timeout in Subscription Manager
In case of timeout in Subscription Manager, Subscription Manager may resend the RIC Subscription Delete Request to RAN. If there is no
response after retry, Subscription Manager responds to xApp with RIC Subscription Delete Response.
+ * Timeout in xApp
+
+ xApp may resend the same request if there is no response in expected time. If xApp resends the same request while processing of previous
+ request has not been completed in Subscription Manager then Subscription Manager drops the new request, makes a log writing and continues
+ processing previous request.
+
.. image:: images/Subscription_Delete_Timeout.png
:width: 600
:alt: Subscription delete timeout picture
Failure case is basically the same as in normal subscription procedure. Failure can come only from RAN when merge is not yet done.
If error happens during route create Subscription Manager drops the RIC Subscription Request message and xApp does not get any response.
- * Timeout case
+ * Timeout in Subscription Manager
Timeout case is basically the same as in normal subscription procedure but timeout can come only in route create during merge operation.
If error happens during route create, Subscription Manager drops the RIC Subscription Request message and xApp does not get any response.
+ * Timeout in xApp
+
+ xApp may resend the same request if there is no response in expected time. If xApp resends the same request while processing of previous
+ request has not been completed in Subscription Manager then Subscription Manager drops the new request, makes a log writing and continues
+ processing previous request.
+
* Subscription delete merge procedure
* Successful case
Delete procedure cannot fail from xApp point of view. Subscription Manager responds with RIC Subscription Delete Response message to xApp.
- * Timeout case
+ * Timeout in Subscription Manager
Timeout can only happen in route delete to Routing manager. Subscription Manager responds with RIC Subscription Delete Response message to xApp.
+ * Timeout in xApp
+
+ xApp may resend the same request if there is no response in expected time. If xApp resends the same request while processing of previous
+ request has not been completed in Subscription Manager then Subscription Manager drops the new request, makes a log writing and continues
+ processing previous request.
+
* Unknown message
If Subscription Manager receives unknown message, Subscription Manager drops the message.
+ * xApp restart
+
+ When xApp is restarted for any reason it may resend subscription requests for subscriptions which have already been subscribed. If REPORT or INSERT type
+ subscription already exists and RMR endpoint of requesting xApp is attached to subscription then successful response is sent to xApp directly without
+ updating Routing Manager and BTS. If POLICY type subscription already exists, request is forwarded to BTS and successful response is sent to xApp.
+ BTS is expected to accept duplicate POLICY type requests. In restart IP address of the xApp may change but domain service address name does not.
+ RMR message routing uses domain service address name.
+
+ * Subscription Manager restart
+
+ Subscription Manager stores successfully described subscriptions from db (SDL). Subscriptions are restored from db in restart. For subscriptions which
+ were not successfully completed, Subscription Manager sends delete request to BTS and removes routes created for those. Restoring subscriptions from
+ db can be disable via submgr-config.yaml file by setting "readSubsFromDb": "false".
+
+Metrics
+-------
+ Subscription Manager adds following statistic counters:
+
+ Subscription create counters:
+ - SubReqFromXapp: The total number of SubscriptionRequest messages received from xApp
+ - SubRespToXapp: The total number of SubscriptionResponse messages sent to xApp
+ - SubFailToXapp: The total number of SubscriptionFailure messages sent to xApp
+ - SubReqToE2: The total number of SubscriptionRequest messages sent to E2Term
+ - SubReReqToE2: The total number of SubscriptionRequest messages resent to E2Term
+ - SubRespFromE2: The total number of SubscriptionResponse messages from E2Term
+ - SubFailFromE2: The total number of SubscriptionFailure messages from E2Term
+ - SubReqTimerExpiry: The total number of SubscriptionRequest timer expires
+ - RouteCreateFail: The total number of subscription route create failure
+ - RouteCreateUpdateFail: The total number of subscription route create update failure
+ - MergedSubscriptions: The total number of merged Subscriptions
+
+ Subscription delete counters:
+ - SubDelReqFromXapp: The total number of SubscriptionDeleteResponse messages received from xApp
+ - SubDelRespToXapp: The total number of SubscriptionDeleteResponse messages sent to xApp
+ - SubDelReqToE2: The total number of SubscriptionDeleteRequest messages sent to E2Term
+ - SubDelReReqToE2: The total number of SubscriptionDeleteRequest messages resent to E2Term
+ - SubDelRespFromE2: The total number of SubscriptionDeleteResponse messages from E2Term
+ - SubDelFailFromE2: The total number of SubscriptionDeleteFailure messages from E2Term
+ - SubDelReqTimerExpiry: The total number of SubscriptionDeleteRequest timer expires
+ - RouteDeleteFail: The total number of subscription route delete failure
+ - RouteDeleteUpdateFail: The total number of subscription route delete update failure
+ - UnmergedSubscriptions: The total number of unmerged Subscriptions
+
+ SDL failure counters:
+ - SDLWriteFailure: The total number of SDL write failures
+ - SDLReadFailure: The total number of SDL read failures
+ - SDLRemoveFailure: The total number of SDL read failures
+
+
+REST interface for debugging and testing
+----------------------------------------
+ Give following commands to get Subscription Manager pod's IP address
+
+ .. code-block:: none
+
+ kubectl get pods -A | grep submgr
+
+ ricplt submgr-75bccb84b6-n9vnt 1/1 Running 0 81m
+
+ Syntax: kubectl exec -t -n ricplt <add-submgr-pod-name> -- cat /etc/hosts | grep submgr | awk '{print $1}'
+
+ Example: kubectl exec -t -n ricplt submgr-75bccb84b6-n9vnt -- cat /etc/hosts | grep submgr | awk '{print $1}'
+
+ 10.244.0.181
+
+ Get metrics
+
+ .. code-block:: none
+
+ Example: curl -s GET "http://10.244.0.181:8080/ric/v1/metrics"
+
+ Get subscriptions
+
+ .. code-block:: none
+
+ Example: curl -X GET "http://10.244.0.181:8088/ric/v1/subscriptions"
+
+ Delete single subscription from db
+
+ .. code-block:: none
+
+ Syntax: curl -X POST "http://10.244.0.181:8080/ric/v1/test/deletesubid={SubscriptionId}"
+
+ Example: curl -X POST "http://10.244.0.181:8080/ric/v1/test/deletesubid=1"
+
+ Remove all subscriptions from db
+
+ .. code-block:: none
+
+ Example: curl -X POST "http://10.244.0.181:8080/ric/v1/test/emptydb"
+
+ Make Subscription Manager restart
+
+ .. code-block:: none
+
+ Example: curl -X POST "http://10.244.0.181:8080/ric/v1/test/restart"
+
+ Use this command to get Subscription Manager's log writings
+
+ .. code-block:: none
+
+ Example: kubectl logs -n ricplt submgr-75bccb84b6-n9vnt
+
+ Logger level in configmap.yaml file in Helm chart is by default 2. It means that only info logs are printed.
+ To see debug log writings it has to be changed to 4.
+
+ .. code-block:: none
+
+ "logger":
+ "level": 4
+
RAN services explained
----------------------
RIC hosted xApps may use the following RAN services from a RAN node:
- REPORT
- POLICY
+ - INSERT
* RIC Subscription Delete procedure
Recommendations for xApps
-------------------------
- * Recommended retry delay
+ * Recommended retry delay in xApp
- Recommended retry delay for xApp is > 10 seconds
+ Recommended retry delay for xApp is >= 5 seconds. Length of supervising timers in Subscription Manager for the requests it sends to BTS is by default 2
+ seconds. Subscription Manager makes one retry by default. There can be only one ongoing request towards per RAN other requests are queued in Subscription
+ Manager.
Code Review / ric-plt / submgr.git / blobdiff