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: sending 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 negotiated with a second network element in the future; receiving a configuration response message sent by the second network element; wherein the configuration response message comprises a first parameter suggestion value of the to-be-negotiated parameter determined by the second network element, and the first parameter suggestion value is referred to and applied to the next round of specific network function session in the future. 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

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, a device, and a 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 in the future;

[0006] The configuration response message sent by the second network element is received; wherein the configuration response message includes a first parameter suggestion value of the parameter to be negotiated determined by the second network element, and the first parameter suggestion value is used as a reference for the next round of specific network function sessions.

[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 in the future;

[0009] Determine the first suggested value for the parameter to be negotiated;

[0010] A configuration response message is sent to the first network element; wherein the configuration response message includes the first parameter suggestion value, which is referenced for application in the next round of specific network function sessions.

[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 A schematic diagram of the structure of a communication system provided in an embodiment of this application;

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

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

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

[0018] Figure 5 A schematic diagram comparing parameter configurations provided by conventional technologies and embodiments of this application;

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

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

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

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

[0023] Figure 10 Another flowchart illustrating the parameter configuration method provided in this application embodiment;

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

[0025] Figure 12 Another schematic diagram of the parameter configuration device provided in the embodiments of this application;

[0026] Figure 13 This 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 follows: Figure 1 As shown, 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 achieving 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 as follows: Figure 2 As shown, this includes several sub-network element nodes and related important interfaces (such as Centralized Unit (CU), Distributed Unit (DU), NG, Xn, F1, Uu interfaces, etc.) of the 3GPP RAN specification. Additionally, the control plane / user plane protocol stack of the 5G communication system Uu air interface is as follows... Figure 3 , Figure 4 As shown, the user plane protocol stack may 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 sensing, computing, and intelligent hyper-convergence capabilities, can configure network function parameters and better understand, analyze, and evaluate the rationality of network function parameter configurations. This allows for the deduction of more suitable network function parameter configurations. In other words, the network element nodes in this application can negotiate future parameters through their integrated AI modules and refer to the negotiated parameters in the next specific network function session to achieve more suitable parameter configurations for that specific network function session, thereby improving the performance of the wireless communication network.

[0042] For example, the parameter configuration between the RAN and UE is described, such as... Figure 5As shown, in traditional technologies, the RAN determines and configures all Radio Resource Control (RRC) parameters for the UE. In the technical solution provided in this application embodiment, both the RAN and the UE integrate artificial intelligence modules. Although the RAN configures all parameters, some parameters are negotiable parameters that can be negotiated with the UE for the next round of specific network function sessions. The UE can analyze and evaluate the RCC parameters sent by the RAN through the air interface based on its own radio 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 parameter configuration of the gNB may lead to a decrease in the subsequent functional performance of the UE. That is, the serving UE can provide suggested values ​​for some RRC parameters through the internally integrated artificial intelligence module for reference in the next round of sessions.

[0043] Among them, the aforementioned artificial intelligence module possesses a relatively advanced level of autonomous intelligence, capable of providing "a fully integrated, synergistic, and intelligent service throughout the entire lifecycle, from user intent to closed-loop execution," such as... Figure 6 As shown, its core elements include: "intent perception", "task objectives", "role setting", and "tool knowledge", with each element analyzed in detail below:

[0044] "Intent perception": the definition of input information and how to provide customized AI services that combine 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 This is a flowchart illustrating a parameter configuration method provided in an embodiment of this application. The method is applied to a first network element, such as... Figure 7 As shown, 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 in the future.

[0052] S702, Receive a configuration response message sent by the second network element; wherein, the configuration response message includes a first parameter suggestion value for the parameter to be negotiated determined by the second network element, and the first parameter suggestion value is used as a reference for the next round of specific network function sessions.

[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 the target parameters configured by the first network element for the current specific network function session. Some or all of these parameters are negotiable parameters that can be negotiated with the second network element for future specific network function sessions. In other words, the first network element provides the parameters to be negotiated, and the second network element determines a first suggested value for these parameters. This first suggested value is used for reference in future sessions. During the execution of the current specific network function session, the first network element continues to apply its own configured parameter values ​​and does not apply the first suggested value provided by the second network element, but it will refer to and apply it in future sessions. The first and second network elements can negotiate parameters for future specific network function sessions, making the parameters configured for future sessions more suitable, thereby improving the performance of the wireless communication network.

[0054] The target parameter can be a specific numerical value (e.g., 1, 2, 3, 4) or a numerical range (e.g., [1-4]).

[0055] 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.

[0056] 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.

[0057] 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 first suggested value of the parameter to be negotiated. The first suggested value determined by the second network element can be a specific numerical value (e.g., 1, 2) or a numerical range (e.g., [1-2]).

[0058] Furthermore, the second network element sends the determined first parameter suggestion value 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 first parameter suggestion value of the parameter to be negotiated carried in the configuration response message, saves the first parameter suggestion value, and uses this first parameter suggestion value as a reference for future rounds of specific network function sessions.

[0059] 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.

[0060] Optionally, the second network element can identify parameters requiring bilateral negotiation based on indication or marking information. For example, for each parameter in the configuration request message, corresponding indication / marking information can be set. Indication / marking information "1" indicates that the parameter does not require bilateral negotiation, while indication / marking information "0" indicates that the parameter is a parameter requiring negotiation. The second network element can identify the parameter corresponding to indication / marking information "0" as a parameter requiring negotiation.

[0061] Optionally, the configuration request message also includes a second parameter suggestion value provided by the first network element for the parameter to be negotiated. This second parameter suggestion value can serve as one of the reference bases for the second network element to determine the first parameter suggestion value. In other words, the first network element configures the parameter values ​​for all parameters involved in this round of specific network function sessions, while simultaneously indicating or marking certain parameters as parameters to be negotiated with the second network element for the next round of specific network function sessions. That is, the first network element provides second parameter suggestion values ​​for the parameters to be negotiated. The second network element, based on its artificial intelligence module and in conjunction with the second parameter suggestion value and / or other relevant information, determines the first parameter suggestion value for the parameter to be negotiated and feeds it back to the first network element. This first parameter suggestion value can or is permitted to be used as a reference in the next round of sessions. Optionally, the first parameter suggestion value fed back by the second network element, the second parameter suggestion value determined by the first network element, or the target parameter value obtained by comprehensively considering the first parameter suggestion value fed back by the second network element and the second parameter suggestion value determined by the first network element can or is permitted to be applied to the next round of specific network function sessions. The specific parameter value that the first network element applies in the next round of specific network function sessions can be determined by comprehensively considering local conditions, user needs, and the current wireless network environment.

[0062] Optionally, the second network element may determine the first parameter suggestion value of the parameter to be negotiated based on at least one of the following reference information: the second 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.

[0063] Among them, the second parameter suggestion value is the parameter suggestion value provided by the first network element based on its own local conditions, business needs and historical data for the parameter to be negotiated. It provides the initial parameter value for parameter negotiation, which facilitates the second network element to perform further optimization.

[0064] 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.

[0065] 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.

[0066] 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 suggested values ​​for the first parameter match the element's actual operational capabilities.

[0067] 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, the recommended values ​​for the first configuration parameter can be made closer to user needs, thus improving the user experience.

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

[0069] 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.

[0070] 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.

[0071] 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.

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

[0073] Among these, configuration request messages and configuration response messages are logically tightly coupled processes. Under this process, the second network element must use a single configuration response message to return the first network element the suggested values ​​for all parameters to be negotiated. For example... Figure 8As shown, 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 with parameter values ​​and do not require bilateral negotiation. Parameters to be negotiated refer to parameters that have been configured with parameter values ​​but require bilateral negotiation for the next round of specific network function sessions. The second network element combines the second parameter suggestion value provided by the first network element with other relevant information to determine the first parameter suggestion value of the parameters to be negotiated, and feeds back the first parameter suggestion values ​​of all parameters to be negotiated to the first network element through a configuration response message.

[0074] Optionally, the above S702 may include: receiving multiple configuration response messages sent sequentially by the second network element at different times; wherein each configuration response message includes a first parameter suggestion value for some or all of the parameters to be negotiated.

[0075] 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 first parameter suggestion 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. Figure 9 As shown, 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: a determined parameter and a parameter to be negotiated (here, the parameter to be negotiated refers to a parameter that has been configured but requires bilateral negotiation). The second network element, combining the second parameter suggestion value provided by the first network element and other relevant information, determines the first parameter suggestion value for the parameter to be negotiated. At different times, it uses multiple configuration response messages to sequentially feed back some or all of the first parameter suggestion values ​​for the parameter to be negotiated to the first network element. For example, each configuration response message may only contain the first parameter suggestion values ​​for some of the parameters to be negotiated, but all configuration response messages combined contain the first parameter suggestion values ​​for all the parameters to be negotiated. Alternatively, each configuration response message may contain the first parameter suggestion values ​​for all the parameters to be negotiated, with each subsequent configuration response message used to update the first parameter suggestion values ​​for the parameters to be negotiated in the previous configuration response message.

[0076] Optionally, for the same parameter to be negotiated, the first parameter suggestion value of the same parameter to be negotiated updated and sent by the second network element at the latest time point is referenced and applied to the next round of specific network function sessions.

[0077] The second network element can feed back suggested values ​​of the first parameter of the parameter to be negotiated at different times. The first network element receives the suggested values ​​of the first parameter of the parameter to be negotiated fed back by the second network element at different times. The suggested value of the first parameter of the same parameter to be negotiated sent by the second network element at the latest time is referenced and applied to the next round of specific network function sessions. Since the suggested value of the first parameter of the parameter to be negotiated sent at the latest time is the most recently determined, it is more adapted to the current wireless network environment and user needs, making the suggested value of the first parameter more accurate. Referring to the suggested value of the first parameter fed back at the latest time can further improve the performance of the wireless communication network.

[0078] 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.

[0079] 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.

[0080] Optionally, the parameters to be negotiated can be any parameters that need to be negotiated between any two network elements or logical functional entities defined by the 3GPP system for the next 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. 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, parameters related to secondary cell (SCell) sleep, Bandwidth Part (BWP) pre-scheduling parameters, Reference Signal Receiving Power (RSRP) value of the candidate cell, measurement gap period, handover trigger offset, and joint scheduling request (SR) and physical uplink control channel (Phase I / O). Parameters related to Channel (PUCCH) resource allocation.

[0081] 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, parameters related to network load balancing, parameters related to Quality of Service (QoS), parameters related to the mobility management process, parameters related to the handover strategy optimization process, and parameters related to the network topology optimization process.

[0082] 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 terminal devices, 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, DRX power saving parameters, beam management parameters, slice resource reservation ratio parameters, and interference coordination parameters.

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

[0084] 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 in the future.

[0085] S1002. Determine the suggested value of the first parameter to be negotiated.

[0086] S1003. Send a configuration response message to the first network element; wherein the configuration response message includes a first parameter suggestion value, which is used as a reference for the next round of specific network function sessions.

[0087] 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.

[0088] Optionally, the second network element can also determine the parameters to be negotiated based on indication or marking information.

[0089] Optionally, the reference information used by the second network element to determine the suggested value of the first parameter includes at least one of the following: the suggested value of the second parameter to be negotiated provided by the first network element, historical similar experience values ​​of 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 value to be negotiated through data from multiple sources, the second network element obtains a more suitable parameter value through diversified reference information, thereby improving the performance of the wireless communication network.

[0090] Optionally, the second network element sending the configuration response message includes: sending a configuration response message to the first network element; wherein the single configuration response message includes the first parameter suggestion values ​​for 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 first parameter suggestion values ​​for the parameters to be negotiated.

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

[0092] Below are some exemplary implementation methods 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 a base station, and the second network element is denoted as a UE. That is, the base station and the UE can negotiate and configure parameters for the next round of specific network function sessions. The negotiated parameter values ​​are applied to the next round of specific network function sessions. For example, the base station can obtain relevant information for initial parameter configuration, but the base station may want to optimize and improve the configured parameters in the future.

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

[0094] The base station recommends a maximum number of HARQ retransmissions, and the UE provides an optimized suggested value based on its local bit error rate. Parameter to be negotiated (for future reference): Maximum number of HARQ retransmissions.

[0095] Implementation Process: The base station sends a HARQ configuration request message, marking the maximum HARQ retransmission count as a parameter to be negotiated (also known as a future reference parameter). 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 references this new maximum HARQ retransmission count in future HARQ processes. For example, the UE might suggest changing the maximum HARQ retransmission count from 4 to 3 based on the internally integrated AI module's suggestion, and the base station records the suggested value and uses the new maximum HARQ retransmission count in subsequent HARQ processes.

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

[0097] The base station proposed extending the DRX cycle to save energy, and the UE provided optimized values ​​based on service latency requirements for reference in subsequent processes. Parameter to be negotiated (for future reference): DRX cycle.

[0098] Implementation Process: The base station sends a DRX configuration request message, marking the DRX period as a parameter to be negotiated (also known as a future reference parameter). 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 then refers to this new DRX configuration in subsequent processes. For example, the UE, based on its internally integrated AI module, suggests adjusting the DRX period provided by the base station from 160ms to 80ms and feeds this back to the base station. The base station records the suggested value and subsequently refers to it when configuring DRX.

[0099] Scenario 3: Clock synchronization precision negotiation

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

[0101] 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 (also known as a future reference parameter). The UE, based on suggestions from its internally integrated artificial intelligence module, adjusts the time synchronization error range provided by the base station, either widening or narrowing it, and provides feedback. The base station receives the suggested values ​​and applies them in subsequent updates to the UE synchronization strategy.

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

[0103] The base station recommends the SRS period, which the UE will dynamically adjust in the future based on service requirements. Parameters to be negotiated (for future reference): SRS period; confirmed parameter: SRSBandwidth = 4RB.

[0104] Implementation Process: The base station sends an SRS configuration request message, marking the SRS period as a parameter to be negotiated (also known as a future reference parameter). The UE provides a suggested SRS period value based on its internally integrated artificial intelligence module and feeds it back. The base station can then update the SRS resource configuration with reference to the suggested value in subsequent processes. For example, the UE suggests adjusting the SRS period from 20ms to 10ms based on the internally integrated artificial intelligence module and feeds it back to the base station, which then applies the new SRS period in subsequent SRS resource configurations.

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

[0106] The base station recommends the CSI reporting cycle, and the UE provides a suggested value based on the real-time requirements of its services. Parameter to be negotiated (for future reference): CSI reporting cycle.

[0107] Implementation Process: The base station sends a CSI configuration request message, marking the CSI reporting period as a parameter to be negotiated (also known as a future reference parameter). 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 records the suggested value and applies it in subsequent processes. 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, which then applies this suggested value when receiving CSI reports.

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

[0109] The base station proposes the SCell deactivation timer duration, and the UE provides a suggested value based on multi-connection requirements. Parameter to be negotiated (for future reference): SCell deactivation timer duration.

[0110] Implementation Process: The base station sends a CA configuration request message, marking the SCell deactivation timer duration as a parameter to be negotiated (also known as a future reference parameter). The UE updates and adjusts the SCell deactivation timer duration provided by the base station based on its internally integrated artificial intelligence module and provides feedback. The base station then refers to the application-recommended value in subsequent processes. For example, the UE might suggest shortening the SCell deactivation timer duration from 100ms to 40ms based on its internally integrated artificial intelligence module and provide feedback to the base station. The base station receives the recommended value and refers to it in subsequent SCell sleep policy updates.

[0111] Scenario 7: Predictive-based BWP pre-scheduling

[0112] The base station suggests pre-scheduled BWP parameters for future use, and the UE provides optimized values ​​for reference in subsequent processes. Parameters to be negotiated (for future reference): Time offset by which the base station reserves resources for user equipment before activating a specific bandwidth portion.

[0113] Implementation Process: The base station sends a BWP pre-scheduling configuration, marking the time offset for reserving resources for the user equipment as a parameter to be negotiated (also known as a future reference parameter). The UE generates a suggested value based on its internally integrated artificial intelligence module. For example, the UE suggests changing the time offset for reserving resources for the user equipment from 10ms to 5ms. The base station records the suggested value, and subsequent handover procedures refer to the new time offset.

[0114] Scenario 8: AI-based mobility prediction parameters

[0115] The base station provides a list of candidate cells for handover, and the UE provides feedback on future preference weights. Parameters to be negotiated (for future reference): RSRP values ​​of candidate cells.

[0116] Implementation Process: The base station sends handover parameter configuration, marking the RSRP value of candidate cells as a parameter to be negotiated (also known as a future reference parameter). The UE generates suggested values ​​based on its internally integrated artificial intelligence module. For example, the UE suggests adjusting Cell1 = 90dBm, Cell2 = 85dBm to Cell1 = 88dBm, Cell2 = 82dBm and provides feedback. The base station records the suggested values ​​and prioritizes the cells suggested by the UE in subsequent handover decisions.

[0117] Scenario 9: Prediction-based Measurement Gap Optimization

[0118] The base station provides a suggested measurement gap period, and the UE provides feedback on future optimized values ​​for reference during the handover process. Parameters to be negotiated (future reference): Measurement gap period MeasGapOffset = 6 (currently applied value by the base station).

[0119] Implementation Process: The base station sends the measurement gap configuration, marking the measurement gap period as a parameter to be negotiated (also known as a future reference parameter). The UE generates a suggested value based on its internally integrated artificial intelligence module; for example, the UE suggests changing the measurement gap period from 6 to 3. The base station records the suggested value and applies the new measurement gap period as a reference in subsequent neighboring cell measurements.

[0120] Scenario 10: Handover Offset Prediction in Mobility Management

[0121] Base station configuration handover trigger offset; UE suggests future optimized values ​​for handover decisions. Parameters to be negotiated (future reference): The offset of neighboring cell signal quality relative to the serving cell signal quality.

[0122] Implementation Process: The base station sends handover parameter configurations, marking the offset of the neighboring cell's signal quality relative to the serving cell's signal quality as a parameter to be negotiated (also known as a future reference parameter). The UE generates suggested values ​​based on its internally integrated artificial intelligence module. For example, the UE suggests changing the offset of the neighboring cell's signal quality relative to the serving cell's signal quality from 2dB to 3dB to trigger handover earlier. The base station records the suggested values ​​and applies the new offsets as a reference in subsequent high-speed scenarios.

[0123] Scenario 11: Coordinated Scheduling Request (SR) and PUCCH Resource Allocation

[0124] The base station dynamically configures the SR cycle and PUCCH resources, and the UE suggests the PUCCH format type for future process reference.

[0125] Implementation Process: The base station sends a joint configuration request, marking the PUCCH format type as a parameter to be negotiated (also known as a future reference parameter). The UE generates a suggested value based on its internally integrated artificial intelligence module. The UE generates the PUCCH format type based on its internally integrated artificial intelligence module. The base station records the PUCCH format type and refers to the UE's suggested PUCCH format type in subsequent version upgrades.

[0126] Scenario 12: Dynamic TDD Slot Configuration

[0127] 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 optimized by the UE in the future. Parameters to be negotiated (for future reference): uplink / downlink time slot parameters, dynamic frame number offset.

[0128] Implementation Process: The base station sends a TDD configuration request message, marking the uplink / downlink time slot ratio and dynamic frame number offset as parameters to be negotiated (also known as future reference parameters). The UE receives the TDD configuration request message, generates suggested values ​​for the uplink / downlink time slot ratio and dynamic frame number offset based on its internally integrated artificial intelligence module, and feeds them back to the base station via a TDD configuration response message. The base station records the time slot configuration parameters fed back by the UE (including the uplink / downlink time slot ratio and dynamic frame number offset) and refers to the suggested values ​​in subsequent cell resource allocation.

[0129] Scenario 13: QoE Measurement Reporting Strategy

[0130] The UE reports video stream QoE data on demand, but the reporting period and trigger threshold can be optimized by the UE in the future. Parameters to be negotiated (for future reference): Reporting period and trigger threshold.

[0131] Implementation Process: The base station initiates a QoE configuration request message, marking the reporting period and trigger threshold as parameters to be negotiated (also known as future reference parameters). The UE receives the QoE configuration request message, generates suggested values ​​for the reporting period and trigger threshold based on its internally integrated artificial intelligence module, and sends these suggested values ​​back to the base station via a configuration response message. Upon receiving the feedback, the base station refers to the suggested parameter values ​​provided by the UE in subsequent similar processes.

[0132] Scenario 14: Negotiation of Uplink Power Control Parameters

[0133] The base station configures the UE uplink transmit power control strategy, but some parameters are optimized by the UE based on channel conditions. Parameters to be negotiated (for future reference): nominal power baseline value, path loss compensation factor.

[0134] Implementation process: The base station sends a power control configuration request message, marking the nominal power reference value and path loss compensation factor as parameters to be negotiated (also known as future reference parameters). 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 refers to the parameter suggestion values ​​provided by the UE in subsequent uplink scheduling policy updates.

[0135] Scenario 15: Uplink MIMO transmission parameter negotiation

[0136] The base station configures the UE's uplink MIMO transmission, but the maximum number of layers can be optimized by the UE based on current channel conditions. Parameters to be negotiated (future reference): maximum uplink MIMO layers and precoding granularity.

[0137] Implementation Process: The base station sends a MIMO configuration request message, marking the maximum uplink MIMO layer number and precoding granularity as parameters to be negotiated (also known as future reference parameters). The UE generates the maximum uplink 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 refers to the parameter suggestion values ​​fed back by the application UE when scheduling uplink configuration layer MIMO transmissions in the future.

[0138] Scenario 16: Random Access Power Ramp-Up Step Size Optimization

[0139] During random access, the UE dynamically adjusts the power ramp-up step size. The base station provides a suggested value for this parameter, which the UE can then suggest for future optimization. Parameters to be negotiated (for future reference): power ramp-up step size and maximum number of preamble retransmissions.

[0140] Implementation Process: The base station sends a random access configuration request message, marking the power ramp step size and the maximum preamble retransmission count as parameters to be negotiated (also known as future reference parameters). The UE generates the power ramp step size and the maximum preamble retransmission count based on its internally integrated artificial intelligence module and feeds them back to the base station. The base station receives the parameter suggestion values ​​fed back by the UE and refers to and applies these parameter suggestion values ​​when updating the cell random access policy in subsequent updates.

[0141] 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 for the next round of specific network function sessions. The negotiated parameter values ​​are applied to the next round of specific network function sessions.

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

[0143] During the initial registration process, the base station and the AMF negotiate the UE's network access parameters. Parameters to be negotiated (for future reference): Globally unique AMF identifier type and public terrestrial mobile network identifier.

[0144] Implementation Process: The base station sends an initial registration request message to the AMF, marking the globally unique AMF identifier type and public land mobile network identifier as parameters to be negotiated (also known as future reference parameters). The AMF generates suggested parameter values ​​for the globally unique AMF identifier type and public land mobile network identifier based on its internally integrated artificial intelligence module and feeds them back to the base station. The base station refers to and applies the suggested parameter values ​​returned by the AMF in subsequent registration processes.

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

[0146] When a UE switches to a new cell, the base station negotiates relevant parameters with the target AMF. Parameters to be negotiated (for future reference): Target AMF identifier and network slice selection assistance information.

[0147] Implementation Process: The base station sends a handover request message to the target AMF, marking the target AMF identifier and network slice selection auxiliary information as parameters to be negotiated (also known as future reference parameters). The target AMF generates suggested parameter values ​​for the target AMF identifier and network slice selection auxiliary information based on its internally integrated artificial intelligence module and feeds them back to the base station. The base station refers to and applies the parameter values ​​returned by the target AMF in subsequent handover procedures.

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

[0149] In scenarios involving dynamically allocated network slices, the base station negotiates network slice-related parameters with the AMF. Parameters to be negotiated (for future reference): Default slice identifier and slice distinguisher.

[0150] Implementation Process: The base station sends a network slice allocation request message to the AMF, marking the default slice identifier and slice distinguisher as parameters to be negotiated (also known as future reference parameters). The AMF generates suggested parameter values ​​for the default slice identifier and slice distinguisher based on its internally integrated artificial intelligence module and feeds them back to the base station. The base station refers to the suggested parameter values ​​returned by the AMF in subsequent slice allocation processes.

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

[0152] In scenarios supporting MEC, the base station and AMF negotiate parameters related to edge computing. Parameters to be negotiated (for future reference): MEC server address and MEC service type.

[0153] Implementation Process: The base station sends a MEC service request message to the AMF, marking the MEC server address and MEC service type as parameters to be negotiated (also known as future reference parameters). The AMF generates suggested parameter values ​​for the MEC server address and MEC service type based on its internally integrated artificial intelligence module and feeds them back to the base station. The base station refers to and applies the suggested parameter values ​​returned by the AMF in subsequent MEC service processes.

[0154] Scenario 5: Parameter negotiation in network slice selection

[0155] The base station negotiates network slice selection parameters with the AMF to support the UE's network slice requirements. Parameters to be negotiated (future reference): List of auxiliary information for single network slice selection.

[0156] Implementation Process: The base station sends a network slice selection request message to the AMF (Application Management Function), which includes initial single network slice selection auxiliary information list values. The AMF generates new single network slice selection auxiliary information list values ​​based on its internally integrated artificial intelligence module and feeds them back to the base station. The base station refers to the single network slice selection auxiliary information list values ​​returned by the AMF in subsequent network slice selection processes.

[0157] Scenario 6: Parameter modification in the registration and update process

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

[0159] 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 and PLAN identifier values ​​based on its internally integrated artificial intelligence module and sends them back to the base station. The base station references the parameter suggestions returned by the AMF in subsequent registration update processes.

[0160] Scenario 7: Parameter negotiation in UE uplink resource request

[0161] When a UE requests uplink resources, the base station negotiates relevant parameters with the AMF. Parameters to be negotiated (future reference): Uplink resource indication.

[0162] Implementation process: The base station sends an uplink resource request message to the AMF (Advanced Feature Controller), 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 feeds it back to the base station. The base station refers to the parameter values ​​returned by the AMF in subsequent uplink resource allocation procedures.

[0163] Scenario 8: Parameter Negotiation in Mobility Restriction Updates

[0164] In the UE mobility restriction update scenario, the base station and AMF negotiate relevant parameters. Parameters to be negotiated (future reference): Mobility restriction list.

[0165] 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 feeds them back to the base station. The base station refers to the parameter values ​​returned by the AMF in subsequent mobility restriction update procedures.

[0166] Scenario 9: Parameter Modification in Network Load Balancing

[0167] In network load balancing scenarios, the base station and AMF negotiate load balancing-related parameters. Parameters to be negotiated (for future reference): Load balancing.

[0168] Implementation process: The base station sends a load balancing request message to the AMF (Application 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 feeds them back to the base station. The base station refers to the parameter values ​​returned by the AMF in subsequent load balancing processes.

[0169] Scenario 10: Quality of Service (QoS) parameter negotiation

[0170] The base station negotiates Quality of Service (QoS) parameters with the AMF to support the UE's QoS requirements. Parameters involved include: QoS Flow Identifier and QoS parameters.

[0171] Implementation Process: The base station sends a QoS parameter negotiation request message to the AMF (Automatic Flow Manager). This message contains an initial QoS flow identifier and QoS parameter values, with the QoS parameter values ​​marked as parameters to be negotiated (also known as future reference parameters). The AMF generates new QoS parameter values ​​based on its internally integrated artificial intelligence module and feeds them back to the base station. The base station then refers to the QoS parameter values ​​returned by the AMF in future processes.

[0172] Scenario 11: Negotiation of Mobility Management Parameters

[0173] During UE mobility management, the base station negotiates relevant parameters with the AMF. The parameter involved is the mobility restriction list.

[0174] Implementation process: The base station sends a Mobility Management Parameter Request (AMF) message to the AMF, which includes the initial mobility restriction list values. The AMF generates new mobility restriction list values ​​based on its internally integrated artificial intelligence module and sends them back to the base station. The base station refers to the new mobility restriction list values ​​returned by the AMF in future processes.

[0175] Scenario 12: Parameter Negotiation in Switching Strategy Optimization

[0176] In handover strategy optimization scenarios, the base station and AMF negotiate handover-related parameters. The relevant parameter is the handover priority list.

[0177] Implementation process: The base station sends a handover policy optimization request message to the AMF, which includes the initial handover priority list values. The AMF generates a new handover priority list value based on its internally integrated artificial intelligence module and feeds it back to the base station. The base station refers to the new handover priority list value returned by the AMF to optimize its handover policy in future processes.

[0178] Scenario 13: Parameter Negotiation in Network Topology Optimization

[0179] In network topology optimization scenarios, base stations negotiate relevant topology optimization parameters with the AMF (Advanced Management Function). Parameters involved: Topology optimization parameters.

[0180] Implementation process: The base station sends a topology optimization request message to the AMF (Application Management Function), which includes initial topology optimization parameter values. The AMF generates new topology optimization parameter values ​​based on its integrated artificial intelligence module and feeds them back to the base station. The base station then refers to these new topology optimization parameter values ​​returned by the AMF in future processes to optimize the network topology.

[0181] 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 for the next round of specific network function sessions. The negotiated parameter values ​​are applied to the next round of specific network function sessions.

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

[0183] When establishing an F1 interface between the CU and DU, the CU can initiate a request and suggest a PRB resource allocation strategy. This strategy is dynamically optimized 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.

[0184] Implementation Process: The CU sends an F1 Setup Request message, marking the PRB allocation mode and slot format parameters as parameters to be negotiated (also known as future reference parameters). The DU determines the PRB allocation mode and slot format parameter values ​​based on its internally integrated AI module and feeds them back to the CU. Upon receiving the feedback, the CU refers to and applies these parameter values ​​during subsequent F1 interface configuration. For example, the DU determines the PRB allocation mode to be dynamic and the 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 refers to and applies these parameter values ​​during subsequent F1 interface configuration.

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

[0186] When the CU establishes a context for the UE, the CU provides a suggested value for the uplink SR period, but expects the DU to provide a future optimized value for this parameter. The parameters involved in establishing the context include the uplink SR period (sr-Periodicity) and the BWP configuration (bwp-Id).

[0187] Implementation Process: The CU sends a UE Context Setup Request message, marking the uplink SR period as a parameter to be negotiated (also known as a future reference parameter). The DU determines the suggested parameter value for 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. After receiving the feedback, the CU refers to the suggested parameter value fed back by the DU when configuring subsequent UE uplink scheduling.

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

[0189] The CU requests dynamic TDD configuration, specifying the uplink / downlink time slot ratio, but expects the DU to provide future optimized values ​​for the uplink / downlink time slot ratio. The parameters involved in dynamic TDD configuration include: uplink / downlink time slot ratio and special time slot configuration.

[0190] Implementation Process: The CU sends a TDD Configuration Request message, in which the uplink / downlink slot ratio is marked as a parameter to be negotiated (also known as a future reference parameter). The DU determines the suggested values ​​for the uplink / downlink slot ratio based on its internally integrated artificial intelligence module and feeds them back to the CU via a TDD Configuration Response message. After receiving the feedback, the CU refers to the suggested parameter values ​​fed back by the DU when updating the cell frame structure in subsequent updates.

[0191] Scenario 4: PDCP Repeat Transmission Configuration

[0192] The CU configures the PDCP layer's retransmission function. The CU specifies the number of PDCP repetitions, which can be optimized by the DU based on link reliability requirements. The parameters involved include the number of PDCP repetitions.

[0193] Implementation Process: The CU sends a PDCP Configuration Request message, in which the PDCP repetition count is marked as a parameter to be negotiated (also known as a future reference parameter). The DU determines the PDCP repetition count based on its internally integrated artificial intelligence module and provides feedback via a PDCP Configuration Response message. After receiving the feedback, the CU refers to and applies this parameter value in subsequent processes to enhance the reliability of data transmission at the edge UE.

[0194] Scenario 5: Switching Parameters for Negotiation

[0195] CU suggests switching the offset value of event A3. The offset value of A3 is marked as a parameter to be negotiated (future reference), and the future suggested value is provided by DU.

[0196] Implementation Process: The CU sends a Handover Configuration Request message, marking the offset value of A3 as a parameter to be negotiated (also known as a future reference parameter). The DU, based on suggestions from its internally integrated AI module, modifies the offset value of A3 provided by the CU to the new offset value and feeds it back to the CU via a Handover Configuration Response message. Upon receiving the feedback, the CU refers to and applies the new offset value of A3 during subsequent handover policy updates.

[0197] Scenario 6: Adjusting the number of HARQ retransmissions

[0198] The CU recommends the maximum number of HARQ retransmissions, marks the maximum number of HARQ retransmissions as a parameter to be negotiated (for future reference), and allows the DU to provide future recommended values.

[0199] Implementation Process: The CU sends a HARQ Configuration Request message, marking the maximum HARQ retransmission count as a parameter to be negotiated (also known as a future reference parameter). The DU, based on its internally integrated AI module, suggests adjusting the maximum HARQ retransmission count provided by the CU to a new maximum HARQ retransmission count and feeds this feedback back to the CU via a HARQ Configuration Response message. Upon receiving the feedback, the CU applies the new maximum HARQ retransmission count in subsequent processes to reduce retransmission latency.

[0200] Scenario 7: Uplink power control parameter update

[0201] The CU recommends the uplink nominal power, but hopes the DU will provide future recommended values ​​based on coverage requirements. The parameters involved include the nominal power baseline and the road loss compensation factor.

[0202] 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 (also known as future reference parameters). The DU, based on suggestions from its internally integrated AI module, adjusts the nominal power reference value and road loss compensation factor provided 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 applies the new nominal power reference value and new road loss compensation factor in subsequent processes to optimize uplink power allocation.

[0203] Scenario 8: RLC mode switching negotiation

[0204] CU recommends using Unacknowledged Mode (UM) for the RLC layer, but allows DU to provide future optimization values ​​based on the business type. Parameters involved include the RLC mode.

[0205] Implementation Process: The CU sends an RLC Configuration Request message, marking the RLC mode as a parameter to be negotiated (also known as a future reference parameter). Based on the VoIP service requirements and the internally integrated AI module's suggestion, the DU changes the RLC mode from UM to Acknowledged Mode (AM) and provides feedback via an RLC Configuration Response message. Upon receiving the feedback, the CU applies AM in subsequent processes to ensure a low packet loss rate for voice services.

[0206] Scenario 9: Negotiation of scheduling parameters for latency-sensitive services

[0207] The CU suggests scheduling priorities, but expects the DU to provide future optimized values. Parameters involved include scheduling priorities.

[0208] Implementation Process: The CU sends a QoS Configuration Request message, marking the scheduling priority as a parameter to be negotiated (also known as a future reference parameter). The DU modifies the scheduling priority to the new priority based on suggestions from its internally integrated AI module and provides feedback via a QoS Configuration Response message. Upon receiving the feedback, the CU applies the new scheduling priority in subsequent processes to ensure critical latency-sensitive services are protected.

[0209] Scenario 10: DRX Energy Saving Parameter Recommendations

[0210] The CU is configured with both long and short DRX periods, but the DU is expected to provide future optimized values. The parameters involved include both long and short DRX periods.

[0211] Implementation Process: The CU sends a DRX Configuration Request message, marking the DRX long period and short period as parameters to be negotiated (also known as future reference parameters). The DU, based on suggestions from its internally integrated AI module, modifies the DRX long period and short period provided by the CU to new DRX long and short periods, and feeds this back to the CU via a DRX Configuration Response message. The CU records the suggested values ​​for future reference during peak and off-peak business periods.

[0212] Scenario 11: Beam Management Parameter Optimization

[0213] The CU configures the beam measurement period, but allows the DU to provide future optimized values. The parameters involved include the beam measurement period.

[0214] Implementation Process: The CU sends a Beam Management Request message, marking the beam measurement period as a parameter to be negotiated (also known as a future reference parameter). The DU, based on its internally integrated artificial intelligence module, suggests modifying the beam measurement period to a new one and feeds this suggestion back to the CU via a Beam Management Response message. The CU then references the suggested value from the DU in subsequent high-mobility scenarios.

[0215] Scenario 12: Negotiating the proportion of reserved slice resources

[0216] The CU configures the slice resource reservation ratio, but allows the DU to adjust it dynamically in the future. The parameters involved include the slice resource ratio and the isolation level.

[0217] Implementation Process: The CU sends a Slice Configuration Request message, marking the slice resource ratio and isolation level as parameters to be negotiated (also known as future reference parameters). The DU, based on suggestions from its internally integrated AI module, modifies the slice resource ratio and isolation level to the new values ​​and feeds this back to the CU via a Slice Configuration Response message. The CU then refers to these suggested values ​​in the next resource allocation cycle.

[0218] Scenario 13: Optimization of Interference Coordination Parameters

[0219] The CU is configured with an interference coordination period, but the DU is allowed to adjust it dynamically in the future. The parameters involved include the interference coordination period.

[0220] Implementation Process: The CU sends an Interference Coordination Request message, marking the interference coordination period as a parameter to be negotiated (also known as a future reference parameter). The DU modifies the interference coordination period to a new value based on suggestions from its internally integrated AI module and provides feedback via an Interference Coordination Response message. The CU then references this new interference coordination period value in subsequent high-interference scenarios.

[0221] Figure 11 This 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, such as... Figure 11 As shown, the device may include a transmitting module 1101 and a receiving module 1102.

[0222] 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 in the future;

[0223] The receiving module 1102 is used to receive a configuration response message sent by the second network element; wherein, the configuration response message includes a first parameter suggestion value of the parameter to be negotiated determined by the second network element, and the first parameter suggestion value is used as a reference for the next round of specific network function sessions.

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

[0225] Optionally, the configuration request message may also include a second parameter suggestion value provided by the first network element for the parameter to be negotiated, wherein the second parameter suggestion value can or is permitted to be used as one of the reference bases for the second network element to determine the first parameter suggestion value.

[0226] Optionally, the first parameter suggestion value, the second parameter suggestion value, or the target parameter value can be or is permitted to be applied to the next round of specific network function sessions in the future, and the target parameter value is obtained based on the first parameter suggestion value and the second parameter suggestion value.

[0227] 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 first parameter suggestion values ​​for 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 first parameter suggestion values ​​for some or all of the parameters to be negotiated.

[0228] Optionally, for the same parameter to be negotiated, the first parameter suggestion value of the same parameter to be negotiated sent by the second network element at the latest time point is referenced and applied to the next round of specific network function sessions.

[0229] 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.

[0230] 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 hybrid HARQ, parameters related to DRX, parameters related to clock synchronization, parameters related to dynamic sounding reference signal resource configuration, parameters related to CSI reporting, parameters related to SCell sleep, BWP pre-scheduling parameters, RSRP value of candidate cells, measurement gap period, handover trigger offset, and parameters related to joint SR and PUCCH resource allocation.

[0231] 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, parameters related to network load balancing, QoS parameters, parameters related to the mobility management process, parameters related to the handover strategy optimization process, and parameters related to the network topology optimization process.

[0232] 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 during F1 interface establishment, parameters related to uplink scheduling on terminal devices, parameters related to dynamic TDD configuration, parameters related to PDCP retransmission, handover parameters, HARQ retransmission count, uplink power control parameters, RLC mode, delay-sensitive service scheduling parameters, DRX energy-saving parameters, beam management parameters, slice resource reservation ratio parameters, and interference coordination parameters.

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

[0234] 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 in the future;

[0235] The determining module 1202 is used to determine a first parameter suggestion value for the parameter to be negotiated;

[0236] The sending module 1203 is used to send a configuration response message to the first network element; wherein, the configuration response message includes the first parameter suggestion value, which is referenced for application in the next round of specific network function sessions.

[0237] Optionally, the reference information used by the determining module 1202 to determine the suggested value of the first parameter includes at least one of the following: the suggested value of the second parameter 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.

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

[0239] Optionally, the determining module 1202 is further configured to determine the parameters to be negotiated based on the indication or marking information.

[0240] 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 first parameter suggestion 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 first parameter suggestion values ​​of the parameters to be negotiated.

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

[0242] Those skilled in the art will understand that Figure 13 The structure shown 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.

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

[0244] 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 in the future;

[0245] The configuration response message sent by the second network element is received; wherein the configuration response message includes a first parameter suggestion value of the parameter to be negotiated determined by the second network element, and the first parameter suggestion value is used as a reference for the next round of specific network function sessions.

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

[0247] 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 in the future;

[0248] Determine the first suggested value for the parameter to be negotiated;

[0249] A configuration response message is sent to the first network element; wherein the configuration response message includes the first parameter suggestion value, which is referenced for application in the next round of specific network function sessions.

[0250] 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.

[0251] 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.

[0252] 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.

[0253] 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).

[0254] 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.

[0255] 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.

[0256] 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.

[0257] 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, Applied to the first network element, including: 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 in the future; The configuration response message sent by the second network element is received; wherein the configuration response message includes a first parameter suggestion value of the parameter to be negotiated determined by the second network element, and the first parameter suggestion value is used as a reference for the next round of specific network function sessions.

2. 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.

3. The method according to claim 1, characterized in that, The configuration request message also includes a second parameter suggestion value provided by the first network element for the parameter to be negotiated. The second parameter suggestion value can or is allowed to be used as one of the reference bases for the second network element to determine the first parameter suggestion value.

4. The method according to claim 3, characterized in that, Also includes: The first parameter suggestion value, the second parameter suggestion value, or the target parameter value can be or is allowed to be applied to the next round of specific network function sessions in the future, and the target parameter value is obtained based on the first parameter suggestion value and the second parameter suggestion value.

5. The method according to claim 1, characterized in that, The receiving of the configuration response message sent by the second network element includes: Receive a configuration response message sent by the second network element; wherein the configuration response message includes the first parameter suggestion value of all parameters to be negotiated; Alternatively, the network element may receive multiple configuration response messages sent sequentially at different times; wherein each configuration response message includes a first parameter suggestion value for some or all of the parameters to be negotiated.

6. The method according to claim 5, characterized in that, For the same parameter to be negotiated, the first parameter suggestion value of the same parameter to be negotiated, which is updated and sent by the second network element at the latest time point, is referenced and applied to the next round of specific network function sessions.

7. The method according to any one of claims 1 to 6, 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 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 functional entities defined by the 3GPP system.

8. The method according to claim 7, 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 Receive (DRX), parameters related to clock synchronization, parameters related to Dynamic Probe Reference Signal Resource Configuration, parameters related to Channel State Information (CSI) reporting, parameters related to secondary cell SCel1 sleep, partial bandwidth BWP pre-scheduling parameters, reference signal received power (RSRP) value of candidate cells, measurement gap period, handover trigger offset, and parameters related to Joint Scheduling Request (SR) and PUCCH resource allocation. Alternatively, 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, parameters related to network load balancing, quality of service (QoS) parameters, parameters related to the mobility management process, parameters related to the handover strategy optimization process, and parameters related to the network topology optimization process. Alternatively, 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 physical resource block (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 repeated transmission of packet data aggregation protocol (PDCP), handover parameters, HARQ retransmission count, uplink power control parameters, RLC mode, delay-sensitive service scheduling parameters, DRX energy-saving parameters, beam management parameters, slice resource reservation ratio parameters, and interference coordination parameters.

9. A parameter configuration method, characterized in that, Applied to the second network element, including: 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 in the future; Determine the first suggested value for the parameter to be negotiated; A configuration response message is sent to the first network element; wherein the configuration response message includes the first parameter suggestion value, which is referenced for application in the next round of specific network function sessions.

10. The method according to claim 9, characterized in that, The reference information for determining the suggested value of the first parameter includes at least one of the following: The first network element provides the suggested value of the second parameter of the parameter to be negotiated, 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.

11. The method according to claim 9, 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.

12. The method according to claim 9, characterized in that, Also includes: The parameters to be negotiated are determined based on the indicated or marked information.

13. The method according to claim 9, characterized in that, Sending the configuration response message to the first network element includes: Send a configuration response message to the first network element; wherein the configuration response message includes the first parameter suggestion value of all parameters to be negotiated; Alternatively, multiple configuration response messages may be sent to the first network element at different times; wherein each configuration response message includes a first parameter suggestion value for some or all of the parameters to be negotiated.

14. A communication node, 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-13.

15. 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-13.

Images