A service-oriented radio access network

Abstract

The application discloses a service-oriented radio access network, comprising: an infrastructure layer for providing physical resources; a virtualization layer divided into a first control plane and a first MANO plane for managing virtualized physical resources and realizing sharing and isolation of the physical resources in the infrastructure layer; a function layer divided into a second control plane and a second MANO plane for configuring and deploying communication resources; and an application layer divided into a third control plane and a third MANO plane for realizing service requirements of terminals accessing the radio access network; the service-oriented radio access network is divided into a control plane, a MANO plane and a user plane, the infrastructure layer is divided into the user plane, the control plane comprises the first, second and third control planes, the MANO plane comprises the first, second and third MANO planes, and a "four-layer three-plane" service-oriented radio access network is formed, so that the RAN is more open, the response speed of the radio access network is improved, the signaling overhead and the configuration resource command execution delay are reduced, and the compiling and image packaging delay are reduced.

Description

Technical Field

[0001] This invention belongs to the field of communication technology, and specifically relates to a service-oriented wireless access network. Background Technology

[0002] Currently, research on service-oriented architecture mainly includes SDN (Software Defined Network) and NFV (Network Function Virtualization) technologies. The main idea of ​​SDN is to break the monolithic, closed architecture by separating the network's control logic from the underlying routing of forwarding traffic. Because the control logic is implemented in a logically centralized control plane, network programmability is introduced through open control plane access, enabling rapid policy execution, network reconfiguration and evolution, and simplifying network management. NFV technology separates the physical network from the software functions running on it. This means that network element functions can run as ordinary software on general-purpose physical servers or switches. These servers and switches can be deployed in data centers, distributed network nodes, or locations close to end users without the need to purchase specialized hardware.

[0003] A major reason for the rigidity of traditional communication network architecture is the proliferation of massive and ever-growing proprietary communication equipment and dedicated network elements in today's networks. While this brings high reliability and performance, it also leads to the integration of network hardware and software. This closed architecture prevents resource sharing and makes it difficult to integrate various services, thus making it increasingly difficult to introduce new services into today's networks. It is evident that future networks need to provide diverse network services with varying quality of service guarantees, but the current RAN (Radio Access Network) is tightly coupled and uses dedicated hardware, resulting in poor network flexibility and scalability. Summary of the Invention

[0004] To address the aforementioned problems in the existing technology, this invention provides a service-oriented wireless access network. The technical problem to be solved by this invention is achieved through the following technical solution:

[0005] This invention provides a service-oriented wireless access network, comprising:

[0006] The underlying infrastructure layer provides the necessary physical resources for the wireless access network, including computing resources, caching resources, and communication resources.

[0007] The virtualization layer is used to manage the virtualized computing resources, cache resources, and communication resources, and to realize the sharing and isolation of physical resources in the infrastructure layer through interfaces; the virtualization layer is divided into a first control plane and a first management and orchestration plane.

[0008] The functional layer is used to configure and deploy the communication resources of the wireless access network; the functional layer is divided into a second control plane and a second MANO plane.

[0009] The application layer is used to implement the service requirements of terminals accessing the wireless access network; the application layer is divided into a third control plane and a third MANO plane.

[0010] The service-oriented radio access network is divided into a control plane, a MANO plane, and a user plane. The infrastructure layer is divided into a user plane. The control plane includes a first control plane, a second control plane, and a third control plane. The MANO plane includes a first MANO plane, a second MANO plane, and a third MANO plane. The control plane is used to control and manage infrastructure resources and provide customized radio access network services to users. The MANO plane is used to manage and orchestrate the infrastructure resources, NG interfaces, and applications. The user plane is used to provide the necessary physical resources for the radio access network and forward user data.

[0011] In one embodiment of the present invention, the computing resources include a central processing unit;

[0012] The cache resources include internal memory and external memory, wherein the internal memory includes random access memory (RAM) and read-only memory (ROM), and the external memory includes hard disk drive (HDD) and solid-state drive (SSD).

[0013] The communication resources include radio frequency remote heads for evolved NBs (eNBs) and next-generation gNBs (gNBs).

[0014] In one embodiment of the present invention, the radio frequency remote head includes a radio frequency module and an antenna, and the radio frequency remote head is used to forward user data in the form of radio frequency signals.

[0015] In one embodiment of the present invention, the first control plane includes Docker Engine, the first MANO plane includes a virtualization infrastructure manager, and the virtualization infrastructure manager includes a virtual machine management platform and a container management platform.

[0016] In one embodiment of the present invention, the second control plane includes multiple independent network element functions obtained by decoupling from the control service function of the radio access network. The multiple independent network element functions are connected through a service interface (SBI) and communicate based on the hypertext transfer protocol (HTTP).

[0017] The second MANO surface includes MANO units with multiple network element functions.

[0018] In one embodiment of the present invention, the third control plane includes various service requirements, and the third MANO plane includes multiple MANO units of wireless access networks.

[0019] In one embodiment of the present invention, the service requirements include: enhanced mobile broadband type, ultra-reliable low latency type, and massive machine-type communication type.

[0020] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0021] The service-oriented radio access network (RAN) provided by this invention includes an infrastructure layer, a virtualization layer, a functional layer, and an application layer, further divided into a control plane, a MANO plane, and a user plane. Specifically, the infrastructure layer is divided into a user plane, the virtualization layer into a first control plane and a first MANO plane, the functional layer into a second control plane and a second MANO plane, and the application layer into a third control plane and a third MANO plane. The control plane includes the first, second, and third control planes, and the MANO plane includes the first, second, and third MANO planes, forming a "four-layer, three-plane" service-oriented RAN. Based on service-oriented and microservice principles, the network functions of the control plane and functional layers are loosely coupled, making the RAN more open. Furthermore, the RAN system management and orchestration are implemented based on technologies such as Docker and Kubernetes. Predefined templates are used to instantiate the system, and a microservice-based RAN configuration process is designed in detail, including base station configuration and resource allocation configuration processes, enabling on-demand configuration of the wireless network. Compared to non-service-oriented radio access networks, the service-oriented radio access network architecture of this invention can improve the response speed of system control services, reduce signaling overhead and configuration resource command execution latency, and reduce compilation and image packaging latency.

[0022] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of an architecture of a service-oriented wireless access network provided in an embodiment of the present invention;

[0024] Figure 2 This is a schematic diagram of the second control plane based on microservices provided in an embodiment of the present invention;

[0025] Figure 3 This is a schematic diagram of a network element function provided in an embodiment of the present invention;

[0026] Figure 4 This is another schematic diagram of the network element function provided in the embodiment of the present invention;

[0027] Figure 5This is another schematic diagram of the network element function provided in the embodiment of the present invention;

[0028] Figure 6 This is another schematic diagram of the network element function provided in the embodiment of the present invention;

[0029] Figure 7 This is a comparison chart of compilation and packaging times for adding power adjustment function according to an embodiment of the present invention;

[0030] Figure 8 This is a comparison chart of the execution time of the configuration resource command provided in the embodiments of the present invention. Detailed Implementation

[0031] The present invention will be further described in detail below with reference to specific embodiments, but the implementation of the present invention is not limited thereto.

[0032] Figure 1 This is a schematic diagram of an architecture for a service-oriented wireless access network provided in an embodiment of the present invention. For example... Figure 1 As shown, an embodiment of the present invention provides a service-oriented wireless access network, including:

[0033] The underlying infrastructure layer provides the necessary physical resources for the wireless access network, including computing resources, caching resources, and communication resources.

[0034] The virtualization layer is used to manage the virtualized computing resources, cache resources, and communication resources, and to realize the sharing and isolation of physical resources in the infrastructure layer through interfaces; the virtualization layer is divided into a first control plane and a first management and orchestration plane.

[0035] The functional layer is used to configure and deploy the communication resources of the wireless access network; the functional layer is divided into a second control plane and a second MANO plane.

[0036] The application layer is used to implement the service requirements of terminals accessing the wireless access network; the application layer is divided into a third control plane and a third MANO plane.

[0037] The service-oriented radio access network is divided into a control plane, a MANO plane, and a user plane. The infrastructure layer is divided into a user plane. The control plane includes a first control plane, a second control plane, and a third control plane. The MANO plane includes a first MANO plane, a second MANO plane, and a third MANO plane. The control plane is used to control and manage infrastructure resources and provide customized radio access network services to users. The MANO plane is used to manage and orchestrate the infrastructure resources, NG interfaces, and applications. The user plane is used to provide the necessary physical resources for the radio access network and forward user data.

[0038] Specifically, in the aforementioned service-oriented radio access network, the infrastructure layer is at the bottom, providing the necessary physical resources such as computing, caching, and communication resources for the radio access network. These physical resources provide the necessary resources and basic environment for the operation of the upper-layer network functions. Optionally, computing resources include CPU (Central Processing Unit); caching resources consist of internal and external memory. Internal memory includes RAM (Random Access Memory) and ROM (Read Only Memory), mainly providing high-speed caching for the upper-layer network functions, namely the virtualization layer, functional layer, and application layer. External memory includes HDD (Hard Disk Drive) and SSD (Solid State Drive), used to store the system files and database data of the radio access network; communication resources include the RRH (Radio Remote Head) of eNB (E-UTRAN NodeB) and gNB (thenext Generation NodeB). The RRH includes a radio frequency module and an antenna, used to forward user data in the form of radio frequency signals.

[0039] Furthermore, the virtualization layer virtualizes and manages computing, caching, and communication resources. These virtualized resources can be allocated and used on demand according to the application. Figure 1 The interface shown enables the sharing and isolation of physical resources at the infrastructure layer. The functional layer is mainly used to control the configuration and deployment of the wireless access network, and to provide customized wireless network services for application layer control applications.

[0040] In the service-oriented wireless access network provided by this invention Figure 1The virtualization layer in the horizontal direction, as shown, can be divided into a first control plane and a first MANO (Management and Orchestration) plane. Specifically, the first control plane includes Docker Engine. Docker technology is a lightweight virtualization that can run multiple containers based on process isolation to achieve resource virtualization and isolation. It can run on a host operating system or a virtual machine. The first MANO plane includes VIM (Virtualized Infrastructure Manager). The Virtualized Infrastructure Manager includes a virtual machine management platform and a container management platform. This embodiment uses Kubernetes to implement Docker container lifecycle management, enabling management of container resource usage and automatic load balancing.

[0041] It should be noted that in some other embodiments of this application, the first control plane may also include a VMM (Virtual Machine Monitor) and a VM (Virtual Machine). The virtual machine monitor can run directly on the hardware or the host operating system to provide an operating system for the VM to run. The VM virtualizes and isolates resources by creating virtualized operating systems to create multiple virtual servers.

[0042] Please continue reading Figure 1 The functional layer can be divided into a second control plane and a second MANO plane. The second control plane includes multiple independent network element functions obtained by decoupling the control service functions of the wireless access network. These multiple independent network element functions are connected through a service-based interface (SBI) and communicate based on the Hypertext Transfer Protocol (HTTP). The second MANO plane includes MANO units of multiple network element functions.

[0043] In this embodiment, the second control plane decouples the centralized radio access network control services into independent NFs (Network Functions), including policy configuration, QoS analysis, radio resource control, and status monitoring. NFs communicate with each other using HTTP (Hypertext Transfer Protocol). NFs can be freely combined to provide customized services, and are instantiated on demand when the corresponding NF function is needed. Figure 1The upward-facing interface provides network configurations and physical resource combinations to meet different application requirements. Furthermore, the MANO units of multiple network element functions in the second MANO plane are used to manage and orchestrate the NFs of the first control plane. Since NFs can run in different physical locations, the MANO units of network element functions are also used to manage the physical host resources deployed on the virtualization platform and the networks they connect to.

[0044] Please continue reading Figure 1 The application layer can be divided into the third control plane and the third MANO plane. The third control plane includes various service requirements, such as eMBB (enhanced Mobile Broadband), URLLC (Ultra-Reliable and Low Latency Communication), and mMTC (massive Machine Type Communication). The application layer abstracts the on-demand deployment and configuration process of NF for users, deploying and configuring NF by calling application. The third MANO plane includes multiple MANO units of the radio access network, which are used to manage and orchestrate RAN application services to ensure their normal operation.

[0045] It can be seen that, in Figure 1 In the vertical direction shown, the service-oriented radio access network (RAN) provided by this invention is divided into a control plane, a MANO plane, and a user plane. The infrastructure layer is divided into the user plane, the control plane includes a first control plane, a second control plane, and a third control plane, and the MANO plane includes a first MANO plane, a second MANO plane, and a third MANO plane, forming a "four-layer, three-plane" service-oriented RAN. Based on service-oriented and microservice principles, the control plane functional layer features loosely coupled network functions, making the RAN more open. Furthermore, RAN system management and orchestration are implemented using technologies such as Docker and Kubernetes. Predefined templates are used to instantiate the system, and a detailed microservice-based RAN configuration process is designed, including base station configuration and resource allocation configuration processes, enabling on-demand configuration of the wireless network. Compared to non-service-oriented RANs, the service-oriented RAN architecture of this invention can improve system control service response speed, reduce signaling overhead and configuration resource command execution latency, and reduce compilation and image packaging latency.

[0046] Figure 2 This is a schematic diagram of the second control plane based on microservices provided in an embodiment of the present invention. Figure 3-6 This is a schematic diagram of a network element function provided in an embodiment of the present invention. For example... Figure 2-6 As shown in the embodiments of the present invention, the functions of each network element are further described.

[0047] (1)SMF (Status Monitoring Function)

[0048] Please see Figure 3 To support real-time online updates of RAN configuration, the control plane needs to continuously acquire RAN status information and operation logs. Administrators can use this function to view the RAN network topology and resource usage, analyze whether the RAN configuration needs to be updated, and adjust resource configuration according to changes in user needs, thereby better meeting user requirements.

[0049] The SMF internally contains a Radio Access Network Information Library (RIB). After the RAN user plane is deployed, it maintains communication with the SMF, periodically acquiring RAN user plane information and updating the RIB data. The RIB is updated only by the SMF. While the SMF updates the RAN user plane configuration, it does not directly change the base station configuration information in the RIB. Instead, it updates the data during periodic interactions between the RAN-U (RAN user plane) and the RIB after the RAN configuration application is successful. This approach ensures the independence of the SMF and prevents errors in the RIB information due to failed RCF configuration update commands.

[0050] Specifically, the SMF first listens for information requests on a designated port and exposes this port both inside and outside the Kubernetes cluster. When the SMF receives a corresponding HTTP GET request, it parses the request carried in the Uniform Resource Locator (URL). The URL format is http: / / IP:PORT / stats / enb / :id / :type?, where IP:PORT represents the IP address of the Docker container where the SMF is located and the port number it is listening on, id represents the base station ID for obtaining information, and type represents the type of information to be obtained. Then, it accesses the RIB to obtain the requested information, converts the obtained request information into JSON format, and returns the result.

[0051] (2) RCF (Resource Control Function)

[0052] Because the number of users accessing the base station and user requests change over time, the wireless access network configuration needs to be updated in real time. For example... Figure 4As shown, through the RCF function, administrators can modify the configuration of the radio access network during base station operation, such as the base station's bandwidth, frequency band, power, base station user scheduling strategy, vRB (virtual resource block) resources, etc., and allocate resources according to user needs to meet the differentiated needs of different service scenarios.

[0053] Specifically, RCF first listens for configuration policy requests on a specified port. Upon receiving a corresponding HTTP request, it parses the URL request. For example, the URL can have two formats:

[0054] http: / / IP:PORT / conf / enb / :id? –data-binary file_path

[0055] http: / / IP:PORT / slice / enb / :id? –data-binary file_path

[0056] The first type is the URL for configuring base station resources, and the second type is the URL for configuring base station radio resource allocation. IP:PORT represents the IP address and listening port number of the Docker container where the RCF resides, respectively. id represents the base station ID for obtaining information, and file_path is the path to the policy configuration file, which is in JSON format. After parsing the URL, if multiple configuration commands are to be executed, their priority must be determined first. Priority can be determined by first-come, first-served or by order of priority. After determining the priority, a wireless network configuration request is sent to the corresponding base station user plane, and finally, the result is returned.

[0057] (3) QAF (QoS Analysis Function)

[0058] like Figure 5 As shown, based on the acquired base station and user information accessing the base station, the QoS (Quality of Service) of the base station and users is analyzed to determine whether the QoS of the base station and users meets the preset indicators, thereby updating the network configuration, which is conducive to better responding to dynamically changing service needs.

[0059] The following section uses rate analysis to detail the QoS analysis function process:

[0060] First, the QoS analysis function listens on a specified port. Upon receiving a corresponding HTTP request, it parses the URL request. The URL format is: http: / / IP:PORT / qos / mac_rate / :interval? –data-binary file_path, where IP:PORT represents the IP address and listening port number of the Docker container where the QAF resides, respectively, and interval represents the time interval for obtaining TBS (Transport Block Size) data. After parsing the URL, it calls the SMF's HTTP interface to obtain the access base station user's ID and the user's location on the t... d TBS value T within the time interval ue The MAC layer rate R of the user within the interval is calculated according to the following formula. ue :

[0061] R ue =T ue *8 / t d / 1000000(1) Add up the TBS data of all access users within the base station to obtain the total TBS data T of the base station within the interval. bs Furthermore, the total MAC layer rate R of the base station can be derived. bs As shown in formulas (2) and (3):

[0062] T bs =T ue1 +T ue2 +... (2)

[0063] R bs =T bs *8 / t d / 1000000 (3)

[0064] After determining the MAC rate data of the base station and the user, it is determined whether the user's requirements are met. The determination method is shown in formula (4):

[0065] 0Mbps <R ue -R th ≤1Mbps (4)

[0066] Among them, R th This indicates that the user requires a minimum rate. If formula (4) is not true, it means that the allocated resources do not meet the user's needs, and an update resource allocation configuration request is sent to the policy configuration function. Conversely, if formula (4) is met, the result is returned. If the MAC rate of the base station does not reach 1 / 2 of the actual achievable peak rate of the base station or exceeds 2 / 3 of the achievable peak rate of the base station, it means that the following formula is not met:

[0067]

[0068] If a request to update the base station configuration is issued, then a result is returned if formula (5) is satisfied. Where R... P For the peak rate of the base station, the base station bandwidth can be configured as 5M, 10M, 20M, etc.

[0069] (4) PCF (Policy Configurator Function)

[0070] like Figure 6 As shown, PCF parses the update configuration request, identifies the policy call configuration template and modifies the template parameters, and then converts it into a JSON file format that RCF can process.

[0071] Specifically, the PCF first listens on a designated port. Upon receiving a corresponding HTTP request, it identifies the requested configuration, which mainly includes two types: radio resource allocation policy configuration and base station resource policy configuration. If it is radio resource configuration, it needs to first determine the updated resource allocation parameters, query the available base station resources through the SMF, and calculate the spectral efficiency η based on the rate R and bandwidth value B.

[0072]

[0073] Once the spectral efficiency is determined, the updated bandwidth resources can be determined based on the difference between the user's required rate and the calculated MAC rate.

[0074] Then, modify the corresponding parameter values ​​in the configuration template file according to the configuration parameters that need to be updated. The configuration template file is stored in dictionary format for easy reading and writing. Convert it into JSON format that RCF can accept. Finally, send the strategy to RCF and return the result.

[0075] Next, this embodiment will further illustrate the above-mentioned service-oriented wireless access network through experiments.

[0076] It should be noted that the experimental platform is deployed based on Docker and Kubernetes. Each server forms a cluster. The server deploying the service-oriented radio access network control plane is designated as the Master Node; the server deploying the core network control plane is designated as Worker Node1; and the server deploying the radio access network user plane is designated as Worker Node2. All servers are connected to the USRP via USB 3.0 interfaces, and the core network user plane function, oai-spgwu, is pushed down to the edge closer to the user. Kubernetes instantiates the platform based on predefined YAML files as templates. The following section uses the oai-ran template as an example to introduce the predefined templates.

[0077] Before deployment and operation, oai-ran needs to read the configuration file and then run the corresponding program according to the commands and parameters in the configuration file. For example, the configuration file includes the IP address and port of oai-ran as well as some parameter modes and facilities for base station operation.

[0078] This embodiment uses Kubernetes' configuration management component, ConfigMap, to store configuration files. ConfigMap decouples container images and configuration information, allowing them to be accessed during container startup and runtime by binding to volumes. This facilitates application configuration modifications and makes container creation more flexible. Then, YAML syntax is used to predefine information such as the NFS storage location, basic image information, listening port number, resources, and the commands for running the program. Based on the predefined YAML template, the platform is deployed and verified by running the `kubectl apply` command. After successful network functionality, the pod status can be viewed on each node using the `kubectl` command.

[0079] In this experiment, the non-service RAN used for comparison was built based on the open-source projects OAI and Mosaic5G, while the non-service radio access network was built based on the containerized platform Docker. The core network control plane was deployed on server PC1, the core network user plane was deployed on another server PC2, and this server was connected to a USRP B210 via a USB 3.0 interface to implement the RRH function of the radio access network. Communication between containers was based on the Weave plugin. This platform designed the radio access network control plane as a service, allowing each network function to be scaled and upgraded independently without affecting the operation and use of other network functions. Upgrading or modifying an NF requires adjusting or adding to the NF code, then recompiling the NF program code, repackaging the container to replace the old image, and redeploying by pulling the recompiled and packaged image to complete an NF upgrade process. Therefore, compilation time and packaging time can reflect the speed of service deployment to some extent. Table 1 shows the compilation time and image packaging time for each NF in the radio access network control plane and user plane. The compilation and packaging time for all NFs is the sum of the compilation and packaging times for all NFs in sequence.

[0080] Table 1

[0081] NF Name Compilation time (s) Image packaging time (s) Sum of compilation and packaging times (s) RAN-U 220.511 131.09 351.601 QAF 1.018 4.969 5.987 PCF 3.020 4.024 7.044 RCF 51.776 17.678 69.454 SMF 43.178 12.157 55.335 All NF 319.503 169.918 489.421 Non-service RAN 328.357 402.61 730.967

[0082] In service-oriented radio access networks, the network elements are independent of each other and can be developed, compiled, and packaged in parallel. In contrast, although non-service-oriented RANs can be developed collaboratively by teams in modules, changes in the interaction information between modules require recompiling and repackaging the entire code and its dependencies, which delays service upgrades and new product launches.

[0083] As shown in Table 1, the compilation and packaging times for all network element functions in a service-oriented radio access network (RAN) are lower than those in a non-service-oriented RAN. This is because compilation requires compiling all source code and linking to the necessary library files, and the non-service-oriented RAN has the largest amount of code and library files. Therefore, the compilation time for a single NF is smaller than, or even significantly smaller than, the compilation time for a non-service-oriented RAN. However, the non-service-oriented RAN does not involve communication between different services, but after decoupling, it is necessary to design interface communication code between NFs. Therefore, the compilation time for all NFs is only 9 seconds lower than that of the non-service-oriented RAN, which is not a significant difference. Packaging, on the other hand, requires packaging the code, library files, required dependencies, and the underlying system. The non-service-oriented RAN needs to package all code, libraries, component tools, and the underlying system. Therefore, the packaging time for a single NF is smaller than, or even significantly smaller than, the packaging time for a non-service-oriented RAN. The packaging time for all NFs is 232 seconds lower than that of the non-service-oriented RAN, a particularly significant difference. Therefore, a service-oriented architecture-based RAN also helps to accelerate service updates and deployment.

[0084] Figure 7 This is a comparison chart of compilation and packaging times for adding power adjustment functionality according to an embodiment of the present invention. For example... Figure 7 As shown, the compilation and packaging times of service-oriented radio access networks (RANs) are both lower than those of non-service-oriented RANs. Specifically, the compilation time is 47 seconds shorter and the packaging time is 253 seconds shorter than that of non-service-oriented RANs. This is because partial upgrades do not significantly modify the code. However, non-service-oriented RANs require repackaging the entire code and its runtime environment dependencies, resulting in a longer packaging time. In contrast, each network function module in the service-oriented architecture is more lightweight, has fewer dependencies, and therefore a shorter packaging time. Thus, RANs based on a service-oriented architecture update faster than non-service-oriented RANs, demonstrating that service-oriented RAN systems can improve network version upgrade speed and service deployment speed. When facing the diverse service demands of future networks, equipment vendors need to continuously upgrade the RAN equipment software. They can support user service needs by upgrading one or a few NFs without upgrading or redesigning the entire system. Service-oriented RAN systems offer faster upgrade and update speeds.

[0085] To illustrate how a service-oriented radio access network (RON) can reduce the command execution time for configuring RAN user plane resources via the control plane, this embodiment deploys a non-service-oriented RON and a radio access network (RAN). Since the execution time of a single resource configuration command is in the millisecond range, the average execution time can be calculated by submitting multiple requests. With an interval of 1000 requests to configure the base station's total bandwidth resources, 1000 to 5000 resource configuration requests are sent sequentially to the two platforms, and the execution time is recorded. The cumulative distribution function is as follows: Figure 8As shown. From Figure 8 As can be seen, the execution time of a configuration resource request in a service-oriented radio access network is 1.5ms lower than that in a non-service-oriented line access network. This is because after decoupling the RAN control plane, the originally serially executed SMF and RCF functions are changed to be executed in parallel. In a non-service-oriented line access network, not only does the RCF continuously request resource control from the RAN user plane, but the SMF also periodically requests the RAN user plane status information. The requests of the two functions follow the principle of first-come, first-served. The RCF request cannot be executed immediately every time; it may need to wait until the SMF request ends once before it can be executed. Therefore, the execution time of the configuration resource request is higher than that of the service-oriented radio access network.

[0086] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0087] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. In addition, those skilled in the art can combine and integrate the different embodiments or examples described in this specification.

[0088] Although this application has been described herein in conjunction with various embodiments, other variations of the disclosed embodiments can be understood and implemented by those skilled in the art in carrying out the claimed application by reviewing the accompanying drawings, the disclosure, and the appended claims.

[0089] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A service-oriented wireless access network, characterized in that, include: The underlying infrastructure layer provides the necessary physical resources for the wireless access network, including computing resources, caching resources, and communication resources. The virtualization layer is used to manage the virtualized computing resources, cache resources, and communication resources, and to realize the sharing and isolation of physical resources in the infrastructure layer through interfaces; the virtualization layer is divided into a first control plane and a first management and orchestration plane. The functional layer is used to configure and deploy the communication resources of the wireless access network; the functional layer is divided into a second control plane and a second MANO plane. The application layer is used to implement the service requirements of terminals accessing the wireless access network; the application layer is divided into a third control plane and a third MANO plane. The service-oriented radio access network is divided into a control plane, a MANO plane, and a user plane. The infrastructure layer is divided into a user plane. The control plane includes a first control plane, a second control plane, and a third control plane. The MANO plane includes a first MANO plane, a second MANO plane, and a third MANO plane. The control plane is used to control and manage infrastructure resources and provide customized radio access network services to users. The MANO plane is used to manage and orchestrate the infrastructure resources, NG interfaces, and applications. The user plane is used to provide the necessary physical resources for the radio access network and forward user data.

2. The service-oriented wireless access network according to claim 1, characterized in that, The computing resources include a central processing unit; The cache resources include internal memory and external memory, wherein the internal memory includes random access memory (RAM) and read-only memory (ROM), and the external memory includes hard disk drive (HDD) and solid-state drive (SSD). The communication resources include radio frequency remote heads for evolved NBs (eNBs) and next-generation gNBs (gNBs).

3. The service-oriented wireless access network according to claim 2, characterized in that, The radio frequency remote head includes a radio frequency module and an antenna, and is used to forward user data in the form of radio frequency signals.

4. The service-oriented wireless access network according to claim 1, characterized in that, The first control plane includes DockerEngine, and the first MANO plane includes a virtualization infrastructure manager, which includes a virtual machine management platform and a container management platform.

5. The service-oriented wireless access network according to claim 4, characterized in that, The second control plane includes multiple independent network element functions obtained by decoupling from the control service functions of the radio access network. These multiple independent network element functions are connected through a service interface (SBI) and communicate based on the Hypertext Transfer Protocol (HTTP). The second MANO surface includes MANO units with multiple network element functions.

6. The service-oriented wireless access network according to claim 5, characterized in that, The third control plane includes various service requirements, and the third MANO plane includes multiple MANO units of the wireless access network.

7. The service-oriented wireless access network according to claim 6, characterized in that, The service requirements include: enhanced mobile broadband, ultra-reliable low latency, and massive machine-type communications.

Images