Connection release message processing method, electronic device, storage medium and program product

Abstract

The invention provides a connection release message processing method, electronic equipment, a storage medium and a program product, and relates to the technical field of communication. According to the method, the scene judgment is carried out on the triggering scene of the RRC Release message, whether to wait for the bottom layer confirmation feedback and match the differentiation processing strategy is dynamically determined, and the terminal processing efficiency is optimized, so that the service processing time delay can be reduced on the premise of ensuring the connection release reliability.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a connection release message processing method, electronic device, storage medium, and program product. Background Technology

[0002] In 5G NR (New Radio) network scenarios, the RRC (Radio Resource Control) connection release process is one of the core processes ensuring efficient utilization of radio resources and reasonable switching of terminal states. Its core purpose is to release the established SRB2 (Signaling Radio Bearer 2) and DRB (Data Radio Bearer), clear the radio resource configuration, or achieve terminal redirection when the terminal completes service transmission, network optimization and adjustment, or triggers a specific operation. Ultimately, this switches the terminal's RRC state from RRC_CONNECTED (connected state) to RRC_INACTIVE (inactive state) or RRC_IDLE (idle state). According to the 3GP protocol, this process is actively triggered by network devices (such as gNBs) only if the terminal has successfully established SRB2 and at least one DRB. It is a key link in maintaining the collaborative operation between the network and the terminal.

[0003] In existing technologies, to ensure the reliability of underlying data transmission, the protocol explicitly requires that after receiving an RRC Release message from the air interface, the terminal cannot immediately perform connection release processing; it must wait for confirmation information from the underlying layer, with a fixed upper limit of 60ms. The intention behind this design is to cover all possible underlying feedback scenarios. However, this unified waiting mechanism increases the service latency for the terminal to process the RRC Release message. Summary of the Invention

[0004] The purpose of this application is to provide a connection release message processing method, electronic device, storage medium, and program product to improve the problem of increased service latency caused by the existing method requiring a fixed waiting time to process the RRC Release message.

[0005] In a first aspect, embodiments of this application provide a connection release message processing method, applied to a terminal, the method comprising: Receive RRC Release messages from network devices; Based on the triggering scenario associated with the RRC Release message, determine whether it is necessary to wait for confirmation feedback from the underlying layer before processing the RRC Release message; Based on the determined result, the corresponding connection release processing strategy is selected to process the RRC Release message.

[0006] In the above implementation process, by performing scenario-based determination of the triggering scenario of RRC Release message, dynamically determining whether it is necessary to wait for underlying confirmation feedback and matching differentiated processing strategies, the terminal processing efficiency is optimized, thereby reducing business processing latency while ensuring the reliability of connection release.

[0007] Optionally, determining whether to wait for confirmation feedback from the underlying layer before processing the RRC Release message based on the triggering scenario associated with the RRC Release message includes: If the triggering scenario associated with the RRC Release message is a final release scenario, then the result is that there is no need to wait for confirmation feedback from the underlying layer before processing the RRC Release message; If the triggering scenario associated with the RRC Release message is a non-terminal release scenario, then the result is determined that confirmation feedback from the underlying layer needs to be waited for before processing the RRC Release message.

[0008] In the above implementation process, by accurately distinguishing between final and non-final release scenarios of RRC Release messages and formulating differentiated confirmation feedback strategies, the underlying confirmation waiting process is eliminated for final release scenarios such as terminal shutdown, which significantly shortens the latency of critical operations such as shutdown and improves the user experience. For non-final release scenarios such as network redirection and data transmission completion, the underlying confirmation feedback waiting mechanism is retained to ensure the consistency of network and terminal states and avoid communication anomalies caused by premature connection release.

[0009] Optionally, the final release scenario includes a non-access stratum detach process scenario triggered by the terminal being powered off, and the triggering scenario is identified in the following ways: If an indication message is received from the non-access layer, the triggering scenario is determined to be a final release scenario. The indication message is used to indicate that the terminal is currently in a power-off triggered detach process.

[0010] In the above implementation process, by using explicit indication information from the non-access layer as the basis for identifying the final release scenario, the accuracy and reliability of the scenario determination are ensured, and processing anomalies caused by scenario misjudgment are avoided.

[0011] Optionally, the step of selecting the corresponding connection release processing strategy to process the RRC Release message based on the determination result includes: If it is determined that confirmation feedback from the underlying layer is required before processing the RRC Release message, then the status information related to the processing of the RRC Release message is obtained, and the RRC Release message is processed based on the estimated maximum waiting time, wherein the estimated maximum waiting time is less than or equal to the maximum waiting time specified by the communication protocol for the terminal to wait for confirmation feedback from the underlying layer after receiving the RRC Release message.

[0012] In the above implementation process, when it is determined that it is necessary to wait for the underlying confirmation feedback, the relevant status information of the RRC Release message is obtained and processed based on the estimated maximum waiting time not exceeding the maximum waiting time specified in the protocol. This strictly follows the communication protocol specifications and ensures the reliability of the underlying confirmation feedback and the consistency of the network and terminal status.

[0013] Optionally, obtaining status information related to the processing of the RRC Release message includes: Obtain confirmation status information from the radio link control layer. The confirmation status information is used to indicate whether the RLC service data unit carrying the RRCrease message needs to wait for status confirmation from the peer RLC entity. The status information includes the confirmation status information.

[0014] In the above implementation process, by obtaining the confirmation status information of the radio link control layer, it is possible to accurately determine whether the RLC service data unit carrying the RRCrease message needs to wait for the status confirmation of the peer RLC entity. This provides an accurate and practical basis for estimating the maximum waiting time, so that the waiting strategy no longer depends on a fixed duration but adapts to specific confirmation requirements. This avoids invalid time consumption in scenarios where RLC status confirmation is not required, and ensures the reliability of the underlying feedback in scenarios where confirmation is required.

[0015] Optionally, processing the RRC Release message based on the estimated maximum waiting time includes: If the confirmation status information indicates that it is not necessary to wait for the status confirmation of the peer RLC entity, then the RRC Release message is processed based on the first estimated maximum waiting time; If the confirmation status information indicates that it is necessary to wait for the status confirmation of the peer RLC entity, then the RRC Release message is processed based on the second estimated maximum waiting time. The second estimated maximum waiting time is the maximum waiting time specified by the communication protocol for the terminal to wait for the underlying confirmation feedback after receiving the RRC Release message. The second estimated maximum waiting time is longer than the first estimated maximum waiting time.

[0016] In the above implementation process, based on the confirmation status information of the radio link control layer, a differentiated estimated maximum waiting time is configured for the processing of RRC Release messages. This not only strictly follows the communication protocol specifications but also achieves precise optimization of the waiting strategy: when there is no need to wait for confirmation of the status of the peer RLC entity, a shorter first estimated maximum waiting time is used, which greatly reduces the time spent on invalid waiting and quickly completes the connection release; when waiting is required, the second estimated maximum waiting time specified by the protocol is used to ensure the reliability of the underlying feedback and the consistency of the network and terminal status, effectively avoiding communication anomalies.

[0017] Optionally, obtaining status information related to the processing of the RRC Release message includes: Obtain the HARQ feedback status information of the physical layer. The HARQ feedback status information is used to indicate the HARQ acknowledgment status of the PDSCH carrying the RRRCRelease message. The status information includes the HARQ feedback status information.

[0018] In the above implementation process, by obtaining the HARQ feedback status information of the physical layer, the HARQ confirmation status of the PDSCH carrying the RRRCRelease message is accurately grasped, providing a precise basis at the physical layer level for the waiting strategy in the non-final release scenario, avoiding blind waiting caused by relying solely on fixed duration or a single layer status.

[0019] Optionally, processing the RRC Release message based on the estimated maximum waiting time includes: If the HARQ feedback status information indicates a HARQ confirmation indication, then the RRC Release message is processed based on a third estimated maximum waiting time, which is less than the maximum waiting time specified in the communication protocol for the terminal to wait for underlying confirmation feedback after receiving the RRC Release message.

[0020] In the above implementation process, when the HARQ feedback status information indicates HARQ feedback confirmation, the RRC Release message is processed with a third estimated maximum waiting time shorter than the maximum waiting time specified in the protocol. This ensures that the PDSCH carrying the message has been reliably received based on the physical layer HARQ confirmation result, eliminating the need for redundant long-term waiting. Furthermore, by shortening the waiting time, the invalid time consumption in non-terminal release scenarios is significantly reduced, thus significantly improving the response speed of RRC connection release.

[0021] Optionally, the first estimated maximum waiting time is equal to the third estimated maximum waiting time, and the first estimated maximum waiting time and the third estimated maximum waiting time are determined based on the processing time and slot length of the PDSCH.

[0022] In the above implementation process, the first and third estimated maximum waiting times are unified and determined based on the PDSCH processing time and slot length. This simplifies the terminal-side waiting time configuration logic, avoids the complex adaptation costs of different short-duration parameters in multiple scenarios, and ensures the accuracy and rationality of the duration setting. Its duration strictly conforms to the actual processing characteristics of the physical layer, being shorter than the maximum waiting time specified in the protocol, effectively avoiding redundant waiting time, while fully covering the necessary cycles of PDSCH processing and HARQ feedback, ensuring the reliability of underlying data reception.

[0023] Secondly, embodiments of this application provide a connection release message processing method, applied to a terminal, the method comprising: Receive RRC Release messages from network devices; Based on the triggering scenario associated with the RRC Release message, determine whether it is necessary to wait for confirmation feedback from the underlying layer before processing the RRC Release message; If not, then process the RRC Release message; If so, obtain the status information related to the processing of the RRC Release message; If the status information indicates that it is not necessary to wait for the status confirmation of the peer RLC entity, then the RRC Release message is processed based on the first estimated maximum waiting time, which is determined based on the HARQ feedback timing parameters and the slot length. If the status information indicates that it is necessary to wait for status confirmation from the peer RLC entity, the RRC Release message is processed based on the second estimated maximum waiting time. The second estimated maximum waiting time corresponds to the maximum waiting time specified by the communication protocol for the terminal to wait for underlying confirmation feedback after receiving the RRC Release message; and the second estimated maximum waiting time is longer than the first estimated maximum waiting time. The processing of the RRC Release message includes executing immediately upon receiving the corresponding confirmation feedback before the estimated maximum waiting time times out, or executing when the estimated maximum waiting time times out.

[0024] In the above implementation process, by first distinguishing the triggering scenarios of RRC Release messages and then adapting the processing strategy as needed, the connection release is directly executed for scenarios that do not require waiting for underlying confirmation feedback (such as terminal shutdown and other final release scenarios), which greatly shortens the latency of key operations and improves the user experience. For scenarios that require waiting, relevant status information is obtained and the estimated maximum waiting time is not exceeded by the maximum waiting time specified by the communication protocol, which effectively avoids the invalid time consumption caused by the fixed long waiting time in the existing technology.

[0025] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the steps of the method provided in the first aspect above are performed.

[0026] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the steps of the method provided in the first aspect above.

[0027] Fifthly, embodiments of this application provide a computer program product, including computer program instructions, which, when read and executed by a processor, perform the steps of the method provided in the first aspect above.

[0028] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 A flowchart illustrating a connection release message processing method provided in this application embodiment; Figure 2 A flowchart illustrating another connection release message processing method provided in this application embodiment; Figure 3 A structural block diagram of a connection release message processing device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device for executing a connection release message processing method, provided in an embodiment of this application. Detailed Implementation

[0031] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0032] It should be noted that the terms "system" and "network" in the embodiments of this invention can be used interchangeably. "Multiple" refers to two or more; therefore, in the embodiments of this invention, "multiple" can also be understood as "at least two". "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / ", unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0033] It should also be noted that all actions involving the acquisition of signals, information, or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where the application is located, and with the authorization granted by the owner of the relevant device.

[0034] To ensure the reliability of the terminal's RRC state transition from RRC_CONNECTED to RRC_IDLE or RRC_INACTIVE, and to prevent inconsistencies between the network and the terminal due to signaling loss (i.e., the network believes the terminal is still in the connected state, while the terminal has actually entered the idle state), the protocol defines strict processing timing constraints. Specifically, the current protocol stipulates that a fixed waiting time must be forcibly inserted from the moment the terminal's RRC layer successfully receives and parses the RRC Release message until it begins to execute the release operations specified in the protocol (such as releasing resource configuration and performing state transitions). The maximum duration of this waiting time is explicitly defined as 60 milliseconds.

[0035] The fundamental purpose of this fixed waiting period is to ensure that the downlink transmission carrying the RRC Release message is fully acknowledged at the underlying layer. The underlying technical logic involves two acknowledgment mechanisms: First, at the physical layer, the terminal needs to use the Hybrid Automatic Repeat reQuest (HARQ) mechanism to send a HARQ ACK to the network for the Physical Downlink Shared Channel (PDSCH) transmission carrying signaling, confirming the successful reception of physical data. Second, at the radio link control layer, if the RRC Release message is carried using an acknowledgment mode requiring reliable transmission, the network-side RLC (Radio Link Control) entity may set a polling bit, requiring the terminal-side RLC entity to send a status report for end-to-end acknowledgment at the link layer. The 60ms fixed duration specified in the protocol is designed to provide a sufficiently ample time window to cover the worst-case scenario for the completion of these two acknowledgment responses.

[0036] However, this fixed waiting time design has revealed significant limitations in practice. First, it inevitably introduces additional service latency. Regardless of the actual channel conditions or whether the underlying acknowledgment has been completed in advance, the terminal must wait until the fixed time expires, artificially extending the perceived service interruption time and impacting the real-time service experience. Second, it increases unnecessary power consumption of the terminal. During the waiting period, multiple protocol stack layers and corresponding hardware modules of the terminal must remain active to monitor potential feedback, preventing them from immediately entering a low-power state, resulting in the inefficient consumption of battery energy.

[0037] To address the aforementioned issues, this application provides a connection release message processing method. This method is applied to a terminal and dynamically determines whether to wait for underlying confirmation feedback and matches differentiated processing strategies by performing scenario-based determination of the triggering scenario of the RRC Release message. This optimizes the terminal processing efficiency and reduces business processing latency while ensuring the reliability of connection release.

[0038] Please refer to Figure 1 , Figure 1 A flowchart of a connection release message processing method provided in this application embodiment is included, the method comprising the following steps: Step S110: Receive an RRC Release message from the network device.

[0039] The RRC Release message is a connection release instruction sent by a network device to a terminal. It is used to release or suspend the RRC connection (including releasing the bearer, radio resource configuration, or redirection). The network device will trigger this message when the terminal has established SRB2 and at least one DRB.

[0040] Terminals can receive RRC Release messages from network devices via the air interface. These messages can carry configuration information related to connection release (such as the release reason and redirection parameters). For example, after a mobile phone completes a video call, the base station sends an RRC Release message to notify the mobile phone to switch from RRC_CONNECTED (connected state) to RRC_INACTIVE (inactive state) or RRC_IDLE (idle state). After the mobile phone, as the terminal, successfully receives the message, it enters the subsequent processing flow.

[0041] Step S120: Based on the triggering scenario associated with the RRC Release message, determine whether it is necessary to wait for confirmation feedback from the underlying layer before processing the RRC Release message.

[0042] After receiving the RRC Release message, the terminal parses the message over the air interface to obtain the release-related configuration information carried in the message, and simultaneously initiates the scenario determination process. The terminal can query the triggering reason of the message through the newly added dedicated interface between RRC and NAS (Non-Access Stratum) to distinguish the scenario type. This dedicated interface is used by the NAS layer to proactively send explicit scenario indication information to the RRC layer when triggering specific processes such as shutdown.

[0043] The triggering scenarios in this scheme can be divided into final release scenarios and non-final release scenarios, distinguished by whether the terminal needs to immediately or prepare to re-establish the connection within a foreseeable short period after executing this RRC connection release. The core characteristic of a final release scenario is that the terminal explicitly knows that it does not need to maintain the current network connection state after this release; a typical example is the non-access stratum detach process triggered by the terminal powering off. A non-final release scenario refers to a situation where the terminal's wireless communication capability does not terminate after releasing the current connection, and the connection may be quickly re-established based on network configuration or service needs, such as a release triggered by data transmission completion or network load balancing. The following explanation will primarily use the "detach process triggered by power-off" as an example of a final release scenario.

[0044] Of course, in specific applications, you can choose whether to wait for confirmation feedback from the underlying layer before processing the RRC Release message, depending on the different triggering scenarios.

[0045] In this scheme, if the triggering scenario associated with the RRC Release message is a final release scenario, the result is determined that there is no need to wait for confirmation feedback from the underlying layer before processing the RRC Release message. If the triggering scenario associated with the RRC Release message is a non-final release scenario, the result is determined that there is need to wait for confirmation feedback from the underlying layer before processing the RRC Release message.

[0046] The underlying confirmation feedback can include RLC ACK and HARQ ACK. RLC ACK is used to confirm the successful reception of RLC layer data, and HARQ ACK is used to confirm the reception status of PDU (Protocol Data Unit) at the physical layer.

[0047] In some implementations, the terminal can identify the triggering scenario by querying the triggering reason of the RRC Release message. For example, if the terminal queries the triggering reason of the message and the query result is "terminal power-off triggers NAS detach", it is determined to be a final release scenario. It is determined that there is no need to wait for the underlying RLC ACK and HARQ ACK, and the RRC Release process is executed directly. This includes releasing the established SRB2 and DRB bearers, clearing the radio resource configuration, switching the RRC state from RRC_CONNECTED to RRC_IDLE, and completing the connection release. For example, when a user actively powers off the phone, the phone, as the terminal, triggers the NAS detach process. After receiving the RRC Release message from the base station, it does not need to wait for the underlying ACK feedback and executes the release operation directly, significantly shortening the power-off latency.

[0048] If the triggering reason found through the RRC and NAS interface is not related to the shutdown-related NAS detach process, it is determined to be a non-terminal release scenario, and it is necessary to wait for the underlying confirmation feedback before processing the RRC Release message.

[0049] This approach precisely distinguishes between final and non-final release scenarios of RRC Release messages and formulates differentiated confirmation feedback strategies. For final release scenarios such as terminal shutdown, the underlying confirmation waiting step is eliminated, significantly reducing the latency of critical operations such as shutdown and improving the user experience. For non-final release scenarios such as network redirection and data transmission completion, the underlying confirmation feedback waiting mechanism is retained to ensure the consistency of network and terminal states and avoid communication anomalies caused by premature connection release.

[0050] In some other implementations, the terminal can also identify the triggering scenario through received indication information. For example, if the aforementioned final release scenario includes a non-access stratum (NAS) detach process triggered by the terminal powering off, then when identifying the triggering scenario, if indication information from the NAS is received, the triggering scenario is determined to be a final release scenario. This indication information is used to characterize that the terminal is currently in a detach process triggered by powering off; otherwise, the triggering scenario is considered to be a non-final release scenario.

[0051] After receiving the RRC Release message, the terminal can use the newly added dedicated RRC and NAS interface to check whether it can receive indication information from the NAS layer. This interface provides a direct data transmission channel for scene determination, ensuring the accuracy and real-time performance of scene recognition. The indication information is a characterizing signal sent from the NAS layer to the RRC layer, specifically used to inform the RRC layer that the terminal is currently in a NAS detach process triggered by power-off.

[0052] If the terminal successfully receives the indication information through this interface, it is clear that the terminal is currently in a NAS detach process triggered by power-off. The triggering scenario is directly determined to be a final release scenario, and there is no need to wait for the underlying RLC ACK and HARQACK; the RRC Release processing operation is then executed directly. If the terminal does not receive the above indication information through the dedicated interface between RRC and NAS, the triggering scenario is determined to be a non-final release scenario, and it is necessary to wait for confirmation feedback from the underlying layer before processing the RRC Release message.

[0053] By using explicit indications from the non-access layer as the basis for identifying the final release scenario, the accuracy and reliability of scenario determination are ensured, and processing anomalies caused by misjudgment of the scenario are avoided.

[0054] Step S130: Based on the determined result, select the corresponding connection release handling strategy to process the RRC Release message.

[0055] The above steps can determine whether it is necessary to wait for confirmation feedback from the underlying layer based on the triggering scenario, and obtain the corresponding confirmation result. That is, the confirmation result includes whether it is not necessary to wait for confirmation feedback from the underlying layer before processing the RRC Release message and whether it is necessary to wait for confirmation feedback from the underlying layer before processing the RRC Release message.

[0056] If there is no need to wait for confirmation feedback from the underlying layer before processing the RRC Release message, the terminal can directly execute the processing of the RRC Release message, including releasing the established bearer, clearing the radio resource configuration, and switching the RRC state to the target state, without waiting for any underlying ACK, which can significantly shorten the processing latency.

[0057] If it is necessary to wait for confirmation feedback from the underlying layer before processing the RRC Release message, the terminal can wait for confirmation feedback from the underlying layer for a set time (such as 60ms as specified in the protocol) before processing the RRC Release message.

[0058] Understandably, the connection release handling strategy here may include processing the RRC Release message immediately, or waiting for a set period of time before processing the RRC Release message. Alternatively, in subsequent embodiments, in a non-terminal release scenario, the RRC Release message may be processed by obtaining status information.

[0059] In the above implementation process, by performing scenario-based determination of the triggering scenario of RRC Release message, dynamically determining whether it is necessary to wait for underlying confirmation feedback and matching differentiated processing strategies, the terminal processing efficiency is optimized, thereby reducing business processing latency while ensuring the reliability of connection release.

[0060] Based on the above embodiments, when the triggering scenario is identified as a non-terminal release scenario, it indicates that confirmation feedback from the underlying layer needs to be waited before processing the RRC Release message. In order to further optimize the terminal processing latency, status information related to the processing of the RRC Release message can be obtained, and the RRC Release message can be processed based on the estimated maximum waiting time. The estimated maximum waiting time is less than or equal to the maximum waiting time specified by the communication protocol, which is the maximum waiting time that the terminal needs to wait for confirmation feedback from the underlying layer after receiving the RRC Release message.

[0061] The status information can be understood as the underlying feedback requirements and status related to the processing of RRC Release messages. Specifically, it may include whether RLC ACK is needed, whether RLC ACK has been replied to, and whether HARQ ACK has been replied to. RLC ACK is used to confirm the successful reception of RLC layer data, and its triggering depends on the polling bit and underlying processing. HARQ ACK is fed back by L1C (Layer 1 Control, physical layer) and is used to confirm the reception status of PDU at the physical layer.

[0062] After identifying the triggering scenario as a non-terminal release scenario, the terminal initiates a status information acquisition process, such as through a newly added dedicated interface for status query. Based on the acquired status information, the terminal executes a differentiated processing strategy within the estimated maximum waiting time. In some cases, the estimated maximum waiting time is the maximum waiting time specified in the protocol, i.e., 60ms. In other cases, the estimated maximum waiting time is less than the maximum waiting time specified in the protocol. In this case, the terminal does not need to wait 60ms to execute the RRC Release message processing, which can effectively shorten the processing latency.

[0063] In the above implementation process, when it is determined that it is necessary to wait for the underlying confirmation feedback, the relevant status information of the RRC Release message is obtained and processed based on the estimated maximum waiting time not exceeding the maximum waiting time specified in the protocol. This strictly follows the communication protocol specifications and ensures the reliability of the underlying confirmation feedback and the consistency of the network and terminal status.

[0064] Based on the above embodiments, when obtaining status information, the confirmation status information of the Radio Link Control (RLC) can be obtained. This confirmation status information is used to indicate whether the RLC service data unit carrying the RRC Release message needs to wait for the status confirmation of the peer RLC entity. The aforementioned status information includes this confirmation status information.

[0065] In this context, peer RLC entities refer to the corresponding interactive entities of the terminal-side RLC and the network-side RLC. The RLC Service Data Unit (RLC SDU) is the upper-layer (RRC layer) data unit received by the RLC layer. The RLC SDU carrying the RRC Release message is an RLC layer data unit that encapsulates the RRC Release instruction. RLC acknowledgment status information is the core status information, specifically used to indicate whether the RLC SDU carrying the RRC Release message needs to wait for status acknowledgment from the peer RLC entity (i.e., the RLC STATUS report). It can include two states: "acknowledgment required" and "acknowledgment not required."

[0066] Once the terminal determines that it needs to wait for confirmation feedback from the lower layer, it needs to determine the required waiting strategy before processing the message. To achieve this, the RRC layer will proactively initiate a query to the RLC entity serving the signaling radio bearer. This query can be implemented through newly added or existing internal inter-layer primitives (such as RRC_RLC_ACK_REQUIREMENT_QUERY). The query request must carry information that uniquely identifies the RLC SDU corresponding to the RRC Release message, such as the RB identifier (e.g., SRB2) and the RLC sequence number. If a new interface is used, a dedicated query interface can be added between the RRC layer and the RLC layer, as well as a dedicated query interface between the RRC layer and the L1C module.

[0067] After receiving a query request, the RLC layer can parse the pre-configured parameters of the RLC SDU stored locally (which are sent in advance by the network side via RRC signaling) to determine whether the SDU has enabled the RLC STATUS reporting mechanism. If enabled, it will return RLC confirmation status information that "it is necessary to wait for the status confirmation of the peer RLC entity"; if not enabled, it will return information that "it is not necessary to wait for the status confirmation of the peer RLC entity".

[0068] In some implementations, after receiving a query request, the RLC layer may also perform the following logical checks to generate confirmation status information and reply to the RRC layer: (1) Check the transmission mode: First, confirm whether the RLC entity carrying the SDU is working in acknowledged mode (AM mode). This is because only AM mode involves waiting for the peer's status report. If it is working in unacknowledged mode or transparent mode, the RLC layer can directly reply "No need to wait for peer status acknowledgment".

[0069] (2) Check the polling bit status: If it is in AM mode, the RLC layer looks up the RLC PDU that encapsulates the SDU. Check whether the polling bit in the header of the PDU was set to "1" when it was sent. The setting of this bit is determined by the RLC protocol rules, usually based on timers or window progress. For critical signaling such as RRC Release, the network-side RLC layer is very likely to set this bit to request reliable acknowledgment.

[0070] (3) Check for existing acknowledgment status: Even if the polling bit is set, the RLC layer still needs to check whether it has received a STATUS PDU that covers the PDU sequence number from the peer RLC entity (network side). If it has been received, it means that the acknowledgment has been completed.

[0071] (4) Generate confirmation status information: Based on the above checks, the RLC layer replies with a clear indication message to the RRC layer. For example: "Need to wait": When the transmission mode is AM, the polling bit is set, and no status acknowledgment has been received from the other end.

[0072] "No need to wait": When the transmission mode is not AM, or although it is AM mode, the polling bit is not set, or a status acknowledgment has been received from the other end.

[0073] In the above implementation process, by obtaining the confirmation status information of the radio link control layer, it is possible to accurately determine whether the RLC service data unit carrying the RRCrease message needs to wait for the status confirmation of the peer RLC entity. This provides an accurate and practical basis for estimating the maximum waiting time, so that the waiting strategy no longer depends on a fixed duration but adapts to specific confirmation requirements. This avoids invalid time consumption in scenarios where RLC status confirmation is not required, and ensures the reliability of the underlying feedback in scenarios where confirmation is required.

[0074] Based on the above embodiments, if the confirmation status information indicates that it is not necessary to wait for the status confirmation of the peer RLC entity, then the RRC Release message is processed based on the first estimated maximum waiting time. If the confirmation status information indicates that it is necessary to wait for the status confirmation of the peer RLC entity, then the RRC Release message is processed based on the second estimated maximum waiting time. The second estimated maximum waiting time is the maximum waiting time specified by the communication protocol for the terminal to wait for the underlying confirmation feedback after receiving the RRC Release message. The second estimated maximum waiting time is longer than the first estimated maximum waiting time.

[0075] Based on the acknowledgment status information returned by the RLC layer, the RRC layer starts the corresponding timer and executes the differentiated waiting strategy.

[0076] If the confirmation status indicates that no waiting is required, the RRC layer starts a timer with a duration of T1 (the first estimated maximum waiting time). Since no higher-level confirmation is needed at this point, once the T1 timer expires, the RRC layer can immediately execute the RRCRelease message processing (such as releasing resources and changing the state). T1 serves as the maximum waiting guarantee for this path, and its value is much smaller than the general fixed maximum waiting time T2, achieving significant latency compression.

[0077] Additionally, during T1, the RRC layer can simultaneously monitor the physical layer for events regarding whether HARQ ACK has been successfully returned. If it is confirmed before T1 timeout that the physical layer has successfully returned HARQ ACK, the RRC Release message can be processed immediately.

[0078] For example, after querying the RLC, the RRC layer learns that the message is marked as "no need to wait for peer confirmation" at the RLC layer. The RRC layer then starts timer T1 (let's assume it's 8ms). Simultaneously, the physical layer reports a HARQ ACK response after 3ms. The RRC layer can safely process the release the instant it receives this successful response from the physical layer (i.e., at 3ms), without waiting for the 8ms T1 timer to expire, much earlier than the 60ms (T2) that might have been expected.

[0079] If the confirmed status information indicates that waiting is required, the RRC layer starts a timer with a duration of T2 (the second estimated maximum waiting time, i.e., the maximum waiting time specified in the protocol, such as 60ms). During this timer's operation, the RRC layer monitors event notifications from the RLC layer. If the RLC layer successfully receives a status acknowledgment (STATUS PDU) from the peer (network side) before T2 timeout and proactively reports an internal indication that "peer acknowledgment received," the RRC layer can perform processing at this point. If this successful indication is not received during the entire T2 period, the RRC layer will perform release processing at the T2 timeout as a worst-case scenario safeguard.

[0080] For example, after querying the RLC, the RRC layer learns that the message requires confirmation of the peer's RLC status. The RRC layer starts a T2 timer (60ms). After 20ms, the peer network's RLC processes the message and returns a STATUS PDU confirming the status. Upon receiving this, the terminal's RLC layer immediately notifies the RRC layer. The RRC layer processes the release immediately upon receiving the notification (at the 20ms mark). Although this path's waiting time (20ms) is longer than T1, it still saves 40ms of latency compared to waiting for a 60ms timeout. If the peer network fails to respond due to an anomaly, the terminal will handle the message as a fallback after the T2 (60ms) timeout. This latency is consistent with the behavior specified in existing protocols, ensuring reliability.

[0081] Additionally, during T2, the RRC layer can simultaneously monitor the physical layer for events regarding whether HARQ ACK has been returned. If it is confirmed before T2 timeout that the physical layer has successfully returned HARQ ACK and the peer network's RLC has processed and returned an acknowledgment STATUS PDU, the RRC Release message can be processed immediately.

[0082] In the above implementation process, based on the confirmation status information of the radio link control layer, a differentiated estimated maximum waiting time is configured for the processing of RRC Release messages. This not only strictly follows the communication protocol specifications but also achieves precise optimization of the waiting strategy: when there is no need to wait for confirmation of the status of the peer RLC entity, a shorter first estimated maximum waiting time is used, which greatly reduces the time spent on invalid waiting and quickly completes the connection release; when waiting is required, the second estimated maximum waiting time specified by the protocol is used to ensure the reliability of the underlying feedback and the consistency of the network and terminal status, effectively avoiding communication anomalies.

[0083] Based on the above embodiments, when obtaining status information, HARQ feedback status information of the physical layer can also be obtained. The HARQ feedback status information is used to indicate the HARQ acknowledgment status of the PDSCH carrying the RRC Release message. The aforementioned status information includes the HARQ feedback status information.

[0084] HARQ acknowledgment statuses typically include the following: ACK (indicating that the PDSCH transmission has been successfully decoded), NACK (indicating that the PDSCH decoding failed), and Pending (waiting, indicating that the current time has not yet reached the HARQ feedback timing specified by the protocol (defined by parameter k1), and the final status is unknown).

[0085] Once the RRC layer enters the optimization waiting process, it can simultaneously initiate a targeted status query to the Physical Layer (L1C) while simultaneously querying the RLC layer. This query can be initiated using newly added or existing internal inter-layer control primitives (e.g., RRC_L1C_HARQ_STATUS_REQ). The request message contains key information that uniquely identifies the target PDSCH transmission, such as: the time-domain resources (e.g., system frame number, timeslot number) where the PDSCH resides, the frequency-domain resource allocation, and the associated HARQ process ID. This information can be obtained by the RRC layer when receiving and parsing the scheduling signaling (such as downlink control information) of the RRC Release message.

[0086] Upon receiving this query request, the physical layer (L1C) performs the following operations to generate a feedback status: Locate the transmission instance: Based on the parameters in the query request, locate the corresponding PDSCH receiving instance in the internal cache or HARQ process status table.

[0087] Check processing progress: Determine whether the decoding process of this PDSCH has been completed. If it has been completed successfully, the status is ACK; if it has been completed but failed, the status is NACK.

[0088] Check feedback timing: If the processing has not yet been completed, or the processing has been completed but the uplink HARQ feedback time slot specified in the protocol (determined by the k1 value) has not yet arrived, the status is Pending.

[0089] Return status information: L1C returns the determined HARQ feedback status (ACK / NACK / Pending) to the RRC layer through a reply primitive (e.g., L1C_RRC_HARQ_STATUS_CNF).

[0090] After receiving this HARQ feedback status information, the RRC layer can process the RRC Release message in conjunction with the feedback status.

[0091] Understandably, the physical layer HARQ feedback status information can be obtained synchronously when obtaining the confirmation status information mentioned above. That is, the terminal can synchronously listen to the physical layer HARQ feedback status information within the first estimated maximum waiting time or the second estimated maximum waiting time. If a HARQ confirmation instruction is received, the connection release process is executed immediately. Otherwise, the terminal waits for the timeout of the first estimated maximum waiting time or the second estimated maximum waiting time to process the request.

[0092] In the above implementation process, by obtaining the HARQ feedback status information of the physical layer, the HARQ confirmation status of the PDSCH carrying the RRRCRelease message is accurately grasped, providing a precise basis at the physical layer level for the waiting strategy in the non-final release scenario, avoiding blind waiting caused by relying solely on fixed duration or a single layer status.

[0093] Based on the above embodiments, if the HARQ feedback status information indicates a HARQ confirmation indication, then the RRC Release message is processed based on the third estimated maximum waiting time. The third estimated maximum waiting time is less than the maximum waiting time specified in the communication protocol that the terminal needs to wait for the underlying confirmation feedback after receiving the RRC Release message.

[0094] In this scheme, the HARQ acknowledgment indicates the HARQ feedback status obtained from the physical layer (L1C) for a specific PDSCH transmission instance carrying this RRRCRelease message, with a value of ACK. This indication means that the PDSCH transmission has been successfully decoded at the physical layer, and the terminal has generated or will generate a HARQ ACK to feed back to the network according to the protocol, marking the success of the air interface downlink transmission.

[0095] The RRC layer queries the physical layer through its internal interface and obtains the HARQ feedback status for the target PDSCH transmission. When the returned status is ACK, the RRC Release message is processed based on the third estimated maximum wait time. If the status is Pending or NACH, the process will fall back to another path that depends on the RLC status or a longer timer (such as the second estimated maximum wait time mentioned above).

[0096] Once the HARQ ACK is confirmed, the RRC layer immediately starts a timer with a duration of T3 (the third estimated maximum wait time). At this point, it is no longer necessary to start the maximum wait timer (T2) specified in the protocol. The start of T3 signifies that the processing flow has entered a rapid closure phase.

[0097] During the T3 timer's execution, the RRC layer can complete some of the preparatory work required for the release operation in parallel. When the T3 timer expires, the RRC layer immediately performs the final processing of the RRC Release message, including releasing the radio resource configuration and updating the RRC status. There is no need to wait for any acknowledgment notification from the RLC layer (even if the RLC indicates "wait is required," this is "overridden" or "preempted" by the reliable acknowledgment from the physical layer). This eliminates the need to start or continue waiting for a timer as long as T2, effectively optimizing the waiting strategy by leveraging the faster feedback characteristics of HARQ ACK.

[0098] In some implementations, when coordinating with the aforementioned confirmation status information, if the RLC confirmation status information obtained at the same time is "no need to wait", then a dual guarantee of "physical layer success + no need for higher layer confirmation" is formed. In this case, the confidence level of executing the release after the shortest timeout between T1 and T3 (when T1 and T3 are not equal) is the highest, which is the path with the lowest latency.

[0099] If the RLC confirmation status is "needs to wait," but the T3 path is still chosen based on the HARQ ACK in this approach, it reflects an aggressive optimization strategy that prioritizes physical layer success. This indicates that for critical signaling such as RRC Release, successful physical layer transmission is fundamental, and the network side usually considers the downlink transmission successful after receiving the HARQ ACK.

[0100] In some implementations, if a HARQ feedback status information indicating a HARQ confirmation is received within the third estimated maximum waiting time, the connection release process is executed immediately; otherwise, the process is executed after the third estimated maximum waiting time has expired.

[0101] In the above embodiments, the first estimated maximum waiting time and the third estimated maximum waiting time can be equal or unequal. The specific values ​​can be set according to actual needs, and they can be less than the second estimated maximum waiting time.

[0102] In the above implementation process, when the HARQ feedback status information indicates HARQ feedback confirmation, the RRC Release message is processed with a third estimated maximum waiting time shorter than the maximum waiting time specified in the protocol. This ensures that the PDSCH carrying the message has been reliably received based on the physical layer HARQ confirmation result, eliminating the need for redundant long-term waiting. Furthermore, by shortening the waiting time, the invalid time consumption in non-terminal release scenarios is significantly reduced, thus significantly improving the response speed of RRC connection release.

[0103] In some implementations, the first estimated maximum waiting time is equal to the third estimated maximum waiting time, which is determined based on the processing time and slot length of the PDSCH.

[0104] The estimation of the maximum waiting time is based on the analysis and comparison of the theoretical maximum latency of different underlying acknowledgment feedback mechanisms. According to the protocol, the timing of HARQ ACK feedback is explicitly defined by parameter k1, and its maximum latency can be precisely calculated and is usually short (e.g., about 15ms). RLC status acknowledgment triggering depends on the polling bit setting and peer processing, and its maximum latency is no less than that of HARQ ACK. The protocol uniformly specifies its upper limit (T2, such as 60ms). Therefore, when it is determined that RLC status acknowledgment is not required, it is safe to use the shorter T1 or T3 latency calculated based on k1 as the waiting limit, thereby achieving latency optimization.

[0105] The processing time of PDSCH is defined by parameter k1 in the communication protocol. k1 is an integer value configured by the network to the terminal via RRC signaling, indicating how many time slots the terminal needs to wait after receiving the last symbol of PDSCH before it can send back HARQ ACK information in the corresponding uplink time slot. It essentially specifies the maximum time limit from "reception completed" to "processing must be completed and ready to send back".

[0106] A time slot is the basic time unit for NR air interface scheduling, and its length depends on the subcarrier spacing. For example, for a 15 kHz subcarrier spacing, one time slot is 1 millisecond; for 30 kHz, it is 0.5 milliseconds.

[0107] The formulas for calculating the first and third estimated maximum waiting times are: T = k1 * time slot length. This duration represents the maximum theoretical processing window reserved by the terminal for processing the PDSCH carrying the RRC Release message and generating HARQ feedback.

[0108] During RRC connection establishment or reconfiguration, the terminal obtains the configuration value of k1 from the network side. Simultaneously, the terminal determines the current timeslot length based on the subcarrier spacing configured for the activated bandwidth portion. The RRC layer or a shared protocol stack timing management module calculates the precise value of T based on this (e.g., if k1=30 and the timeslot length is 0.5ms, then T=15ms, much smaller than the protocol-specified 60ms), and stores it for use in subsequent processes.

[0109] In the above implementation process, the first and third estimated maximum waiting times are unified and determined based on the PDSCH processing time and slot length. This simplifies the terminal-side waiting time configuration logic, avoids the complex adaptation costs of different short-duration parameters in multiple scenarios, and ensures the accuracy and rationality of the duration setting. Its duration strictly conforms to the actual processing characteristics of the physical layer, being shorter than the maximum waiting time specified in the protocol, effectively avoiding redundant waiting time, while fully covering the necessary cycles of PDSCH processing and HARQ feedback, ensuring the reliability of underlying data reception.

[0110] The following example illustrates the implementation process of the above solution.

[0111] Assuming the maximum waiting time specified by the protocol (the second estimated maximum waiting time T2) is 60ms, the physical layer processing parameter k1 is configured with 30 time slots, and the current subcarrier spacing is 30kHz (time slot length is 0.5ms), then the calculated first / third estimated maximum waiting time T1 or T3 = 30 * 0.5ms = 15ms.

[0112] Scenario 1: In a non-power-off scenario, the terminal is in a normal connected state and receives an RRC Release message requesting to be released to RRC_IDLE due to network load adjustment.

[0113] At time T0, the terminal's RRC layer receives and decodes the RRC Release message. It is determined to be a normal release scenario not triggered by power-off, and enters the optimized waiting process.

[0114] At time T0+0.1ms, query the RLC layer for confirmation status (query whether the RLC SDU carrying this message needs to wait for confirmation from the peer) and query the L1C layer for HARQ feedback status (query the HARQ confirmation status of this PDSCH transmission).

[0115] At T0+0.5ms, the query result is returned: RLC reply does not need to wait, the terminal starts timer T1=15ms, and synchronously listens for the reply from L1C layer within this time.

[0116] At T0+2ms, the L1C layer replies with an ACK status in the HARQ, and starts timer T3. Since the third estimated maximum waiting time is equal to the first estimated maximum waiting time, the same timer can be used for joint judgment. Because timer T1 has already started, the processing of the RRC Release message can be performed directly.

[0117] At T0+2.1ms, the RRC Release process is executed to release the radio bearer and switch the state to RRC_IDLE.

[0118] Of course, if no HARQ feedback status is received from the L1C layer within 15ms, or if the received feedback status is Pending or NACK, RRC Release processing will be performed after waiting for 15ms, such as at T0+15.6ms. The entire waiting time is also shorter than the 60ms specified in the protocol, greatly reducing processing latency.

[0119] Scenario 2: In a non-power-off scenario, the terminal receives an RRC Release message requesting suspension to RRC_INACTIVE.

[0120] At time T0, the terminal's RRC layer receives and decodes the RRC Release message. It is determined to be a normal release scenario not triggered by power-off, and enters the optimized waiting process.

[0121] At time T0+0.1ms, query the RLC layer for confirmation status (query whether the RLC SDU carrying this message needs to wait for confirmation from the peer) and query the L1C layer for HARQ feedback status (query the HARQ confirmation status of this PDSCH transmission).

[0122] At T0+0.5ms, the query result returns: the RLC reply indicates that it needs to wait for confirmation from the other end. The terminal starts a timer T2=60ms and synchronously listens for the L1C layer's reply within this duration. The RRC layer subscribes to the RLC layer's "confirmation received" event notification and continuously monitors the T2 timer.

[0123] At T0+15ms, the network side completes the processing and sends an RLC STATUSPDU containing the corresponding acknowledgment status to the terminal. Upon receiving this, the terminal's RLC layer immediately generates an internal "peer acknowledgment received" event and notifies the subscribed RRC layers.

[0124] At T0+15.1ms, RRC Release is executed, releasing and suspending the status, and then the T2 timer is canceled.

[0125] Of course, in some implementations, the RRC Release message is processed only after receiving the HARQ acknowledgment from the L1C layer during this 60ms period.

[0126] If at T0+16ms, the L1C layer replies with a HARQ status indicating that HARQ ACK has been received, then all necessary acknowledgments have been obtained.

[0127] At T0+16.1ms, RRC Release is executed, releasing and suspending the status, and then the T2 timer is canceled.

[0128] Of course, if no status acknowledgment is received from the peer's RLC within 60ms, and no HARQ feedback status is received from the L1C layer, or if the feedback status is Pending or NACK, then the RRCrease process will be executed after waiting for 60ms.

[0129] Therefore, when the terminal needs to wait for confirmation feedback from the underlying layer, the RRC Release process can be executed once all the confirmation statuses at the underlying layer are known. Otherwise, it waits for the corresponding timeout mechanism. The maximum timeout is 60ms as specified in the protocol, which avoids the invalid time consumption caused by waiting for a fixed duration.

[0130] Please refer to Figure 2 , Figure 2 A flowchart of another connection release message processing method provided in this application embodiment, the method including the following steps: Step S210: Receive an RRC Release message from the network device.

[0131] Step S220: Based on the triggering scenario associated with the RRC Release message, determine whether it is necessary to wait for confirmation feedback from the underlying layer before processing the RRC Release message.

[0132] Step S230: Process the RRC Release message.

[0133] Step S240: Obtain status information related to the processing of the RRC Release message; Step S250: If the status information indicates that it is not necessary to wait for the status confirmation of the peer RLC entity, then process the RRC Release message based on the first estimated maximum waiting time.

[0134] The first estimated maximum waiting time is determined based on the HARQ feedback timing parameters and the time slot length.

[0135] Step S260: If the status information indicates that it is necessary to wait for the status confirmation of the peer RLC entity, then process the RRC Release message based on the second estimated maximum waiting time.

[0136] The second estimated maximum waiting time corresponds to the maximum waiting time that the terminal needs to wait for the underlying confirmation feedback after receiving the RRC Release message, as specified in the communication protocol, and the second estimated maximum waiting time is longer than the first estimated maximum waiting time.

[0137] The processing of the RRC Release message includes executing immediately upon receiving the corresponding confirmation feedback before the estimated maximum waiting time times out, or executing when the estimated maximum waiting time times out.

[0138] Understandably, for the sake of convenience and brevity, the detailed implementation process of this embodiment can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0139] In the above implementation process, by first distinguishing the triggering scenarios of RRC Release messages and then adapting the processing strategy as needed, the connection release is directly executed for scenarios that do not require waiting for underlying confirmation feedback (such as terminal shutdown and other final release scenarios), which greatly shortens the latency of key operations and improves the user experience. For scenarios that require waiting, relevant status information is obtained and the estimated maximum waiting time is not exceeded by the maximum waiting time specified by the communication protocol, which effectively avoids the invalid time consumption caused by the fixed long waiting time in the existing technology.

[0140] Please refer to the above method embodiments. Figure 3 , Figure 3 This is a structural block diagram of a connection release message processing device 300 provided in an embodiment of this application. The device 300 may be a module, program segment, or code on an electronic device. It should be understood that the device 300 corresponds to the above method embodiment and is capable of executing the various steps involved in the method embodiment. The specific functions of the device 300 can be found in the description above. To avoid repetition, detailed descriptions are appropriately omitted here.

[0141] Optionally, the device 300 includes: Message receiving module 310 is used to receive RRC Release messages from network devices; The determination module 320 is used to determine, based on the triggering scenario associated with the RRC Release message, whether it is necessary to wait for confirmation feedback from the underlying layer before processing the RRC Release message; The processing module 330 is used to select the corresponding connection release processing strategy to process the RCRelease message based on the determined result.

[0142] Optionally, the determining module 320 is configured to determine that if the triggering scenario associated with the RRC Release message is a final release scenario, then there is no need to wait for confirmation feedback from the underlying layer before processing the RRC Release message; and if the triggering scenario associated with the RRC Release message is a non-final release scenario, then there is a need to wait for confirmation feedback from the underlying layer before processing the RRC Release message.

[0143] Optionally, the final release scenario includes a non-access stratum detach process scenario triggered by the terminal being powered off, and the triggering scenario is identified in the following ways: If an indication message is received from the non-access layer, the triggering scenario is determined to be a final release scenario. The indication message is used to indicate that the terminal is currently in a power-off triggered detach process.

[0144] Optionally, the processing module 330 is configured to, if the determination result is that confirmation feedback from the underlying layer needs to be waited before processing the RRC Release message, obtain status information related to the processing of the RRC Release message, and process the RRC Release message based on the estimated maximum waiting time, wherein the estimated maximum waiting time is less than or equal to the maximum waiting time specified by the communication protocol for the terminal to wait for confirmation feedback from the underlying layer after receiving the RRC Release message.

[0145] Optionally, the processing module 330 is configured to acquire confirmation status information from the radio link control layer. The confirmation status information is used to indicate whether the RLC service data unit carrying the RRC Release message needs to wait for status confirmation from the peer RLC entity. The status information includes the confirmation status information.

[0146] Optionally, the processing module 330 is configured to process the RRC Release message based on a first estimated maximum waiting time if the confirmation status information indicates that it is not necessary to wait for the status confirmation of the peer RLC entity; and to process the RRC Release message based on a second estimated maximum waiting time if the confirmation status information indicates that it is necessary to wait for the status confirmation of the peer RLC entity. The second estimated maximum waiting time is the maximum waiting time specified by the communication protocol for the terminal to wait for the underlying confirmation feedback after receiving the RRC Release message, and the second estimated maximum waiting time is longer than the first estimated maximum waiting time.

[0147] Optionally, the processing module 330 is configured to acquire HARQ feedback status information of the physical layer, wherein the HARQ feedback status information is used to indicate the HARQ acknowledgment status of the PDSCH carrying the RRC Release message, and the status information includes the HARQ feedback status information.

[0148] Optionally, the processing module 330 is configured to process the RRC Release message based on a third estimated maximum waiting time if the HARQ feedback status information indicates a HARQ confirmation indication. The third estimated maximum waiting time is less than the maximum waiting time specified in the communication protocol for the terminal to wait for underlying confirmation feedback after receiving the RRC Release message.

[0149] Optionally, the first estimated maximum waiting time is equal to the third estimated maximum waiting time, and the first estimated maximum waiting time and the third estimated maximum waiting time are determined based on the processing time and slot length of the PDSCH.

[0150] It should be noted that those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0151] Please refer to Figure 4 , Figure 4 This application provides a schematic diagram of the structure of an electronic device for executing a connection release message processing method. The electronic device may include: at least one processor 410, such as a CPU; at least one communication interface 420; at least one memory 430; and at least one communication bus 440. The communication bus 440 is used to implement connection communication between these components. In this embodiment, the communication interface 420 is used for signaling or data communication with other node devices. The memory 430 may be a high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 430 may also be at least one storage device located remotely from the aforementioned processor. The memory 430 stores computer-readable instructions, which, when executed by the processor 410, cause the electronic device to perform the aforementioned method process.

[0152] Understandable. Figure 4 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown. Figure 4 The components shown can be implemented using hardware, software, or a combination thereof.

[0153] This application provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it performs the method process executed by the electronic device in the above method embodiments.

[0154] This embodiment discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer can perform the methods provided in the above-described method embodiments, such as including: Receive RRC Release messages from network devices; Based on the triggering scenario associated with the RRC Release message, determine whether it is necessary to wait for confirmation feedback from the underlying layer before processing the RRC Release message; Based on the determined result, the corresponding connection release processing strategy is selected to process the RRC Release message.

[0155] In summary, the embodiments of this application provide a connection release message processing method, an electronic device, a storage medium, and a program product. This method optimizes terminal processing efficiency by performing scenario-based determination of the triggering scenario of the RRC Release message, dynamically determining whether it is necessary to wait for underlying confirmation feedback and matching differentiated processing strategies, thereby reducing business processing latency while ensuring the reliability of connection release.

[0156] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0157] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0158] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0159] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0160] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for handling connection release messages, characterized in that, Applied to a terminal, the method includes: Receive RRC Release messages from network devices; Based on the triggering scenario associated with the RRC Release message, determine whether it is necessary to wait for confirmation feedback from the underlying layer before processing the RRC Release message; Based on the determined result, the corresponding connection release processing strategy is selected to process the RRC Release message.

2. The method according to claim 1, characterized in that, The step of determining whether to wait for confirmation feedback from the underlying layer before processing the RRC Release message, based on the triggering scenario associated with the RRC Release message, includes: If the triggering scenario associated with the RRC Release message is a final release scenario, then the result is that there is no need to wait for confirmation feedback from the underlying layer before processing the RRC Release message; If the triggering scenario associated with the RRC Release message is a non-terminal release scenario, then the result is determined that confirmation feedback from the underlying layer needs to be waited for before processing the RRC Release message.

3. The method according to claim 2, characterized in that, The final release scenario includes a non-access stratum detach process scenario triggered by the terminal powering off, and the triggering scenario is identified in the following ways: If an indication message is received from the non-access layer, the triggering scenario is determined to be a final release scenario. The indication message is used to indicate that the terminal is currently in a power-off triggered detach process.

4. The method according to claim 1, characterized in that, The step of selecting the corresponding connection release processing strategy to process the RRC Release message based on the determined result includes: If it is determined that confirmation feedback from the underlying layer is required before processing the RRC Release message, then the status information related to the processing of the RRC Release message is obtained, and the RRC Release message is processed based on the estimated maximum waiting time, wherein the estimated maximum waiting time is less than or equal to the maximum waiting time specified by the communication protocol for the terminal to wait for confirmation feedback from the underlying layer after receiving the RRC Release message.

5. The method according to claim 4, characterized in that, The acquisition of status information related to the processing of the RRC Release message includes: Obtain confirmation status information from the radio link control layer. The confirmation status information is used to indicate whether the RLC service data unit carrying the RRCrease message needs to wait for status confirmation from the peer RLC entity. The status information includes the confirmation status information.

6. The method according to claim 5, characterized in that, The process of processing the RRCRelease message based on the estimated maximum waiting time includes: If the confirmation status information indicates that it is not necessary to wait for the status confirmation of the peer RLC entity, then the RRC Release message is processed based on the first estimated maximum waiting time; If the confirmation status information indicates that it is necessary to wait for the status confirmation of the peer RLC entity, then the RRC Release message is processed based on the second estimated maximum waiting time. The second estimated maximum waiting time is the maximum waiting time specified by the communication protocol for the terminal to wait for the underlying confirmation feedback after receiving the RRC Release message. The second estimated maximum waiting time is longer than the first estimated maximum waiting time.

7. The method according to claim 4, characterized in that, The acquisition of status information related to the processing of the RRC Release message includes: Obtain the HARQ feedback status information of the physical layer. The HARQ feedback status information is used to indicate the HARQ acknowledgment status of the PDSCH carrying the RRRCRelease message. The status information includes the HARQ feedback status information.

8. The method according to claim 7, characterized in that, The process of processing the RRCRelease message based on the estimated maximum waiting time includes: If the HARQ feedback status information indicates a HARQ confirmation indication, then the RRC Release message is processed based on a third estimated maximum waiting time, which is less than the maximum waiting time specified in the communication protocol for the terminal to wait for underlying confirmation feedback after receiving the RRC Release message.

9. The method according to claim 6 or 8, characterized in that, The first estimated maximum waiting time is equal to the third estimated maximum waiting time, which is determined based on the processing time and slot length of the PDSCH.

10. A method for handling connection release messages, characterized in that, Applied to a terminal, the method includes: Receive RRC Release messages from network devices; Based on the triggering scenario associated with the RRC Release message, determine whether it is necessary to wait for confirmation feedback from the underlying layer before processing the RRC Release message; If not, then process the RRC Release message; If so, obtain the status information related to the processing of the RRC Release message; If the status information indicates that it is not necessary to wait for the status confirmation of the peer RLC entity, then the RRC Release message is processed based on the first estimated maximum waiting time, which is determined based on the HARQ feedback timing parameters and the slot length. If the status information indicates that it is necessary to wait for status confirmation from the peer RLC entity, the RRC Release message is processed based on the second estimated maximum waiting time. The second estimated maximum waiting time corresponds to the maximum waiting time specified by the communication protocol for the terminal to wait for underlying confirmation feedback after receiving the RRC Release message; and the second estimated maximum waiting time is longer than the first estimated maximum waiting time. The processing of the RRC Release message includes executing immediately upon receiving the corresponding confirmation feedback before the estimated maximum waiting time times out, or executing when the estimated maximum waiting time times out.

11. An electronic device, characterized in that, It includes a processor and a memory, the memory storing computer-readable instructions that, when executed by the processor, perform the method as described in any one of claims 1-10.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it performs the method as described in any one of claims 1-10.

13. A computer program product, characterized in that, It includes computer program instructions, which, when read and executed by a processor, perform the method as described in any one of claims 1-10.

Images