Services RAN protocol stack dynamic expansion and contraction method and system

Abstract

The invention provides a service RAN (Radio Access Network) protocol stack dynamic expansion and contraction method and system, and the system comprises a digital object management module which is used for regularly pushing received key performance indexes to a decision control module; the decision control module is used for judging whether the service instance needs to be subjected to capacity expansion or capacity shrinkage based on the key performance index, forming a capacity expansion instruction or a capacity shrinkage instruction, and sending the capacity expansion instruction or the capacity shrinkage instruction to the service scheduling module; the service scheduling module is used for carrying out service instance capacity expansion or service instance capacity reduction based on the capacity expansion instruction or the capacity reduction instruction sent by the decision control module; the API server module serves as an external uniform interface of the system and is used for data interaction between an external RAN network and the system and data interaction among modules in the system; and the database module is used for storing system data. According to the scheme, the adaptability and the flexibility of the RAN network are improved, the reliability and the stability of the system are enhanced, rapid updating and deployment are supported, and resource utilization is optimized.

Description

Technical Field

[0001] This invention relates to the fields of network data transmission, network protocol control and applications, and in particular to a method and system for dynamically scaling up and down a service-oriented RAN protocol stack. Background Technology

[0002] With the advancement of 5G and future 6G networks, the Radio Access Network (RAN) faces increasingly complex challenges and opportunities. 5G introduces ultra-high bandwidth, ultra-low latency, and massive connectivity capabilities, making emerging application scenarios such as high-definition video streaming, massive Internet of Things (IoT), and autonomous driving a reality. However, these scenarios place more stringent demands on networks, particularly in terms of bandwidth, latency, reliability, and flexibility.

[0003] Traditional RAN architectures, especially their protocol stacks, suffer from rigid designs and a lack of flexibility, making it difficult to quickly respond to these diverse and dynamically changing demands. As network requirements continue to evolve, existing RAN architectures need to be rethought and redesigned to better adapt to future communication environments.

[0004] Future RAN architectures may need to be more adaptable, enabling flexible resource configuration across various application scenarios. Simultaneously, the protocol stack needs to become more modular and service-oriented to support specific requirements in different scenarios. For example, in autonomous driving scenarios, low latency and high reliability are critical requirements, while in large-scale IoT scenarios, the network needs to support efficient connectivity and management of a large number of devices.

[0005] To address these challenges, RAN innovation goes beyond simple performance improvements; it requires comprehensive reforms in areas such as architecture design, protocol stack optimization, and resource management to meet the diverse needs of future networks. This transformation is not only to adapt to current 5G network requirements but also to prepare for the arrival of 6G.

[0006] Existing solutions have the following drawbacks: they typically collect data at fixed time intervals through monitoring, which can lead to untimely responses when dealing with sudden traffic spikes or rapidly changing network conditions; data analysis relies on preset analytical indicators and steps, such as using monitoring information to identify microservices that may need scaling up or microservices that may need scaling down due to excess service capacity, thus lacking adaptability to unknown patterns or newly emerging performance bottlenecks and limiting the generalization of algorithms; and in RAN scenarios, existing processing methods cannot meet the requirements of a large number of concurrent requests, extremely low service latency, and high reliability. Summary of the Invention

[0007] To address at least some of the technical problems existing in the prior art, the present invention provides the following technical solutions:

[0008] On one hand, the present invention provides a service-oriented RAN protocol stack dynamic scaling system, the system comprising:

[0009] The digital object management module is used to periodically push the received key performance indicators to the decision control module;

[0010] The Decision Control Module (PCF) is used to determine whether to expand or shrink the service instance based on key performance indicators, and to generate expansion or shrinkage instructions, which are then sent to the service scheduling module.

[0011] The Service Scheduling Module (SSF) is used to expand or shrink service instances based on the expansion or shrinkage instructions sent by the Decision Control Module.

[0012] The API server module serves as the unified interface for the system to the outside world, and is used for data interaction between the external RAN network and the system, as well as data interaction between various modules within the system.

[0013] The database module is used to store system data.

[0014] Preferably, the digital object management module includes a digital object center submodule, which is responsible for the creation, deletion, updating and querying of digital objects, and stores the relevant data of the digital objects in the database module;

[0015] The decision control module is also used to generate service scheduling strategies and scaling control strategies, which communicate with the service scheduling module through the API server module.

[0016] Preferably, the service scheduling module is also responsible for starting or terminating service instances in the system.

[0017] Preferably, in the API server module, each URI corresponds to a callback function. When the API server module receives an HTTP request for a certain URI, it calls the callback function corresponding to that URI to parse the data in the HTTP request and sends the parsed data in the HTTP request to the corresponding module through the channel.

[0018] Once the corresponding module has finished processing, the processing result is sent back to the API server module through another channel;

[0019] When the modules within the system communicate with the outside world, the API server module directly calls the HTTP client function to complete the communication between the system and the outside world.

[0020] Preferably, when a request is made to create a digital object, the digital object center submodule creates a corresponding digital object instance in the database module based on the digital object template contained in the request, and assigns a unique digital object instance ID;

[0021] The digital object center submodule is also used for pushing digital objects, so as to push digital object instances or digital object instance updates that have subscribed to a digital object to the subscribed functional entities.

[0022] Preferably, the digital object management module is also used for event monitoring, specifically in the following manner:

[0023] Based on features related to major events in historical data, a prediction model M1 is trained to predict changes in user volume caused by major events.

[0024] And based on the features related to the major events collected in real time, the user volume changes are predicted;

[0025] Compare the predicted changes in user volume with a threshold and verify the accuracy of the prediction results;

[0026] When the accuracy requirements are met, the decision control module is triggered to make a scaling up or scaling down decision, and the scaling up or scaling down is executed through the service scheduling module.

[0027] The digital object management module evaluates the scaling up or scaling down effect, records predicted events, actual events and corresponding processing actions, and feeds the processing results back to the prediction model M1.

[0028] Preferably, the database module includes:

[0029] The time-series database submodule is used to store real-time monitoring metrics data of network operation, including CPU utilization, number of failed requests, and number of RRC connections;

[0030] The in-memory database submodule is used to store Cell DOI data and UE DOI data;

[0031] The image storage submodule is used to store and distribute container images of RAN network functions.

[0032] Preferably, the decision control module generates service scheduling strategies and scaling control strategies, obtained through a user volume prediction model, specifically including:

[0033] Key performance indicators are collected from the digital object management module and preprocessed; features that significantly affect the prediction of rapid changes in user volume are extracted from the preprocessed data through statistical analysis; user volume change prediction results are obtained through the trained user volume prediction model; and expansion or reduction strategies are generated based on the user volume change prediction results.

[0034] The user volume prediction model is deployed in the decision control module; the user volume prediction model consists of an LSTM model and an XGBoost model; when the performance of the user volume prediction model degrades or the distribution of feature data changes, the user volume prediction model is updated.

[0035] Preferably, the statistical analysis includes:

[0036] The process involves identifying outliers and distribution characteristics in the preprocessed key performance indicator (KPI) data and removing outliers; calculating the correlation coefficients between different KPIs to filter out KPI data that are strongly correlated with changes in user volume; calculating the autocorrelation and partial autocorrelation functions between strongly correlated KPI data and performing periodic decomposition to obtain time-related features; performing principal component analysis on the time-related features to obtain important features; and simultaneously, dividing user behavior or network status into different groups through cluster analysis to obtain the behavior patterns of different groups.

[0037] The process control charts that yield key features and behavioral patterns of different groups are obtained, and key inflection points in user volume changes are identified as driving trigger features.

[0038] Preferably, the decision control module communicates with the digital object management module and service scheduling module inside the system via a channel; the decision control module also communicates with the digital object management module and service scheduling module outside the system via an HTTP interface.

[0039] Preferably, the service scheduling module is further used to redirect user access requests to allocate user access requests to appropriate RAN network function instances;

[0040] The service scheduling module encapsulates RAN network function instances as containers.

[0041] Preferably, the system further includes a security module embedded in the API server module. The security module achieves system security protection by setting transmission protocols, implementing data encryption, key management, data integrity verification, establishing secure data transmission channels, and detecting and responding to anomalies.

[0042] On the other hand, the present invention also provides a method for dynamically scaling a service-oriented RAN protocol stack, the method being executed by the service-oriented RAN protocol stack dynamic scaling system described above, the method comprising:

[0043] S1: After the service is instantiated, the service instance reports key indicator data to the digital object management module;

[0044] S2: The digital object management module periodically pushes the collected key indicator data to the decision control module; based on the key indicator data, the decision control module determines whether it is necessary to expand or shrink the service instance.

[0045] S3: The decision control module generates a scaling-up or scaling-down strategy for the service instance based on the judgment result; if a scaling-up or scaling-down operation is required, the decision control module sends a scaling-up or scaling-down instruction to the service scheduling module, and the service scheduling module executes the scaling-up or scaling-down operation.

[0046] The expansion process is as follows:

[0047] S3-1: Upon receiving the scaling instruction, the service scheduling module starts a container for a new service instance on the corresponding server according to the scaling instruction from the decision control module.

[0048] S3-2: After a new service instance starts, the service scheduling module initiates a service registration request;

[0049] The volume reduction process is as follows:

[0050] S3-3: Upon receiving a scaling-down instruction, the service scheduling module terminates the specified service instance according to the scaling-down instruction from the decision control module.

[0051] S5-2: The service scheduling module then initiates a service registration request to ensure that terminated service instances are correctly removed from the system.

[0052] Compared with existing technologies, this solution has the following beneficial technical effects:

[0053] 1. Enhance network adaptability and flexibility: Through the dynamic scaling method of the service-oriented RAN protocol stack, network resource allocation can be quickly adjusted according to real-time network demands and load changes. This dynamic adjustment capability enables the network to adapt more flexibly to various application scenarios, such as high-definition video streaming, large-scale Internet of Things (IoT), and autonomous driving, meeting the diverse needs for bandwidth, latency, reliability, and flexibility in different scenarios.

[0054] 2. Optimized Resource Utilization and Cost-Effectiveness: This solution achieves decoupling of computing and storage, as well as on-demand scaling up and down of service instances, through intelligent resource management and scheduling strategies. This not only improves resource utilization efficiency but also reduces costs incurred due to over-configuration or resource waste, thereby enhancing overall cost-effectiveness.

[0055] 3. Enhanced System Reliability and Stability: Through modular and service-oriented protocol stack design, this invention ensures high availability and fault recovery capabilities for critical network functions. In the face of network failures or performance bottlenecks, the system can respond quickly and reallocate resources, guaranteeing the continuity and stability of network services.

[0056] 4. Enhance user experience: This solution can dynamically optimize network configuration by monitoring network performance indicators and service quality parameters in real time and combining decision support information generated by AI / ML algorithms, thereby providing a smoother and higher quality user experience, especially in application scenarios with extremely high requirements for latency and reliability.

[0057] 5. Supports rapid innovation and deployment: The system architecture of this solution supports rapid service innovation and deployment. Utilizing containerization technology and Kubernetes cluster management, new services and features can be quickly packaged into container images, managed and distributed through Docker Registry, enabling rapid iteration and deployment.

[0058] 6. Promote technical standardization and interoperability: This solution adopts standardized communication protocols and interfaces, such as HTTP / 1.1 and the Prometheus time-series database, which promotes interoperability between different systems and components and facilitates future technology expansion and integration. Attached Figure Description

[0059] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0060] Figure 1 This is a functional partitioning of the service-oriented RAN control domain according to an embodiment of the present invention;

[0061] Figure 2 This is a schematic diagram of the API server module structure according to an embodiment of the present invention;

[0062] Figure 3 This is a schematic diagram of the DO central module structure according to an embodiment of the present invention;

[0063] Figure 4 This is a schematic diagram illustrating the interaction between the PCF module and other modules in an embodiment of the present invention.

[0064] Figure 5 This is a schematic diagram of the SSF module in an embodiment of the present invention. Detailed Implementation

[0065] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the figures. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0066] To address the problems existing in the above-mentioned technologies, this solution mainly solves the following technical problems by designing a new dynamic scaling method for the service-oriented RAN protocol stack:

[0067] 1. Optimized for specific scenarios: This solution is specially optimized for RAN scenarios and is more suitable for the special needs of radio access networks, such as high reliability, low latency and large-scale connectivity, compared with existing inventions.

[0068] 2. Real-time performance monitoring: This solution introduces an event-based triggering mechanism into the RAN system, rather than relying solely on time interval monitoring, which improves the response speed to changes in network conditions.

[0069] 3. This solution combines online learning mechanisms with machine learning algorithms, which improves the accuracy of predicting changes in user volume.

[0070] 4. This solution incorporates enhanced security measures during data transmission, processing, and storage.

[0071] 5. This solution enables rapid service recovery and an effective fault tolerance mechanism, improving the stability and reliability of the system in the face of failures.

[0072] The following detailed description of the architecture and implementation of this solution, with reference to specific embodiments, provides a comprehensive overview.

[0073] In the system architecture described in this solution, each function is divided into multiple key modules that work together to ensure efficient network operation and flexible resource management.

[0074] I. Main processes of service instance management and scaling:

[0075] The first stage is indicator reporting and decision generation:

[0076] After a service is instantiated, each instance reports its key performance indicators (KPIs) to the Digital Object Management Function (DOMF). The DOMF is responsible for periodically pushing this KPI data to the Policy and Control Function (PCF), which uses the collected KPI data to determine whether the service instance needs to be scaled up or down.

[0077] More preferably, the key performance indicators include, but are not limited to, the following aspects:

[0078] Throughput: Measures the number of requests or data transfers a service can handle per unit of time, reflecting the effective utilization of network bandwidth.

[0079] Latency: The time required for a service request to be sent and for a response to be completed. It is especially important for applications with high real-time requirements.

[0080] Resource utilization: This includes the utilization rate of resources such as CPU, memory, storage, and network, reflecting the effective use of system resources.

[0081] Error rate: The percentage of requests that fail is an important indicator for evaluating system stability and reliability.

[0082] System Availability: The proportion of time a service is up-to-date, reflecting the stability and reliability of the system.

[0083] Quality of Service (QoS) metrics, such as packet loss rate and jitter, directly impact user experience, especially in multimedia transmission and real-time communication applications.

[0084] Energy Consumption: In the context of green communication and energy conservation and emission reduction, energy consumption has also become one of the important indicators for evaluating network performance.

[0085] Mobility: The ability of a terminal to maintain a communication connection while moving, reflecting the degree of network support for mobile users.

[0086] Reliability: The ability to successfully transmit user traffic within a predetermined time, reflecting the stability and reliability of network transmission.

[0087] Spectrum efficiency: Measures the effectiveness and efficiency of network data transmission under limited spectrum resources.

[0088] The above-mentioned data do not require preprocessing. All preprocessing and analysis will be performed by PCF after the data is pushed to PCF.

[0089] The second stage is the execution of expansion and contraction instructions:

[0090] Scaling up: If the PCF determines that service instances need to be expanded, the PCF will send an expansion instruction to the Service Scheduling Function (SSF). The SSF will then start a new service instance container on the corresponding server and complete the service registration of the instance.

[0091] More preferably, the expansion decision is based on the judgment made by PCF according to key indicators. The judgment process varies depending on the actual situation. The main basis for the judgment is that PCF believes that the service instances are insufficient to support the current user requests.

[0092] Scaling down: If PCF decides to reduce the size of a service instance, SSF will terminate the specified service instance according to the instruction and send a service deregistration request to the service management function to ensure the effective release of resources.

[0093] The decision to scale down is understandable, similar to scaling up, because PCF believes that the number of service instances is greater than the number of user requests, and therefore decides to scale down in order to save resources.

[0094] II. Functional Module Division of the Control Domain

[0095] In this embodiment, combined with Figure 1 As shown, the control domain functions are mainly divided into the following four sub-modules to jointly support the operation and management of the service-oriented RAN:

[0096] 1. API Server, i.e., the API server module:

[0097] This module provides a unified communication interface to the outside world, enabling communication based on the HTTP / 1.1 protocol. As the system's entry point, it is responsible for handling external requests and interacting with internal modules.

[0098] 2. DOMF, or Digital Object Management Module:

[0099] The Digital Object Central Submodule (DO Central Submodule) and the database are the core components of DOMF. The Digital Object Central Submodule is responsible for managing the creation, deletion, updating, and querying of digital objects (DOs), and storing the data in databases such as Prometheus (primarily used for storing time-series data), Redis (primarily used for storing cached data), and DockerRegistry (primarily used for storing RNF image data).

[0100] 3. PCF, or Decision Control Module:

[0101] PCF generates network-level service scheduling and scaling control policies based on data pushed by DOMF. These policies communicate with SSF through the API server module to ensure dynamic management and optimization of service instances.

[0102] 4. SSF, or Service Scheduling Module:

[0103] SSF communicates with the Kubernetes API to schedule and scale RNFs (RAN Network Functions) according to the PCF's policies. This module is responsible for starting or terminating service instances and executing the service scheduling and scaling control policies defined by the PCF to adapt to changes in network load and optimize resource allocation.

[0104] The service-oriented RAN control domain is designed with three core functional modules—DOMF, PCF, and SSF—to achieve efficient management and dynamic scaling of service instances. The API server module serves as a unified external interface, ensuring the system's openness and scalability. The modules work closely together through clear interfaces and communication mechanisms, guaranteeing the RAN's flexibility and availability.

[0105] III. The following is a detailed introduction to each module.

[0106] 1. API Server, i.e., the API server module:

[0107] Combination Figure 2 As shown, the API server module plays a crucial communication role in the system, responsible for data interaction with the external RAN network module (RNF). The API server module employs independent Go routines (lightweight concurrent execution units in Go that can execute functions concurrently) to handle HTTP server and client functionalities separately. This design ensures the efficient operation of the API server module in high-concurrency environments. The API server uses the Gin framework to handle HTTP requests. The advantage of this approach lies in its middleware mechanism and built-in router, which allows for easy definition of corresponding callback functions for each URI (Uniform Resource Identifier).

[0108] In a more preferred implementation, this embodiment uses the Go language to handle concurrent HTTP server and client processing. Leveraging the characteristics of Go routines, this achieves the following objectives:

[0109] High efficiency --- goroutine context switching is cooperative and controlled by Go's runtime system, rather than the operating system's scheduler, which makes the switching very efficient.

[0110] Lightweight – Compared to traditional threads, goroutines have dynamically adjustable stack sizes, starting very small (typically a few KB) and expanding as needed, which makes creating and destroying goroutines very inexpensive.

[0111] Concurrent execution --- Using goroutines allows a program to execute multiple functions or methods simultaneously without explicitly creating additional threads.

[0112] It should be further noted that other languages ​​can also be used here, as long as they can meet the purpose of concurrent execution, they can be applied to the solution in this embodiment.

[0113] In the API server module, each URI corresponds to a specific callback function. When the API server module receives an HTTP request for a specific URI, it automatically invokes the callback function associated with that URI. The main task of the callback function is to parse the JSON data in the request and send the parsed data to the internal functional modules for processing via a Go channel.

[0114] Communication between the API server module and its internal functional modules is implemented using Go channels. After receiving an HTTP request and parsing the JSON, the API server module sends the data through a channel to the designated internal module for processing. Once processed, the internal module sends the result back to the API server module through another channel.

[0115] When internal functional modules need to communicate with external systems, such as sending requests to other RNFs or receiving data, the API server module directly calls the HTTP client functionality provided by the net / http package. This design simplifies the communication process between internal modules and external systems, enabling the API server module to efficiently handle various HTTP requests.

[0116] The API server module uses JSON format for data exchange with external RNFs. This format offers good readability and versatility, making it suitable for data transfer between different systems. Upon receiving an external request, the API server module parses the JSON data in the request and passes it to the internal module according to a predefined structure. This predefined structure can be, for example, a JSON field structure.

[0117] The structural design of this module has at least the following advantages:

[0118] High performance: Through the combination of the Gin framework and Go routines, the API Server can handle high-concurrency HTTP requests, ensuring stable operation of the system in large-scale deployment environments.

[0119] A concise communication mechanism: Go channels are used for communication between internal modules, simplifying the data transfer process and reducing coupling.

[0120] Flexibility: The API Server handles different URI requests through callback functions, giving the system good scalability and flexibility.

[0121] 2. DOMF, or Digital Object Management Module

[0122] Combination Figure 3 As shown, the DOMF module is a core component of the service-oriented RAN system, responsible for managing the state data of Digital Objects (DOs) and ensuring the integrity and consistency of state data during the scaling up or down of service instances. State data management here refers to recording all operations during the management process, recording the corresponding operation and the state of each DO after each operation.

[0123] (1) Digital Object (DO)

[0124] Concept: DO is a digital abstraction of physical resources and devices in a service-oriented RAN system. It represents a type of digital instance in the system, such as cell, user equipment (UE), and RAN network function (RNF).

[0125] Instantiation: Each DO instance is called a Digital Object Instance (DOI), which is the specific representation of the DO at a particular point in time. DOIs can be stored in memory or a database.

[0126] Template: The Digital Object Template (DOT) is used to define the parameter fields contained in each DO, thereby guiding the creation and management of DOIs.

[0127] (2) Digital Object Central Submodule (DO Central Submodule)

[0128] The Digital Object Center submodule is a core submodule of DOMF, responsible for managing the lifecycle of DOs and data push services.

[0129] DO management functions:

[0130] Function Description: The DO management function handles the creation, deletion, modification, and query (CUDQ) of DOIs. When an external request creates a DO, the DO central submodule creates a corresponding DOI in the database based on the DOT information contained in the request and assigns a unique numeric object instance ID (i.e., DOI ID).

[0131] Thread design: The DO management function uses a separate Go routine to handle CUDQ requests. This routine continuously listens to a specific channel, receives requests from the API server module, and performs relevant operations on DOIs in memory or the database to ensure the consistency and integrity of DO data.

[0132] DO push function:

[0133] Function Description: The DO push function is responsible for pushing DOI data to functional entities that have subscribed to the DO. Functional entities can obtain DOI data through subscription or query requests. When the conditions in the subscription request are met, the DO center submodule will proactively push the updated DOI data to the corresponding functional entities.

[0134] Thread design: The DO push function is also implemented using a separate Go routine. This routine listens for subscription and query requests through a channel. When a new request arrives, the DO push routine returns the DOI operation result or real-time data based on the request content.

[0135] (3) Event monitoring

[0136] To address the monitoring mechanism for rapid changes in user volume caused by major events in the RAN environment, this embodiment designs an event monitoring system based on prediction and verification. The detailed steps are as follows:

[0137] S1: Feature Extraction and Model Training

[0138] Feature extraction: Extract features related to major events from historical data, such as time (holidays, large-scale events), location (sports venues, commercial centers), and historical user growth patterns.

[0139] Model training: The predictive model M1 was trained using a random forest (and a small machine learning algorithm) to predict changes in user volume caused by major events.

[0140] S2: Real-time data monitoring

[0141] Data collection: Real-time collection of network performance metrics, including but not limited to user connection count, network traffic, signal quality, etc.

[0142] Feature calculation: Based on current and historical data, calculate features related to changes in user volume.

[0143] S3: Predicting User Volume Changes

[0144] Real-time prediction: Using a trained model, predict changes in user volume over a period of time based on features calculated in real time.

[0145] Threshold setting: Set a threshold for the prediction results to determine whether the number of users may change rapidly.

[0146] S4: Event Prediction Verification

[0147] Time threshold: Set a time threshold (e.g., 30 seconds) to continuously monitor the actual changes in user volume within this time period.

[0148] Comparison with actual data: Compare the predicted results with the actual changes in user volume to verify the accuracy of the prediction.

[0149] S5: Triggering the scaling mechanism

[0150] Confirm rapid change: If the actual number of users changes beyond a preset threshold, confirm the rapid change event.

[0151] Scaling / Scaling Decision: The PCF is triggered to generate a scaling / scaling decision, and the scaling / scaling operation is executed through the SSF. In one optional implementation, the PCF first presets a scaling / scaling strategy, and when the setting is triggered, the PCF sends a message to the SSF to execute the corresponding scaling / scaling strategy.

[0152] S6: Perform expansion / shrinkage operations

[0153] Resource scheduling: Based on the decisions of the PCF, the SSF adjusts the number of RNF instances and service resources by communicating with the Kubernetes API.

[0154] Service optimization: Optimize network configuration and service allocation to cope with changes in user volume. The optimization process is performed at the SSF.

[0155] S7: Monitoring and Adjustment

[0156] Continuous monitoring: Continue to monitor network performance and user volume changes after scaling up or down operations are performed.

[0157] Performance Evaluation: Evaluate the effectiveness of scaling up and down operations and make adjustments as needed. In one optional implementation, performance evaluation can be performed by setting thresholds m and i. If any instance has a memory load higher than m or a network load higher than i, it is considered unsatisfactory and needs to be readjusted.

[0158] S8: Recording and Feedback

[0159] Event Log: Records all predicted events, actual events, and corresponding actions.

[0160] Feedback mechanism: The event processing results are fed back to the prediction model M1 to optimize the accuracy of future predictions.

[0161] (4) Database Integration

[0162] In order to effectively manage and store different types of DO data, a corresponding database storage scheme needs to be designed. In this embodiment, the DOMF module adopts a scheme that combines three types of databases: time-series database, in-memory database, and mirror database.

[0163] a. Time series database:

[0164] In this embodiment, the time-series database is used to store real-time monitoring metrics of network operation, including CPU utilization, number of failed requests, and number of RRC connections. It provides alarm, service discovery, query interfaces, and batch data acquisition functions, enabling complex data analysis based on time series data to help operations personnel understand system performance and service quality. Here, the time-series data can be implemented using an open-source database, such as the Prometheus time-series database.

[0165] b. In-memory database:

[0166] In this embodiment, the in-memory database is used to store cell DOI (i.e., Cell DOI) and user equipment DOI (i.e., UEEDOI) data. Due to the high throughput and low latency characteristics of the independently configured in-memory database, it is very suitable for use in scenarios that require fast access and updates, such as real-time data management and querying.

[0167] c. Mirror storage:

[0168] In this embodiment, the image database is used to store and distribute RNF container images, supporting push and pull operations of images in the internal network, ensuring that the required network function instances can be quickly deployed and started when the service is expanded or reduced.

[0169] 3. PCF, or Decision Control Module

[0170] refer to Figure 4 As shown, the PCF (Policy and Control Function) module plays a crucial role in the service-oriented RAN system, responsible for generating network policy decisions based on DOI (Digital Object Instance) data, including data redirection and RNF (RAN Network Function) scheduling. The actual execution here takes place within the SSF.

[0171] (1) Functions and roles of PCF

[0172] Data redirection decision: PCF generates a data redirection strategy by analyzing the network status reflected in DO (Data Request). This strategy determines which RNF (Resource Request) the data flow should be routed to for processing based on network load, thereby optimizing network performance.

[0173] Optionally, for redirection strategies, if the load on RNF instance RA1 is too high, and a user in RA1 is making a request, the data can be redirected to RA2 (an instance with lower load). Redirection primarily depends on the number of user connections, memory usage, and network usage. Both memory and network usage can be used as criteria for decision-making.

[0174] RNF scheduling decisions: The PCF is also responsible for generating RNF scheduling policies, such as expanding, shrinking, or reallocating resources. Based on key indicators such as the number of RRC connected users, the PCF can dynamically adjust the number and distribution of RNF instances to ensure efficient network operation.

[0175] (2) Implementation of PCF

[0176] In this embodiment, since different policy algorithms may impose different requirements on the implementation of PCF, the PCF module can be implemented as a lightweight Go routine or as an independent process. This flexibility allows PCF to adapt to different network scenarios and needs. For example, depending on actual needs, it can be set as a process or as a lightweight Go routine.

[0177] Interface specification definition: A key aspect of PCF module design is the specification definition of its interfaces. Whether used as a Go routine or a standalone process, PCF needs to communicate efficiently with DOMF and SSF.

[0178] (3) Optimization of PCF algorithm prediction capability

[0179] S1: Data Collection and Preprocessing

[0180] Data collection: Collect key performance indicators (KPIs) from the Digital Object Management (DOMF) module, such as the number of user connections, traffic utilization, signal quality, etc.

[0181] Preprocessing: The collected data is cleaned, standardized, and normalized to improve the generalization ability of the algorithm.

[0182] S2: Feature Selection

[0183] Feature extraction: Statistical analysis (see (4) below for specific methods) was used to extract features from the processed data that have a significant impact on the prediction of rapid changes in user volume.

[0184] Feature engineering: Constructing new feature combinations to enhance the model's predictive power. Optionally, constructing new feature combinations can be done in the following ways:

[0185] I. Data Cleaning

[0186] Data cleaning is an important step in feature engineering. It involves detecting and processing missing, outlier, and duplicate values ​​in the data to ensure the accuracy and integrity of the data.

[0187] 1. Missing value handling: After detecting missing values, you can choose to delete rows or columns containing missing values, or fill them using the mean, median, mode, interpolation methods, etc.

[0188] 2. Outlier handling: Common outlier handling methods include deleting outliers, replacing outliers, truncation, scaling / normalization, and using statistical models or interpolation methods.

[0189] 3. Duplicate value handling: Identify and remove duplicate values ​​in the data to avoid negative impacts on model training.

[0190] II. Feature Scaling

[0191] Feature scaling is the process of scaling feature data proportionally to keep it within the same numerical range, which helps improve the stability and performance of the model.

[0192] 1. Min-Max Scaling: Scaling the feature value to a specified minimum and maximum value, typically between 0 and 1.

[0193] 2. Standardization: By subtracting the mean and dividing by the standard deviation, the characteristic values ​​are transformed into a standard normal distribution.

[0194] 3. Normalization: This also scales data to a fixed range, but it usually differs from minimum-maximum scaling. Normalization may involve more complex transformations, such as logarithmic transformations and exponential transformations.

[0195] III. Feature Coding

[0196] Feature encoding is the process of converting non-numerical features into numerical features so that machine learning algorithms can process them.

[0197] 1. One-Hot Encoding: Converts categorical features into multiple binary features, with one binary feature corresponding to each category.

[0198] 2. Label Encoding: Converts categorical features into continuous integer codes.

[0199] 3. Feature Hashing: This method maps features to a fixed range of integers using a hash function, thereby reducing the number of features and lowering storage costs.

[0200] IV. Feature Selection

[0201] Feature selection is to select the most representative or distinguishable features from the original feature set to reduce the data dimension and the number of features, thereby improving the computational efficiency.

[0202] 1. Filtering Method: Score each feature according to its divergence or correlation, and set a threshold or select the number of thresholds to be selected to screen features.

[0203] 2. Wrapper Method: Select features according to the objective function (such as prediction effect score), and select or exclude several features each time.

[0204] 3. Embedded Method: First use certain machine learning algorithms and models for training to obtain the weight coefficients of each feature, and select features according to the coefficients from large to small.

[0205] V. Feature Transformation

[0206] Feature transformation is to transform the original features to better meet the requirements of the model or extract more useful features.

[0207] 1. Polynomial Features: Generate new features by combining polynomials of the original features.

[0208] 2. Logarithmic Transformation: Perform logarithmic transformation on the feature values to improve the distribution characteristics of the data.

[0209] 3. Exponential Transformation: Perform exponential transformation on the feature values to adjust the scale of the data.

[0210] VI. Text Processing

[0211] Text processing is to convert text data into numerical features so that machine learning algorithms can process it.

[0212] 1. Word Segmentation: Split text data into words or phrases.

[0213] 2. Stop Word Removal: Remove common but meaningless words in the text, such as "de", "shi", etc.

[0214] 3. Bag of Words Representation: Represent the text as a vocabulary, where the occurrence times of each vocabulary are used as the feature values of that vocabulary.

[0215] 4. TF-IDF Representation: Consider the frequency of a vocabulary in the text and its inverse document frequency in the entire corpus to generate more accurate text features.

[0216] VII. Time Series Feature Extraction

[0217] Time series feature extraction is the process of extracting useful features from time series data for prediction or analysis.

[0218] 1. Lag Features: New features are generated by shifting time series data forward or backward by a certain time step.

[0219] 2. Moving average feature: Calculate the moving average of time series data to generate new features.

[0220] 3. Time series characteristics: Extract the periodicity, trend and other features of time series data.

[0221] VIII. Combination Characteristics

[0222] Combined features combine multiple features to generate new features, providing richer information.

[0223] 1. Feature crossover: Combining two or more features to generate new features.

[0224] 2. Feature merging: Combining multiple features, such as combining low-dimensional discrete features.

[0225] IX. Feature Dimensionality Reduction

[0226] Feature dimensionality reduction transforms a high-dimensional feature space into a low-dimensional feature space to reduce feature dimensionality and data complexity, thereby improving the training efficiency and generalization ability of the model.

[0227] 1. Principal Component Analysis (PCA): By projecting the data along the direction that maximizes the variance, the original data is transformed into a set of linearly independent representations across all dimensions.

[0228] 2. Linear Discriminant Analysis (LDA): Maps two parts of data onto a hyperplane, minimizing the covariance between samples of the same class and maximizing the center distance between sets of samples of different classes. It can be used for dimensionality reduction or supervised classification.

[0229] In summary, feature engineering algorithms and methods cover multiple aspects, including data cleaning, feature scaling, feature encoding, feature selection, feature transformation, text processing, time series feature extraction, feature combination, and feature dimensionality reduction. These algorithms and methods play a crucial role in machine learning and data analysis, helping to improve data representation, reveal hidden information, and enhance model stability and performance.

[0230] S3: Model Selection and Training

[0231] Algorithm selection: Select the LSTM algorithm suitable for time series forecasting and the XGBoost algorithm suitable for processing structured data.

[0232] Model Training: LSTM and XGBoost models were trained using historical data to predict rapid changes in user volume. It should be noted that these models can be used individually or in combination.

[0233] S4: Online Learning Mechanism

[0234] Real-time data stream: Continuously collect network performance metrics through real-time data streams for use in online learning.

[0235] Model fine-tuning: The model is fine-tuned using newly collected data to adapt to real-time changes in network conditions. One possible method for model fine-tuning is to first validate the newly collected data, setting a threshold t. If the accuracy is lower than t, the model is retrained using new data.

[0236] S5: Model Update Strategy

[0237] Regular updates: Set a fixed time period (such as weekly or monthly) to fully retrain the model.

[0238] Triggered updates: The model is updated immediately upon detecting a significant performance degradation or change in data distribution. Judgments regarding performance degradation can include: if the model's accuracy on the validation set falls below a manually set threshold t during the current validation, then retraining is performed.

[0239] S6: Model Evaluation and Validation

[0240] Performance evaluation: Use a validation set to evaluate the model's prediction accuracy and generalization ability. Alternatively, a threshold can be set for this evaluation.

[0241] Results Verification: The accuracy of the model's predictions was verified by comparing the results with actual user volume changes.

[0242] S7: Decision Generation

[0243] Decision logic: Based on the model prediction results, PCF generates corresponding scaling decisions. One implementation method here is: if the load (including network, memory, etc.) increases significantly within t minutes (a pre-set time parameter), an empty RNF instance is created in advance; or if the load decreases significantly, the load is checked after t minutes, triggering a scaling decision.

[0244] Strategy Optimization: Continuously optimize the scaling strategy based on the model's predictive performance and actual results. Here, the optimization method can be set as follows: If the predicted result is a significant increase in load, but this does not actually occur, collect load status data (including memory and network changes) during this period and retrain the model.

[0245] S8: Model Deployment and Monitoring

[0246] Model deployment: Deploy the trained model into PCF for real-time prediction and decision-making.

[0247] Performance monitoring: Continuously monitor the model's performance in actual operation to ensure its stability and accuracy.

[0248] S9: Feedback Loop

[0249] Feedback collection: Collect the difference between the model's predicted results and the actual changes in user volume.

[0250] Model iteration: Using feedback to iteratively improve the model in order to increase the accuracy of future predictions.

[0251] (4) Statistical analysis methods

[0252] It should be noted that the following statistical analysis method is a sequential process. For example, first, the method in S1 is used to calculate key indicators, such as the mean and median. Then, the results of S1 and the method in S2 are used for statistical analysis, and the calculation continues in sequence. The statistical data of the next step is the statistical result of the previous step.

[0253] S1: Descriptive Statistical Analysis

[0254] Objective: To gain a basic understanding of the data, including central tendency (mean, median), dispersion (variance, standard deviation), and distribution shape (skewness, kurtosis).

[0255] Application: Identifying outliers and basic data distribution characteristics in data provides a foundation for further analysis. Here, identification refers to recognizing the central tendency (mean, median), dispersion (variance, standard deviation), and distribution shape (skewness, kurtosis), etc.

[0256] S2: Correlation Analysis

[0257] Method: Calculate the correlation coefficients between different indicators (such as Pearson correlation coefficient and Spearman rank correlation coefficient).

[0258] Application: Identifying which metrics are strongly correlated with changes in user volume, thus serving as potential features.

[0259] S3: Principal Component Analysis (PCA)

[0260] Principal component analysis is used to extract the main components from multiple related variables and input them into the new feature model, thereby achieving dimensionality reduction of the data and focusing only on important features.

[0261] S4: Change Point Detection

[0262] Methods: Statistical process control charts (such as CUSUM) and mutation point analysis.

[0263] Application: Identify key turning points in user volume changes as event-driven triggering features.

[0264] S5: Feature Selection

[0265] Method: The model performance is optimized by selecting the most influential feature subset from a large number of features. The selection can be achieved through methods such as recursive feature elimination (RFE) and model-based feature selection (such as feature importance using tree models).

[0266] S6: Using LSTM for prediction

[0267] This yields a curve that changes over time, with the x-axis representing time and the y-axis representing load. This allows us to predict the load over a future period, including memory load and network load.

[0268] (5) PCF communication settings

[0269] Internal PCF Communication: For PCFs built into the system, communication between modules is mainly achieved through Go Channels. The PCF receives DOI data from the DOMF and passes the generated network policy to the SSF via the Channel. This channel-based communication method features low latency and high efficiency, making it ideal for operations with high real-time requirements.

[0270] External PCF Communication: For PCFs running on external systems or in different processes, communication is achieved via the HTTP protocol. The PCF retrieves DOI data from the DOMF via HTTP and sends the generated policy to the SSF through the HTTP interface. This design ensures the system's flexibility and scalability, allowing the PCF to be deployed and run in different environments.

[0271] (6) Setting the relationship between PCF and other modules

[0272] Input and Output: PCF's input is DOI data from DOMF, which reflects the current network status, such as the number of users and traffic load. Based on this data, PCF generates corresponding network adjustment strategies, including RNF scaling and load balancing.

[0273] Communication relationships: The communication relationships between PCF and DOMF / SSF modules are as follows: Figure 4 As shown, the built-in PCF communicates with DOMF and SSF via a channel to ensure fast data transmission. The external PCF, on the other hand, communicates with DOMF and SSF via an HTTP interface.

[0274] (7) PCF Strategy Generation

[0275] In this embodiment, the strategies for PCF generation mainly include the following two:

[0276] RRC Connection Management: PCF generates scaling strategies for managing RNFs based on key metrics such as the number of RRC connected users. When the number of users for a particular RNF exceeds or falls below a preset threshold, PCF triggers scaling operations to ensure continuous optimization of the user experience. Key metrics here include network load, memory load, ambient temperature, and server temperature.

[0277] Load balancing: PCF can also generate load balancing strategies based on network load conditions, and distribute traffic reasonably to multiple RNF instances to avoid single point of overload.

[0278] 4. SSF, or Service Scheduling Module

[0279] Combination Figure 5 As shown, the SSF (Service Scheduling Function) module is responsible for scheduling RNF (RAN Network Function) instances in the service-oriented RAN system and dynamically adjusting service policies according to network requirements. The SSF is designed based on the Kubernetes framework, enabling flexible resource management and task scheduling to ensure efficient network operation.

[0280] (1) Functions and roles of SSF

[0281] RNF Scheduling: The SSF, based on the policy generated by the PCF, is responsible for scaling out and scaling in RNF instances. This function ensures that instances are automatically scaled up to meet demand when network traffic increases, and scaled down to save resources when traffic decreases. The scaling process is as follows:

[0282] S4: Expansion process:

[0283] S4-1: Upon receiving the scaling instruction, the Service Scheduling Module (SSF) starts a container for a new service instance on the corresponding server according to the instructions of the PCF.

[0284] S4-2: After a new service instance starts, SSF sends a service registration request to the service management module to ensure that the new service instance can be discovered and used by other components in the system.

[0285] S5: Volume reduction process:

[0286] S5-1: Upon receiving a scaling-down instruction, the Service Scheduling Module (SSF) terminates the specified service instance according to the instructions from the PCF.

[0287] S5-2: SSF then sends a service registration request to the service management module to ensure that the terminated service instance is correctly removed from the system.

[0288] Service Policy Configuration: SSF is also responsible for configuring service policies, including the redirection of user access requests. Through decisions provided by PCF, SSF can dynamically allocate user access requests to the most suitable RNF instance, thereby optimizing user experience and network performance. For dynamic allocation, RNF instances contain priority tags; new requests are preferentially assigned to higher-priority instances.

[0289] The execution methods for redirection include, but are not limited to, the following:

[0290] 1. Server-side redirection: Redirection can be handled in server-side code by setting relevant status codes and redirect URLs in the response. For example, redirection rules can be set in the web server configuration file, or redirection logic can be written in server-side scripts (such as PHP, Java, etc.).

[0291] 2. Client-side redirection: Redirection can be handled in client-side code using the browser's redirection API or JavaScript. For example, the JavaScript `window.location.href` property can be used to set a new URL, thus achieving a redirect.

[0292] 3. Proxy Redirection: Redirection is handled within the proxy server, which is configured with relevant rules and redirection logic. This approach is typically used in scenarios such as load balancing and content delivery networks (CDNs).

[0293] (2) Kubernetes-based implementation

[0294] Kubernetes Framework: SSF's service scheduling and configuration functions are implemented based on the Kubernetes framework, which enables automated management of application deployment, scaling and operation, ensuring system stability and elasticity.

[0295] Automated scheduling: SSF automatically adjusts the number and distribution of RNF instances according to PCF's policies. This automated scheduling enables the system to respond flexibly under different load conditions, maintaining high network availability.

[0296] SSF dynamically adjusts RNF instances based on pre-defined policies in PCF. For example, policies can be set in PCF as follows:

[0297] Control the network load of all RNF instances to t%, and do not allow any RNF instance to have a network load higher than t%, where t is a manually set hyperparameter. Then:

[0298] S1: Retrieve a list of current RNF instances, denoted as R1, R2...Rn, and check the network load of all instances.

[0299] S2: Divide instances with a percentage higher than t% into RA1, RA2...RAk, and instances with a percentage lower than t% into RB1, RB2...RBm.

[0300] S3: Divide a portion of the user requests on RA1 into the remaining requests, which need to be redistributed, while the rest continue on RA1.

[0301] S3: Redistribute the remaining requests in RA1 to RB1. If the load on RB1 reaches t% during the redistribution process, the redistribution of RB1 is considered complete. At this point, the remaining unallocated requests in RA1 are redistributed to RB2, and so on. When all remaining requests in RA1 have been redistributed, RA1 is considered to have completed its adjustment.

[0302] S4: Perform this operation on all instances. There are two possible scenarios.

[0303] S4-1: If there exists a Rai, i∈(1,k) with remaining unassigned requests, create a new RC1 and assign the remaining requests to RC1. If the load of RC1 reaches t%, and there are still unassigned requests, create RC2, and so on, until all remaining requests are assigned.

[0304] S4-2: If all remaining requests in RAi,i∈(1,k) are fully allocated, and there are still RBj…RBm,j∈(1,k) whose load has not reached t%, then the priority of allocating new requests to RBj…RBm,j∈(1,k) is increased. That is, when there are new requests, they are preferentially allocated to RBj…RBm,j∈(1,k).

[0305] S4-3: If there exists RBj…RBm, j∈(1,k), and the load is below the threshold p%, where p is a manually set hyperparameter, then all requests in this instance are moved to a higher priority instance. After the redirection is completed, this instance is deregistered.

[0306] (3) SSF module design

[0307] RNF scaling management: SSF manages the scaling of RNF instances through the Kubernetes API according to the PCF policy. When the PCF detects that the load on an RNF instance is too high, the SSF will trigger a scaling operation to add new RNF instances to share the load; conversely, when the load decreases, the SSF will trigger a scaling operation to release excess resources.

[0308] User Request Redirection: SSF also manages the redirection of user access requests. Based on the policies provided by PCF, SSF can dynamically distribute new user access requests to RNF instances with lighter loads or those better suited for handling, ensuring balanced and stable network services.

[0309] The dynamic allocation method can be set as follows:

[0310] S1. Detect the current RNF instance;

[0311] S2. Sort the load of RNF instances;

[0312] S3. Assign new user access requests to the RNF instance with the lowest load.

[0313] (4) Interaction between SSF and other modules

[0314] Interaction with PCF: SSF communicates with PCF via a channel or HTTP interface. PCF passes the generated policies to SSF, which then performs specific scheduling and configuration operations based on these policies.

[0315] Integration with Kubernetes: SSF interacts with the Kubernetes framework through the Kubernetes API to enable dynamic management of RNF instances. This integration allows SSF to automate complex service scheduling tasks.

[0316] Furthermore, in this embodiment, SSF encapsulates RNF instances as containers and performs automated scaling and management. Containerization technology enables the system to manage applications more flexibly, while providing better isolation and portability.

[0317] Meanwhile, SSF dynamically adjusts the allocation of user requests based on service discovery and load balancing mechanisms. By monitoring the system's operational status, SSF can promptly distribute the load to appropriate RNF instances, thereby improving the overall efficiency of the system.

[0318] IV. System Execution Process

[0319] The execution process of the system will be described in detail below with reference to this embodiment.

[0320] Based on the above description of the system modules in this embodiment, the scaling control process of this solution will be explained. The overall execution process is as follows:

[0321] S1: After service instantiation, the service instance reports its key metrics data to the Digital Object Management module (DOMF). This data reflects the instance's running status and performance.

[0322] Key metrics data include, but are not limited to:

[0323] 1.RSRP (Reference Signal Received Power):

[0324] Definition: Reference signal received power, which represents the power of the downlink reference signal received by the user equipment (UE) from the serving cell.

[0325] Importance: Used to assess network coverage quality; the higher the RSRP value, the better the network coverage.

[0326] 2.RSRQ (Reference Signal Received Quality):

[0327] Definition: Reference signal reception quality is the ratio of RSRP to the total received power, reflecting the quality of the signal.

[0328] Importance: Used to measure signal quality, it is crucial for optimizing network performance and improving user experience.

[0329] 3.SINR (Signal to Interference plus Noise Ratio):

[0330] Definition: Signal-to-interference-plus-noise ratio (SNR) represents the ratio of the useful signal power to the sum of the interference and noise power.

[0331] Importance: Used to evaluate the communication quality of user equipment; a high SINR value means better communication quality.

[0332] 4. Cell load:

[0333] Definition: Represents the number of users or the volume of services currently being handled by the community.

[0334] Importance: Used to monitor network capacity and load balancing to prevent service quality degradation caused by overload.

[0335] S2: DOMF periodically pushes the collected key performance indicator (KPI) data to the decision control module (PCF). PCF analyzes this KPI data to determine whether it is necessary to expand or shrink service instances.

[0336] S3: Based on the analysis results, PCF generates scaling decisions for service instances. If instance scaling is required, PCF sends scaling instructions to the Service Scheduling Module (SSF) and executes the scaling operation.

[0337] S4: Expansion process:

[0338] S4-1: Upon receiving the scaling instruction, the Service Scheduling Module (SSF) starts a container for a new service instance on the corresponding server according to the instructions of the PCF.

[0339] S4-2: After a new service instance starts, SSF sends a service registration request to the service scheduling module to ensure that the new service instance can be discovered and used by other components in the system.

[0340] S5: Volume reduction process:

[0341] S5-1: Upon receiving a scaling-down instruction, the Service Scheduling Module (SSF) terminates the specified service instance according to the instructions from the PCF.

[0342] S5-2: SSF then sends a service registration request to the service management module to ensure that the terminated service instance is correctly removed from the system.

[0343] During system execution, we will elaborate on the key processes involved.

[0344] 1. RNF DOI creation process

[0345] S1: RNF sends a request to the Digital Object Management Function (DOMF) to create a Digital Object Instance (DOI). The request includes custom metric data and the URI for retrieving this data.

[0346] S2: After receiving a request, DOMF creates a DOI in the corresponding database based on the Numeric Object Template (DOT) in the request and assigns a unique DOI ID.

[0347] S3: DOMF periodically retrieves RNF metric data based on the URI in the DOI and stores this data in the Prometheus database for subsequent monitoring and analysis.

[0348] 2. RNF indicator collection process

[0349] S1: DOMF periodically retrieves RNF metric data via a predefined URI.

[0350] S2: RNF receives a request from DOMF.

[0351] S3: RNF responds to DOMF's requests, providing current metric data.

[0352] S4: DOMF stores the collected indicator data into the Prometheus database and uses it for subsequent decision analysis in PCF.

[0353] 3. RNF scaling and configuration process

[0354] S1: PCF sends a request to DOMF to obtain RNF metric data.

[0355] S2: DOMF queries the Prometheus database for relevant RNF metric data via PromSQL.

[0356] S3: Prometheus returns the query results to DOMF.

[0357] S4: DOMF returns the RNF metrics data to PCF.

[0358] S5: PCF generates scaling and configuration requests based on the acquired RNF metric data and sends them to DOMF.

[0359] S6: DOMF forwards the configuration request to SSF, and SSF performs service configuration through the Kubernetes API Server.

[0360] S7: Finally, DOMF returns the operation results to PCF.

[0361] 4. Security Protection Mechanism

[0362] S1: Define data transmission security objectives

[0363] The objective is clear: to ensure that all data transmitted through the API Server meets the standards of confidentiality, integrity, availability, and authentication.

[0364] Architecture integration: The API Server design incorporates a security module responsible for handling the security of all incoming and outgoing data.

[0365] S2: Selecting and developing secure transmission protocols

[0366] Protocol Customization: Configure the API Server with the TLS 1.3 protocol to ensure that all external communication uses this protocol.

[0367] Certificate Management: Manage the lifecycle of TLS certificates through automated tools, including issuance, renewal, and revocation.

[0368] S3: Implement data encryption

[0369] Encryption strategy: AES-256 encryption algorithm is used for data transmission between DOMF and PCF / SSF to ensure data security within the internal network.

[0370] Key management: Use a hardware security module (HSM) to securely generate, store, and distribute encryption keys.

[0371] S4: Data Integrity Verification

[0372] Hash verification: The transmitted data packets are signed using the SHA-256 hash function to ensure that the data has not been tampered with during transmission.

[0373] Signature Implementation: ECDSA is used for digital signatures during data transmission to verify the source and integrity of the data.

[0374] S5: Establish a secure data transmission channel

[0375] VPN Deployment: For data transmission across public networks, deploy an IPsec VPN tunnel to provide an additional layer of security for the data.

[0376] Network isolation: Isolating sensitive data transmission paths from other network traffic at the physical or virtual level.

[0377] S6: Anomaly Detection and Response

[0378] IDS / IPS: Deploy intrusion detection systems (IDS) and intrusion prevention systems (IPS) at the network boundary to identify and prevent potential attacks.

[0379] Response Mechanism: Establish a rapid response mechanism to immediately activate the emergency plan once an anomaly or security incident is detected.

[0380] 5. Fault recovery and fault tolerance mechanisms

[0381] S1: Define the fault detection strategy

[0382] Real-time monitoring: Implement real-time monitoring in API Server, DOMF, and SSF to track service status and performance metrics in real time.

[0383] Fault indicators: Define fault detection indicators, such as service response timeout, increased error rate, abnormal resource utilization, etc.

[0384] S2: Implement fault detection mechanism

[0385] Health checks: Regular health checks are performed on service instances, including liveness detection and readiness detection.

[0386] Anomaly Reporting: Once an anomaly is detected, it should be reported to the PCF immediately, triggering the fault assessment process.

[0387] S3: Fault Assessment and Classification

[0388] Fault Analysis: PCF analyzes the received fault reports to determine the fault type and scope of impact.

[0389] Fault Classification: Faults are classified according to their severity and urgency in order to determine the appropriate response strategy.

[0390] S4: Implementation of Fault Tolerance Mechanism

[0391] Redundant deployment: Deploy copies of service instances on different physical or virtual nodes to ensure that a single point of failure will not cause a complete service interruption.

[0392] Failover: Configure a failover mechanism so that when the primary service instance fails, requests are automatically redirected to the standby instance.

[0393] S5: Automatic Fault Recovery Process

[0394] Fast failover: For critical services (such as PCF), implement fast failover replicas.

[0395] Service restart: For non-critical failures, attempt to automatically restart the service instance to restore normal service.

[0396] S6: Data Backup and Recovery

[0397] Regular backups: Regularly back up critical data, including configuration files, databases, and important logs.

[0398] Fast recovery: When a service instance fails, data and state can be quickly restored from backups, reducing data loss and service interruption time.

[0399] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0400] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A service-oriented RAN protocol stack dynamic expansion and contraction system, characterized in that: The system comprises: A digital object management module is used to regularly push the received key performance indicators to the decision control module; The decision control module is used to determine whether the service instance needs to be expanded or reduced based on the key performance indicators, and to generate an expansion instruction or a reduction instruction and send it to the service scheduling module; A service scheduling module, used to expand or shrink a service instance based on the expansion instruction or shrink instruction sent by the decision control module; API server module, serving as the unified external interface of the system, for data interaction between the external RAN network and the system, and data interaction between modules within the system; Database module, used to store system data.

2. The system according to claim 1, characterized in that The digital object management module includes a digital object center submodule, which is responsible for the creation, deletion, update and query of digital objects, and stores the relevant data of digital objects into the database module; The decision control module is also used to generate a service scheduling strategy and a scaling control strategy, and the service scheduling strategy and the scaling control strategy communicate with the service scheduling module through the API server module.

3. The system according to claim 1, characterized in that The service scheduling module is also responsible for starting or terminating service instances in the system.

4. The system according to claim 2, characterized in that In the API server module, each URI corresponds to a callback function. When the API server module receives an HTTP request for a certain URI, the callback function corresponding to the URI is called to parse the data in the HTTP request, and the parsed data in the HTTP request is sent to the corresponding module through the channel; When the corresponding module completes the processing, the processing result is sent back to the API server module through another channel; When each module in the system communicates with the outside, the API server module directly calls the HTTP client function to complete the communication of the system with the outside.

5. The system according to claim 2, characterized in that When a request is made to create a digital object, the digital object center submodule creates a corresponding digital object instance in the database module according to the digital object template included in the request, and assigns a unique digital object instance ID; The digital object center submodule is also used for pushing digital objects, so as to push digital object instances or digital object instance updates that have subscribed to a digital object to subscribed functional entities.

6. The system according to claim 2, characterized in that The digital object management module is also used for event monitoring, and the specific implementation method is as follows: Based on the features related to major events in historical data, the prediction model M1 is trained to predict the changes in user volume caused by major events; and predicting changes in the amount of users based on the features related to the major events collected in real time; Compare the predicted user volume change with the threshold and verify the accuracy of the predicted results; When the accuracy requirement is met, the capacity expansion or contraction decision of the decision control module is triggered, and the capacity expansion or contraction is executed through the service scheduling module; The digital object management module evaluates the effect of expansion or contraction, records predicted events, actual events and corresponding processing actions, and feeds back the processing results to the prediction model M1.

7. The system according to claim 1, characterized in that The database module includes: The time series database submodule is used to store real-time monitoring indicator data of network operation, including CPU usage, number of request failures, and number of RRC connections; The memory database submodule is used to store Cell DOI data and UE DOI data; The image storage submodule is used to store and distribute container images of RAN network functions.

8. The system according to claim 2, characterized in that The decision control module generates a service scheduling strategy and a scaling control strategy, which are obtained through a user volume prediction model, specifically including: Collect key performance indicators from the digital object management module and perform preprocessing; extract features that have a significant impact on predicting rapid changes in user volume from the preprocessed data through statistical analysis; obtain user volume change prediction results through the trained user volume prediction model; generate expansion strategy or reduction strategy based on the user volume change prediction results; The user volume prediction model is deployed in the decision control module; the user volume prediction model is composed of an LSTM model and an XGBoost model; when the performance of the user volume prediction model decreases or the distribution of feature data changes, the update of the user volume prediction model is triggered.

9. The system according to claim 1, characterized in that The decision control module communicates with the digital object management module and the service scheduling module inside the system through a channel; the decision control module communicates with the digital object management module and the service scheduling module outside the system through an HTTP interface.

10. A method for dynamic expansion and contraction of a service-oriented RAN protocol stack, characterized in that: The method is performed by the service-oriented RAN protocol stack dynamic expansion and contraction system according to any one of claims 1 to 9, and the method includes: S1: After the service is instantiated, the service instance reports key indicator data to the digital object management module; S2: The digital object management module regularly pushes the collected key indicator data to the decision control module; the decision control module determines whether the service instance needs to be expanded or reduced based on the key indicator data; S3: The decision control module generates an expansion strategy or a reduction strategy for the service instance according to the judgment result; if an expansion or reduction operation is required, the decision control module sends an expansion instruction or a reduction instruction to the service scheduling module, and the service scheduling module executes the expansion or reduction operation; The expansion process is as follows: S3-1: After receiving the expansion instruction, the service scheduling module starts a container of a new service instance on the corresponding server according to the expansion instruction of the decision control module; S3-2: After the new service instance is started, the service scheduling module initiates a service registration request; The shrinking process is as follows: S3-3: After receiving the scaling-down instruction, the service scheduling module terminates the specified service instance according to the scaling-down instruction of the decision control module; S5-2: The service scheduling module then initiates a service registration request to ensure that the terminated service instance is correctly removed from the system.

Images