Resource coordination method, system, and device
By collaboratively determining the number of tokens and the traffic offloading strategy through base stations and core network equipment, the problem of the inability to dynamically coordinate resources in 5G networks is solved, and the dynamic allocation of resources and the rationality of the traffic offloading strategy are realized.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHINA UNITED NETWORK COMM GRP CO LTD
- Filing Date
- 2022-11-30
- Publication Date
- 2026-07-07
Smart Images

Figure CN116017580B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of mobile communication technology, and in particular to a resource coordination method, system and device. Background Technology
[0002] As 5G technology matures, its applications for enterprise users (to business, 2B) are becoming more diverse, especially in areas such as the industrial internet and smart healthcare, where it will be widely adopted in the near future.
[0003] To meet the business needs of enterprise users, the 5G network architecture introduces User Plane Function (UPF) devices and Multi-access Edge Computing (MEC) devices. Base stations connect to core network equipment via UPF devices; MEC devices, acting as computing nodes, feature low latency in service processing. After service data is accessed and forwarded to the UPF device via the base station, the UPF device, based on the pre-configured traffic distribution strategy of the core network equipment, distributes the service data to service processing nodes such as MEC devices, enterprise private clouds, or central clouds.
[0004] However, the service data accessed through the base station may surge at a certain time, and the above-mentioned diversion method cannot achieve dynamic coordination of resources. Summary of the Invention
[0005] This application provides a resource coordination method, system, and device to solve the problem of resources being unable to be dynamically coordinated.
[0006] In a first aspect, this application provides a resource coordination method applied to a base station. The resource coordination method includes: receiving a service request from a terminal device; determining the number of tokens corresponding to the service request based on the service attribute characteristics corresponding to the service request, wherein the number of tokens reflects the resources consumed; sending a resource coordination request to a core network device, the resource coordination request carrying the number of tokens, the resource coordination request being used to instruct the core network device to configure a traffic splitting strategy for the service request based on the number of tokens, and sending the traffic splitting strategy to a UPF device.
[0007] Optionally, the business attribute characteristics include business throughput and business priority. Based on the business attribute characteristics corresponding to the business request, the number of tokens corresponding to the business request is determined, including: determining a dynamic value of the number of tokens to be allocated to the business request based on the business throughput and business priority, wherein the higher the business throughput and / or the higher the business priority, the more dynamic values there are; and determining the number of tokens corresponding to the business request based on the dynamic values.
[0008] Optionally, the number of tokens corresponding to the service request is determined based on the dynamic value, including: obtaining a fixed value of the number of tokens pre-configured for the area where the base station is located, the fixed value being determined based on the total network traffic in the area; and determining that the number of tokens corresponding to the service request is the sum of the dynamic value and the fixed value.
[0009] Secondly, this application provides a resource coordination method applied to core network equipment. The resource coordination method includes: receiving a resource coordination request from a base station, wherein the resource coordination request carries a token number, and the token number is determined according to the service attribute characteristics corresponding to the service request; configuring a traffic splitting strategy for the service request according to the token number; and sending the traffic splitting strategy to the UPF device.
[0010] Optionally, a traffic splitting strategy can be configured for business requests based on the number of tokens, including: matching the target resource allocation level corresponding to the number of tokens in the resource-to-token relationship, where the resource-to-token relationship is the ratio between the resource allocation level and the number of tokens; and configuring a traffic splitting strategy for business requests based on the target resource allocation level.
[0011] Optionally, the resource coordination method further includes: before configuring a traffic splitting strategy for a business request based on the number of tokens, determining whether the number of tokens is greater than or equal to the minimum threshold value in the resource-token relationship; if so, then configuring a traffic splitting strategy for the business request based on the number of tokens; if not, then entering a waiting state.
[0012] Optionally, the resource coordination method further includes: real-time detection of the amount of allocable idle resources for at least one of multi-access edge computing, private cloud and public cloud; when the amount of idle resources is greater than a first threshold, increasing the ratio of resource-to-token relationship so that the same number of tokens can match more resources; when the amount of idle resources is less than a second threshold, decreasing the ratio of resource-to-token relationship so that the same number of tokens can match fewer resources; wherein the second threshold is greater than the first threshold.
[0013] Thirdly, this application provides a resource coordination system, comprising: a base station for performing a resource coordination method as provided in any of the first aspects above; and a core network device for performing a resource coordination method as provided in any of the second aspects above.
[0014] Fourthly, this application provides an electronic device, including: a memory and a processor; the memory for storing program instructions; and the processor for calling the program instructions to execute a resource coordination method as provided in any of the first aspects above, or a resource coordination method as provided in any of the second aspects above.
[0015] Fifthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the resource coordination method of any one of the first aspects above, or the resource coordination method of any one of the second aspects above.
[0016] Sixthly, this application provides a computer program product, including a computer program; when the computer program is executed, it implements the resource coordination method provided in the first or second aspect above.
[0017] The resource coordination method, system, and device provided in this application receive service requests from terminal devices, determine the number of tokens corresponding to the service request based on the service attribute characteristics, where the number of tokens reflects the consumed resources, and send a resource coordination request to the core network device. The resource coordination request carries the number of tokens and is used to instruct the core network device to configure a traffic offloading strategy for the service request based on the number of tokens, and then sends the traffic offloading strategy to the UPF device. Through this application, the base station determines the corresponding number of tokens based on the service attribute characteristics, enabling the core network to allocate a traffic offloading strategy adapted to the service based on this token number parameter. This achieves dynamic resource coordination and reduces the resource consumption of the core network when formulating traffic offloading strategies. Attached Figure Description
[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0019] Figure 1 This is a schematic diagram of the network architecture provided in the embodiments of this application;
[0020] Figure 2 Flowchart of the resource coordination method provided in the embodiments of this application Figure 1 ;
[0021] Figure 3 Flowchart of the resource coordination method provided in the embodiments of this application Figure 2 ;
[0022] Figure 4 This is an interactive schematic diagram of the resource coordination system provided in the embodiments of this application;
[0023] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.
[0024] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0025] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.
[0026] Figure 1 The network architecture diagram provided for the embodiments of this application uses a 5G network as an example. Figure 1 As shown, the network architecture includes terminal equipment, base stations, user plane function equipment (hereinafter referred to as UPF equipment), multi-access edge computing (hereinafter referred to as MEC), private cloud, central cloud (also known as public cloud) and core network module. The arrows in the diagram indicate the direction of the service path.
[0027] Terminal devices can be mobile phones, computers, smartwatches, in-vehicle devices, etc., which transmit uplink data such as service requests to the core network via base stations. In this embodiment, the UPF device is a separate dedicated device, positioned between the base station and the core network. MEC refers to edge computing nodes, which can be understood as a small data center or public cloud.
[0028] The core network acts as a manager, responsible for the unified management of all base stations within its jurisdiction (in China, typically one or two core networks per province). The core network receives service request data forwarded from base stations and, based on the service type or relevant attribute values, forwards it to specific directions for service processing, such as... Figure 1 The three business paths shown are: business path 1 to the central cloud, business path 2 to the private cloud, and business path 3 to the MEC. The specific business processing is performed by the central cloud, the private cloud, and the MEC, respectively.
[0029] The configuration of the traffic offloading strategy for service requests, as described above, is often done in a fixed manner. That is, based on the established offloading strategy, the core network uniformly configures most base stations and stores the user information they report. However, the entire system lacks a dynamic adjustment mechanism. For example, sometimes the traffic volume of a certain base station surges, and the computing resources required for its service requests also surge. However, according to the pre-configured strategy, the UPF device will invariably forward the service traffic to the private cloud (the UPF device identifies the service field and forwards it to a specific direction based on the service type or related attribute values, but this strategy is formulated and issued by the core network and executed by the device in a fixed manner). At this time, the resource utilization of the private cloud has exceeded its limit and can no longer provide services, thus affecting the service traffic. In addition, the resources of the core network are also limited, making it impossible to formulate and manage personalized strategies for each base station device and its connected services. This is why all devices currently execute fixed strategies.
[0030] In summary, this application provides a resource coordination method, system, and device, aiming to solve the problem of resource mismatch caused by fixed strategies. The resource coordination method proposed in this application will be explained in detail below with reference to specific embodiments.
[0031] Figure 2 Flowchart of the resource coordination method provided in the embodiments of this application Figure 1 This method is applied to base stations. For example... Figure 2 As shown, the resource coordination method includes:
[0032] S201: Receive service requests from terminal devices.
[0033] The base station receives and forwards service requests from terminal devices. Each service request contains corresponding service attribute characteristics, which may include, for example, the priority of the service, the service throughput, and the type of resource requested.
[0034] S202: Determine the number of tokens corresponding to the business request based on the business attribute characteristics, where the number of tokens reflects the resources consumed.
[0035] In this context, a token is a signaling device that can be recognized by the core network. The core network can formulate corresponding service processing and traffic distribution strategies based on the number of tokens (i.e., the token count). Specifically, the token count reflects the resources required to process the service and its importance. Therefore, service requests with different service attributes typically correspond to different token counts. For example, service requests with higher priority correspond to higher token counts, and / or service requests with higher throughput correspond to higher token counts.
[0036] Each time a base station receives a service request, it will identify the service attribute characteristics of the request and determine the corresponding number of tokens based on the service attribute characteristics in order to obtain the corresponding resource allocation from the core network.
[0037] In some embodiments, a correspondence between service attribute features and token counts can be pre-defined. The base station can obtain this correspondence at any time and determine the token count based on each matching result.
[0038] S203: Send a resource coordination request to the core network device. The resource coordination request carries a token count. The resource coordination request is used to instruct the core network device to configure a traffic offloading policy for the service request based on the token count, and send the traffic offloading policy to the UPF device.
[0039] The resource coordination request contains information about the type of service request. For example, the resource coordination request may directly contain a service request, which includes the type of resource requested from the core network.
[0040] For example, resource types can include link assurance and computing power assurance. Link assurance refers to the link resources required for service transmission, which may involve routing links and physical transport layer links between base stations and access network devices, links between the access network and the core network, and links between the core network and the data center. Only by establishing these links can end-to-end transmission assurance be achieved for the service.
[0041] Computing power assurance refers to the computing resources required for business processing. A base station is merely a network node and transmission device; it does not possess business processing capabilities itself. To process the business requests it receives, it needs to send those requests to a data center or cloud for processing. Specifically, this mainly involves the types mentioned above: private cloud, MEC, and public cloud. These are all data centers, but they differ in scale, computing resources, algorithms, and therefore, business processing capabilities.
[0042] Resource coordination requests carry a token count, which is a parameter determined based on the characteristics of the service and reflects the resources required to process the service, i.e., the importance of the service. For example, a higher token count indicates greater importance and a higher priority for timely processing. The core network then configures corresponding traffic allocation strategies for service requests based on the token count. For instance, for resource coordination requests related to computing power assurance, if the request carries a high token count, it is decided to allocate the service processing task to a data center with stronger computing power or more idle resources. This decision (i.e., the traffic allocation strategy) is sent to the UPF device, which then executes the specific traffic allocation strategy.
[0043] It should be noted that in this embodiment of the application, the UPF device is used as the execution subject of the traffic splitting strategy to illustrate the application. However, in other embodiments, the execution subject of the traffic splitting strategy is not limited to the UPF device.
[0044] This application embodiment receives service requests from terminal devices, determines the number of tokens corresponding to the service request based on the service attribute characteristics, where the number of tokens reflects the resources consumed, and sends a resource coordination request to the core network device. The resource coordination request carries the number of tokens and is used to instruct the core network device to configure a traffic offloading strategy for the service request based on the number of tokens, and then sends the traffic offloading strategy to the UPF device. Through this application embodiment, the base station determines the corresponding number of tokens based on service attribute characteristics, enabling the core network to allocate a traffic offloading strategy adapted to the service based on this token number parameter. This achieves dynamic resource coordination and reduces the resource consumption of the core network when formulating traffic offloading strategies.
[0045] Based on the above embodiments, optionally, the business attribute features include business throughput and business priority. Determining the number of tokens corresponding to a business request based on the business attribute features includes: determining a dynamic value of the number of tokens to be allocated to the business request based on the business throughput and business priority, wherein the higher the business throughput and / or the higher the business priority, the more dynamic values there are; and determining the number of tokens corresponding to the business request based on the dynamic values.
[0046] The dynamic token count refers to a value determined based on the service attributes of a received service request. Higher service priority and / or greater service throughput result in a higher dynamic token count. Within the same base station, more dynamic token counts indicate a larger total token count. Specifically, the dynamic token count can be determined using the following formula:
[0047] X = a × T + b × P + c × R,
[0048] Where T represents service throughput; P represents service priority; R represents reserved parameters, which can be temporarily or randomly defined according to the needs of the network operator; and a, b, and c are the weighting coefficients corresponding to service throughput, service priority, and reserved parameters, which can be set according to the actual situation during use.
[0049] Furthermore, based on the dynamic value, the number of tokens corresponding to the service request is determined, including: obtaining a fixed value of the number of tokens pre-configured for the area where the base station is located, the fixed value being determined based on the total network traffic in the area; and determining that the number of tokens corresponding to the service request is the sum of the dynamic value and the fixed value.
[0050] In other words, the fixed value is a pre-configured fixed value, which can be calculated by the core network based on the network-wide traffic model within the region / area. Typically, a province has only one core network, but the traffic situation varies between different provinces. For example, the traffic situation differs between coastal and inland areas, between industrial cluster areas and non-industrial cluster areas, and between industrial park areas and commercial center areas.
[0051] For example, through a specific model, the priority information and traffic characteristics of service requests connected to / received by base stations in different regions can be obtained. Based on these characteristics, a fixed value can be assigned to each base station in different regions. The fixed value reflects a macroscopic value and has regional attributes. For example, the fixed value of base stations in regions with greater service demand or higher service urgency can be set higher.
[0052] When determining the number of tokens for each service request, the base station determines a dynamic value for the number of tokens to be allocated to the service request based on the service attribute characteristics corresponding to that request. The base station then sums its fixed value with the dynamic value to determine the total number of tokens for that service request. In this way, areas with greater service demand or higher urgency / importance will be able to obtain a relatively higher number of tokens, and will be able to obtain more and faster resources from the core network.
[0053] Figure 3 Flowchart of the resource coordination method provided in the embodiments of this application Figure 2 Correspondingly, this method is applied to core network equipment. For example... Figure 3 As shown, the resource coordination method includes:
[0054] S301: Receive a resource coordination request from the base station. The resource coordination request carries a token count, which is determined based on the service attribute characteristics corresponding to the service request.
[0055] S302: Configure a traffic splitting strategy for business requests based on the number of tokens;
[0056] S303: Send the traffic splitting policy to the UPF device.
[0057] After receiving a resource coordination request from a base station, the core network equipment identifies the number of tokens carried by the request and determines the corresponding traffic offloading strategy based on the number of tokens. That is, it configures the corresponding number of service processing resources. The specific resource type can be determined based on the type of service request contained in the resource coordination request.
[0058] After the core network equipment has formulated the traffic offloading policy, it will issue specific execution instructions to the executors included in the policy. Among them, the UPF equipment offloads the service to specific computing nodes (i.e., data centers) or link nodes.
[0059] Based on the above embodiments, optionally, configuring a traffic splitting strategy for service requests based on the number of tokens means including: matching the target resource allocation level corresponding to the number of tokens in the resource-to-token relationship, where the resource-to-token relationship is the ratio between the resource allocation level and the number of tokens; and configuring a traffic splitting strategy for service requests based on the target resource allocation level.
[0060] The resource-to-token relationship is the ratio between resource allocation level and the number of tokens. Core network devices can match the resource allocation level corresponding to the number of tokens, and then formulate / configure the corresponding traffic offloading strategy based on the resource allocation level. Generally, the higher the number of tokens, the higher the resource allocation level, and the more resources should be configured for that service request.
[0061] The resource-token relationship can be a pre-configured relationship table in the core network equipment, or it can be a relationship table calculated by the core network equipment during the process of configuring traffic distribution strategies for various service requests. The core network equipment directly matches the corresponding resource allocation level based on the resource-token relationship, without needing to perform real-time calculations of various data for each service request, significantly saving the core network equipment's computing costs. Different token counts can match different resource allocation levels, allowing service requests with different importance or resource requirements to be allocated different resource ratios, further realizing dynamic resource allocation and improving the rationality and adaptability of traffic distribution strategies.
[0062] In some embodiments, the resource coordination method further includes: real-time detection of the amount of allocable idle resources for at least one of multi-access edge computing, private cloud and public cloud; when the amount of idle resources is greater than a first threshold, increasing the ratio of resource-token relationship so that the same number of tokens can match more resources; when the amount of idle resources is less than a second threshold, decreasing the ratio of resource-token relationship so that the same number of tokens can match fewer resources; wherein the second threshold is greater than the first threshold.
[0063] In this embodiment, three main types of data centers for providing computing resources are exemplified: MEC, private cloud, and public cloud. While receiving and processing resource coordination requests, the core network equipment also monitors the amount of allocable idle resources in these data centers in real time. The amount of allocable idle resources refers to the amount of idle resources available for task allocation. To meet the needs of the base station, the core network also consumes its own resources, such as resources required for signaling interaction, resources needed for real-time monitoring, and resources required for related computing, such as Central Processing Units (CPUs), Field-Programmable Gate Arrays (FPGAs), Neural Network Processing Units (NPUs), and various storage resources, to meet the service requirements of the base station.
[0064] When the amount of available idle resources varies, the core network equipment dynamically adjusts the resource-to-token ratio. In other words, the core network equipment maintains a table showing the relationship between resource allocation and the number of tokens, and this table is constantly changing. When the core network equipment detects that the amount of available idle resources is sufficient, the same resource consumption will correspond to fewer tokens. This means that the core network equipment is more likely to meet the demands from the base station at this time.
[0065] The first and second thresholds exemplify the limits for determining whether the resource-token relationship needs adjustment. In practice, more than two thresholds can be set, and their values can be adjusted adaptively. The more thresholds set, the greater the dynamic flexibility of the resource-token relationship, but the more core network maintenance resources are consumed. Thus, when idle resources are scarce, resource coordination requests with more tokens will be prioritized or allocated more resources; this process does not require specific calculations from the core network equipment, but only needs to be performed by matching the current resource-token relationship.
[0066] In other embodiments, the resource coordination method further includes: before configuring a traffic splitting strategy for a service request based on the number of tokens, determining whether the number of tokens is greater than or equal to the minimum threshold value in the resource-token relationship; if so, configuring a traffic splitting strategy for the service request based on the number of tokens; if not, entering a waiting state. That is, the core network device temporarily suspends service requests / resource coordination requests carrying fewer tokens and prioritizes processing service requests carrying more tokens. When the amount of idle resources increases, the ratio of the resource-token relationship is increased, and the same resource consumption requires fewer tokens, so the suspended service requests can reach the minimum threshold value in the resource-token relationship and be processed.
[0067] For example, a base station sends a resource coordination request to the core network equipment, carrying M tokens. However, the resource-to-token relationship required for this request in the current resource-token relationship requires N tokens. Since M < N, the core network equipment cannot meet the base station's needs in a timely manner, causing this service request / resource coordination request to enter a waiting state.
[0068] The above embodiments explain in detail the resource coordination method provided by this application. The resource coordination system, electronic device, storage medium and program product provided by the embodiments of this application will be specifically described below.
[0069] Figure 4 This is a schematic diagram illustrating the interaction of a resource coordination system provided in an embodiment of this application. For example... Figure 4 As shown, the resource coordination system includes a base station and core network equipment, wherein the base station is used to execute any of the resource coordination methods applied to the base station as provided in the above embodiments; and the core network equipment is used to execute any of the resource coordination methods applied to the core network equipment as provided in the above embodiments.
[0070] For example, such as Figure 4 As shown, the interaction process of this resource coordination system includes:
[0071] S401: The base station receives a service request from the terminal device;
[0072] S402: The base station determines the number of tokens corresponding to the service request based on the service attribute characteristics corresponding to the service request;
[0073] S403: The base station sends a resource coordination request to the core network equipment, carrying a token count;
[0074] S404: Core network equipment configures traffic routing policies for service requests based on the number of tokens;
[0075] S405: The core network equipment sends a traffic offloading policy to the UPF equipment;
[0076] S406: The core network equipment sends a reply instruction to the base station.
[0077] The reply instruction indicates that the service request has been processed. After receiving the reply instruction, the base station will end the service request task and wait for the next service request task.
[0078] Optionally, the service attribute characteristics include service throughput and service priority. The base station determines the number of tokens corresponding to the service request based on the service attribute characteristics corresponding to the service request, including: determining a dynamic value of the number of tokens to be allocated to the service request based on the service throughput and service priority, wherein the higher the service throughput and / or the higher the service priority, the more dynamic values there are; and determining the number of tokens corresponding to the service request based on the dynamic values.
[0079] Optionally, the base station determines the number of tokens corresponding to the service request based on the dynamic value, including: obtaining a fixed value of the number of tokens pre-configured for the area where the base station is located, the fixed value being determined based on the total network traffic in the area; and determining that the number of tokens corresponding to the service request is the sum of the dynamic value and the fixed value.
[0080] Optionally, the core network device configures a traffic distribution strategy for service requests based on the number of tokens, including: matching the target resource allocation level corresponding to the number of tokens in the resource-to-token relationship, where the resource-to-token relationship is the ratio between the resource allocation level and the number of tokens; and configuring a traffic distribution strategy for service requests based on the target resource allocation level.
[0081] Optionally, the core network equipment can also be used to: determine whether the number of tokens is greater than or equal to the minimum threshold value in the resource-token relationship before configuring a traffic splitting policy for a service request based on the number of tokens; if yes, then execute the traffic splitting policy configuration for the service request based on the number of tokens; if no, then enter a waiting state.
[0082] Optionally, the core network equipment can also be used to: perform real-time detection of the amount of allocable idle resources for at least one of multi-access edge computing, private cloud, and public cloud; when the amount of idle resources is greater than a first threshold, increase the ratio of resource-to-token relationship so that the same number of tokens can match more resources; when the amount of idle resources is less than a second threshold, decrease the ratio of resource-to-token relationship so that the same number of tokens can match fewer resources; wherein the second threshold is greater than the first threshold.
[0083] The system provided in this application embodiment can be used to execute the above-described resource coordination method. Its implementation and technical effects are similar, and will not be described again here.
[0084] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device 500 includes:
[0085] Processor 501, memory 502, communication interface 503, and system bus 504.
[0086] The memory 502 and the communication interface 503 are connected to the processor 501 via the system bus 504 and communicate with each other. The memory 502 is used to store computer execution instructions, the communication interface 503 is used to communicate with other devices, and the processor 501 is used to execute the computer execution instructions to execute the resource coordination method for base station or core network equipment as described in the above method embodiment.
[0087] Specifically, processor 501 may include one or more processing units. For example, processor 501 may be a CPU, a Digital Signal Processing (DSP), an Application Specific Integrated Circuit (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.
[0088] Memory 502 can be used to store program instructions. Memory 502 may include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function), etc. The data storage area may store data created during the use of electronic device 500 (such as audio data), etc. In addition, memory 502 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 501 executes various functional applications and data processing of electronic device 500 by running program instructions stored in memory 502.
[0089] Communication interface 503 can provide wireless communication solutions, including 2G / 3G / 4G / 16G, for use on electronic device 500. Communication interface 503 can receive electromagnetic waves via an antenna, filter and amplify the received electromagnetic waves, and then transmit them to a modem processor for demodulation. Communication interface 503 can also amplify the signal modulated by the modem processor and radiate it as electromagnetic waves via the antenna. In some embodiments, at least some functional modules of communication interface 503 can be housed in processor 501. In some embodiments, at least some functional modules of communication interface 503 and at least some modules of processor 501 can be housed in the same device.
[0090] System bus 504 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This system bus 504 can be divided into address bus, data bus, control bus, etc. For ease of illustration, it is represented by only one thick line in the diagram, but this does not indicate that there is only one bus or one type of bus.
[0091] It should be noted that the number of memory 502 and processor 501 is not limited in this embodiment; there can be one or more of them. Figure 5 The diagram illustrates an example; the memory 502 and processor 501 can be connected via wired or wireless means, such as a bus connection. In practical applications, this electronic device 500 can be various forms of computers or mobile terminals. Computers include, for example, laptops, desktop computers, workbenches, servers, blade servers, mainframe computers, etc.; mobile terminals include, for example, personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices.
[0092] The electronic device in this embodiment can be used to execute the technical solutions in the above method embodiments. Its implementation principle and technical effect are similar, and will not be repeated here.
[0093] This application also provides a computer-readable storage medium storing computer-executable instructions. When executed by a processor, these instructions are used to implement the resource coordination method for base stations or core network equipment described in the above-described method embodiments.
[0094] This application also provides a computer program product, including a computer program; when the computer program is executed, it implements the resource coordination method for base station or core network equipment as described in the above method embodiments.
[0095] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.
[0096] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.
Claims
1. A resource coordination method, characterized in that, Applied to base stations, the resource coordination method includes: Receive service requests from terminal devices; Obtain a fixed value of the number of tokens pre-configured for the area where the base station is located, the fixed value being determined based on the total network traffic within the area; Based on the business throughput and business priority in the business attribute characteristics corresponding to the business request, a dynamic value of the number of tokens allocated to the business request is determined; wherein, the higher the business throughput and / or the higher the business priority, the more dynamic values there are; the business attribute characteristics include the priority of the carried business, the business throughput, and the type of requested resources; the dynamic value is determined based on the following method: X=a×T+b×P+c×R; Where T represents service throughput; P represents service priority; R represents reserved parameters; and a, b, and c are the weighting coefficients corresponding to service throughput, service priority, and reserved parameters, respectively. The number of tokens corresponding to the service request is determined to be the sum of the dynamic value and the fixed value; The number of tokens reflects the resources consumed; A resource coordination request is sent to the core network device. The resource coordination request carries the number of tokens and is used to instruct the core network device to match the target resource allocation level corresponding to the number of tokens in the resource-to-token relationship. The resource-to-token relationship is the ratio between the resource allocation level and the number of tokens. According to the target resource allocation level, a traffic splitting strategy is configured for the service request, and the traffic splitting strategy is sent to the User Plane Function (UPF) device. Specifically, the ratio of the resource-to-token relationship is increased when the amount of allocable idle resources is greater than a first threshold, so that the same number of tokens can be matched with more resources; the ratio of the resource-to-token relationship is decreased when the amount of allocable idle resources is less than a second threshold, so that the same number of tokens can be matched with fewer resources; the second threshold is less than the first threshold.
2. A resource coordination method, characterized in that, The resource coordination method, applied to core network equipment, includes: The system receives a resource coordination request from a base station. This request carries a token count, which is determined by the sum of a dynamic value and a fixed value. The fixed value is a pre-configured token count for the area where the base station is located, determined based on the total network traffic within the area. The dynamic value is determined by the base station based on the service throughput and service priority characteristics of the service attribute features corresponding to the service request. The dynamic value is determined based on the following formula: X = a × T + b × P + c × R. Where T represents service throughput; P represents service priority; R represents reserved parameters; and a, b, and c are the weighting coefficients corresponding to service throughput, service priority, and reserved parameters, respectively. The higher the service throughput and / or the higher the service priority, the more dynamic values there are; the service attribute features include the priority of the service, the service throughput, and the type of requested resources. Configure a traffic splitting strategy for the service request based on the number of tokens; Send the traffic splitting strategy to the User Plane Function (UPF) device; The step of configuring a traffic splitting strategy for the service request based on the number of tokens includes: In the resource-token relationship, a target resource allocation level is matched with the number of tokens, and the resource-token relationship is the ratio between the resource allocation level and the number of tokens. Configure a traffic splitting strategy for the service requests based on the target resource allocation level; Real-time detection of allocable idle resources is performed for at least one of multi-access edge computing, private cloud, and public cloud. When the amount of idle resources exceeds the first threshold, the ratio of resource-to-token relationship is increased so that the same number of tokens can be matched with more resources. When the amount of idle resources is less than the second threshold, the ratio of resource-to-token relationship is reduced so that the same number of tokens can match fewer resources. The second threshold is less than the first threshold.
3. The resource coordination method according to claim 2, characterized in that, Also includes: Before configuring a traffic splitting strategy for the service request based on the number of tokens, determine whether the number of tokens is greater than or equal to the minimum threshold value in the resource-token relationship; If so, then execute the step of configuring a traffic splitting strategy for the service request based on the number of tokens; If not, then enter the waiting state.
4. A resource coordination system, characterized in that, include: Base station, used to perform the resource coordination method as described in claim 1; A core network device for performing the resource coordination method as described in any one of claims 2 to 3.
5. An electronic device, characterized in that, include: Memory, processor; The memory is used to store program instructions; The processor is configured to invoke the program instructions to execute the resource coordination method as described in claim 1, or the resource coordination method as described in any one of claims 2 to 3.
6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the resource coordination method as described in claim 1, or the resource coordination method as described in any one of claims 2 to 3.