dataesr/scientific-paragraphs-categorization huggingface dataset:
Experimental setup This experiment was conducted on a CDR dataset using Google Colab with a GPU. The NVIDIA Tesla T4 GPU was utilized, along with the necessary libraries and software being installed. The algorithms used in the experiment generated an outlier-ness score, with a higher score indicating a more anomalous sample. Four performance metrics were evaluated, including the True Positive Rate (TPR), False Positive Rate (FPR), Area Under the Curve of Receiver Operating Characteristics (AUC-ROC), and F1-score. Detailed descriptions of these metrics can be found in Section 5. 3. For training the model, we use 80% mixed data, while in testing, we use 20% fraud and legitimate call data. With NFA, we analyze customer usage patterns with the open-source PyTorch implementation of Neural Factorization Machines (NFMs)  [26]  and extract features using an autoencoder (AE).
Performance metrics In this section, we present evaluation metrics such as TPR, FPR, F1score, and AUC for assessing the accuracy of the fraud detection algorithm. Based on the experimental results, which are presented in the form of a confusion matrix, the following terms are defined: True Positive (TP): The number of normal calls predicted as normal by the algorithm. False Positive (FP): The number of fraudulent calls incorrectly predicted by the algorithm as normal calls. True Negative (TN): The number of fraudulent calls correctly predicted by the algorithm as fraud. False Negative (FN): The number of normal calls predicted as fraud by the algorithm. Due to the imbalance of our CDR dataset, we consider both TPR and FPR in our analysis. TP, FP, TN, and FN can calculate these performance metrics.
In this study, we used the following metrics to measure performance. True Positive Rate (TPR): In machine learning, this is also called sensitivity or recall and refers to a method's ability to estimate how many calls were correctly identified in a dataset. Calculating it mathematically, it can be written as follows: TPR ¼ TP TP þ FN (7) False Positive Rate (FPR): False Positive Rate (FPR) is a measure of the likelihood that an actual value will be reported as positive when it actually is negative. This can be expressed mathematically as follows: FPR ¼ FP FP þ TN (8) In some cases, we may prefer high precision and recall at the expense of another metric. When precision is maximized, the number of false positives will be minimized, whereas when the recall is maximized, the number of false negatives will be minimized.
Execution Time: In our study, we evaluated the execution time of different algorithms on a complete dataset and presented the results in Table  3. It is evident from the table that our proposed approach, NFA, has a higher execution time compared to other baseline methods. However, this increase in execution time is a trade-off for the improved performance of the algorithm in real-time fraud detection. NFA is designed to handle real-time fraud detection in a dynamic and complex environment and requires a more sophisticated and computationally intensive approach, aiming to improve the algorithm's overall detection performance. This is why the NFA uses advanced algorithms and techniques to analyze and process large amounts of data effectively. To demonstrate the feasibility of our approach in real-time environments, where the detection speed is crucial, we measured the execution time of our proposed approach on a single call event and found that it takes only 937.
Further, we analyzed normal and fraudulent phone calls made during a single day and on different days of the week to gain a deeper understanding of their patterns and characteristics. The insights gained from this analysis can be used to improve the security of communication systems, enhance the customer experience, and make data-driven decisions. The analysis revealed the frequency and timing of normal and fraudulent calls, which can be visualized in Fig. 5 (a) and (b). In these figures, we show the number of normal and fraudulent calls made over a specified period and analyze the patterns of fraud calls over a day. By dividing the data into intervals of time, such as hours or half-hours, and counting the number of normal and fraudulent calls in each interval, we can identify spikes or dips in call volume and determine if fraudulent calls are more likely to occur at specific times of the day.
Conclusion and future work In this paper, we present NFA, a new real-time technique to identify telecom fraud based on customer calling behavior. NFA integrates neural factorization machines (NFM) and autoencoders (AE) to capture customer usage patterns, and its NFM component directly learns feature interactions from raw data, improving fraud detection. Furthermore, NFA employs memory modules to comprehend customer calling patterns. The threshold-based classification algorithm assesses calls and categorizes them as either fraudulent or normal based on their deviation from typical call patterns. Finally, we demonstrate the effectiveness of our proposed approach through a series of experiments conducted on a real-world CDR dataset comprising 670,211 call records. In order to evaluate the performance of our proposed method, we compared it to several baseline approaches.
Acknowledgements This research work has been conducted in cooperation with members of  DETSI  project supported by  BPI France  and  Pays de Loire  and  Auvergne Rhone Alpes. The authors would like to sincerely thank  Lilian Perron  from  Araxxe  and  Fabrice Chesneau  from  Expandium , a  VIAVI Solutions company , for supporting our research.
Driven by the key principles of open interfaces, virtualization and programmability, Open RAN has emerged as a new paradigm to evolve contemporary Radio Access Networks (RANs) into a more vendor-agnostic, softwarized, and intelligent ecosystem. To this end, Software Defined RAN (SD-RAN) initiatives (e. g. , O-RAN) are drafting specifications to provide the means to embrace it. However, even though O-RAN following the Open RAN paradigm specifies Service Models (SMs) to monitor and control the RAN, it does not go beyond the Quality of Service (QoS) mechanisms provided by 3GPP. Therefore, the QoS degradation that occurs mostly due to data flow's nature at the slowest data path link (e. g. , high L2 sublayers), is not addressed by contemporary O-RAN SMs. In this paper, we present a traffic control system for SD-RAN, denoted as TC-RAN, that consists of an E2 service Model (E2SM) and a RAN Function (RF) that adheres to the Open RAN principles and promotes data flows to first-class citizens in cellular networks, upgrading contemporary 5G QoS mechanism.
In fact, the 10 th anniversary for the first implementation of the nowadays, well understood and deployed AQM algorithms CoDel and FQ-CoDel  [35]  has been recently celebrated. The FQ-CoDel algorithm is based in a Deficit Round Robin (DRR) scheduler and a group of queues, where the flows' packet header is hashed, and the packets are enqueued accordingly. Each queue has a quantum to guarantee their fairness when scheduled in a Round Robin (RR) manner, as well as a Codel AQM to keep the latency and the queue size under control. This approach has been explored in Wi-Fi wireless communications with excellent results  [36]   [11] , where additionally to these techniques, the mature Linux network stack provides the versatile TC utility to handle the flows. However, apart from a few exceptions  [15]  [37]  [38]  with limited adoption but encouraging outcomes, these mature solutions have not been widely applied in cellular networks.
In this manner, the data path distance is reduced, and thus, the latency. Therefore, the natural architectural evolution for reducing the latency of the data path leads to our proposed design, where the data flows of low latency applications are directly managed by the RAN, avoiding the unnecessary GTP encapsulation/decapsulation that occurs between the UPF and the CU, through the NGAP protocol  [51]. This brings user plane (UP) capabilities directly into the RAN, closer to the slowest link in the data path, which is the wireless channel as shown in Section V. Thus, with the proposed TC-RAN system, the RAN acquires new packet processing capabilities, able to directly interact with edge/local applications servers (e. g. , for time-sensitive or synchronous applications) without any intervention of the UPF and just before the slowest data path link, avoiding unnecessary delays.
IV. ARCHITECTURE AND IMPLEMENTATION In this section, we elaborate on the TC-RAN architectural design, challenges, and implementation details, primarily focusing on the following design challenges: • Design and implement a programmable data flow processing pipeline for 5G/6G SD-RAN that supports composability, customizability and extendability. • Create a novel set of user-plane abstraction in a form of (open) interfaces between the TC RF and E2 Node, that is applicable to both current and future cellular systems, ensuring backward and forward compatibility.
The classifier can be loaded online as it is designed as a shared object, enabling forward compatibility. 2) Ingress::Policer: The second stage in the pipeline is the policer. Once the classifier has assigned the destination queue for the packet, the responsibility moves to the policer. The policer can reject the packet received from the classifier or redirect it to another queue, if a rate limit is reached within a time window. The policer answers the question of how much data rate can be accepted, and thus, it decides either to forward the packet, deviate it or drop it. Typical statistics are the transmitted rate, and the deviation rate. The maximum rate, and the time window for calculating them, can be dynamically configured. Only one policer can exist per 3 More details can be found at: https://gitlab.
The shaper allows egressing a packet from a queue if a rate has not been reached. Therefore, it answers whether a packet should be egressed or not. Similar to the scheduler, the shaper needs to be informed if the packet was ultimately forwarded. Contrarily to the policer, the shaper cannot discard a packet, but it can limit the rate at which packets are egressed. The shaper only answers whether the following packet can be dequeued or not. Typical statistics show the current rate of a queue, which can also be configured, as well as its time window to calculate it. Similarly to the policer, the shaper's lifetime is bound with the lifetime of a queue, and thus, it can only exist if an associated queue exists. 6) Egress::Pacer: The last stage in the TC RF pipeline is the pacer. While the shaper works per TC RF queue, the pacer is responsible for not bloating the RLC buffer that exists before the MAC sublayer, that aggregates the data egressed from all the TC SM queues.
B. Programability Besides, the TC SM can configure the RF 6 stages using the add/delete/modify actions relying on the E2AP Control message generated by the nearRT-RIC, while the statistics are gathered using the E2AP RIC Indication message, similar to other E2SMs (e. g. , KPM). TC SM's pipeline design allows composing complex architectures tailored to specific use cases. To name a few: (i) the FQ-CoDel with cellular network specificities can be smoothly composed using a stochastic classifier, CoDel queues, a deficit round-robin scheduler and a 5G-BDP pacer, (ii) or the L4S architecture can be implemented using a classifier that segregates the flows into "classic" and "scalable", two queues capable of marking (i. e. , ECN) or dropping the packet when congestion is detected, a conditional priority scheduler and a pacer to avoid bloating the RLC buffer, (iii) or a flow slicing pipeline can be configured deploying an OSI classifier to segregate the flows, a policer to limit the input data rate, FIFO queues, a RR scheduler to evenly allocate transmission opportunities, a shaper to limit one queue's rate and a 5G-BDP pacer to avoid the bufferbloat at RLC.
C. TC-RAN Implementation Regarding the code used in our implementation, the TC-RAN can be divided between the code that is necessary to define its E2SM compatible data layout with its encoding/decoding schemes and the code that is needed in the TC RF. The former and later contain approximately 5K lines of C11 code each (we use the Generic reserved keyword for static polymorphism in the encoding/decoding scheme, with no external dependencies). TC-RAN has been prototyped in downlink in the 5G gNodeB of OpenAirInterface (OAI)  [55]. The TC RF needs to communicate with the SDAP and the PDCP sublayers in downlink to ingress and egress packets as required. However, the API needs to be as small as possible yet complete. To identify the RLC DRB, the RAN, needs to pass the Radio Network Temporal Identifier (RNTI), as well as the DRB ID, which uniquely identifies the RLC buffer, in conjunction with the packet address location and its size.
For egressing, a mechanism periodically traverses the active TCs, activating the pipeline and forwarding packets if required. TC-RAN is implemented using the scalable I/O system call notification facility epoll, and a configurable timer file descriptor. Since different TC RF instances do not share data among them, if further parallelism is needed, different instances could be processed in parallel. Thus, ingress and egress can be considered as two independent processes that only share a queue. We prototyped TC-RAN in a monolithic gNodeB where we obtained the RLC buffer status periodically, just after the MAC scheduler has formed the TBS, and thus, the packets from the RLC buffer have been dequeued. However, the RLC buffer status needed for the pacer, could also be gathered using an xApp or in a disaggregated deployment, this can also be achieved through the F1-U protocol Downlink Data Delivery Status procedure messages  [45] , where the desired buffer size and its data rate for the corresponding data radio bearer is transmitted.
The classifier, queue, scheduler and pacer stages are designed as shared objects with a common interface, similar to how loadable kernel modules are designed (i. e. , at start the module function pointers are initialized  6  ), and thus, they can be reconfigured online, enabling fine-grained control of the proposed TC RF pipeline from an xApp. We did not use recursive mechanisms in TC-RAN. However, in our design, recursive structures within shared objects can be easily implemented if needed.
V. EVALUATION In this section, we first describe our testbed and the overhead of TC RF in comparison with vanilla OAI  [55]. Following, we validate TC-RAN's per-flow traffic slicing and low-latency capabilities. Next we show a real online multiplayer game scenario, and we end this section with some results that aim to shed some light in the still open question of the adequacy of handling 5G QoS in the RAN against CCA solutions in a time-varying MCS cellular scenario. The code used in this manuscript for the RAN can be found in the official OAI's repository,  7  , while nearRT-RIC's and xApp code is available at FlexRIC's official repository  8.
B. Validation In this subsection, we validate the TC-RAN's capabilities and its versatility. For stability purposes we limited the MCS to 10. 1) RAN Flow Slicing: Similar to how the MAC Resource Block Groups (RBGs) can be sliced (e. g. , assigning a percentage of RBGs to a specific RLC buffer), so can be achieved with data flows. In Fig. 6a , four flows in downlink can be observed. Around the 5 th second, the TC RF is reconfigured through an xApp with an OSI classifier, a second FIFO queue, a RR scheduler and a 5G-BDP pacer, as shown in Fig. 5a. The OSI classifier will segregate the flows according to their 5-tuple when queuing, while the RR scheduler will fairly dequeue the packets from the available queues. Additionally, a control message is sent to the classifier, aiming to segregate the Flows 2, 3, and 4 into an independent queue, emulating an application that consists of 3 flows, while the rest of the flows (i.
TC-RAN's versatility to unleash 5G QoS means is shown in this section. Current Linux default TCP CCA's (i. e. , Cubic) behavior ruins most of the time-sensitive use cases described by 3GPP, and it is not capable of dynamically adjusting its rate to the cellular network channel variability. However, TC-RAN, through its composable, customizable and reconfigurable flexible design, provides the means to deploy different configurations to achieve stringent time and resource demands. Using TC-RAN, xApps are empowered to dynamically compose, customize and reconfigure the data flow pipelines in near real-time considering the RAN status, and thus, optimize the overall performance. Additionally, some limitations when trying to optimize the QoS from the CCA have been shown.
VI. CONCLUSION In this paper, we present TC-RAN, an O-RAN compatible E2SM for promoting traffic flows to first-class citizens in cellular networks, modifying the current 3GPP stack, while embracing the Open RAN paradigm. As demonstrated in this paper, there exist concrete and realistic scenarios that neither 3GPP nor O-RAN address, that are of utmost importance for guaranteeing the QoS in cellular networks. The presented TC SM is a fundamental pillar to embrace the 5G/6G QoS requirements and manage the traffic flows through a standard interface (i. e. , E2SM) in the RAN, that opens a new field for cross-optimization algorithms in AI/ML to combine RB allocation with per-flow QoS. The presented 6 stage pipeline segregates the responsibility of each module, following the principle of Do One Thing and Do It Well and enabling extension, customization, composition and programmability.
Therefore, addressing the problem close to the slowest data path link is of upmost importance, for which TC-RAN provides the means. Furthermore, it shows the necessity of a communication link between the RAN and the CCA to avoid squandering RBs. TC-RAN is open source 12 13 under a permissive license (i. e. , OAI's FRAND license) 14 to promote its adoption and use. As future work, we plan to extend the TC-RAN with more pluggable entities (e. g. , RED AQM queue), devise new abstractions to facilitate xApp control loop (e. g, SLA on total throughput) and port the TC RF into other cellular network stacks (e. g. , srsRAN). 12 https://gitlab. eurecom. fr/oai/openairinterface5g/-/tree/tc-ran 13 https://gitlab. eurecom. fr/mosaic5g/flexric/-/tree/master/ 14 https://openairinterface. org/legal/oai-public-license/.
Semantic Web (SW) technologies are suitable to represent taxonomic knowledge in Knowledge Graphs (KG). However, cases that do not fall in this category such as numerical relationships (e. g. , algebraic operations or unit conversion) that can enrich the KGs data are poorly represented. Current approaches mostly trigger these relationships in a materialised fashion (i. e. , perform all the relationships in advance), which leads to storage and updating problems. Besides, these relationships are often not represented using linked data formats ignoring the FAIR and LOD guidelines, which leads to issues of interoperability, reproducibility and adoption. In this work, we propose QAVAN, a query-answering approach that computes efficiently only the necessary numerical relationships relevant to answer to a given query.
QAVAN exploits SW technologies such as SHACL for representing and computing these relationships while plays in favour of FAIR and LOD principles. We evaluated and compared QAVAN against a materialised approach using two real datasets extracted from two very well-known data sources, DBpedia and MeteoFrance. Results expose the numerous benefits of QAVAN in terms of execution time, memory usage, and disk space in different scenarios for example against big datasets. We also evaluated two QAVAN extensions, the nested numerical relationships and the inference services. Our results show that these extensions allow to apply the numerical relationships for a greater number of instances to provide more query results.
Introduction Recent technological advances have exponentially increased the acquisition of massive and rich datasets in diverse domains (e. g. agriculture, biomedical, environmental, social). This context has raised new challenges regarding data organisation and reuse, as well as the need to adopt Findable-Accessible-Interoperable-and-Reusable (FAIR) data principles  [1]. In that sense, Knowledge Graphs (KGs) have gained attention as a data structure to handle disparate datasets that contain numerical information of many individual observations. In addition to common tasks performed over KGs: ontological reasoning  [2] , validation  [3] , mappings  [4] ; new needs such as representing and computing mathematical formulas that enhance KGs with new derived data are becoming more and more relevant in most of domains.
For instance, the Body Mass Index (BMI) of a person can be derived from their current weight and height and can be used to enrich the initial data. Similarly, the Vapour Pressure Deficit (VPD) in the atmosphere can be derived from the air temperature and the air relative humidity. While experts are aware of such mathematical formulas, most of them are performed in adhoc programming languages limiting their reusability and reproducibility. Besides, when KG data is transformed into tabular formats many contextual data and semantic links are lost, making more difficult the data processing task  [5]. Additionally, solutions to handle data completion problems  [6]  are mainly based on graph embeddings and often ignore this numerical knowledge. Currently, there is no standard manner to represent this kind of knowledge while the existing SW alternatives present different limitations.
Many approaches  [7] [8] [9] [10] [11]  that allow somehow to represent numerical relationships over KGs compute the corresponding data in a materialised fashion. This means that all the mathematical relationships are performed against the initial KG to obtain a new enriched graph containing as well the resulting triples. For instance, SPARQL  [7]  and its extensions allow to express mathematical relationships and define derived data through CONSTRUCT queries. However, a mediated script should perform the materialisation to enrich the KG. This strategy has been followed by Bischof et al. [11]  that used a Python script and CONSTRUCT queries to enrich the KG data. While the materialised strategy provides a first solution to this problem, it can lead to disk space and memory allocation issues on large KGs.
Moreover, it is not https://doi. org/10. 1016/j. knosys. 2023. 111252 Received 27 June 2023; Received in revised form 2 November 2023; Accepted 30 November 2023 • A theoretical comparison of the related approaches considering aspects relevant for big and heterogeneous KGs. • QAVAN, an efficient query-answering approach able to perform on the fly numerical relationships that produce new derived data. QAVAN exploits SW engines and technologies to that goal. • Two extended experimental evaluations of QAVAN, on (i) a meteorological dataset  [15] , composed mainly of numerical weather observations, demonstrating the high impact of such an approach in experimental data, and (ii) DBpedia  1  and Eurostat 2  data to demonstrate the generic nature of our approach and its capacity to be extended allowing new features relevant in the SW.
Method. Whether or not to perform ANRs in advance is an important decision to take. In database research, the concept of views  [17]  is used to define a new table produced by an SQL query. If the query results are not stored, it is known as a virtual view. On the contrary, if the query results are stored, it is known as a materialised view. Following the same principle in our context, depending on how the results are stored we define materialised or virtual ANRs. Note that the terms of backward and forward chaining are used in the domain of automated reasoning to represent similar concepts. Nevertheless, such methods do not mention the fact of storing the results, we therefore choose to use the database field concept. Engine. Engines perform ANRs in two steps: (i) performing the mathematical formula inside the 𝑒𝑣𝑎𝑙 relation and (ii) triggering the ANRs to produce new triples.