Parameter configuration method and device and computer readable storage medium

Abstract

The embodiment of the invention provides a parameter configuration method and device and a computer readable storage medium. The method comprises the following steps: a first network element sends a configuration request message to a second network element; wherein the configuration request message comprises target parameters configured by the first network element for the current round of specific network function session, and at least part of the target parameters are to-be-negotiated parameters needing to negotiate with a second network element for the current round of specific network function session; the first network element receives a configuration response message sent by the second network element; wherein the configuration response message comprises the parameter value of the to-be-negotiated parameter determined by the second network element, and the parameter value is applied to the specific network function session of the round. According to the method, parameter configuration which is more adaptive to a specific network function can be realized, so that the performance of a wireless communication network is improved.

Description

Parameter configuration methods, devices, and computer-readable storage media Technical Field

[0001] This application relates to the field of communication technology, and in particular to a parameter configuration method, device, and computer-readable storage medium. Background Technology

[0002] Under the current communication network mechanism, the parameter configuration message sender can initiate a parameter configuration process according to the actual task requirements, and configure relevant parameters through the parameter configuration process. The parameter configuration message receiver usually fully accepts and complies with all parameter configurations of the parameter configuration message sender (or rejects all parameter configurations of the parameter configuration message sender). However, this method may result in improper parameter configuration, which may lead to a decrease in communication network performance. Summary of the Invention

[0003] This application provides a parameter configuration method, device, and computer-readable storage medium.

[0004] In a first aspect, embodiments of this application provide a parameter configuration method applied to a first network element, comprising:

[0005] Send a configuration request message to the second network element; wherein the configuration request message includes target parameters configured by the first network element for the current round of specific network function session, and at least some of the target parameters are parameters to be negotiated by the second network element for the current round of specific network function session;

[0006] The configuration response message sent by the second network element is received; wherein the configuration response message includes the parameter value of the parameter to be negotiated determined by the second network element, and the parameter value is applied to the current round of specific network function session.

[0007] Secondly, embodiments of this application provide a parameter configuration method applied to a second network element, including:

[0008] Receive a configuration request message sent by a first network element; wherein the configuration request message includes target parameters configured by the first network element for the current round of specific network function session, and at least some of the target parameters are parameters to be negotiated by the second network element for the current round of specific network function session;

[0009] Determine the parameter value of the parameter to be negotiated;

[0010] Send a configuration response message to the first network element; wherein the configuration response message includes the parameter value, and the parameter value is applied to the current round of specific network function session.

[0011] Thirdly, embodiments of this application provide a communication device, including: a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the parameter configuration method provided in the first or second aspect of embodiments of this application.

[0012] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the parameter configuration method provided in the first or second aspect of embodiments of this application.

[0013] Further details regarding the above embodiments and other aspects of this application, as well as their implementations, are provided in the accompanying drawings, detailed description, and claims. Attached Figure Description

[0014] Figure 1 is a schematic diagram of a communication system provided in an embodiment of this application;

[0015] Figure 2 is a schematic diagram of a wireless access network provided in an embodiment of this application;

[0016] Figure 3 is a schematic diagram of an air interface control plane protocol stack provided in an embodiment of this application;

[0017] Figure 4 is a schematic diagram of an air interface user plane protocol stack provided in an embodiment of this application;

[0018] Figure 5 is a schematic diagram comparing the parameter configurations provided by conventional technology and embodiments of this application;

[0019] Figure 6 is a schematic diagram of the components of an artificial intelligence module provided in an embodiment of this application;

[0020] Figure 7 is a flowchart illustrating a parameter configuration method provided in an embodiment of this application.

[0021] Figure 8 is a schematic diagram of a configuration response message sending method provided in an embodiment of this application;

[0022] Figure 9 is another schematic diagram of the configuration response message sending method provided in the embodiments of this application;

[0023] Figure 10 is another flowchart illustrating the parameter configuration method provided in the embodiments of this application;

[0024] Figure 11 is a schematic diagram of a parameter configuration device provided in an embodiment of this application;

[0025] Figure 12 is a schematic diagram of another structure of the parameter configuration device provided in the embodiment of this application;

[0026] Figure 13 is a schematic diagram of a communication device provided in an embodiment of this application. Detailed Implementation

[0027] It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0028] The parameter configuration method provided in this application can be applied to various wireless communication systems. For example, the wireless communication system may be a fifth-generation (5G) communication system, a 3GPP-related communication system, a sixth-generation (6G) communication system, and a future evolution communication system or a system integrating multiple systems, etc. This application does not limit this.

[0029] For example, taking a 5G communication system as an example, the logical structure of a 5G communication system can be as shown in Figure 1. The user equipment (UE) wirelessly accesses and connects to the radio access network (RAN) via the air interface (Uu), and connects to control plane network elements (such as the Access and Mobility Management Function (AMF)) and user plane network elements (such as the User Plane Function (UPF)) within the core network through the RAN. It also connects to a remote data network application server (such as the DNServer) through the user plane network elements, thereby realizing end-to-end transmission and interaction of user service data. In addition, the core network of the 5G communication system also includes the following logical functional entities: Authentication Server Function (AUSF), Unified Data Management (UDM), Session Management Function (SMF), Policy and Charging Control Function (PCF), and Application Function (AF).

[0030] Furthermore, the logical architecture of 5G NG-RAN is shown in Figure 2, which includes several sub-network element nodes and related important interfaces (such as Centralized Unit (CU), Distributed Unit (DU), NG, Xn, F1, Uu interfaces, etc.) according to the 3GPP RAN specification. Additionally, the control plane / user plane protocol stack of the 5G communication system Uu air interface is shown in Figures 3 and 4. The user plane protocol stack can include: Application Layer, Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), and Physical Layer (PHY).

[0031] The application layer supports various user applications, such as Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), and Voice over Internet Protocol (VoIP).

[0032] SDAP is used to map Quality of Service (QoS) streams to radio bearers and to tag packets with QoS information.

[0033] PDCP is responsible for data compression, encryption, integrity protection, and sequential transmission;

[0034] RLC is used for data segmentation, reassembly, and error correction;

[0035] MAC is responsible for scheduling, multiplexing, and error correction for Hybrid Automatic Repeat Request (HARQ).

[0036] PHY is used for the transmission and reception of wireless signals.

[0037] The control plane protocol stack may include: Non-Access Stratum (NAS), Radio Resource Control (RRC), PDCP, RLC, MAC, and PHY.

[0038] The NAS is used to handle signaling between the UE and the core network, including registration, authentication, and session management.

[0039] RRC is used to manage radio resources, including cell handover, radio bearer configuration, and UE connection status management;

[0040] The other layers of the control plane are similar to those of the user plane, except that the control plane processes signaling data.

[0041] Under the current 3GPP network mechanism, the parameter configuration message receiver (e.g., UE or a downstream node in the network) typically accepts all parameter configurations from the parameter configuration message sender (e.g., base station (gNB) or an upstream node in the network) (or rejects all parameter configurations from the parameter message sender). However, this approach may result in improper parameter configuration, leading to a degraded communication network performance. To address this, the technical solution provided in this application integrates an artificial intelligence module into the network element nodes of the wireless communication system. This AI module, based on its own converged capabilities of sensing, computing, and intelligence, can configure network function parameters and better understand, analyze, and evaluate the rationality of network function parameter configurations. This allows for the derivation of more suitable network function parameter configurations. In other words, the network element nodes in this application can negotiate parameters through their integrated AI modules and immediately apply the negotiated parameters in the current negotiation process, achieving more suitable parameter configurations for specific network function sessions, thereby improving the performance of the wireless communication network.

[0042] For example, taking the parameter configuration between the RAN and UE as an example, as shown in Figure 5, in the traditional technology, the RAN determines and configures all Radio Resource Control (RRC) parameters for the UE. However, in the technical solution provided in this application embodiment, both the RAN and the UE are integrated with artificial intelligence modules. The RAN only configures some parameters for the UE, and the remaining parameters can be negotiated and determined with the UE for the specific network function of this round. The UE can analyze and evaluate the parameters sent by the RAN through the air interface based on its own wireless space environment, user behavior characteristics, dynamic trends of multiple services, and other background information, and deduce whether there are more suitable and optimized parameter configurations, or determine whether the RAN's parameter configuration may lead to a subsequent performance degradation of the UE. That is, the RAN only configures some parameters for the serving UE, and the remaining parameters are determined and configured by the serving UE itself.

[0043] Among them, the aforementioned artificial intelligence module possesses a relatively advanced level of autonomous intelligence. It can provide a hyper-converged service that integrates sensing, computing, and intelligence throughout the entire lifecycle, from user intent to closed-loop execution, as shown in Figure 6. The core elements of the artificial intelligence module include: "intent perception," "task objectives," "role setting," and "tool knowledge," etc. The specific analysis of each element is as follows:

[0044] "Intent perception": the definition of input information and how to provide customized artificial intelligence services in combination with specific scenarios and contexts;

[0045] "Task objectives" include: information acquisition, interpretation (weak analysis), decision-making, execution, analysis (deep analysis), speculation, planning, and generation. Network element nodes at different levels have the ability to perform tasks of different types and sizes.

[0046] "Role Setting" (Identity Certificate): Controller, Organizer, Assistant, Defender, and Executor, etc.;

[0047] "Tools and knowledge": Various types of data, knowledge, experience, and tools both inside and outside the system.

[0048] In different communication scenarios and use cases, the various elements of the artificial intelligence module can be defined and designed according to actual needs to meet the parameter negotiation requirements of different communication scenarios and use cases.

[0049] For ease of description, in the following embodiments, the parameter configuration message sender is referred to as the first network element, and the parameter configuration message receiver is referred to as the second network element. In one embodiment, optionally, the first network element includes at least one of the following: base station, CU, DU, AMF, SMF, PCF, and other network elements or logical functional entities defined by the 3GPP system; the second network element includes at least one of the following: UE, base station, CU, DU, AMF, SMF, PCF, and other network elements or logical functional entities defined by the 3GPP system.

[0050] Figure 7 is a flowchart illustrating a parameter configuration method provided in an embodiment of this application. This method is applied to a first network element, and as shown in Figure 7, the method may include:

[0051] S701. Send a configuration request message to the second network element; wherein, the configuration request message includes target parameters configured by the first network element for the current round of specific network function session, and at least some of the target parameters are parameters to be negotiated by the second network element for the current round of specific network function session.

[0052] S702, Receive a configuration response message sent by the second network element; wherein the configuration response message includes the parameter value of the parameter to be negotiated determined by the second network element, and the parameter value is applied to the specific network function session in this round.

[0053] Specifically, based on the requirements of a specific network function session, the first network element initiates a parameter negotiation process with the second network element, sending a configuration request message. This message includes target parameters configured by the first network element for this specific network function session. Some or all of these parameters are negotiable parameters that can be negotiated with the second network element for this specific network function session. In other words, the first network element provides the parameters to be negotiated, and the second network element determines and configures their values. The first and second network elements can negotiate parameters for this specific network function session, making the parameters configured for it more suitable and thus improving the performance of the wireless communication network. The target parameter values ​​can be specific numerical values ​​(e.g., 1, 2, 3, 4) or numerical ranges (e.g., [1-4]).

[0054] Optionally, a specific network function session may include at least: communication control plane signaling procedures, communication user plane data sessions, and other new service plane data sessions.

[0055] Optionally, the first network element and the second network element may integrate an artificial intelligence module, and the two can negotiate parameters through the integrated artificial intelligence module.

[0056] After receiving the configuration request message, the second network element parses the message and identifies the parameters to be negotiated that require bilateral negotiation. Based on the integrated artificial intelligence module, it performs local analysis and evaluation to determine the parameter values ​​to be negotiated. The parameter values ​​to be negotiated determined by the second network element can be specific numerical values ​​(e.g., 1, 2) or numerical ranges (e.g., [1-2]).

[0057] Furthermore, the second network element sends the parameter value of the parameter to be negotiated in the configuration response message to the first network element. The first network element receives the configuration response message sent by the second network element, obtains the parameter value of the parameter to be negotiated carried in the configuration response message, and applies the parameter value to the specific network function session in this round.

[0058] Optionally, the parameter values ​​of the parameters to be negotiated in the configuration request message sent by the first network element are null and / or non-null. In one implementation, the first network element configures the parameter values ​​of some parameters only for this round of specific network function session, while leaving the parameter values ​​of some parameters blank and pending determination. The parameters with blank and pending parameter values ​​can be called blank parameters. The second network element determines the parameter values ​​of the blank parameters based on the artificial intelligence module and feeds back the parameter values ​​of the blank parameters to the first network element.

[0059] In another implementation, the first network element configures the parameter values ​​of all parameters involved in the current round of specific network function session, and indicates or marks some parameters as parameters to be negotiated with the second network element for the current round of specific network function session. That is, the first network element provides the parameter values ​​of the parameters to be negotiated, and the second network element updates the parameter values ​​of the parameters to be negotiated based on the artificial intelligence module and feeds back the updated parameter values ​​to the first network element.

[0060] The second network element can determine the parameter value of the parameter to be negotiated based on at least one of the following reference information: the parameter suggestion value of the parameter to be negotiated provided by the first network element, the historical similar experience value of the second network element, historical service-related performance statistics, local status information, user preference data, self-protection data, and pre-simulation prediction data.

[0061] The suggested values ​​of the parameters mentioned above can be determined by the first network element based on its local conditions, business needs and historical data. They provide initial parameter values ​​for parameter negotiation, which facilitates further optimization by the second network element.

[0062] Historical similar experience values ​​are the optimal parameter configuration experiences accumulated by the second network element in similar past scenarios. These experiences can include which parameter configurations have effectively improved network performance under specific service loads, user behaviors, or network environments. By using historical similar experience values, we can provide a reference for current decisions, reduce the probability of repeating incorrect configurations, and accelerate the parameter optimization process.

[0063] Historical service-related performance statistics refer to statistical data related to service performance collected during the network's historical operation, such as throughput, latency, and packet loss rate. This data reflects the network's actual performance under different configurations. By analyzing historical service-related performance statistics, second-level network elements can be assisted in evaluating the impact of different parameter configurations on service performance, thereby providing more optimal configurations.

[0064] Local status information refers to the operational status information of the second network element itself, including resource usage, load level, and fault status. Analyzing local status information ensures that the provided parameter values ​​match its actual operational capabilities.

[0065] User preference data reflects users' preferences for network services, such as the need for low latency or high throughput. This data may come from user feedback, application layer logs, or user behavior analysis. By analyzing user preference data, configured parameter values ​​can be made closer to user needs, thus improving the user experience.

[0066] Self-protection data refers to data collected to prevent network failures or performance degradation, including redundant resource status and backup path information. By analyzing self-protection data, the provided parameter values ​​enable the network to recover quickly and maintain service quality in the event of a failure.

[0067] Pre-simulation prediction data refers to the predicted results of network performance based on parameter configurations calculated in advance using simulation models. This data, generated based on network models and historical data, is used to assess the potential effects of future configurations, assisting secondary network elements in anticipating the potential impact of parameter adjustments and avoiding unfavorable configurations.

[0068] In some implementations, the artificial intelligence module can employ machine learning or deep learning algorithms to determine the parameter values ​​to be negotiated. For example, algorithms such as linear regression, logistic regression, random forest, neural networks, or reinforcement learning can be used to comprehensively process the parameter suggestions provided by the first network element, historical similar experience values ​​from the second network element, historical service-related performance statistics, local status information, user preference data, self-protection data, and pre-simulation prediction data to obtain the parameter values ​​to be negotiated.

[0069] The second network element determines the parameter values ​​of the parameters to be negotiated by integrating data from multiple sources. The diversification of reference information makes the determined parameter values ​​more suitable, thereby improving the performance of the wireless communication network.

[0070] Optionally, the configuration request message may also include indication or marking information, which is used to indicate or mark parameters to be negotiated in the target parameters. For example, corresponding indication / marking information is set for each parameter in the configuration request message, where indication / marking information "1" indicates that the parameter is a parameter that does not require bilateral negotiation, and indication / marking information "0" indicates that the parameter is a parameter to be negotiated.

[0071] Optionally, the above S702 may include: receiving a configuration response message sent by the second network element; wherein the configuration response message includes the parameter values ​​of all parameters to be negotiated.

[0072] In this process, configuration request messages and configuration response messages are logically tightly coupled. Under this process, the second network element must return the parameter values ​​of all parameters to be negotiated to the first network element using a single configuration response message. As shown in Figure 8, the first network element sends a configuration request message to the second network element. The configuration request message includes at least one of the following: determined parameters and parameters to be negotiated. Both determined parameters and parameters to be negotiated are parameters involved in a specific network function session. Here, determined parameters refer to parameters that have been configured and do not require bilateral negotiation. Parameters to be negotiated include parameters that have been configured but require bilateral negotiation and / or missing parameters that have not been configured and require bilateral negotiation. The second network element determines the parameter values ​​of the parameters to be negotiated and returns the parameter values ​​of all parameters to be negotiated to the first network element through a single configuration response message.

[0073] Optionally, the above S702 may include: receiving multiple configuration response messages sent by the second network element at different times; wherein each configuration response message includes some or all of the parameter values ​​of the parameters to be negotiated.

[0074] The configuration request message and configuration response message can also be two loosely coupled processes. Under this process, the second network element can send multiple configuration response messages to the first network element at different times. Each configuration response message can include some or all of the parameter values ​​of the parameters to be negotiated. That is, the parameters to be negotiated can be fed back in batches or modified and updated multiple times, improving the flexibility of parameter configuration. As shown in Figure 9, the first network element sends a configuration request message to the second network element. The configuration request message includes at least one of the following: determined parameters and parameters to be negotiated (here, parameters to be negotiated include parameters that have been configured but require bilateral negotiation and / or missing parameters that have not been configured and require bilateral negotiation). The second network element determines the parameter values ​​of the parameters to be negotiated and uses multiple configuration response messages at different times to feed back some or all of the parameter values ​​of the parameters to be negotiated to the first network element. For example, each configuration response message only contains some of the parameter values ​​of the parameters to be negotiated, but all configuration response messages combined contain the parameter values ​​of all the parameters to be negotiated. For example, each configuration response message contains the parameter values ​​of all parameters to be negotiated, and the subsequent configuration response message is used to update the parameter values ​​of the parameters to be negotiated in the previous configuration response message.

[0075] Optionally, for the same parameter to be negotiated, the parameter value of the same parameter to be negotiated sent by the second network element at the latest time point is applied to the specific network function session in this round.

[0076] In this process, the second network element can feed back the parameter values ​​of the parameters to be negotiated at different time points. The first network element receives the parameter values ​​of the parameters to be negotiated fed back by the second network element at different time points. The parameter value of the same parameter to be negotiated that the second network element updates and sends at the latest time point is applied to the specific network function session in this round. Since the parameter value of the parameter to be negotiated sent at the latest time point is the most recently determined, it is more adapted to the current wireless network environment and user needs, making the fed-back parameter value more accurate. Applying the parameter value fed back at the latest time point can further improve the performance of the wireless communication network.

[0077] Optionally, the configuration request message may be a reused existing message (e.g., Time Division Duplexing (TDD) configuration request, Quality of Experience (QoE) configuration message, Power Control configuration message, Random Access configuration message, Discontinuous Reception (DRX) configuration message, etc.) and / or a dedicated configuration request message.

[0078] Optionally, the configuration response message mentioned above may be a reused existing message (e.g., TDD configuration response, QoE configuration response, power control configuration response, random access configuration response, DRX configuration response, etc.) and / or a dedicated configuration response message.

[0079] Optionally, the aforementioned parameters to be negotiated can be parameters that need to be negotiated between any two network elements or logical functional entities defined by the 3GPP system for this round of specific network function sessions. Optionally, the first network element is one of the terminal equipment and the base station, and the second network element is the other of the terminal equipment and the base station. The parameters to be negotiated between the first network element and the second network element include at least one of the following: parameters related to dynamic TDD time slot configuration, parameters related to QoE measurement reporting, parameters related to uplink power control, parameters related to uplink multiple-input multiple-output (MIMO) transmission, parameters related to random access procedures, parameters related to Hybrid Automatic Repeat Request (HARQ), parameters related to DRX, parameters related to clock synchronization, parameters related to dynamic sounding reference signal resource configuration, parameters related to Channel State Information (CSI) reporting, and parameters related to secondary cell (SCell) sleep.

[0080] Optionally, the first network element is one of the base station and the AMF, and the second network element is the other of the base station and the AMF. The parameters to be negotiated between the first network element and the second network element include at least one of the following: parameters related to the initial registration process, parameters related to cell handover, parameters related to dynamic allocation of network slices, parameters related to edge computing, parameters related to the network slice selection process, parameters related to the terminal device registration and update process, parameters related to the terminal device uplink resource allocation, parameters related to mobility restriction updates, and parameters related to network load balancing.

[0081] Optionally, the first network element is one of the CU and DU, and the second network element is the other of the CU and DU. The parameters to be negotiated between the first network element and the second network element include at least one of the following: parameters related to the allocation of physical resource blocks (PRB) when the F1 interface is established, parameters related to uplink scheduling of the terminal device, parameters related to dynamic TDD configuration, parameters related to PDCP retransmission, handover parameters, HARQ retransmission count, uplink power control parameters, radio link control (RLC) mode, and delay-sensitive service scheduling parameters.

[0082] Figure 10 is a schematic flowchart of another parameter configuration method provided in an embodiment of this application. This method is applied to a second network element, and as shown in Figure 10, the method may include:

[0083] S1001, Receive a configuration request message sent by the first network element; wherein the configuration request message includes target parameters configured by the first network element for the current round of specific network function session, and at least some of the target parameters are parameters to be negotiated by the second network element for the current round of specific network function session.

[0084] S1002. Determine the parameter values ​​of the parameters to be negotiated.

[0085] S1003. Send a configuration response message to the first network element; wherein the configuration response message includes parameter values, which are applied to the specific network function session in this round.

[0086] Optionally, the configuration request message may also include indication or marking information used to indicate or mark parameters to be negotiated in the target parameters.

[0087] Optionally, the second network element may also determine the parameter to be negotiated in the target parameters based on at least one of the following:

[0088] Determine the parameters to be negotiated based on the instructions or marking information;

[0089] Parameters with null values ​​in the target parameters are identified as parameters to be negotiated.

[0090] For example, corresponding indication / marking information is set for each parameter in the configuration request message. Indication / marking information "1" indicates that the parameter does not require bilateral negotiation, and indication / marking information "0" indicates that the parameter is a parameter to be negotiated. The second network element can identify the parameter corresponding to indication / marking information "0" as a parameter to be negotiated.

[0091] In cases where the configuration request message contains missing parameters, missing parameters with empty values ​​in the target parameters can be identified as parameters to be negotiated.

[0092] Optionally, the reference information used by the second network element to determine the parameter values ​​to be negotiated includes at least one of the following: suggested parameter values ​​provided by the first network element, historical similar experience values ​​from the second network element, historical service-related performance statistics, local status information, user preference data, self-protection data, and pre-simulation prediction data. By comprehensively determining the parameter values ​​to be negotiated through data from multiple sources, the second network element obtains more suitable parameter values ​​through diversified reference information, thereby improving the performance of the wireless communication network.

[0093] Optionally, the second network element sending the configuration response message includes: sending a configuration response message to the first network element; wherein, the configuration response message includes the parameter values ​​of all the parameters to be negotiated. Alternatively, the second network element sending the configuration response message includes: sending multiple configuration response messages to the first network element at different times; wherein, each configuration response message includes some or all of the parameter values ​​of the parameters to be negotiated.

[0094] In this embodiment, the first network element and the second network element negotiate parameters for the current round of specific network function session through signaling interaction, so that the parameters configured for the current round of specific network function session are more suitable, thereby improving the performance of the wireless communication network.

[0095] Below, some exemplary implementation methods are listed to explain the parameter configuration method provided in the above embodiments of this application. In the first exemplary implementation method, the first network element is denoted as the base station, and the second network element is denoted as the UE. That is, the base station and the UE can negotiate and configure parameters, and the negotiated parameter values ​​are applied to the current round of specific network function session.

[0096] The first scenario is that some parameters in the configuration request message are missing parameters. For example, the base station does not need to obtain relevant information for initial parameter configuration, and the terminal device (UE) determines and configures the parameter values ​​of the missing parameters.

[0097] Scenario 1: Dynamic TDD Slot Configuration

[0098] The base station can dynamically adjust the TDD uplink / downlink time slot ratio to adapt to sudden uplink traffic demands, but some parameters can be intelligently filled in by the UE. Missing parameters can be uplink / downlink time slot parameters and dynamic frame number offset.

[0099] Implementation Process: The base station sends a TDD configuration request message, which includes periodicity information, uplink / downlink time slot ratio, and dynamic frame number offset. The base station only configures the periodicity information parameter value; the uplink / downlink time slot ratio and dynamic frame number offset parameter values ​​are left blank. The UE receives the TDD configuration request message, generates the uplink / downlink time slot ratio and dynamic frame number offset parameter values ​​based on its internally integrated artificial intelligence module, and feeds them back to the base station via a TDD configuration response message. Upon receiving the feedback, the base station immediately applies the time slot configuration parameters fed back by the UE (which include the uplink / downlink time slot ratio and dynamic frame number offset), that is, it updates the cell resource allocation for this round using these time slot configuration parameters.

[0100] Scenario 2: QoE Measurement and Reporting Strategy

[0101] The UE reports video stream QoE data on demand, but the reporting period and trigger threshold can be determined and configured by the UE. Missing parameters: reporting period and trigger threshold.

[0102] Implementation Process: The base station initiates a QoE configuration request message, configuring only some parameters from the message, leaving some parameters blank. These blank parameters can be the reporting period and trigger threshold. The UE receives the QoE configuration request message, generates the reporting period and trigger threshold parameter values ​​based on its internally integrated artificial intelligence module, and sends these values ​​back to the base station via a configuration response message. Upon receiving the feedback, the base station immediately applies the parameter values ​​provided by the UE.

[0103] Scenario 3: Dynamic adaptation of uplink power control parameters

[0104] The base station configures the UE uplink transmit power control strategy, but some parameters are filled in by the UE based on the channel status. Missing parameters: nominal power reference value, path loss compensation factor.

[0105] Implementation process: The base station sends a power control configuration request message, specifying only the mode as dynamic, with the nominal power reference value and path loss compensation factor left blank. The UE generates the nominal power reference value and path loss compensation factor based on its internally integrated artificial intelligence module and feeds them back to the base station. The base station immediately applies the parameter values ​​provided by the UE and adjusts its uplink scheduling strategy.

[0106] Scenario 4: Dynamic adaptation of MIMO layer number

[0107] The base station configures the UE's uplink MIMO transmission, but the maximum number of layers can be filled by the UE based on the current channel conditions. Missing parameters: maximum uplink MIMO layers and precoding granularity.

[0108] Implementation process: The base station sends a MIMO configuration request message, specifying only the mode as full-dimensional MIMO, leaving the uplink maximum MIMO layer number and precoding granularity blank. The UE generates the uplink maximum MIMO layer number and precoding granularity based on its internally integrated artificial intelligence module and feeds them back to the base station. The base station immediately applies the parameter values ​​fed back by the UE and schedules uplink configuration layer MIMO transmission.

[0109] Scenario 5: Random Access Power Ramp-Up Step Size Optimization

[0110] The UE dynamically adjusts the power ramp-up step size during random access; this parameter is missing from the base station parameters. Missing parameters: power ramp-up step size and maximum preamble retransmission count.

[0111] Implementation process: The base station sends a random access configuration request message, specifying only the response window, the empty power ramp step size, and the maximum number of preamble retransmissions. The UE generates the power ramp step size and the maximum number of preamble retransmissions based on its internally integrated artificial intelligence module and feeds them back to the base station. The base station receives the parameter values ​​fed back by the UE and immediately applies them, that is, it updates the cell random access policy using the parameter values ​​fed back by the UE.

[0112] The second scenario: Some parameters in the configuration request message allow the current process to be modified and updated (in each scenario under this scenario, these parameters are recorded as parameters to be negotiated). For example, the base station can obtain relevant information to perform initial parameter configuration, but the UE is more familiar with the local situation and user customization needs, so the UE decides and configures the parameter values ​​of the parameters to be negotiated.

[0113] Scenario 1: Optimization of maximum HARQ retransmission count

[0114] The base station recommends a maximum number of HARQ retransmissions, which the UE adjusts immediately based on its local bit error rate. Parameter to be negotiated (to be modified immediately): Maximum number of HARQ retransmissions.

[0115] Implementation Process: The base station sends a HARQ configuration request message, marking the maximum HARQ retransmission count as a parameter to be negotiated. The UE, based on its internally integrated AI module and considering the base station's suggested value for the maximum HARQ retransmission count along with other relevant information, generates a new maximum HARQ retransmission count and feeds it back to the base station. The base station immediately applies the new maximum HARQ retransmission count to update the HARQ process. For example, the UE modifies the base station's suggested maximum HARQ retransmission count from 4 to 3 based on its internally integrated AI module and feeds it back; the base station immediately applies the new value and updates the HARQ process.

[0116] Scenario 2: DRX periodic adjustment for Network Energy Saving (NES)

[0117] The base station proposes extending the DRX period to save energy, and the UE negotiates an update based on service latency requirements. Parameter to be negotiated (to be modified immediately): DRX period.

[0118] Implementation Process: The base station sends a DRX configuration request message, marking the DRX period as a parameter to be negotiated. The UE, based on its internally integrated AI module and considering the base station's suggested value for the DRX period along with other relevant information, generates a new DRX period and feeds it back to the base station. The base station immediately applies the new DRX configuration. For example, the UE, based on its internally integrated AI module, adjusts the DRX period provided by the base station from 160ms to 80ms and feeds it back to the base station. The base station accepts the modification and immediately applies the new DRX configuration.

[0119] Scenario 3: Clock synchronization precision negotiation

[0120] The base station requires the UE to synchronize its clock within a specified range, which the UE adjusts based on its hardware capabilities. Parameters to be negotiated (to be modified immediately): The allowable time synchronization error range for the UE during uplink transmission.

[0121] Implementation process: The base station sends a clock synchronization request message, marking the allowable time synchronization error range for the UE in uplink transmission as a parameter to be negotiated. The UE, based on its internally integrated artificial intelligence module, widens or narrows the time synchronization error range provided by the base station and provides feedback. The base station immediately applies the new value and updates the UE synchronization policy.

[0122] Scenario 4: Resource Configuration for Dynamic Sounding Reference Signal (SRS)

[0123] The base station recommends the SRS period, which the UE should adjust immediately according to service requirements. Parameters to be negotiated (to be modified immediately): SRS period, confirmed parameter: SRSBandwidth = 4RB.

[0124] Implementation Process: The base station sends an SRS configuration request message, marking the SRS period as a parameter to be negotiated. The UE updates the SRS period provided by the base station based on its internally integrated artificial intelligence module and reports it back. The base station immediately applies the updated value and updates the SRS resource configuration. For example, the UE adjusts the SRS period from 20ms to 10ms based on its internally integrated artificial intelligence module and reports it back to the base station. The base station accepts the modification and immediately updates the SRS resource configuration.

[0125] Scenario 5: Dynamic Adjustment of CSI Reporting Cycle

[0126] The base station recommends the CSI reporting cycle, which the UE should immediately modify based on its real-time service requirements. Parameter to be negotiated (to be modified immediately): CSI reporting cycle.

[0127] Implementation process: The base station sends a CSI configuration request message, marking the CSI reporting period as a parameter to be negotiated. The UE updates and adjusts the CSI reporting period provided by the base station based on its internally integrated artificial intelligence module and feeds it back. The base station immediately applies the updated value. For example, the UE adjusts the CSI reporting period from 20ms to 5ms based on its internally integrated artificial intelligence module and feeds it back to the base station. The base station immediately applies the new period and receives high-frequency CSI reports.

[0128] Scenario 6: SCell activation delay optimization in Carrier Aggregation (CA)

[0129] The base station proposes the SCell deactivation timer duration, which the UE adjusts according to multi-connection requirements. Parameter to be negotiated (to be modified immediately): SCell deactivation timer duration.

[0130] Implementation Process: The base station sends a CA configuration request message, marking the SCell deactivation timer duration as a parameter to be negotiated. The UE updates and adjusts the SCell deactivation timer duration provided by the base station based on its internally integrated artificial intelligence module and reports the updated value back. The base station immediately applies the updated value. For example, the UE shortens the SCell deactivation timer duration from 100ms to 40ms based on its internally integrated artificial intelligence module and reports it back to the base station. The base station accepts the modification and immediately implements the SCell fast sleep policy.

[0131] In the second exemplary embodiment, the first network element is denoted as the base station and the second network element is denoted as the AMF. That is, the base station and the AMF can negotiate and configure parameters, and the negotiated parameter values ​​are applied to the specific network function session in this round.

[0132] The first scenario is that some parameters in the configuration request message are missing parameters. For example, the base station does not need to obtain relevant information for initial parameter configuration, and the AMF determines and configures the parameter values ​​of the missing parameters.

[0133] Scenario 1: Parameter negotiation in the initial registration process

[0134] During the initial registration process, the base station and the AMF negotiate the UE's network access parameters. Missing parameters: globally unique AMF identifier type and public terrestrial mobile network identifier.

[0135] Implementation Process: The base station sends an initial registration request message to the AMF (Application Management Function). The parameter values ​​for the globally unique AMF identifier type and the public land mobile network identifier in this message are currently undetermined. The AMF generates the parameter values ​​for the globally unique AMF identifier type and the public land mobile network identifier based on its internally integrated artificial intelligence module and sends them back to the base station. The base station immediately applies the parameter values ​​returned by the AMF to complete the registration process.

[0136] Scenario 2: Switching target AMF parameter configurations in the scene

[0137] When a UE switches to a new cell, the base station negotiates relevant parameters with the target AMF. Missing parameters: Target AMF identifier and network slice selection assistance information.

[0138] Implementation Process: The base station sends a handover request message to the target AMF (Application Not Found). The parameter values ​​for the target AMF identifier and network slice selection auxiliary information in this message are missing and pending. The target AMF generates the parameter values ​​for the target AMF identifier and network slice selection auxiliary information based on its integrated artificial intelligence module and feeds them back to the base station. The base station uses the parameter values ​​returned by the target AMF to complete the handover process.

[0139] Scenario 3: Parameter negotiation in dynamic allocation of network slices

[0140] In scenarios involving dynamically allocated network slices, the base station negotiates network slice-related parameters with the AMF. Missing parameters: default slice identifier and slice distinguisher.

[0141] Implementation Process: The base station sends a network slice allocation request message to the AMF (Application Function). The default slice identifier and slice distinguisher parameters in this message are left undetermined. The AMF generates the default slice identifier and slice distinguisher parameters using its integrated artificial intelligence module and sends them back to the base station. The base station then uses the parameters returned by the AMF to complete the slice allocation process.

[0142] Scenario 4: Parameter negotiation in Mobile Edge Computing (MEC) scenarios

[0143] In scenarios supporting MEC, the base station and AMF negotiate edge computing-related parameters. Missing parameters: MEC server address and MEC service type.

[0144] Implementation Process: The base station sends a MEC service request message to the AMF (Advanced Management Function). The MEC server address and MEC service type parameters in this message are missing and pending. The AMF generates the MEC server address and MEC service type parameters using its integrated artificial intelligence module and sends them back to the base station. The base station then uses the parameters returned by the AMF to complete the MEC service process.

[0145] The second scenario: Some parameters in the configuration request message allow the current process to be modified and updated (in each scenario under this case, these parameters are recorded as parameters to be negotiated). For example, the base station can obtain relevant information to perform initial parameter configuration, but the AMF determines and configures the parameter values ​​of the parameters to be negotiated.

[0146] Scenario 1: Parameter negotiation in network slice selection

[0147] The base station negotiates network slice selection parameters with the AMF to support the UE's network slice requirements. Parameters to be negotiated: A list of auxiliary information for single network slice selection.

[0148] Implementation Process: The base station sends a network slice selection request message to the AMF (Application Function), which includes initial single network slice selection auxiliary information list values. The AMF generates a new single network slice selection auxiliary information list value based on its internally integrated artificial intelligence module and feeds it back to the base station. The base station immediately applies the single network slice selection auxiliary information list value returned by the AMF to complete the network slice selection process.

[0149] Scenario 2: Parameter modification in the registration and update process

[0150] During the registration update process, the base station negotiates and updates the UE's registration parameters with the AMF. Parameters to be negotiated: AMF identifier and Public Land Mobile Network identifier.

[0151] Implementation Process: The base station sends a registration update request message to the AMF (Application Management Function), which includes the initial AMF identifier value and Public Land Mobile Network (PLN) identifier value. The AMF generates new AMF identifier values ​​and PLAN identifier values ​​based on its internally integrated artificial intelligence module and sends them back to the base station. The base station immediately applies the parameter values ​​returned by the AMF to complete the registration update process.

[0152] Scenario 3: Parameter negotiation in UE uplink resource requests

[0153] When a UE requests uplink resources, the base station negotiates relevant parameters with the AMF. Parameter to be negotiated: Uplink resource indication.

[0154] Implementation process: The base station sends an uplink resource request message to the AMF (Advanced Management Function), which includes an initial uplink resource indication value. The AMF generates a new uplink resource indication value based on its internal artificial intelligence module and sends it back to the base station. The base station immediately applies the parameter values ​​returned by the AMF to complete the uplink resource allocation process.

[0155] Scenario 4: Parameter negotiation in mobility restriction updates

[0156] In the UE mobility restriction update scenario, the base station and AMF negotiate relevant parameters. Parameter to be negotiated: Mobility restriction list.

[0157] Implementation Process: The base station sends a Mobility Restriction Update Request message to the AMF (Active Mobility Restriction Module), which contains the initial mobility restriction list values. The AMF generates new mobility restriction list values ​​based on its integrated artificial intelligence module and sends them back to the base station. The base station immediately applies the parameter values ​​returned by the AMF to complete the mobility restriction update process.

[0158] Scenario 5: Parameter Modification in Network Load Balancing

[0159] In network load balancing scenarios, the base station and the AMF negotiate load balancing-related parameters. The parameter to be negotiated is: load balancing.

[0160] Implementation process: The base station sends a load balancing request message to the AMF (Advanced Management Function), which contains initial load balancing parameter values. The AMF generates new load balancing parameter values ​​based on its integrated artificial intelligence module and sends them back to the base station. The base station immediately applies the parameter values ​​returned by the AMF to complete the load balancing process.

[0161] In the third exemplary embodiment, the first network element is denoted as CU and the second network element is denoted as DU. That is, CU and DU can negotiate and configure parameters, and the negotiated parameter values ​​are applied to the specific network function session in this round.

[0162] The first scenario: Some parameters in the configuration request message are missing parameters. For example, the CU does not need to obtain relevant information for initial parameter configuration, and the DU determines and configures the parameter values ​​of the missing parameters.

[0163] Scenario 1: PRB resource allocation during F1 interface establishment

[0164] When establishing an F1 interface between the CU and DU, the CU initiates a request but does not specify a PRB resource allocation strategy. This strategy is dynamically determined by the DU based on the current load. The parameters involved include the PRB allocation mode, time slot format, and number of frequency domain resource blocks.

[0165] Implementation Process: The CU sends an F1 Setup Request message, in which the parameters for PRB allocation mode and time slot format are empty. The DU determines the parameter values ​​for PRB allocation mode and time slot format based on its internally integrated AI module and feeds them back to the CU. Upon receiving the feedback, the CU immediately applies these parameter values ​​to complete the F1 interface configuration. For example, the DU determines the PRB allocation mode to be dynamic and the time slot format to be Format2 based on its internally integrated AI module and feeds it back to the CU via an F1 Setup Response message. Upon receiving the feedback, the CU immediately applies these parameter values ​​to complete the F1 interface configuration.

[0166] Scenario 2: Scheduling parameter configuration during UE context establishment

[0167] When the CU establishes a context for the UE, it does not specify the uplink scheduling request (SR) period. This uplink SR period is dynamically filled by the DU based on channel quality. The parameters involved include the uplink SR period (sr-Periodicity) and the BWP configuration (bwp-Id).

[0168] Implementation process: The CU sends a UE Context Setup Request message, in which the parameter value for the uplink SR period in the UE Context Setup Request message is empty. The DU determines the uplink SR period based on its internally integrated artificial intelligence module and feeds it back to the CU via a UE Context Setup Response message. Upon receiving the feedback, the CU immediately applies this parameter value to configure UE uplink scheduling.

[0169] Scenario 3: Parameter negotiation for dynamic TDD configuration

[0170] The CU requests dynamic TDD configuration but does not specify the uplink / downlink time slot ratio. This ratio will be dynamically filled by the DU based on service requirements. The parameters involved include the uplink / downlink time slot ratio and special time slot configuration.

[0171] Implementation process: The CU sends a TDD Configuration Request message, in which the uplink / downlink slot ratio parameter is empty. The DU determines the uplink / downlink slot ratio parameter value based on its internally integrated artificial intelligence module and feeds it back to the CU via a TDD Configuration Response message. Upon receiving the feedback, the CU immediately applies the parameter value to configure and update the cell frame structure.

[0172] Scenario 4: PDCP Repeat Transmission Configuration

[0173] The CU configures the PDCP layer's retransmission function, but does not specify the number of PDCP repetitions. This number of PDCP repetitions is dynamically filled by the DU based on link reliability requirements. The relevant parameters include the number of PDCP repetitions.

[0174] Implementation process: The CU sends a PDCP Configuration Request message, in which the parameter value for the PDCP repetition count is empty. The DU determines the PDCP repetition count based on its internally integrated artificial intelligence module and provides feedback via a PDCP Configuration Response message. Upon receiving the feedback, the CU immediately applies this parameter value to enhance the reliability of data transmission at the edge UE.

[0175] The second scenario: Some parameters in the configuration request message allow the current process to be modified and updated (in each scenario under this case, these parameters are recorded as parameters to be negotiated). For example, the CU can obtain relevant information for initial parameter configuration, but the DU determines and configures the parameter values ​​of the parameters to be negotiated.

[0176] Scenario 1: Switching Parameters for Negotiation

[0177] CU suggests switching the offset value of event A3. The offset value of marker A3 is a parameter to be negotiated and determined and configured by DU.

[0178] Implementation process: The CU sends a Handover Configuration Request message, marking the offset value of A3 as a parameter to be negotiated. The DU modifies the offset value of A3 provided by the CU to the new offset value based on its internally integrated artificial intelligence module, and feeds back to the CU via a Handover Configuration Response message. Upon receiving the feedback, the CU immediately applies the new offset value of A3 to update the handover strategy.

[0179] Scenario 2: Adjustment of HARQ retransmission count

[0180] The CU recommends the maximum number of HARQ retransmissions, marks the maximum number of HARQ retransmissions as a parameter to be negotiated, and allows the DU to modify it immediately.

[0181] Implementation process: The CU sends a HARQ Configuration Request message, marking the maximum HARQ retransmission count as a parameter to be negotiated. The DU, based on its internally integrated AI module, adjusts the maximum HARQ retransmission count provided by the CU to the new maximum HARQ retransmission count and feeds it back to the CU via a HARQ Configuration Response message. Upon receiving the feedback, the CU immediately applies the new maximum HARQ retransmission count to reduce retransmission latency.

[0182] Scenario 3: Uplink power control parameter update

[0183] The CU recommends the uplink nominal power, but the DU needs to adjust it based on coverage requirements. The parameters involved include the nominal power baseline and the road loss compensation factor.

[0184] Implementation Process: The CU sends a Power Control Configuration Request message, marking the nominal power reference value and road loss compensation factor as parameters to be negotiated. The DU, based on its internally integrated artificial intelligence module, adjusts the nominal power reference value and road loss compensation factor suggested by the CU to new nominal power reference values ​​and new road loss compensation factors, and feeds this back to the CU via a Power Control Configuration Response message. Upon receiving the feedback, the CU immediately applies the new nominal power reference value and new road loss compensation factor to optimize uplink power allocation.

[0185] Scenario 4: RLC mode switching negotiation

[0186] CU recommends using Unacknowledged Mode (UM) for the RLC layer, but DU is allowed to modify it based on the business type. The parameters involved include the RLC mode.

[0187] Implementation Process: The CU sends an RLC Configuration Request message, marking the RLC mode as a parameter to be negotiated. The DU, based on the VoIP service requirements and using its internally integrated AI module, modifies the RLC mode from UM to Acknowledged Mode (AM) and provides feedback via an RLC Configuration Response message. Upon receiving the feedback, the CU immediately applies AM to ensure a low packet loss rate for voice services.

[0188] Scenario 5: Negotiation of scheduling parameters for latency-sensitive services

[0189] The CU suggests scheduling priorities, but the DU needs to adjust these priorities based on the current service queue. The parameters involved include scheduling priorities.

[0190] Implementation Process: The CU sends a QoS Configuration Request message, marking the scheduling priority as a parameter to be negotiated. The DU modifies the scheduling priority to the new priority based on its internally integrated artificial intelligence module and feeds back the changes via a QoS Configuration Response message. Upon receiving the feedback, the CU immediately applies the new scheduling priority to ensure critical latency-sensitive services are protected.

[0191] Figure 11 is a schematic diagram of a parameter configuration device provided in an embodiment of this application. This device can also be called an artificial intelligence module and is integrated into a first network element. As shown in Figure 11, the device may include a transmitting module 1101 and a receiving module 1102.

[0192] Specifically, the sending module 1101 is used to send a configuration request message to the second network element; wherein, the configuration request message includes target parameters configured by the first network element for the current round of specific network function session, and at least some of the target parameters are parameters to be negotiated by the second network element for the current round of specific network function session;

[0193] The receiving module 1102 is used to receive a configuration response message sent by the second network element; wherein, the configuration response message includes the parameter value of the parameter to be negotiated determined by the second network element, and the parameter value is applied to the specific network function session in this round.

[0194] Optionally, the parameter value of the parameter to be negotiated in the configuration request message is an empty value and / or a non-empty value.

[0195] Optionally, the configuration request message may further include indication or marking information, which is used to indicate or mark the parameter to be negotiated.

[0196] Optionally, the receiving module 1102 is specifically used to receive a configuration response message sent by the second network element; wherein the configuration response message includes the parameter values ​​of all parameters to be negotiated; or, the receiving module 1102 is specifically used to receive multiple configuration response messages sent by the second network element at different times; wherein each configuration response message includes some or all of the parameter values ​​of the parameters to be negotiated.

[0197] Optionally, for the same parameter to be negotiated, the parameter value of the same parameter to be negotiated sent by the second network element at the latest time point is applied to the specific network function session in this round.

[0198] Optionally, the first network element includes at least one of the following: base station, CU, DU, AMF, session management function SMF, PCF, and other network elements or logical function entities defined by the 3GPP system; the second network element includes at least one of the following: terminal equipment, base station, CU, DU, AMF, SMF, PCF, and other network elements or logical function entities defined by the 3GPP system.

[0199] Optionally, the first network element is one of the terminal equipment and the base station, and the second network element is the other of the terminal equipment and the base station. The parameters to be negotiated include at least one of the following: parameters related to TDD time slot configuration, parameters related to QoE measurement reporting, parameters related to uplink power control, parameters related to uplink MIMO transmission, parameters related to random access procedures, parameters related to HARQ, parameters related to DRX, parameters related to clock synchronization, parameters related to dynamic sounding reference signal resource configuration, parameters related to CSI reporting, and parameters related to SCell sleep.

[0200] Optionally, the first network element is one of the base station and the AMF, and the second network element is the other of the base station and the AMF. The parameters to be negotiated include at least one of the following: parameters related to the initial registration process, parameters related to cell handover, parameters related to dynamic allocation of network slices, parameters related to edge computing, parameters related to the network slice selection process, parameters related to the terminal device registration and update process, parameters related to the terminal device uplink resource allocation, parameters related to mobility restriction updates, and parameters related to network load balancing.

[0201] Optionally, the first network element is one of CU and DU, and the second network element is the other of CU and DU. The parameters to be negotiated include at least one of the following: parameters related to PRB allocation when the F1 interface is established, parameters related to uplink scheduling on the terminal device, parameters related to dynamic TDD configuration, parameters related to PDCP retransmission, handover parameters, HARQ retransmission count, uplink power control parameters, RLC mode, and delay-sensitive service scheduling parameters.

[0202] Figure 12 is a schematic diagram of another structure of the parameter configuration device provided in an embodiment of this application. This device can also be called an artificial intelligence module and is integrated into the second network element. As shown in Figure 12, the device may include: a receiving module 1201, a determining module 1202, and a sending module 1203.

[0203] Specifically, the receiving module 1201 is used to receive a configuration request message sent by the first network element; wherein, the configuration request message includes target parameters configured by the first network element for the current round of specific network function session, and at least some of the target parameters are parameters to be negotiated by the second network element for the current round of specific network function session;

[0204] The determining module 1202 is used to determine the parameter value of the parameter to be negotiated;

[0205] The sending module 1203 is used to send a configuration response message to the first network element; wherein the configuration response message includes the parameter value, which is applied to the specific network function session in this round.

[0206] Optionally, the configuration request message may further include indication or marking information, which is used to indicate or mark the parameter to be negotiated.

[0207] Optionally, the determining module 1202 described above is also used for at least one of the following:

[0208] The parameters to be negotiated are determined based on the indicated or marked information;

[0209] The parameters with null values ​​in the target parameters are identified as the parameters to be negotiated.

[0210] Optionally, the reference information for determining the parameter value by the determining module 1202 includes at least one of the following: the parameter suggestion value of the parameter to be negotiated provided by the first network element, the historical similar experience value of the second network element, historical service-related performance statistics, local status information, user preference data, self-protection data, and pre-simulation prediction data.

[0211] Optionally, the sending module 1203 is specifically used to send a configuration response message to the first network element; wherein the configuration response message includes the parameter values ​​of all parameters to be negotiated; or, the sending module 1203 is specifically used to send multiple configuration response messages to the first network element at different time points; wherein each configuration response message includes some or all of the parameter values ​​of the parameters to be negotiated.

[0212] In one embodiment, a communication device is provided, which may be the first network element or the second network element described in the above embodiments. The internal structure diagram of the communication device is shown in Figure 13. The communication device includes a processor, a memory, a network interface, and a database connected via a system bus. The processor of the communication device provides computing and control capabilities. The memory of the communication device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the communication device stores data generated during parameter configuration. The network interface of the communication device is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a parameter configuration method.

[0213] Those skilled in the art will understand that the structure shown in Figure 13 is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the communication device to which the present application is applied. Specific communication devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0214] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the following steps:

[0215] Send a configuration request message to the second network element; wherein the configuration request message includes target parameters configured by the first network element for the current round of specific network function session, and at least some of the target parameters are parameters to be negotiated by the second network element for the current round of specific network function session;

[0216] The configuration response message sent by the second network element is received; wherein the configuration response message includes the parameter value of the parameter to be negotiated determined by the second network element, and the parameter value is applied to the current round of specific network function session.

[0217] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the following steps:

[0218] Receive a configuration request message sent by a first network element; wherein the configuration request message includes target parameters configured by the first network element for the current round of specific network function session, and at least some of the target parameters are parameters to be negotiated by the second network element for the current round of specific network function session;

[0219] Determine the parameter value of the parameter to be negotiated;

[0220] Send a configuration response message to the first network element; wherein the configuration response message includes the parameter value, which is applied to the current round of specific network function session.

[0221] The computer storage medium in this application embodiment can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. Computer-readable storage media include (a non-exhaustive list): electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), electrically erasable, programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0222] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, the data signals carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0223] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, radio frequency (RF), or any suitable combination thereof.

[0224] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination of programming languages, including object-oriented programming languages ​​(such as Java, Smalltalk, C++, Ruby, and Go) and conventional procedural programming languages ​​(such as the "C" language or similar programming languages). The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network (including a Local Area Network (LAN) or a Wide Area Network (WAN)), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0225] Those skilled in the art will understand that the term user terminal encompasses any suitable type of wireless user equipment, such as mobile phones, portable data processing devices, portable web browsers, or vehicle-mounted mobile stations.

[0226] Generally, the various embodiments of this application can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. For example, some aspects can be implemented in hardware, while others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device, although this application is not limited thereto.

[0227] Embodiments of this application can be implemented by executing computer program instructions through the data processor of a mobile device, for example, in a processor entity, or through hardware, or through a combination of software and hardware. The computer program instructions can be assembly instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages.

[0228] Any block diagram of logical flow in the accompanying drawings of this application may represent program steps, or may represent interconnected logic circuits, modules, and functions, or may represent a combination of program steps and logic circuits, modules, and functions. The computer program may be stored in memory. The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as, but not limited to, read-only memory (ROM), random access memory (RAM), optical storage devices and systems (Digital Multifunction Discs, DVDs, or CDs), etc. Computer-readable media may include non-transitory storage media. The data processor may be of any type suitable to the local technical environment, such as, but not limited to, general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and processors based on multi-core processor architectures.

Claims

1. A parameter configuration method, characterized in that, The method is applied to a first network element and includes: sending a configuration request message to a second network element; wherein the configuration request message includes target parameters configured by the first network element for the current round of specific network function sessions, and at least some of the target parameters are parameters to be negotiated by the second network element for the current round of specific network function sessions; receiving a configuration response message sent by the second network element; wherein the configuration response message includes parameter values ​​of the parameters to be negotiated determined by the second network element, and the parameter values ​​are applied to the current round of specific network function sessions.

2. The method according to claim 1, characterized in that, The parameter value of the parameter to be negotiated in the configuration request message is null and / or non-null.

3. The method according to claim 1, characterized in that, The configuration request message also includes indication or marking information, which is used to indicate or mark the parameter to be negotiated.

4. The method according to claim 1, characterized in that, The step of receiving the configuration response message sent by the second network element includes: receiving a configuration response message sent by the second network element; wherein the configuration response message includes the parameter values ​​of all parameters to be negotiated; or, receiving multiple configuration response messages sent by the second network element at different times; wherein each configuration response message includes some or all of the parameter values ​​of the parameters to be negotiated.

5. The method according to claim 4, characterized in that, For the same parameter to be negotiated, the parameter value of the same parameter to be negotiated sent by the second network element at the latest time point is applied to the current round of specific network function session.

6. The method according to any one of claims 1 to 5, characterized in that, The first network element includes at least one of the following: base station, centralized unit (CU), distributed unit (DU), access and mobility management function (AMF), session management function (SMF), policy control function (PCF), and other network elements or logical functional entities defined by the 3GPP system; the second network element includes at least one of the following: terminal equipment, base station, CU, DU, AMF, SMF, PCF, and other network elements or logical functional entities defined by the 3GPP system.

7. The method according to claim 6, characterized in that, The first network element is one of the terminal equipment and the base station, and the second network element is the other of the terminal equipment and the base station. The parameters to be negotiated include at least one of the following: parameters related to Dynamic Time Division Duplex (TDD) slot configuration, parameters related to Quality of Experience (QoE) measurement and reporting, parameters related to uplink power control, parameters related to uplink Multiple-Input Multiple-Output (MIMO) transmission, parameters related to random access procedures, parameters related to Hybrid Automatic Repeat Request (HARQ), parameters related to Discontinuous Receiver (DRX), parameters related to clock synchronization, parameters related to Dynamic Probe Reference Signal Resource Configuration, parameters related to Channel State Information (CSI) reporting, and secondary cell SCel. The parameters to be negotiated include at least one of the following: parameters related to the initial registration process, parameters related to cell handover, parameters related to dynamic allocation of network slices, parameters related to edge computing, parameters related to the network slice selection process, parameters related to the terminal device registration and update process, parameters related to the terminal device uplink resource allocation, parameters related to mobility restriction updates, and parameters related to network load balancing; or, the first network element is one of the CU and DU, and the second network element is the other of the CU and DU, and the parameters to be negotiated include at least one of the following: parameters related to the allocation of physical resource blocks (PRB) during F1 interface establishment, parameters related to terminal device uplink scheduling, parameters related to dynamic TDD configuration, parameters related to repeated transmission of packet data aggregation protocol (PDCP), handover parameters, HARQ retransmission count, uplink power control parameters, RLC mode, and latency-sensitive service scheduling parameters.

8. A parameter configuration method, characterized in that, The method, applied to a second network element, includes: receiving a configuration request message sent by a first network element; wherein the configuration request message includes target parameters configured by the first network element for the current round of specific network function sessions, and at least some of the target parameters are parameters to be negotiated by the second network element for the current round of specific network function sessions; determining the parameter values ​​of the parameters to be negotiated; and sending a configuration response message to the first network element; wherein the configuration response message includes the parameter values, and the parameter values ​​are applied to the current round of specific network function sessions.

9. The method according to claim 8, characterized in that, The configuration request message also includes indication or marking information, which is used to indicate or mark the parameter to be negotiated.

10. The method according to claim 9, characterized in that, It also includes at least one of the following: determining the parameter to be negotiated based on the indication or marking information; identifying parameters with null values ​​in the target parameters as the parameter to be negotiated.

11. The method according to claim 8, characterized in that, The reference information for determining the parameter value includes at least one of the following: the parameter suggestion value of the parameter to be negotiated provided by the first network element, the historical similar experience value of the second network element, historical service-related performance statistics, local status information, user preference data, self-protection data, and pre-simulation prediction data.

12. The method according to claim 8, characterized in that, Sending a configuration response message to the first network element includes: sending a single configuration response message to the first network element; wherein the single configuration response message includes the parameter values ​​of all parameters to be negotiated; or, sending multiple configuration response messages to the first network element at different times; wherein each configuration response message includes some or all of the parameter values ​​of the parameters to be negotiated.

13. A communication device, characterized in that, include: A memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the method according to any one of claims 1-12.

14. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1-12.

Images