(We'll also provide the answers!)
When the xAPP receives an RMR response for a subscription request, what should the subscription ID in that RMR message be?
When Subscription Manager is used in the RIC, it will have ability to merge subscriptions and thus when an xApp receives a response to its subscription request, the sub_id will be the sub_id as assigned by Subscription Manager. However, when no Subscription Manager is used, the sub_id of the response should match the "RIC Request Sequence Number" of the original subscription request message.
What should the xAPP do with the sub_id (i.e how to use it in the future ?)
The RIC INDICATION messages related to the subscription will carry the same sub_id as the subscription response. If the xApp creates a RIC CONTROL message based on a RIC INDICATION, it should use the same sub_id value as the indication. Similarly, if the xApp forwards the RIC INDICATION, it should use the same sub_id value.
The xApp may choose to implement its logic based on the sub_id or may ignore the sub_id in its logic as illustrated below:
receive message;
switch (msg.sub_id) {
case 1 :
process message related to subscription 1;
break;
case 2:
process message related to subscription 2;
}
OR
receive message;
if (msg.mtype == RIC INDICATION) {
decode message;
if msg.procedure_code = x and type_of_message = y ... {
process message
Similarly, would a response to delete subscription request, or if the response is a failure also contain a subscription ID ?
Yes. The sub_id in these messages should be the same as the one returned in the original RIC SUBSCRIPTION RESPONSE message.
When the xAPP sends out a subscription, what should the gNodeB ID be (that is, the RMR "meid" field)?
ANSWER: The current guidance from use case team is that it would be the Global gNB ID (e.g., "NYN0001246"). For now, the xApp needs to know this name or read it from the R-NIB, but in the future we are planning of allowing an xApp to specify the meid with a special value denoting "ALL" and the Subscription Manager will send the subscription to all the gNBs that this xApp is allowed to manage (possible R2 feature).
When the xAPP sends a subscription request, the Subscription Manager is supposed to intercept the message, exchange it with RAN and then send back a response to the xAPP. How does the Subscription Manager know ‘which’ xAPP to send the response back to?
RMR has been extended with an operation (rmr_get_src) that allows any message receiver (including Subscription Manager) to read the sender information (hostname, port). Given this information, the Subscription Manager can populate RMR routes that will deliver the response to the original sender (routing based on message type and the sub_id).
In terms of xAPP behavior, if an xAPP dies and returns back, should it retry all subscriptions or is it the xAPP’s responsibility to store the subscriptions in a persistent manner?
The fact that an xApp dies and then recovers does not cancel the subscriptions in the RAN. So, the recover xApp will automatically start receiving the messages that it previous subscribed to. The cleanest solution would likely be that the xApp persists its subscriptions and thus know what it subscribed to when it recovers.
Note that if the xApp accidentally reissues its subscriptions, the Subscription Manager should detect them as duplicates and simply merge into the existing subscriptions (no new subscriptions to RAN). Details to be ironed out in R2.
Also, are there any expiry times for subscriptions after which they need to be renewed ? Without an expiry time, I can see (in an unstable environment), new subscriptions quickly piling up.
To our knowledge, there has not been any discussion yet subscriptions expiring in the RAN.
Can I dump the contents of the route table that RMr is using?
Kind of. RMr supports a verbose option for the thread that collects route information from a static file, or from the Route Manager. Parsing information as it parses the entries, as well as a before and after summary of the table can be generated. It's not perfect, but it is useful for some testing. Details are on the RMr Route Table Dump page
What are the CMake configuration options that are supported?
When running the 'cmake' command to configure RMr and create the Makefile, it is possible to add one of several flags to the command line (e.g. cmake .. -DDEV_PKG). the following is a list of the supported flags:
- -DDEV_PKG=1 turn on development mode. This causes the header files, and the archive (.a) to be included in the resulting package(s) and/or installed when 'make install' is executed. If this flag is omitted, then a run-time package is generated which does not include the header files or the archives.
- -DBUILD_DOC=1 this causes the document formatting tool ({X}fm) to be loaded at configuration time, and the RMr man pages to be generated. If the development package option is set, the man pages will be installed such that commands like man rmr are available.
- -DPACK_EXTERNALS=1 Causes the Nanomsg and NNG libraries to be placed into the package and/or installed. (This is meant only for testing and should never be used when generating a deployable package.)
- -DSKIP_EXTERNALS=0 Causes the build process to assume that Nanomsg and NNG are currently installed in the developement environment and do not need to be explicitly built.