A Novel Radio Network Information Service (RNIS) to MEC Framework in B5G Networks

Abstract

Multi-Access Edge Computing (MEC) reduces latency, provides high-bandwidth applications with real-time performance and reliability, supporting new applications and services for the present and future Beyond the Fifth Generation (B5G). Radio Network Information Service (RNIS) plays a crucial role in obtaining information from the Radio Access Network (RAN). With the advent of 5G, RNIS requires improvements to handle information from the new generations of RAN. In this scenario, improving the RNIS is essential to boost new applications according to the strict requirements imposed. Hence, this work proposes a new RNIS as a service to the MEC framework in B5G networks to improve MEC applications. The service is validated and evaluated, and demonstrates the ability to adequately serve a large number of MEC apps (two, four, six and eight) and from 100 to 2000 types of User Equipment (UE).

1. Introduction

The technologies introduced by the Fifth Generation of mobile networks (5G) [1,2] serve a variety of services and applications, where enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC) and massive Machine Type Communications (mMTC) provide support for applications such as autonomous cars, virtual reality, Agriculture 4.0, and among others. With the growing expansion of 5G, academia and industry have invested in research into Beyond Fifth Generation (B5G) and the Sixth Generation of mobile networks (6G) [3,4]. Due to the evolution of various B5G Internet of Things (IoT) devices, applications are also emerging that will not be adequately satisfied by 5G and 6G networks, facing challenges linked to the huge increase in the volume of traffic and management of large amounts of data on the network, stemming from the popularization of services, applications and activities that require high computing power. Applications such as multisensory extended reality, holographic telepresence, autonomous systems, and connected robotics require more computing power and mobile communication infrastructure [5].

Demand scenarios impose substantial challenges on 5G and 6G networks. These include increasing traffic volumes, managing large amounts of data, and increasing computational demands. These challenges are explained by the fact that the supply of emerging services and applications is multiplying. Therefore, Multi-Access Edge Computing (MEC) [6,7] has emerged as a critical technology for 5G and 6G, enabling the optimization of mobile resources by hosting computing services and offering cloud computing resources, facilitating the movement of devices and resulting in context-aware services [8,9,10]. In this way, scenarios with a large number of IoT devices with different levels of computing power, demanding requirements, and being interconnected at various stages of the production chain can be addressed, being connected by the Next Generation Radio Access Network (NG-RAN), with various applications running at the edge of the network, closer to the end user, with MEC services enabling the enhancement and optimization of applications [11]. The Radio Access Network (RAN) in which these smart devices are located provides a varied granularity of information about User Equipment (UE) and context-sensitive applications, which is constantly being generated [12]. The use of the Radio Network Information Service (RNIS), which interacts with the RAN by collecting and exposing the information, is needed for gathering and making this RAN-level information about UE available. It can facilitate the exposure of information such as latency, location of UE, and signal strength to interested MEC apps by exposing them through Mp1 by means of a notification system where the consumer subscribes to a topic of interest and receives such information [13,14,15,16,17].

The information about the UE found in the RAN prior to the arrival of the MEC could only be accessed via the radio operators. With the arrival of the MEC, this information is now available through the RNIS [18]. Therefore, the RNIS plays a crucial role in communication with the RAN, making it possible to collect radio information about the UE. This information includes data about latency, location of individual types of UE or groups of UE, changes in UE parameters, signal strength, measurements, and statistics related to the user plan, status, and capabilities of the UE, among others. This information is available to edge applications, allowing them to make knowledgeable decisions and perform specific tasks as required [18].

Agriculture 4.0, with the help of smart technologies, sensors, and equipment, has brought about a number of improvements in the sector, with new applications, techniques, and efficiency in the use of inputs, among others. The key to this transformation lies in the ability to collect more information and measurements on agricultural production and EUs. RNIS enables contextual information to be consumed by agricultural applications, integrating this information and providing a resilient, adaptable and efficient system. The RNIS accesses the now-available information, improving performance and expanding the services offered by different applications, such as in the Agriculture 4.0 scenario. MEC profoundly transforms agricultural practices in smart agriculture by integrating sectors, agricultural automation, drones, and more to improve operations. The data collected by sensors is processed at the edge (MEC), enabling dynamic adjustments, while algorithms help automate agricultural machinery operations. Efficient data analysis at the MEC boosts agricultural efficiency by using RNIS information to adapt to the conditions of applications and devices in a precise and timely manner. In the face of that, RNIS is essential in providing detailed RAN information.

As seen in Figure 1, the concept of Agriculture 4.0 brings a series of applications in different scenarios and sectors of the production chain. These applications use a variety of sensors and devices scattered around the environment, such as temperature and humidity sensors, drones for irrigating crops, robots for planting, and autonomous heavy machinery. These scattered devices generate information and help control remote operations. Using the B5G network, more IoT devices are scattered around the environment, communicating, generating, and sharing information. The data is sent to the network’s edge, where it is processed and used by interested applications. Hence, this contributes to decision-making and improving the quality of services. In this way, applications that depend on the context of the environment can perform even better, driving the advancement of agriculture and industry and bringing innovative solutions to the sector [19,20].

Figure 1. Agriculture 4.0 in the context of emerging technologies such as B5G and MEC.

Considering scenarios with higher performance demands, 5G networks have faced challenges related to the increase in traffic volume, such as managing large amounts of data generated in the network and an increase in computational demands [13], all of which stem from the popularization of services, applications, and activities that require increasingly precise information about UE [13]. The current RNIS and MEC specifications do not include specific 3GPP UE link information, which raises uncertainties about how RNIS should interact with 5G mobile networks. The lack of detail raises questions about how RNIS should obtain information from the 5G Radio Access Network, highlighting the case that RNIS itself needs improvement to obtain and expose such radio network information effectively and whether communication between the MEC and 5G networks [21] needs improvement to provide such information-capture mechanisms. In addition, the correct exposure of NG-RAN information needs an improvement in terms of integration between MEC and B5G [18,22,23,24].

This paper proposes RNIS as a service to the MEC framework in B5G networks, highlighting the improvements needed and the paths available to enhance the delivery of relevant information using Agriculture 4.0 as a use case. The importance of RNIS and the need to improve it to effectively obtain and display radio network information are discussed. The RNIS aims to improve performance and enable new business models based on information available to MEC applications (MEC apps). We have proposed the development of an RNIS coupled with MEC integrated with B5G at the network’s edge, collecting and providing RAN information to enhance agricultural applications. We have validated our proposed service using Agriculture 4.0 applications as a use case in different scenarios.

Our main contributions are as follows:

• New RNIS as a service to the MEC framework in B5G networks
• Specification and architecture of the new RNIS improvements
• Implementation and validation of the RNIS available on public repository [25] in order to utilize the community to build on this knowledge.

In addition to this Introduction section, Section 2 discusses the related work. Section 3 describes our proposal describing the specification and architecture of the new RNIS as a service improvements, and also details regarding implementation. Section 4 presents the validation, evaluation and results. Section 5 finalizes our work by presenting our conclusions and future work directions.

2. Related Work

Only some works in the literature discuss improving RNIS integration with the MEC framework on new-generation B5G mobile networks. This section describes the main works that are similar to our proposal.

Pencheva et al. [16] propose designing a Web Service (WS) based on Service-oriented Architecture (SOA) that provides access to radio network information in order to be used for dynamic quality of service control of data sessions. The proposal consists of two approaches to WS for MEC: bearer management WS and cell-related radio network information WS, where the former enables mobile edge applications to dynamically control the QoS available in user sessions by managing the E-UTRAN Radio Access Bearer (ERAB) and the latter enables applications to receive information on measurements related to the eNodeB, including Radio Resource Control (RRC) connection establishment. The proposed web services provide access to available radio network information based on network protocols such as RRC, S1 Application Protocol (S1AP), and X2 application protocol (X2-AP). However, the 5GC architecture does not support interfaces and protocols for legacy access networks [26] such as S1AP, defined to 4G LTE [27].

Kireva et al. [28] propose the implementation of RNIS, focusing on the handover procedure and proposing handover state models for mobile applications leaving a source and destination LTE base station (eNodeB). The work studies a way of implementing RNIS in a mobile edge environment, highlighting some of the information that can be received in cases of cellular subscription. This research focuses on notifications about the handover procedure, where handover state models are proposed to view applications at the network’s edge from a source eNodeB and destination eNodeB. However, the work needs to explore ways of improving the RNIS so that information not currently present is exposed in the context of the new generations of mobile networks and also for general emerging applications.

Tan et al. [29] propose a cellular network structure for MEC using a cache update algorithm with radio network recognition. The work highlights the importance of MEC and the usefulness of Dynamic Adaptive Streaming over HTTP (DASH) and RNIS for accelerating multimedia services. The development of a testbed based on 4G LTE base stations was presented, carrying out tests on the structure, compared with traditional networks, enabling a high quality of experience. This work aims to collect edge information to help the MEC cache video with appropriate representations, focusing on ensuring Quality of Experience (QoE) for its users in the RAN network by caching with radio network recognition and selecting appropriate segments through DASH. The information from the RAN is used by the update and caching algorithm to help decide which representation segments should be stored in a cache at the network’s edge. The approach adopted leaves out RNIS updates according to ETSI [23] and does not mention ways of using this method in the 5G context.

Nasimi et al. [30] explore real-time decision-making mechanisms, selectively storing traffic, considering network conditions and QoS. The MEC must locally store delay-tolerant data traffic for this scheme until the delay conditions expire. This mechanism gives the network more control over providing high-priority data radio resources. The authors introduce a dedicated Congestion Control Engine (CCE), which captures RAN conditions through RNIS functions. Knowledge acquired through RNIS makes real-time decision-making possible for selective traffic discarding, thus making it more intelligent and better performing. The authors point out that data traffic for the next generations will bring challenges related to congestion and network delays. However, they must consider the up-to-date RNIS and integration with B5G networks.

Arora et al. [18] point out that the data in a RAN is generated on a large scale and needs to be processed on devices with limited resources, such as storage and processing capacity, which represents a challenge. Scalability challenges arise as the number of mobile terminals generating data and MEC-hosted applications consuming RNIS grows. This work focuses on implementing alternative solutions for distributing messages in the publish-subscribe model (RabbitMQ and Apache Kafka) and evaluating and comparing the performance of solutions for implementing RNIS in MEC. This work compares candidate solutions for implementing RNIS by consuming information from an eNodeB. However, the solution considered aspects of the Fourth Generation network.

Atanasov et al. [31] discuss how many studies have focused on predicting UE behavior. However, most predictive algorithms require a lot of computing power, causing them to migrate to analytical applications deployed at the network’s edge. Hence, the authors propose a mobile edge service that allows external applications to provide information about the UE’s predicted or expected activity and mobility. These applications can gather information from the radio location network to establish patterns in the UE’s behavior, thus making the information available through the network to help optimize resource management procedures. This mobile edge service allows other analytical applications to provide prognostic information about UE behavior to the RAN. Moreover, a dedicated application can send the values of the expected UE behavior parameters to the RAN using the proposed service interfaces, which can optimize mobility management procedures and manage user connections intelligently. However, this work needs to address the aspects of RNIS based on improvements to the emerging conditions for B5G.

Following the previous work, Atanasov et al. [32] discussed issues in providing the network with the prognosis of the UE behavior calculation. Hence, they proposed an extension of the RNIS, which involves improving the service to allow MEC apps to contribute prognostic data on user behavior. This extension enables service improvement and proactive decision-making at the network edge in 5G networks. Also, the proposed extension allows MEC apps to subscribe to RNIS on UE-related cell information and inform the radio access bearer, enabling an analysis of user behavior and mobility patterns. The proposal aims to extend the functionality of RNIS by allowing an exchange of information where RNIS can receive new information from the MEC app in addition to the RAN itself. However, it does not deal with improving information collection for interested subscribers.

Based on the works discussed, most studies suggest the use of RNIS functions and the processing of information from the RAN for the LTE 4G networks. However, none of the literature takes into account the latest ETSI RNIS specification, unlike our proposed service and Atanasov et al.’s work, which also discusses integration with 5G. This information is presented in Table 1.

Table 1. Comparison with the related literature.

Work	RNIS Integration with MEC Using 4G	RNIS Integration with MEC Using 5G	Using RNIS for MEC applications	New RNIS Functionality	Improvement of RNIS Information
Pencheva et al. [16]	X		X
Kireva et. al. [28]	X		X
Tan et. al. [29]	X		X
Nasimi et. al. [30]	X		X
Arora et al. [18]	X		X
Atanasov et. al. [31]	X	X	X
Atanasov et. al. [32]		X	X	X
Our Proposal		X	X	X	X

All of the works which proposed using RNIS for MEC applications, such as that of Arora et al. [18], have enabled the implementation of RNIS by validating different brokers. Atanasov et al. [32] have been developing new functionalities for the service by extending the information delivery aspect so that MEC apps contribute with prognostic data about the behavior of the UE like our proposal also does.

RNIS needs improvements to collect and expose contextual information about UE networks. Current implementations show the importance of using RNIS in 4G and 5G contexts; however, the services still need to be improved. While some of these earlier works [16,18,28,29,30,31,32] carry out tests on the best brokers to be used in the development of the service, other works focused on the development of new functionalities for RNIS, such as the ability to obtain information from MEC apps. However, the efficiency of information delivery is ignored, with the LTE context generally being prioritized. Another point is that there is no open source implementation to compare performance, making it difficult to analyze the proposed services.

However, in contrast to the literature, our proposed service aims to improve the delivery of RNIS information to interested consumers (MEC services and MEC apps), even with a new source of information provided by MEC apps in which the RNIS needs improvement to ensure efficient delivery of information to its consumers, especially in the context of B5G networks.

3. Our Proposed RNIS as a Service to MEC Framework in B5G Networks

Multi-Access Edge Computing (MEC), introduced by ETSI, is a technology that extends intelligence to the network’s edge, offering excellent processing and storage capacity [33]. It is considered one of the leading emerging technologies for 5G and 6G networks, providing an environment for IT services and computing resources at the edge of the mobile network [34,35]. MEC enables interaction with the RAN through a critical component of MEC—the RNIS—which provides information to support various applications. By using real-time and contextual information from the RAN, MEC enables improvements in the performance of existing applications and the development of new and innovative ones. Figure 2 illustrates the MEC reference architecture, in which we can see some of the essential components for the proposal.

Figure 2. MEC reference architecture [14].

The MEC architecture consists of components such as MEC host, MEC Platform (MEP), MEC applications (MEC apps), and Multi-Access Edge Orchestrator (MEO), managing MEC apps and acting as an intermediary between the MEC host and the Operations/Business Support System (OSS/BSS) of the operator [14]. The MEP, in turn, can interact with the MEC apps via the Mp1 reference point, which enables service discovery, application registration, and communication. Through this interface, the MEC apps can consume the services the MEP provides. The Mp2 reference point bridges the MEP and the data plane, enabling the MEP to obtain RAN-level information about the UE. In this way, MEC is characterized by its proximity to mobile users, low latency, location recognition, and real-time network context information [9].

MEC brings with it several advantages and benefits for mobile edge applications. RNIS stands out from MEC as one of the primary MEP services, offering and collecting information about radio network conditions. The actual use of RNIS for emerging applications in the B5G context requires improvements to the service so that it can adapt to network conditions and provide accurate information to interested MEC apps. Some of this information needs to be addressed in the current specifications, such as methods for collecting and exposing information regarding the RRC, centralized coordinated beam management, and lower-layer information.

Emerging applications are increasingly demanding, requiring growing requirements and generating intense network traffic. This fact already highlights the need for RNIS to advance with its demands. In different works, RNIS is used as a basis for analysis and dynamic adjustments to the behavior of various applications, both in emerging 5G scenarios and in 4G itself. In this way, RNIS must be prepared to support such demands, consuming and exposing information quickly, effectively, and fairly.

The existing technical documents are based on the MEC reference architecture, exploring its functionalities at the network’s edge and highlighting the operation of RNIS and its relationship with interested applications (MEC apps). In the ETSI GS MEC 012 [15] document, RNIS is described as a mobile edge service provided by MEP that communicates via two APIs, each of which has its function, namely to collect, obtain, and expose information.

The Mp1 API is the communication interface between RNIS and the MEC apps, enabling service registration, service discovery, communication support for services, and other functionalities. This interface includes application availability, support procedures for session state relocation, traffic rules, DNS rule activation, storage access, and information such as time of day. In addition, the Mp1 reference point can also be used to consume services and provide functionalities specific to a service. The Mp2 API, on the other hand, is described as the communication interface between the RNIS and the radio network information provider.

3.1. RNIS as a Service Architecture

In this context, our proposed RNIS as a service enhancement is designed to manage information traffic for various applications, boosting delivery and enabling optimization and performance for its agricultural clients. RNIS brings several advantages that have already been highlighted for 4G networks. However, for 5G networks, an improved RNIS for communicating and capturing information will be necessary. The technical document provides information on uptake but needs to be detailed to include 5G networks. One of the key questions identified by ETSI 031 [23] (a document describing the main areas of study in MEC and 5G integration) is whether RNIS itself requires enhancement to expose more radio network information expressly for the 5G RAN, such as lower layers and coordinated beam management information.

Figure 3 shows the general architecture of the RNIS as a service proposal, where RNIS is deployed in the MEC Platform, consuming information via Mp2 in the RNIS direction to RAN information providers and providing information in the MEP direction to MEC apps. In this proposal, the RNIS comprises the Broker RabbitMQ, which proved very efficient in the tests carried out by ARORA et al. [18]. The Broker can classify and organize messages by various criteria, as specified in ETSI document 012 [15]. In addition to the Broker, RNIS has incorporated a Receiver responsible for analyzing and organizing messages from gNodeB, managing them, and adapting them to a specific format, such as JSON. The messages are then forwarded to the Broker.

Figure 3. General RNIS as a service architecture proposed.

RNIS enables efficient and practical access to information about UE in the radio network via applications at the network’s edge, either for internal MEC Platform services or interested MEC applications. Upon implementing this functionality, the service receives information from the RAN and reviews and adapts it appropriately to allocate it through the implemented receiver. After this process, the service forwards the information to predefined topics of interest, hosted in a Broker, where it is exposed to RNIS’s functionalities and forwarded to interested clients, such as MEC apps.

To properly deliver information to consumers, it must have a clear destination route. To enable this delivery, consumers must register with RNIS, providing their pre-registered identifier, the type of notification they are interested in, and the callback URL from which they wish to receive the information. Initially, RNSI also offered the option of delivery via socket; however, in our proposal, we opted to process the information exclusively via callback. This approach provides greater flexibility and control in the management of notifications.

RNIS plays an important role in a number of agricultural applications. Among them, it is possible to improve overall efficiency and reduce logistical costs, minimize carbon emissions and improve logistical optimization during crop transport by using MEC for local data processing and RNIS to ensure efficient communication between UE and edge infrastructure. Improving operating costs and enhancing the safety of operations is possible through the automation of agricultural machinery with MEC and RNIS. This results in improved safety and increased operational efficiency [20,36].

In short, the service acts as an effective bridge between the RAN and applications at the network’s edge, ensuring the efficient flow of information, proper validation, and accurate delivery to consumers registered with RNIS. The proposal aims to implement the RNIS as a service and serve agricultural applications, seeking appropriate times for such applications. In this way, efforts are focused on the ability to receive information (requests from the RAN) and process it, preparing it for interested consumers.

3.2. 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 the MEP direction to the MEC app (applications interested in receiving information) via the Mp1 API.

Figure 4. RNIS as a service specification workflow.

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, plmn_info, s1_bearer_info or l2meas_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.

Table 2. API resource information.

Resource Name	Resource URI	HTTP Method
RAB information	/queries/rab_info	GET
PLMN information	/queries/plmn_info	GET
S1 Bearer information	/queries/s1_bearer_info	GET
Layer 2 measurements	/queries/layer2_meas	GET
All subscriptions for a subscriber	/subscriptions	GET POST
Existing subscription	/subscriptions/{subscriptionId}	GET PUT DELETE
Notification callback	Client provided callback reference	POST

• PLMN information: Retrieves the current state of Public Land Mobile Network (PLMN) information, which refers to a public mobile communication network;
• S1 Bearer information: Retrieves the current state of S1 Bearer information, which is a communication interface between different parts of a mobile communication network;
• Layer 2 measurements: Retrieves the current state of Layer 2 measurement information, which includes data about the data link layer in communication;
• All subscriptions for a subscriber: Retrieves a list of active subscriptions for a specific subscriber;
• POST Create a new subscription: Creates a new subscription for a subscriber;
• Existing subscription: Retrieves information about a specific subscription using the subscription ID;
• PUT Modify existing subscription by sending a new data structure: Modifies an existing subscription by sending a new data structure;
• DELETE Cancel the existing subscription: Cancels the existing subscription;
• Notification callback: Sends a notification using the callback reference provided by the client.

3.3. RNIS as a Service Implementation

In order to achieve the objectives set out in this work, the RNIS implementation was developed, incorporating the features mentioned in Section 3.1. The implementation was carried out using the Python programming language in conjunction with the Flask framework. Flask is a lightweight and highly extensible web framework, offering the flexibility to choose and integrate various libraries. It stands out for facilitating the creation of RESTful APIs, providing efficient tools for defining endpoints and handling HTTP requests. In the context of Flask, it is possible to define routes to specify how the application should react to different HTTP requests (GET, POST, etc.), using Python decorators. This framework, centered on routes (URLs) and views (functions that respond to requests), takes an approach that simplifies the mapping of URLs to functions in the code, clearly outlining the application’s behavior.

The RNIS implementation can be divided into two main parts: the Receiver and the Broker. Thus, the Receiver is activated when requests from Mp2 reach RNIS. The information obtained is then forwarded to the Receiver, which must check it against the standard RNIS definitions, change it to the correct format if necessary and deliver it to the Broker. In turn, it receives the information and records it in appropriate topics (RAB establishment notifications from the Radio Network Information Service, or cell change notifications from the Radio Network Information Service), previously determined by the RNIS and selected by the MEC apps.

RNIS has registration endpoints where consumers (MEC apps) must enter their identifier, callback URL and type of notification of interest. This information is stored indefinitely until the consumer unsubscribes. This way, the consumer should receive notifications via Mp1 whenever there is updated information.

RNIS performs some essential functions that filter the type of information desired and deliver the data using the method provided via POST in the registry. This RNIS as a service provides efficient access to information about UE in the radio network, either for internal MEC Platform services or for interested MEC apps. To enable this functionality, the service receives information from the RAN via an Mp1 communication interface. It then reviews and adapts this information to allocate it appropriately through the implemented Receiver. The information is directed to predefined topics of interest, hosted in a Broker, where it is exposed to the RNIS’s own functionalities and forwarded to interested consumers.

It is crucial that the information has a clear destination route in order to be properly delivered to consumers. As mentioned above, for this delivery to be possible, consumers must register with RNIS, showing interest in the established topics. Next, we show some excerpts from the code following the workflow mentioned above in Figure 4.

The code snippet shown in Listing 1 shows the configuration of API routes. Initially, an instance of the API class is created and then the additions of resources to this API are demonstrated, each representing a specific endpoint for data manipulation. These routes must receive information of the RAB and PLMN types, triggering the RabInfo and PlmnInfo functions shown in Listing 2 to classify and process the data.

The first resource, called RabInfo, is associated with the route /rni/v2/queries/rab_ info/ <string:app_instance_id>, configured to handle POST requests. The second resource, PlmnInfo, is linked to the route /rni/v2/queries/plmn_info/<string:app_instance_id> also configured to handle POST requests. This structuring is common in web applications that follow the RESTful architectural style, allowing specific endpoints to be defined for various operations.

Listing 1. Endpoint API.

Listing 2 represents a POST endpoint. When a POST request is made to the /rni/v2/ queries/rab_info/ <string:app_instance_id> route, the RabInfo is triggered, receiving the data and passing it through the RabInfoModel. After verification and validation, this information is sent to the Emit, which is responsible for forwarding the information to the Broker.

Listing 2. Function post class RabInfo.

Illustrated in Listing 3 is an example of a Model. For each type of data, we have a corresponding Model with its characteristics and peculiarities (RabInfoModel, PlmnInfoModel, S1BearerInfoModel, L2MeasinfoModel). The constructor method __init__, when called automatically during the creation of a new object of the class, receives the parameters corresponding to that type of message; in this case, rab receives four parameters: app_instance_id, cell_user_info, request_id, and time_stamp. Each of these parameters is assigned to a corresponding attribute of the class instance, ensuring that the object is instantiated with specific values and thus has a consistent initial state. Each of these parameters received contains a sequence of information that makes them up, e.g., time_stamp: nano_seconds and seconds. In this way, we have several Models to validate and guarantee the standardization of the information.

Within RabInfoModel itself, there is a method called setter time_stamp which in turn makes the appropriate call to check this data, thus calling the Model responsible for TimeStamp(Model). The setter time_stamp method is one of the verification methods responsible for validating and processing the value assigned to the time_stamp property. It checks that the value is not an empty string, creates a new TimeStamp object from the data provided and then converts this object to JSON before assigning it to the class’s private _time_stamp property.

The same happens with cell_user_info, which checks that the information has been passed correctly and calls the model responsible for validating each of its attributes (CellUEInfo(Model)). It then validates and returns them with confirmation that they can proceed with the information delivery flow. An example of the parameters received by CellUEInfo includes: associate_id, dl_gbr_data_volume_ue, dl_gbr_delay_ue,

dl_gbr_pdr_ue, dl_gbr_throughput_ue, dl_nongbr_data_volume_ue.

Listing 3. Class Model RabInfoModel.

After all the checks carried out by RabInfoModel, the data is forwarded to Emit’, as shown in Listing 4. This function encapsulates the logic for sending messages to a specific topic in the Broker, using the previously configured channel and connection. The Exchange class has an implementation that configures the connection and provides the channel and queue name needed for the operation with Broker. In this way, Emit contains the crucial information for publishing to the specific topic for this type of information.

In this way, the flow of receiving and processing information from the RNIS is observed, obtaining data from the RAN. The information is then received, processed and assigned to its corresponding topics, ready to be sent to consumers interested in receiving various types of information. In Listing 4 (Function emit class Exchange), you can see the flow of consumers registering and waiting to receive notifications.

Listing 4. Function emit class Exchange.

Listing 5 shows the route, /<appRoot>/rni/v2/subscriptions, which is responsible for handling HTTP POST requests. The dynamic parameters of the URL are captured, appRoot being one of them. During request processing, the JSON payload data is extracted, including NotificationSubscription and callback_uri. Validation is carried out to ensure the presence of these essential parameters, as well as checking the integrity of the NotificationSubscription. If errors occur, appropriate responses are sent with HTTP 400 status codes.

If validation is successful, the application is registered by calling the insert_application function, and a JSON response containing information about the registered application, such as NotificationSubscription, callback_uri and an identifier (id_registre), is returned with an HTTP status code of 200. In the event of exceptions during execution, an error response with code 500 is sent, containing details of the exception that occurred. Once the consumer has registered (subscribed), the registration information is stored in a database that feeds the receive_and_send_messages, allowing it to deliver the messages to the routes predetermined by the consumer.

Listing 6 presents a function dedicated to receiving messages from a RabbitMQ queue called notification and sending them to a callback URL (callback_url) using the POST method. The implementation begins by establishing a connection with RabbitMQ and configuring a channel for subsequent operations. Next, an exchange and an exclusive queue are declared and linked. When a message is received, the callback function is triggered, converting the message from bytes to string and performing a POST to the return URL using the requests library. The code includes exception handling to deal with possible errors during the process, thus allowing the flow of execution to be maintained over the logic of receiving and sending messages.

In short, this function uses the pika library to interact with the Broker, defines a temporary queue, associates it with an Exchange using a specific routing key, and starts a consumer that calls the callback function whenever a message is received. The callback function decodes the message, and sends it to a callback URL via HTTP POST. The code also handles exceptions and prints error messages if problems occur during execution.

Listing 5. Register_application.

Listing 6. Function receive_and_send_messages class Receiver.

The RNIS implementation works with the logic of multiple threads, where different parts of the program can run simultaneously. Each part of the program that is executed simultaneously is called a “thread”. A thread is the smallest unit of execution in a process, and a process can have several threads. To process and forward notifications, we have simultaneous threads, while initially we used 1 thread for each type of information, working to notify consumers.

4. Performance Evaluation and Results

We start this section by describing the Agriculture 4.0 (see Figure 1) as the use case scenario where a smart farm uses technologies such as MEC, 5G and IoT to revolutionize agricultural practices. The farm is made up of agricultural equipment, such as tractors, harvesters and drones, which are all connected and equipped with sensors and communication devices. The equipment generates and collects operational data that is transmitted over the network. The data is processed by intelligent algorithms in order to analyze the information in real time. This analysis allows farming practices to be adjusted dynamically, taking into account factors such as climate, soil and the specific needs of the crops.

Among the various use cases and agricultural applications, it is possible to highlight important radio information for optimizing these scenarios, such as network coverage, signal strength, network latency, and network availability. Integrating this RNIS information into MEC apps creates a more resilient, adaptable and efficient system. The RAB and PLMN requests can consist of the requirements of application messages. As we did not have access to the applications and equipment for a real use case, we used the RAB and PLMN information for the appropriate tests.

In the aforementioned agricultural scenario, extremely strict requirements in terms of response speed are not necessary. Latencies of up to 100 ms are tolerable, and latencies of less than 1 millisecond are not critical. In this scenario, we have 100 to 200 agricultural devices, such as tractors, harvesters, drones and other equipment, which are controlled by edge applications. These applications analyze relevant data for each group of devices, providing specific information according to the activities carried out by each piece of agricultural equipment. In addition, there are two to four MEC apps that consume information from RNIS and contribute to improving decision-making. With applications responsible for various services within agriculture, each of the MEC apps can consume information and provide services for various types of UE.

MEC apps can take advantage of RAN-level information to optimize their performance, supporting the control of agricultural use cases. Some of the MEC apps in this agricultural context include the following: autonomous vehicle fleet management; bandwidth management; traffic control; device tracking; harvest management; and agricultural transportation. Each of these applications can address several use cases with numerous types of agricultural UE.

4.1. Environment Setting

We have considered an environment with two bare-metal machines with different configurations: (i) an Intel Core i5-10300H (CPU @ 2.50 GHz octa-core and 8 GB of RAM, Intel, Santa Clara, CA, USA ) and (ii) an Intel Core i7-10510U (CPU @ 1.80 GHz octa-core and 32 GB of RAM, Intel, Santa Clara, CA, USA). Initially, we planned to integrate the RNIS as a service with the MEC framework EALTEdge, but due to instabilities in the framework, we opted to conduct the evaluation in a bare-metal environment leaving this task as future work.

Looking at the evaluated environments, the Intel® Core™ i5-10300H and Intel® Core™ i7-10510U processors differ mainly in performance and energy efficiency. The i5-10300H offers better performance in intensive computing tasks, while the i7-10510U is more energy efficient. The i7-10510U also has a significantly higher RAM capacity, with 32 GB compared to the i5-10300H’s 8 GB.

The scenario includes the use of three components: Locust, RNIS and MEC app. Locust is an open-source tool known for its simplicity and effectiveness in load evaluation. It simulates user interactions, allowing you to control the frequency and quantity of requests. RNIS receives, processes and forwards data to MEC apps. MEC apps subscribe to RNIS topics to receive notifications. Evaluation will be categorized based on the number of users, execution time and number of MEC apps subscribed (number of customers). Data such as the number of requests, processing time and receipt of information to MEC apps will be analyzed. The evaluated methodology includes sending requests every second, lasting 5, 10 and 20 min, involving different number of users: 100, 200, 400, 600, 800, 1000, 1500 and 2000. Each figure shows a specific number of users and the number of MEC apps consuming information, with two, four, six and eight MEC apps for each group of users mentioned above. By analyzing the graphs, one can see how the number of users and the number of MEC apps influences the sharing of the system, with interesting combinations for use. It is worth noting that the greater the number of users, the greater the amount of information being sent to the RNIS, where each user represents a UE with various pieces of information. The more types of UE connected to the network, the more information will be sent to the RNIS.

In order to evaluate our proposed service, Radio Access Bearer (RAB) and Public Land Mobile Network (PLMN) messages were sent simultaneously in all instances. With a higher priority for sending PLMN-type messages compared to RAB, Locust allows several types of information to be sent simultaneously, with variations in priority using weights for each type of message. In this case, it was decided to prioritize the sending of PLMN-type messages, which implies a greater amount of information of this type compared to the RAB, obtaining different amounts of messages for analysis. The data analyzed in these evaluations are: (i) average number of requests sent vs. average requests served and requests not served (calculated as a percentage relative to the total sent); (ii) average processing time for requests; (iii) RNIS as a service processing time (total time minus external time); and (iv) average time to reach MEC app.

All results were run ten times for five minutes each in order to compute the 95% confidence interval. It is important to highlight that several periods of 5, 10, 15, 20, and 30 min were evaluated, none of which impacted the results.

4.2. Results

This section presents the results representing different scenarios in two different environments as mentioned before, i.e., i5 and i7.

Figure 5 and Figure 6 show the results of two, four, six and eight MEC apps (i5 vs. i7) for RAB messages regarding the average number of requests sent vs. the average requests served and requests not served considering different numbers of users (100, 200, 400, 600, 800, 1000, 1500 and 2000).

Figure 5. Requests RAB i5—two, four, six and eight MEC apps.

Figure 6. Requests RAB i7—two, four, six and eight MEC apps.

Figure 7 and Figure 8 show the results of two, four, six and eight MEC apps (i5 vs. i7) for PLMN messages regarding the average number of requests sent vs. average requests served and requests not served considering different numbers of users (100, 200, 400, 600, 800, 1000, 1500 and 2000).

Figure 7. Requests PLMN i5—two, four, six and eight MEC apps.

Figure 8. Requests PLMN i7—two, four, six and eight MEC apps.

RNIS performance is dynamic, varying in proportion to the increase in the number of requests. Looking at Figure 5, Figure 6, Figure 7 and Figure 8, it can be seen that in situations with a lower load, such as the scenarios with 100 and 200 users and up to eight consumers, RNIS demonstrates a remarkable capacity to handle and process requests up to the MEC apps. However, as the load of requests increases, especially beyond 400 users, there is an increase in unfulfilled requests. This points to possible limitations in the sizing of the system to deal with higher loads.

In the intervals of 100 to 200 users sending information every 1 s (Figure 5, Figure 6, Figure 7 and Figure 8), it was possible to send an average of 13,591.3 requests with 100 users and 12,744.1 requests with 200 users, being RAB-type requests. In addition, it was possible to send an average of 20,240.7 requests with 100 users and 24,755.9 requests with 200 users, being PLMN-type requests, simultaneously, with no unanswered requests.

It is worth mentioning that the number of requests can change depending on the resources the implementation has. In the study carried out, the machine equipped with the i5 processor achieved a better result. On the other hand, the i7 achieved 7767.6 requests with 100 users and 7111.95 requests with 200 users, being of the RAB type. In addition, it recorded 15,669.6 requests with 100 users and 14,446.1 requests with 200 users of the PLMN type, simultaneously, also without recording any unfulfilled requests.

With 400 simultaneous users, sending information at one-second intervals, it was clear that RNIS did not meet all the requests. It was observed that, from this scenario onwards, RNIS receives more requests, but is unable to meet all the demands. As the number of requests increases, there is a significant increase in the number of unfulfilled requests and a corresponding decrease in fulfilled requests.

Figure 9 and Figure 10 show the results of two, four, six and eight MEC apps (i5 vs. i7) for RAB messages regarding average processing time for requested vs. RNIS as a service processing time and time to reach MEC app considering different numbers of users (100, 200, 400, 600, 800, 1000, 1500 and 2000).

Figure 9. Average time RAB i5—two, four, six and eight MEC apps.

Figure 10. Average time RAB i7—two, four, six and eight MEC apps.

Figure 11 and Figure 12 show the results of two, four, six and eight MEC apps (i5 vs. i7) for RAB messages regarding average processing time for requested vs. RNIS as a service processing time and time to reach MEC app considering different numbers of users (100, 200, 400, 600, 800, 1000, 1500 and 2000).

Figure 11. Average time PLMN i5—two, four, six and eight MEC apps.

Figure 12. Average time PLMN i7—two, four, six and eight MEC apps.

Figure 9, Figure 10, Figure 11 and Figure 12 show that the best scenario is the environment with two consumer MEC apps connected, regardless of the execution machine, i5 or i7. On the i5 machine, when dealing with information of the RAB type, the highest time reached approximately 5.164 ms of internal processing and 7.334 ms of processing up to the MEC app. With regard to PLMN-type information, which is predominantly sent to the RNIS, the highest processing time was 7.184 ms internally and 9.234 ms up to the MEC app. On the i7 machine, when dealing with RAB-type information, the highest time was approximately 8.442 ms of internal processing and 13.399 ms of processing up to the MEC app. With regard to PLMN-type information, which is predominantly sent to RNIS, the highest processing time was 10.167 ms internally and 14.814 ms up to the MEC app.

Looking at Figure 9, Figure 10, Figure 11 and Figure 12, we can see that in the scenarios with six and eight MEC apps, there is a significant increase in processing times, showing the performance of RNIS in scenarios with fewer MEC apps. In both scenarios with six MEC apps, it can be seen that the time needed to process the information and deliver it to the end user is more than 12 ms of internal processing. Since, with the addition of MEC apps that consume information, the service faces greater difficulties, it consumes more resources to manage all the requests and requires longer processing times. It is interesting to note that as the service has more connected users providing information, the number of unanswered requests increases. The fewer requests there are to process, the more quickly and efficiently the system is able to handle them. There is a bottleneck related to the number of simultaneous requests. The relationship with the increase in the number of users is linked to the capacity of the RNIS to serve them all. With fewer requests handled, there are fewer requests to be processed and, consequently, less processing time required.

It is important to bear in mind that, in both scenarios, the time it takes to process and deliver information can take a few milliseconds, and that the number of unfulfilled requests can increase as more users use the system. However, it is possible to improve processing times when there are fewer requests to deal with.

In the scenario with eight MEC applications (Figure 9, Figure 10, Figure 11 and Figure 12), the longest processing times stand out, reaching up to 4 s even in the scenario with 100 connected users and all requests answered. The behavior of unanswered requests starts after 400 users, resulting in a reduction in processing time. However, the times remain considerably high, with averages ranging from 48 to 200 ms. This pattern continues for larger numbers of users connected to the network, indicating that, with eight MEC applications, current resources are not providing acceptable times.

The results indicate consistent performance in the scenarios analyzed, providing valuable insights into the performance of RNIS when processing different types of information under varying conditions.

The proposal is capable of efficiently handling and processing up to 200 users, sending information every 1 s, with four consumer MEC apps. It meets all demands and provides information in times of less than 19,133 ms with the basic configuration of the i5 machine. With 200 users and two MEC apps, processing and delivery times are even better, with times of less than 13,058 ms. Taking into account that the MEC app is in the same implementation environment as the RNIS, it takes less time because it is in this condition. However, for higher loads, additional considerations are needed when sizing the system to optimize RNIS performance under more demanding conditions.

When evaluating the performance of RNIS at different load levels, such as 100 and 200 users, the system showed acceptable processing times and total times up to the MEC app client, with all requests fulfilled. However, at higher loads, especially above 400 users, there is an increase in unfulfilled requests and processing times, suggesting limitations in sizing the system to handle high loads. Considering the context of consumer MEC applications and the configurations of the Intel Core i5-10300H (CPU @ 2.50 GHz octa-core and 8 GB of RAM, Intel, Santa Clara, CA, USA), it is feasible to serve up to four simultaneous MEC applications, as each MEC app can handle several types of UE. However, in order to meet the growing demand for MEC apps, it will be necessary to improve the machine’s specifications to ensure optimal performance.

5. Conclusions

This work proposed a new RNIS as a service to the MEC framework in B5G networks which defines the requirements for the implementation of the RNIS. Furthermore, our implementation of the RNIS resulted in detailed information about its performance in the environment evaluated.

Analyzing the RNIS metrics in different load scenarios highlights its efficiency and challenges. The proposed service is able to meet these demands, being viable for up to four simultaneous applications in our scenario; however, the growing demand may require improvements in specifications for optimal performance. The current implementation of RNIS as a service covers different use cases considering possible limitations in mission-critical cases with very restricted time requirements and high device density. In this way, the application satisfies the use cases of our test context and can satisfy other use cases depending on the need. It is possible to improve the application for new cases.

As future work, we are collaborating with the EALTEdge development group to implement the service within the framework and expanding the proposed architecture to include a real test environment. A real implementation between MEC 5G and 6G will be developed to allow the RNIS to reach its potential. Advances in RNIS will include improvements in implementation, development of new components such as AI and the enhancement of information capture to optimize message delivery. The inclusion of an AI focused on analyzing contextual information from UE can enhance the RNIS, allowing for better ways of delivering and optimizing the service.