# A Novel Radio Network Information Service (RNIS) to MEC Framework in B5G Networks
## 3 Our Proposed RNIS as a Service to MEC Framework in B5G Networks
### RNIS as a Service Specification  
The operational flow is illustrated in the Figure 4, directed from the RAN to the MEP (information provider to MEP). As the information arrives at the RNIS, it is processed by a specific Receiver for each data type, who is responsible for verifying and forwarding the information to the Models responsible. This information arrives in the raw format required by the Mp2 API and is processed and transformed by RNIS into a format called JSON, which is the ideal format for RNIS procedures. Once this has been performed, the information is forwarded to specific Broker topics, which deliver the information to interested applications. The topics are predefined based on the specification and can be adjusted to improve the experience of the topic subscriber. The topic follows the fanout standard for message brokering in the Broker. In this way, the information is forwarded in  
Figure 3: General RNIS as a service architecture proposed. the MEP direction to the MEC app (applications interested in receiving information) via the Mp1 API. The information from RAN must be sent via the following route: /rni/v2/queries/<TYPE>/string:app_instance_id. In this route, it necessary to replace <TYPE> with the type of data to be sent (rab_info, plmm_info, s1_bearer_info or l2 meas_info). The Receiver is responsible for initiating the call to check the information format and initiating the call to publish the information in the Broker. At this point, the information is directed to a specific function called Emit, which is responsible for publishing it. The Emit function of the Exchange class publishes this information in specific topics (initially predetermined), which interested applications will consume. Each topic follows the fanout pattern for storing and publishing the information. The Emit function connects to the Broker. It ensures that information is registered in the appropriate topics, enabling RNIS to direct the information to the topics according to its consumer register. This consumption process takes place when RNIS registers each consumer, where RNIS makes a route available /<appRoot>/rni/v2/subscriptions, waiting for the parameters NotificationSubscription and callback_uri, so, using insert_application, RNIS registers this application in the database that keeps the consumer register and their subscriptions of interest (subscribing to topics). In this way, RNIS maintains a function called receive_and_send_messages connected to Broker, receiving information and checking which consumers want that type of information and delivering it via the registered callback. In summary, RNIS receives information via the Mp2 API about the user's equipment connected to the RAN. This data related to the radio network is processed by RNIS and organized into specific topics. RNIS uses dedicated models for each data type, checking and classifying the information before forwarding it to a Broker. Specific RNIS functions manage to obtain data from the Broker, identifying interested consumers, delivering the information via callbacks, and consumers registering their interest with RNIS via an Mp1 route. Table 2 shows the RNIS as a service resources, based on the ETSI GS MEC 012 [15] documentation, describing the resource types, routes, and methods used.