Method for processing pdu session modification command, electronic device, storage medium and program product

Abstract

The application provides a processing method of a PDU session modification command, an electronic device, a storage medium and a program product, and relates to the technical field of communication. The method temporarily stores the second PDU session modification command without immediately processing it by adding a message queue and a waiting confirmation state on the terminal side, ensures that the subsequent command will not be processed in advance before the confirmation message of the first PDU session modification command is received, and avoids parameter mis-modification or legality detection failure caused by pseudo out-of-order. Meanwhile, the terminal performs corresponding operations according to the command to which the confirmation message belongs after the confirmation message is received, eliminates the ACK ambiguity problem, makes two PDU session modification commands with extremely short intervals take effect in the order intended by the network side, and thus effectively guarantees the success rate of the related service creation process and improves the service experience of users in a multimedia communication scenario.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a method for processing PDU session modification commands, an electronic device, a storage medium, and a program product. Background Technology

[0002] In 5G mobile communication systems, terminals and the network manage PDU (Protocol Data Unit) sessions via NAS (Non-Access Stratum) protocols. The communication standard protocol explicitly specifies a serial transmission mechanism for PDU session modification commands; that is, within the same PDU session, the network side must receive the terminal's response to the previous modification command before sending the next one. In the typical scenario of IMS (IP Multimedia Subsystem) video telephony creation, the mobile network needs to configure voice QoS (Quality of Service) stream parameters and video QoS stream parameters for the current session using consecutive PDU session modification commands. According to the protocol design, the network side sends two PDU session modification commands sequentially, and the second command is only sent after the complete transaction corresponding to the first command (including the terminal sending a response message and the network side returning an ACK) is completed. When sending PDU session modification commands, the network side sets the PTI (Procedure Transaction Identity) to 0, indicating that no independent transaction identity is allocated.

[0003] In existing technologies, mobile terminals typically employ a multi-core processor architecture, with their NAS layer protocol stack software running in a multi-threaded environment. Under this architecture, downlink messages from the network side, after arriving at the terminal hardware, must pass through multiple stages, including the underlying driver, operating system scheduling, and multi-threaded processing of the protocol stack, before being delivered to the NAS layer business logic. Due to the time uncertainty of thread scheduling on different cores, as well as the influence of interrupt handling and buffering delays, the order in which messages arrive at the NAS layer may differ from the actual sending order on the network side. Specifically, the network side interacts in the order of "send command 1, receive terminal response, send ACK, send command 2," but due to the aforementioned scheduling factors, the terminal NAS layer may arrive at the NAS layer processing module before receiving the ACK for the response to command 1. This phenomenon, not initiated by the network side but caused by a misalignment in the message processing order within the terminal, is called pseudo-out-of-order delivery.

[0004] In such pseudo-out-of-order scenarios, existing technologies have significant shortcomings, mainly as follows: First, if the terminal processes the second command before receiving the ACK for the first command, the parameters of the second command will be designed based on the state after the first command takes effect. Direct processing by the terminal may lead to incorrect modification of the parameters or failure to pass the validity check.

[0005] Secondly, when the terminal receives an ACK, it cannot distinguish whether it is a response to the first command or the second command, resulting in ambiguity between the ACK and the command. This leads to the inability to correctly trigger parameter activation or process transfer, ultimately affecting the user's business experience. Summary of the Invention

[0006] The purpose of this application is to provide a method for processing PDU session modification commands, an electronic device, a storage medium, and a program product to solve the problem that existing technical solutions lack an effective identification and processing mechanism for pseudo-out-of-order scenarios, and cannot guarantee that multiple consecutive PDU session modification commands can still take effect in the original order intended by the network side when the arrival order is abnormal.

[0007] In a first aspect, embodiments of this application provide a method for processing PDU session modification commands, applied to a terminal, the method comprising: Upon receiving the first PDU session modification command, a first response message for the first PDU session modification command is sent to the network side, and the system enters a waiting confirmation state. In the state of waiting for confirmation, if a second PDU session modification command is received before receiving a confirmation message for the first response message, the second PDU session modification command is temporarily stored in the message queue, and the state of waiting for confirmation is maintained. If the confirmation message is received while the confirmation is pending, the operation corresponding to the modification command for the first PDU session is executed, and the confirmation pending state is released.

[0008] In the above implementation process, by adding a message queue and a waiting confirmation state on the terminal side, the second PDU session modification command is temporarily stored and not processed immediately. This ensures that subsequent commands are not processed before the confirmation message of the first PDU session modification command is received, avoiding parameter mismodification or legality detection failure due to pseudo-out-of-order delivery. At the same time, after receiving the confirmation message, the terminal executes the corresponding operation according to the command it belongs to, eliminating the ACK ambiguity problem. This allows two PDU session modification commands with a very short interval to take effect in the order intended by the network side, thereby effectively ensuring the success rate of the relevant service creation process and improving the user's service experience in multimedia communication scenarios.

[0009] Secondly, embodiments of this application provide a processing apparatus for PDU session modification commands, applied to a terminal, the apparatus comprising: The message sending module is used to receive the first PDU session modification command, send a first response message to the network side in response to the first PDU session modification command, and enter a waiting confirmation state; The temporary storage module is used to temporarily store the second PDU session modification command in the message queue and maintain the waiting confirmation state if a second PDU session modification command is received before receiving a confirmation message for the first response message in the waiting confirmation state. The execution module is configured to, if the confirmation message is received in the waiting confirmation state, perform the operation corresponding to the modification command for the first PDU session and release the waiting confirmation state.

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

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

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

[0013] 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

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

[0015] Figure 1 A flowchart illustrating a method for processing PDU session modification commands provided in this application embodiment; Figure 2 A structural block diagram of a PDU session modification command processing device provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of an electronic device for executing a PDU session modification command, as provided in an embodiment of this application. Detailed Implementation

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

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

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

[0019] This application provides a method for processing PDU session modification commands. This method adds a message queue and a waiting-for-acknowledgment state on the terminal side, temporarily storing the second PDU session modification command without immediate processing. This ensures that subsequent commands are not processed prematurely before receiving the acknowledgment message for the first PDU session modification command, avoiding parameter mismodification or legality detection failure due to pseudo-out-of-order delivery. Simultaneously, after receiving the acknowledgment message, the terminal executes the corresponding operation according to its associated command, eliminating ACK ambiguity. This allows two PDU session modification commands with a very short interval to take effect in the order intended by the network side, effectively ensuring the success rate of related service creation processes and improving the user's service experience in multimedia communication scenarios.

[0020] Please refer to Figure 1 , Figure 1 A flowchart illustrating a method for processing a PDU session modification command, provided in an embodiment of this application, is shown. This method, applied to a terminal, includes the following steps: Step S110: Receive the first PDU session modification command, send a first response message to the network side for the first PDU session modification command, and enter the waiting confirmation state.

[0021] The "waiting for confirmation" state refers to the protocol state in which the terminal has completed sending a response to a PDU session modification command but has not yet received the corresponding confirmation message from the network side. In this state, the terminal does not process new commands that arrive later immediately, but performs a temporary storage operation.

[0022] In this scheme, a state machine can be used to manage the received commands. The state machine can include at least an idle state and a waiting-for-acknowledgment state to drive the entire processing flow.

[0023] Initially, the terminal is in an idle state, listening for PDU session modification commands sent by the network side. In specific implementation, the terminal can receive the first PDU session modification command sent by the network side through the NAS layer. This command carries the PDU session parameters to be modified, such as QoS flow parameters and maximum session aggregation bit rate.

[0024] In some implementations, to ensure the accuracy of parameter modification, the terminal performs a compliance check on the parameters in the command and constructs a corresponding first response message based on the check result. If the parameters conform to the rules, an acceptance message is constructed, i.e., the PDU session modification is accepted. If the parameters do not conform to the rules, a rejection message is constructed, i.e., the PDU session modification command is rejected. Then, the response message is sent to the network side, and the current state is transferred to the waiting confirmation state to listen for the confirmation message (ACK) returned by the network side for the response.

[0025] Upon receiving the first PDU session modification command from the network side, the terminal does not directly respond with an accept or reject statement. Instead, it first performs a validity verification process. Specifically, the terminal verifies the validity of the first PDU session modification command, obtains the verification result, determines the target response type of the response message based on the verification result (accept or reject), and then sends a first response message to the network side for the first PDU session modification command. The response type of this first response message is the target response type.

[0026] In some implementations, during the validity check, it may be checked whether the parameter format in the first PDU session modification command conforms to the protocol specification, and / or whether the parameter requested to be modified by the first PDU session modification command conflicts with the current PDU session context.

[0027] Among them, the format conformity check checks whether the data type, numerical range, encoding format, etc. of each parameter strictly conform to the communication standard protocol specifications. If the format of any parameter does not conform to the protocol, the check result is directly judged as failing.

[0028] Context compatibility verification checks whether the requested parameter modification conflicts with the PDU session context currently maintained by the terminal. The PDU session context is a data structure maintained in the terminal's memory that describes the complete configuration state of the current PDU session. Its contents include established QoS flow lists, currently used bandwidth parameters, session priority, and associated radio bearer mappings. When performing context compatibility verification, the terminal compares the requested parameters in the command with the current configuration recorded in this context to determine whether the modification request can be safely executed. For example, does the requested new QoS flow exceed the maximum flow limit of the current session? Does the requested bandwidth resource exceed the subscribed authorization range? Or does the modified parameter combination cause a semantic conflict in the session operation? For instance, if modifications are requested to interdependent flow parameters but the new values ​​contradict each other, and any conflict exists, the verification result is deemed unsuccessful.

[0029] It should be noted that the above two dimensions of verification can use an "AND" logical relationship, that is, the verification result is only determined to be passed if both the format verification and the context verification pass.

[0030] After obtaining the verification result, the terminal determines the target response type of the first response message based on the verification result. When the verification result is successful, the terminal determines the target response type as Accept and constructs a "PDU session modification command accepted" message accordingly. When the verification result is unsuccessful, the terminal determines the target response type as Reject and constructs a "PDU session modification command rejected" message accordingly. The rejected message may further include a rejection reason value to indicate the specific reason for the network side's rejection. After determining the target response type, the terminal generates the corresponding first response message according to that response type and sends it to the network side via the air interface. After transmission, the state machine enters a waiting-for-acknowledgment state from the idle state, listening for the acknowledgment message returned by the network side for the first response message.

[0031] Through the above verification and response determination process based on the verification results, the terminal ensures that it only accepts the modified parameters if they are legal and compatible with the current session state, thus avoiding subsequent processing failures due to parameter errors or conflicts from the source.

[0032] Step S120: In the waiting confirmation state, if a second PDU session modification command is received before the confirmation message for the first response message is received, the second PDU session modification command is temporarily stored in the message queue and the waiting confirmation state is maintained.

[0033] The message queue refers to a buffer area in the terminal memory used to sequentially store the message bodies of PDU session modification commands that have not yet been processed, and its organization is first-in, first-out.

[0034] If, while the terminal is in a waiting-for-acknowledgment state, it receives a second PDU session modification command from the network side before receiving an acknowledgment message for the first response message, the terminal will not immediately process the second PDU session modification command. Instead, it will save the command completely to a preset message queue and continue to maintain the current waiting-for-acknowledgment state of the state machine, waiting for an acknowledgment message for the first response message. At this time, the second PDU session modification command is in a pending state, its parameters have not yet taken effect, and the terminal will not send any response message regarding the second PDU session modification command to the network side.

[0035] Step S130: In the waiting confirmation state, if a confirmation message is received, the operation corresponding to the modification command for the first PDU session is executed, and the waiting confirmation state is released.

[0036] After receiving a confirmation message for the first response message while in the pending confirmation state, the terminal first determines the type of the confirmation message, distinguishing between acceptance and rejection. If it is an acceptance confirmation, the terminal executes the activation operation for the first PDU session modification command, that is, it formally applies the parameters carried by the command to the current PDU session context; if it is a rejection confirmation, the terminal abandons the activation operation and does not modify the current PDU session parameters.

[0037] After completing the corresponding operations for the first command, the terminal releases the waiting confirmation state of the state machine, that is, enters the idle state, and can further check whether there is a temporarily stored second PDU session modification command in the message queue. If it exists, it is retrieved and processed in sequence.

[0038] In the above implementation process, by adding a message queue and a waiting confirmation state on the terminal side, the second PDU session modification command is temporarily stored and not processed immediately. This ensures that subsequent commands are not processed before the confirmation message of the first PDU session modification command is received, avoiding parameter mismodification or legality detection failure due to pseudo-out-of-order delivery. At the same time, after receiving the confirmation message, the terminal executes the corresponding operation according to the command it belongs to, eliminating the ACK ambiguity problem. This allows two PDU session modification commands with a very short interval to take effect in the order intended by the network side, thereby effectively ensuring the success rate of the relevant service creation process and improving the user's service experience in multimedia communication scenarios.

[0039] In the above implementation of the operation corresponding to the first PDU session modification command, if the first response message is an accept message, then the acknowledgment message is an acknowledgment of the accept message, and the parameters corresponding to the first PDU session modification command can be applied. If the first response message is a reject message, then the acknowledgment message is an acknowledgment of the reject message, and the application of the parameters corresponding to the first PDU session modification command can be abandoned, and the PDU session modification commands stored in the message queue can be processed sequentially.

[0040] The activation operation refers to the process by which the terminal changes the modified parameters carried in the PDU session modification command from the "pending execution" state in the protocol control block to the "formal application" state. This process involves updating the PDU session context data structure in memory, notifying the RRC (Radio Resource Control) layer to adjust the corresponding radio bearer configuration, and synchronizing session change information with the upper-layer application module so that the modified parameters actually take effect in the data transmission between the terminal and the network.

[0041] The idle state refers to the protocol state in which the terminal has completed the complete transaction of the current PDU session modification command, that is, sent a response and received the corresponding confirmation message, and has executed or abandoned the corresponding effective operation. There are no ongoing modification transactions waiting to be processed, and the terminal can receive and process the next PDU session modification command issued by the network side at any time.

[0042] In practice, after receiving an acknowledgment message for the first response message while in a waiting-for-acknowledgment state, the terminal first determines the type of the acknowledgment message to identify whether it is an acknowledgment for an accepted message or a acknowledgment for a rejected message. If the determination result indicates that the acknowledgment message is an acknowledgment for an accepted message, it means that the network side has successfully received and acknowledged the terminal's acceptance response to the first PDU session modification command. At this point, the terminal executes the activation operation for the first PDU session modification command, that is, formally applying the various modification parameters carried in the command to the current PDU session context, so that the new QoS flow configuration, bandwidth parameters, or session policies actually take effect in the protocol stack and the underlying air interface bearer. After completing the activation operation, the terminal releases its current waiting-for-acknowledgment state and transitions its state machine to an idle state to prepare to receive the next PDU session modification command from the network side or execute other normal processes.

[0043] When the determination result indicates that the confirmation message is an acknowledgment of a rejection message, it means that the network side has successfully received the terminal's rejection response to the first PDU session modification command and will not require the terminal to execute the modification content of the command. At this time, the terminal abandons the operation of applying the parameters in the first PDU session modification command, and the current PDU session context remains unchanged. Subsequently, the terminal checks whether there are any temporarily stored PDU session modification commands in the message queue, such as the aforementioned second PDU session modification command. If so, it retrieves the stored PDU session modification commands from the queue in sequence, temporarily releases the waiting confirmation state and enters the idle state, and then processes the retrieved PDU session modification commands. If the queue is empty, the terminal directly releases the waiting confirmation state and enters the idle state.

[0044] It should be noted that in the case of rejection of confirmation, since the first PDU session modification command has not taken effect, the commands temporarily stored in the queue (whose original design may be based on the state after the first command took effect) may no longer be applicable. When the terminal retrieves and processes the data, it can re-execute the verification according to the latest session context and decide whether to accept or reject based on the verification result.

[0045] Through the above implementation, after the terminal receives the confirmation message, it performs differentiated follow-up operations according to the different types (acceptance or rejection) of the first response message: if the first command has been accepted, its parameters are applied normally to ensure that the correct modification is implemented; if the first command has been rejected, the application operation is abandoned immediately to avoid invalid or incorrect parameter modification, and then the second PDU session modification commands temporarily stored in the message queue are processed in sequence so that the commands in the queue can get a timely processing opportunity.

[0046] In some implementations, when retrieving a PDU session modification command from the message queue for processing, the earliest stored PDU session modification command can be retrieved from the message queue, and then a second response message for the PDU session modification command can be sent to the network side, and then the process can enter a waiting confirmation state.

[0047] In other words, the terminal will also process the commands one by one according to the storage order in the message queue. That is, for each retrieved command, it will perform a validity check, construct a corresponding response message and send it to the network side, and then enter the waiting confirmation state again to complete the complete transaction process of the command.

[0048] After releasing the pending confirmation state, if the terminal determines that there is a temporarily stored PDU session modification command in the message queue, it retrieves the first stored PDU session modification command (e.g., the aforementioned second PDU session modification command) from the head of the queue according to the storage order of the message queue. After retrieving the command, the terminal does not directly perform an activation operation on its parameters, but treats it as a completely new command to be processed and executes a complete single-command processing flow. Specifically, the terminal performs a validity check on each parameter in the command, which is the same as the check performed on the first PDU session modification command, including but not limited to parameter format specification and context compatibility checks. Based on the check result, the terminal determines the target response type of the second response message for the command. If the check passes, it is determined to be accepted, and a "PDU session modification command accepted" message is constructed; if the check fails, it is determined to be rejected, and a "PDU session modification command rejected" message is constructed, which may carry the corresponding rejection reason value.

[0049] The terminal sends the second response message to the network side and enters a waiting-for-acknowledgment state after sending, listening for the acknowledgment message returned by the network side for the second response message. Subsequently, the terminal performs the same operations as it did for the first PDU session modification command in this waiting-for-acknowledgment state: if a new PDU session modification command is received before receiving the acknowledgment message, it is temporarily stored at the end of the message queue again; if an acknowledgment message is received, the terminal performs the corresponding activation or abort operation based on its type, and continues processing any subsequent commands that may exist in the queue until the message queue is completely cleared.

[0050] It's important to note that the message queue uses a first-in, first-out (FIFO) organization method, ensuring that commands arriving at the terminal first are retrieved and processed first, thus maintaining the original temporal order of commands. If multiple commands are stored in the message queue simultaneously, the terminal repeats the above process one by one. After processing each command (i.e., completing response sending, waiting for confirmation, and taking effect / abandoning the operation), the next command is retrieved from the head of the queue and processing continues until the queue is empty. During this process, the terminal independently executes a complete single-transaction flow for each command retrieved from the queue, including response sending, waiting for confirmation, and parameter taking effect. These transactions are executed serially and do not interleave. If the terminal receives a new command from the network while processing commands in the message queue, it adds that command to the message queue for processing.

[0051] In the above implementation process, by adopting a first-in-first-out sequential processing mechanism for PDU session modification commands in the message queue, and independently executing response sending and re-entering the waiting confirmation state when processing each command, it is ensured that each command temporarily stored in the queue can obtain the same complete single transaction processing flow as a normally received command.

[0052] Based on the above embodiments, if the terminal receives the second PDU session modification command before receiving the confirmation message for the first response message, the terminal may first send a temporary response message for the second PDU session modification command to the network side.

[0053] Specifically, after saving the second PDU session modification command to the message queue, the terminal does not perform legality verification or substantive acceptance / rejection determination. Instead, it immediately constructs a special temporary response message and sends it to the network side via the air interface. This temporary response message differs from normal acceptance messages (PDU session modification command acceptance) or rejection messages (PDU session modification command rejection). It carries specific indication information to inform the network side that the terminal has successfully received the second PDU session modification command. However, because it is currently processing the transaction of the previous PDU session modification command, i.e., waiting for the confirmation message for the first response message, it cannot temporarily perform a complete acceptance or rejection determination and parameter activation operation for the second command. The network side needs to maintain the current PDU session context state and wait for further responses from the terminal.

[0054] Upon receiving the temporary response message, the network side recognizes that the terminal has received the command and that a no-response timeout will not occur, thus maintaining the session connection. Simultaneously, it stops the response timeout timer for the second PDU session modification command, awaiting the terminal's subsequent sending of a formal accept or reject message. When the terminal subsequently completes processing the first PDU session modification command and retrieves the second PDU session modification command from the message queue, it can re-execute the complete verification process and send a separate formal accept or reject message to complete the transaction.

[0055] It should be noted that the temporary response message serves only as a temporary confirmation mechanism and does not represent the terminal's final decision on the second PDU session modification command. Whether to accept or reject the command ultimately depends on the validity check result performed by the terminal when retrieving the command later.

[0056] In the above implementation process, while temporarily storing the second PDU session modification command, a temporary response message is actively sent to the network side, so that the network side can know in a timely manner that the terminal has successfully received the command but cannot complete the full processing immediately.

[0057] Based on the above embodiments, a capacity limit can also be set for the message queue. If the message queue reaches the capacity limit, the newly received PDU session modification command is discarded, and a corresponding indication message is returned to the network side.

[0058] In practice, the terminal pre-configures a capacity limit for the message queue. This capacity limit restricts the maximum number of PDU session modification commands that can be stored in the message queue simultaneously. The specific value of the capacity limit can be set according to the terminal's hardware resource capabilities (such as available memory size) and business scenario requirements, for example, configured as 4 or 8 commands.

[0059] Before the terminal performs the operation of temporarily storing the second PDU session modification command in the message queue, it first checks whether the number of commands currently stored in the message queue has reached its capacity limit. If the number of currently stored commands is less than the capacity limit, the terminal normally stores the newly received PDU session modification command at the end of the message queue and continues to execute the corresponding process as described in the aforementioned embodiment. If the number of currently stored commands has reached the capacity limit, it indicates that the message queue has no remaining storage space, and the terminal cannot accommodate any more PDU session modification commands. In this case, the terminal discards the newly received PDU session modification command, that is, it does not store it in the message queue, nor does it perform any substantive processing or activation operation on the command.

[0060] While discarding the command, the terminal can also return a corresponding indication message to the network side. This indication message informs the network side that the terminal's message queue is full and cannot accept new PDU session modification commands. Upon receiving this indication message, the network side can decide on subsequent actions, such as delaying the resending of the command, negotiating session parameters with the terminal through other means, or triggering an upper-layer application to execute an alternative process. After sending the indication message, the terminal maintains its current state. That is, if the terminal is currently in a waiting-for-acknowledgment state, it continues to maintain this state to wait for the acknowledgment message for the first response message, without changing the original state transition logic due to the queue being full. If subsequent message queues become available because the terminal has processed stored commands, for example, if the terminal retrieves a command from the queue for processing and removes it from the queue, the message queue returns to a storable state, and newly received PDU session modification commands can be re-enqueued normally.

[0061] It should be noted that the indication message can use the reason value defined in the standard protocol, such as indicating insufficient resources or that the request has been temporarily rejected. It can also use extended reason values ​​to explicitly indicate the specific state of "the terminal's temporary queue is full", so that the network side can more accurately understand the terminal's processing capacity limitations.

[0062] In the above implementation process, by setting a capacity limit for the message queue, newly received PDU session modification commands are discarded when the queue is full, and a corresponding indication message is returned to the network side. This effectively prevents the terminal from exhausting memory resources or accumulating processing queues due to infinite caching in extreme abnormal scenarios, ensuring the operational stability of the terminal protocol stack. At the same time, the returned indication message enables the network side to perceive the current cache pressure status of the terminal in real time, avoiding the network from continuously sending invalid commands when the terminal cannot accept new commands. Based on this feedback, the network side can proactively adjust the subsequent command sending strategy, such as delaying retransmission or triggering upper-layer alternative processes. This establishes an effective flow control feedback mechanism between the limited terminal resources and the network's delivery requirements.

[0063] Based on the above embodiments, the terminal may simultaneously start a timed monitoring mechanism when or after sending the first response message. If no confirmation message is received before the timed monitoring mechanism expires, the first response message will be resent. If no confirmation message is received after the number of resentments reaches a preset threshold, the session abnormality recovery process will be executed.

[0064] The timed monitoring mechanism refers to a time monitoring method initiated by the terminal after sending a response message, used to constrain the maximum time for waiting for confirmation messages from the network side. Its specific implementation involves starting a hardware or software timer, setting a timeout threshold, and triggering the corresponding timeout handling callback function at the timeout point. This mechanism is a common method in communication protocols to ensure that transactions do not block indefinitely.

[0065] The preset threshold refers to the maximum number of times a terminal is allowed to resend the same response message; it is a pre-configured fixed integer value. When the number of resends reaches this value, it indicates that there has been no response from the network side for an extended period, and further resending is meaningless. The terminal should terminate the current transaction and enter the anomaly recovery process. This threshold can be set according to the recommended value in the protocol standard, or it can be adjusted according to the reliability requirements of different business scenarios.

[0066] The session failure recovery process refers to a series of fault-tolerant operations performed when the terminal determines that the current PDU session modification transaction cannot be completed normally. Its purpose is to recover the terminal from the abnormal suspension state and avoid session deadlock caused by prolonged resource occupation. Specific operations may include, but are not limited to: releasing all resources of the current PDU session to realign the terminal's state with the network side; returning a failure indication to the upper-layer application to trigger the application layer to take alternative measures; or reinitializing the relevant state machines of the protocol stack to clear all incomplete transaction records. The specific actions of this process can be flexibly configured according to the terminal product strategy.

[0067] When the terminal sends a first response message to the network side regarding the modification command for the first PDU session, or after the message is sent, it synchronously initiates a timed monitoring mechanism. This timed monitoring mechanism monitors the waiting time for the network side to return an acknowledgment message. When initiating this mechanism, the terminal sets a preset timeout threshold. This threshold can refer to the corresponding timer duration defined in the communication standard protocol standard, or a shorter timeout threshold can be configured for low-latency sensitive services such as IMS video telephony.

[0068] During the operation of the timed monitoring mechanism, the terminal continuously checks whether it has received an acknowledgment message from the network side regarding the first response message. If the terminal successfully receives the acknowledgment message before the preset timeout period expires, the timed monitoring mechanism automatically stops, and the terminal performs subsequent operations according to the normal procedure. If the timed monitoring mechanism times out, i.e., the preset timeout period has expired and the terminal has still not received the acknowledgment message, the terminal determines that the network side may have failed to receive the first response message due to reasons such as wireless link quality or network congestion, or that the acknowledgment message returned by the network side was lost during transmission.

[0069] At this point, the terminal triggers a retransmission process, resending the first response message to the network side. Simultaneously, the retransmission resets and restarts the timed monitoring mechanism, continuing to wait for confirmation from the network side. Each time a retransmission occurs, the terminal updates the retransmission counter. If the number of retransmissions reaches a preset threshold, such as the 2 or 3 retransmission limit typically defined in the protocol, but the terminal still hasn't received any confirmation message, the terminal determines that the modification transaction of the current PDU session cannot be completed through the normal response retransmission process. In this case, the terminal executes a session anomaly recovery process, including but not limited to: releasing the current PDU session, triggering local session reconstruction, reporting the session failure event to the upper-layer application (such as the IMS module) to trigger application-layer retry or call degradation, or clearing the PDU session modification commands already temporarily stored in the message queue and resetting the protocol stack state to ensure the terminal recovers from the abnormal state to a normal idle state, avoiding resource deadlock caused by infinite waiting.

[0070] In the above implementation process, a timed monitoring mechanism is introduced to set timeout protection for the response waiting process. When the acknowledgment message is lost due to network signal abnormalities or congestion, the terminal can actively resend the response after the timeout, avoiding permanent being stuck in the waiting state due to a single message loss, thus improving the reliability of transaction completion. When the number of resends reaches the threshold and no acknowledgment is received, the terminal executes the session abnormality recovery process, promptly releasing the occupied protocol resources and queue resources, preventing resource deadlock that could cause IMS video calls to be suspended for a long time or completely unable to be established.

[0071] Based on the above embodiments, before temporarily storing the second PDU session modification command in the message queue, the parameters of the first PDU session modification command can be simulated to take effect in the virtual context, and the parameters of the second PDU session modification command can be superimposed on the simulated effect. Resource conflict detection is then performed on the superimposed parameter combination. If the resource conflict detection passes, the second PDU session modification command can be temporarily stored in the message queue. If the resource conflict detection fails, the second PDU session modification command is refused to be temporarily stored in the message queue, and a rejection indication message is sent to the network side.

[0072] The virtual context refers to a temporary mirror area created by the terminal in memory, which has the same data structure and initial configuration as the current real PDU session context. All parameter modifications performed in the virtual context are simulated and do not affect the actual data transmission and session state between the terminal and the network. Its function is similar to a sandbox environment, used to pre-judge whether the modified resource configuration is reasonable before it officially takes effect.

[0073] Simulated activation refers to the terminal applying the modified parameters in the PDU session modification command to the virtual context, causing the configuration data in the virtual context to be updated accordingly. However, this update is limited to the virtual space and does not trigger any actual adjustment of the air interface bearer or the real allocation of hardware resources. It only serves as the data basis for subsequent resource conflict detection.

[0074] Resource conflict detection refers to a series of reasonableness checks performed by the terminal on the combined parameters in a virtual context. The detection is based on various constraints, including the terminal's hardware capabilities, network subscription authorization, and allowed value combinations according to protocol specifications. A successful detection is indicated by all combined parameters not exceeding any constraints; a failed detection is indicated by at least one constraint being breached, in which case the combined configuration is considered unexecutable.

[0075] A rejection indication message is a response message sent by a terminal to the network side when a resource conflict detection fails. It reports to the network side that the second PDU session modification command was rejected due to a resource conflict. This message can reuse the "PDU session modification command rejection" message format from the standard protocol, and carries a clear reason value to indicate the specific reason for the rejection, helping the network side understand the cause of the failure and determine subsequent session adjustment strategies.

[0076] In this implementation, before temporarily storing the second PDU session modification command in the message queue, the terminal adds a resource prediction process to ensure that the temporarily stored command will not conflict with the already accepted first command when it takes effect in the future. Specifically, after receiving the second PDU session modification command, the terminal does not directly store it in the message queue, but instead allocates an independent virtual context space in memory. This virtual context is a copy or shadow area of ​​the actual configuration of the current PDU session, and the session parameters maintained within it are completely consistent with the currently effective session context. However, all modification operations are performed within this virtual space, without affecting the actual session configuration and data transmission.

[0077] The terminal first simulates the activation of the modified parameters of the first PDU session modification command in the virtual context. This involves updating the QoS flow parameters, bandwidth parameters, 5QI, and other relevant configurations in the virtual context according to the requirements of the first PDU session modification command, ensuring the virtual context reflects the session state after the first PDU session modification command has fully taken effect. Based on this simulation, the terminal further overlays the modified parameters of the second PDU session modification command onto the virtual context. That is, on top of the virtual configuration simulating the activation state of the first PDU session modification command, a second simulation modification is performed according to the requirements of the second PDU session modification command to obtain the complete parameter combination after overlay.

[0078] Subsequently, the terminal performs resource conflict detection on the superimposed parameter combination. This detection is used to determine whether the terminal's overall resources are still within a supportable range after applying all modifications of the first PDU session modification command and the second PDU session modification command simultaneously. The content of resource conflict detection includes, but is not limited to: detecting whether the total number of superimposed QoS streams exceeds the maximum number of streams allowed by the current PDU session; detecting whether the total bandwidth required by the voice stream and video stream exceeds the maximum aggregate bit rate subscribed by the terminal and the network; detecting whether there is a priority conflict between different QoS streams, such as two streams being allocated the same guaranteed bit rate resources but the total resources are insufficient; and detecting whether the modified parameter combination causes a logical contradiction in the radio bearer configuration.

[0079] If the resource conflict detection passes, it indicates that the superimposed parameter combination can coexist completely and compatiblely in the virtual environment. The terminal allows the second PDU session modification command to be temporarily stored in the message queue and continues to execute the subsequent process as described in the aforementioned embodiment. If the resource conflict detection fails, it indicates that applying the modification of two commands simultaneously will lead to resource overruns or configuration conflicts. Based on this, the terminal determines that the second PDU session modification command is not executable in the current scenario. In this case, the terminal refuses to temporarily store the command in the message queue and does not store it in the queue. At the same time, it sends a rejection indication message to the network side. This rejection indication message informs the network side that the terminal cannot accept the second PDU session modification command due to resource conflicts and may carry a corresponding rejection reason value to indicate the specific conflict type (e.g., insufficient resources, priority conflict, etc.). After sending the rejection indication message, the terminal maintains its current state, that is, it continues to wait for the confirmation message for the first response message and does not affect the existing transaction process of the first PDU session modification command due to the rejection of the second PDU session modification command.

[0080] In the above implementation process, by introducing a virtual context simulation and resource conflict detection mechanism before temporarily storing the second PDU session modification command, the terminal can predict the resource compatibility after applying two commands at the same time in advance in the memory isolation environment. Only when the superimposed parameter combination completely passes the detection is it allowed to be enqueued; otherwise, it is rejected in advance and the network is notified in time. This allows the network to quickly know the cause of the conflict and adjust the subsequent session parameter configuration strategy accordingly, avoiding repeated rejections caused by the network continuously issuing incompatible commands.

[0081] Please refer to the above method embodiments. Figure 2 , Figure 2 This is a structural block diagram of a PDU session modification command processing apparatus 200 provided in an embodiment of this application. The apparatus 200 may be a module, program segment, or code on an electronic device (such as a terminal). It should be understood that the apparatus 200 corresponds to the method embodiment described above and is capable of executing the various steps involved in the method embodiment. The specific functions of the apparatus 200 can be found in the description above, and detailed descriptions are omitted here to avoid repetition.

[0082] Optionally, the device 200 includes: The message sending module 210 is used to receive the first PDU session modification command, send a first response message to the network side in response to the first PDU session modification command, and enter a waiting confirmation state. The temporary storage module 220 is configured to, in the waiting confirmation state, if a second PDU session modification command is received before receiving a confirmation message for the first response message, temporarily store the second PDU session modification command in a message queue and maintain the waiting confirmation state. The execution module 230 is configured to, if the confirmation message is received in the waiting confirmation state, perform the operation corresponding to the modification command for the first PDU session and release the waiting confirmation state.

[0083] Optionally, the execution module 230 is configured to, if the first response message is an accept message, perform an effective operation on the parameters corresponding to the first PDU session modification command; if the first response message is a reject message, abandon the effective operation on the parameters corresponding to the first PDU session modification command, and process the PDU session modification commands stored in the message queue in sequence.

[0084] Optionally, the execution module 230 is configured to retrieve the first stored PDU session modification command from the message queue; send a second response message for the PDU session modification command to the network side; and enter a waiting confirmation state.

[0085] Optionally, the message sending module 210 is further configured to send a temporary response message to the network side for the second PDU session modification command.

[0086] Optionally, the message sending module 210 is configured to perform a validity check on the first PDU session modification command and obtain a check result; determine the target response type of the response message based on the check result, wherein the target response type is accept or reject; and send a first response message to the network side in response to the first PDU session modification command, wherein the response type of the first response message is the target response type.

[0087] Optionally, the message sending module 210 is used to check whether the parameter format in the first PDU session modification command conforms to the protocol specification; and / or to check whether the parameter requested to be modified by the first PDU session modification command conflicts with the current PDU session context.

[0088] Optionally, the device 200 further includes: The monitoring module is used to start a timed monitoring mechanism when the first response message is sent; if the confirmation message is not received before the timed monitoring mechanism expires, the first response message is resent; if the confirmation message is still not received after the number of resentments reaches a preset threshold, the session abnormal recovery process is executed.

[0089] Optionally, the message sending module 210 is further configured to discard newly received PDU session modification commands and return a corresponding indication message to the network side if the message queue reaches its capacity limit.

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

[0091] Please refer to Figure 3 , Figure 3 This is a schematic diagram of an electronic device for executing a PDU session modification command processing method, provided in an embodiment of this application. The electronic device may include: at least one processor 310, such as a CPU; at least one communication interface 320; at least one memory 330; and at least one communication bus 340. The communication bus 340 is used to establish communication between these components. In this embodiment, the communication interface 320 is used for signaling or data communication with other node devices. The memory 330 may be a high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 330 may also be at least one storage device located remotely from the aforementioned processor. The memory 330 stores computer-readable instructions, which, when executed by the processor 310, cause the electronic device to perform the aforementioned method process.

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

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

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

[0095] In summary, the embodiments of this application provide a method for processing PDU session modification commands, an electronic device, a storage medium, and a program product. This method, by adding a message queue and a waiting-for-acknowledgment state on the terminal side, temporarily stores the second PDU session modification command without immediate processing, ensuring that subsequent commands are not processed prematurely before receiving the acknowledgment message for the first PDU session modification command. This avoids incorrect parameter modification or legality detection failure due to pseudo-out-of-order delivery. Simultaneously, after receiving the acknowledgment message, the terminal executes the corresponding operation according to its associated command, eliminating ACK ambiguity. This allows two PDU session modification commands with a very short interval to take effect in the order intended by the network side, effectively ensuring the success rate of related service creation processes and improving the user's service experience in multimedia communication scenarios.

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

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

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

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

[0100] 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 processing PDU session modification commands, characterized in that, Applied to a terminal, the method includes: Upon receiving the first PDU session modification command, a first response message for the first PDU session modification command is sent to the network side, and the system enters a waiting confirmation state. In the state of waiting for confirmation, if a second PDU session modification command is received before receiving a confirmation message for the first response message, the second PDU session modification command is temporarily stored in the message queue, and the state of waiting for confirmation is maintained. If the confirmation message is received while the confirmation is pending, the operation corresponding to the modification command for the first PDU session is executed, and the confirmation pending state is released.

2. The method according to claim 1, characterized in that, Perform the operation corresponding to the modification command for the first PDU session, including: If the first response message is an acceptance message, then the parameters corresponding to the first PDU session modification command are applied and the change is applied. If the first response message is a rejection message, then the operation to apply the parameter corresponding to the first PDU session modification command is abandoned, and the PDU session modification commands stored in the message queue are processed sequentially.

3. The method according to claim 2, characterized in that, The PDU session modification commands stored in the message queue are processed sequentially, including: Retrieve the earliest stored PDU session modification command from the message queue; Send a second response message to the network side regarding the PDU session modification command, and enter a waiting confirmation state.

4. The method according to claim 1, characterized in that, If the second PDU session modification command is received before the confirmation message for the first response message is received, the method further includes: Send a temporary response message to the network side for the modification command of the second PDU session.

5. The method according to claim 1, characterized in that, The step of sending a first response message to the network side regarding the modification command for the first PDU session includes: The first PDU session modification command is validated for legality, and the validation result is obtained; The target response type of the response message is determined based on the verification result, wherein the target response type is accept or reject. Send a first response message to the network side in response to the modification command for the first PDU session, wherein the response type of the first response message is the target response type.

6. The method according to claim 5, characterized in that, The validity verification of the first PDU session modification command includes: Check whether the parameter format in the first PDU session modification command conforms to the protocol specification; And / or, check whether the parameters requested to be modified by the first PDU session modification command conflict with the current PDU session context.

7. The method according to claim 1, characterized in that, The method further includes: A timed monitoring mechanism is initiated when the first response message is sent; If the confirmation message is not received before the timed monitoring mechanism expires, the first response message is resent. If the confirmation message is not received after the number of retransmissions reaches the preset threshold, the session abnormality recovery process will be executed.

8. The method according to claim 1, characterized in that, The method further includes: If the message queue reaches its capacity limit, newly received PDU session modification commands are discarded and a corresponding indication message is returned to the network side.

9. 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-8.

10. 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-8.

11. 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-8.

Images