Link maintenance method, device, system, terminal, and readable storage medium
Patent Information
- Application Number
- JP2023574496
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2021-08-03
- Filing Date
- 2022-06-20
- Publication Date
- 2025-02-19
- Estimated Expiration
- 2042-06-20
Smart Images

Figure 0007633432000001 
Figure 0007633432000002 
Figure 0007633432000003
Abstract
Description
[Technical field]
[0001] This application is filed based on a Chinese patent application bearing application number 202110886833.2 and filing date on August 3, 2021, and claims priority to the Chinese patent application, the entire contents of which are hereby incorporated by reference into this application.
[0002] TECHNICAL FIELD The present disclosure relates to the technical field of communications, and in particular to a link maintenance method, an apparatus, a system, a terminal, and a readable storage medium. [Background technology]
[0003] Currently, when a terminal does not have a service, it releases the Radio Resource Control (RRC) connection, and the network uses an inactivity timer to control the time from when the network has no service until the RRC connection is released, and the time is generally set to 10 seconds. However, for services with high latency requirements, such as industrial automation and Internet of Vehicles, it takes time to re-establish the RRC connection, which results in a large delay in starting the service, making it difficult to meet the needs of services with high latency requirements. Summary of the Invention [Problem to be solved by the invention]
[0004] The main objective of the embodiments of the present application is to propose a link maintenance method, a system, an electronic device, and a computer-readable storage medium. [Means for solving the problem]
[0005] In order to achieve at least the above object, an embodiment of the present application provides a link maintenance method applied to a terminal, the link maintenance method comprising: determining an end time of the first service after starting the first service on the network side; receiving a radio resource control release (RRC) message corresponding to the first service sent by the network side, determining a time when the RRC release message is received; estimating a timing period of an inactivity timer configured on the network side based on the end time and a time when the RRC release message is received; and after causing the network side to start a second service, starting timing from the end of the second service, and before the timing time reaches the timing time, transmitting a virtual data packet to the network side to maintain an RRC connection between the terminal and the network side.
[0006] To achieve at least the above object, an embodiment of the present application provides a link retention device, comprising: A first determination module configured to determine an end time of the first service after causing a network side to start the first service; A second determination module configured to, when receiving a radio resource control release (RRC) release message corresponding to the first service sent by the network side, determine a time point when the RRC release message is received; an estimation module configured to estimate a timing period of an inactivity timer set by the network side based on the end time and a time when the RRC release message is received; and a transmitting module configured to, after causing the network side to start a second service, start timing from an end of the second service, and transmit a virtual data packet to the network side before the timing time reaches the timing time, thereby maintaining an RRC connection between the terminal and the network side.
[0007] To achieve at least the above objective, an embodiment of the present application provides a link maintenance system, including a terminal and a network side. The terminal is configured to determine an end time of the first service after causing the network side to start the first service. The network side is configured to send an RRC release message corresponding to the first service to the terminal. The terminal is also configured to determine a time when the RRC release message is received, and estimate a timing period of an inactivity timer configured on the network side based on the end time and the time when the RRC release message is received. The terminal is also configured to, after causing the network side to start a second service, start timing from the end of the second service, and transmit a virtual data packet to the network side before the timing time exceeds the timing time, thereby maintaining an RRC connection between the terminal and the network side.
[0008] In order to achieve at least the above object, an embodiment of the present application provides a terminal, the terminal comprising: At least one processor; a memory communicatively connected to the at least one processor; The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the link maintenance method described above.
[0009] To achieve at least the above object, an embodiment of the present application also provides a computer-readable storage medium storing a computer program which, when executed by a processor, implements the above link maintenance method. [Brief description of the drawings]
[0010] [Figure 1]2 is a flowchart of a link maintenance method according to an embodiment of the present application; [Diagram 2] FIG. 2 is a schematic diagram illustrating estimation of timing times according to an embodiment of the present application; [Diagram 3] FIG. 2 is a schematic diagram of a unit of a terminal according to an embodiment of the present application; [Figure 4] 4 is a flowchart of another link maintenance method according to an embodiment of the present application; [Diagram 5] 1 is a schematic diagram of a link retaining device according to an embodiment of the present application. [Figure 6] FIG. 1 is a schematic diagram of a link retention system according to an embodiment of the present application. [Figure 7] FIG. 2 is a structural schematic diagram of a terminal according to an embodiment of the present application; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0011] In order to make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the embodiments of the present application will be described in detail below with reference to the drawings. However, in various embodiments of the present application, many technical details are presented to allow the reader to better understand the present application, but the technical solutions claimed for protection in the present application can be realized without these technical details and various changes and modifications based on the following embodiments. The division of the various embodiments below is made for the convenience of explanation and does not constitute any limitation on the specific embodiments of the present application. Various embodiments may be combined with each other and reference each other unless inconsistent.
[0012] In one embodiment of the present application, a link maintenance method is provided that is applied to a terminal. The terminal may be a terminal that has low latency and is not sensitive to power consumption, but has high latency requirements. For example, the terminal may be a Customer Premise Equipment (CPE), a vehicle Internet terminal, etc. Below, the implementation details of the link maintenance method of this embodiment are specifically described, but the following content is provided to facilitate understanding of the implementation details provided, and is not essential for implementing this embodiment.
[0013] The link maintaining method in this embodiment specifically includes steps 101 to 104, as shown in the schematic flow chart of FIG.
[0014] Step 101: After the network side starts a first service, the end time of the first service is determined.
[0015] Step 102: Upon receiving an RRC release message corresponding to the first service sent by the network side, determine the time when the RRC release message is received.
[0016] Step 103: Estimate the timing time of the inactivity timer set on the network side based on the end time and the time when the RRC release message is received.
[0017] Step 104: After causing the network side to start the second service, start timing from the end of the second service, and before the timing time reaches a timing time, send a virtual data packet to the network side to maintain an RRC connection between the terminal and the network side.
[0018] Here, when the network side receives the virtual data packet, it resets the current time count of the inactivity timer to zero and maintains the RRC connection between the terminal and the network side.
[0019] In this embodiment, a method is provided for the terminal to estimate the timing of the inactivity timer by itself, taking into consideration that the timing of the inactivity timer actually set on the network side is a network side parameter and is not transmitted to the terminal with signaling. That is, the method is a method for estimating the timing of the inactivity timer reasonably by taking the end point of the first service as the starting point and the time point of receiving the RRC release message as the end point. After the network side starts the second service, the timing starts from the end of the second service, and before the timing time reaches the timing time, a virtual data packet is sent to the network side to maintain the RRC connection between the terminal and the network side. In this embodiment, there is no need to modify the network side, and the terminal itself times the time, and before the timing time reaches the timing time, a virtual data packet is sent to the network side to maintain the RRC connection between the terminal and the network side, so that the terminal and the network side are always connected. This reduces the service delay and meets the needs of services with high requirements for delay, that is, mainly the demand for low-delay services.
[0020] In step 101, the terminal determines an end time of the first service after causing the network side to start the first service. Here, the network side may be a base station. The first service may be a service that the terminal starts when it normally powers on and registers with the network. For example, the first service may be a first service that the terminal starts when it normally powers on and registers with the network. The terminal may start preparing to maintain an RRC connection between the terminal and the network side from the first service after powering on and registering, so that the terminal and the network side can quickly enter an RRC connection maintenance state.
[0021] In one example, the step of the terminal determining the end time of the first service includes the steps of: the terminal determining a last acknowledgement (ACK) corresponding to the first service, the last ACK being the last ACK sent by the terminal to the network side, or the last ACK received by the terminal and sent by the network side; and then the terminal determining the time when the last ACK is sent or received as the end time of the first service. Whether the first service has ended can be easily and accurately determined by the last ACK received or sent.
[0022] In one example, the manner in which the terminal determines the last ACK corresponding to the first service may be as follows: When the terminal receives or transmits an ACK for the first service, it updates this ACK to a reference ACK; When the terminal continues to receive or transmit ACKs for the first service, it updates the ACKs it continues to receive or transmit to a reference ACK; When the terminal is no longer able to receive or does not transmit an ACK corresponding to the first service, it sets the reference ACK to the point of the last ACK corresponding to the first service.
[0023] In another example, the manner in which the terminal determines the last ACK corresponding to the first service may be as follows: The terminal records the time of each received and transmitted ACK, and when the terminal receives an RRC release message, the time of the ACK that is closest to the time when the terminal receives the RRC release message is determined as the time of the last ACK.
[0024] In step 102, when the terminal receives an RRC release message corresponding to the first service sent by the network side, the terminal determines the time when the RRC release message is received. Here, the RRC release message corresponding to the first service may be understood as an RRC release message that is sent by the network side after the first service is terminated and is timed to a timing time actually set by the network side. When the terminal receives the RRC release message corresponding to the first service sent by the network side, the time that the network side is timing from the time when the first service is theoretically terminated reaches the timing time of the inactivity timer actually set on the network side. That is, it indicates that a predetermined time has passed since the first service was terminated. When the terminal receives the RRC release message, it disconnects from the network side.
[0025] In step 103, the terminal takes the end point as the start point of the timing time to be estimated, takes the time when the RRC release message is received as the end point of the timing time to be estimated, and estimates the timing time of the inactivity timer set by the network side based on the start point and the end point. In a specific implementation, the terminal may take the last ACK sent or received by the terminal as the start point, and the reception of the RRC release message issued by the network side as the end point, and calculate the estimated timing time as a T value, i.e., the timing time of the inactivity timer set by the network side. For example, as shown in FIG. 2, it can be seen that the initial value T of the estimated inactivity timer, i.e., the estimated timing time, is the duration between the end point of the last ACK and the end point of the RRC release message.
[0026] In step 104, after the terminal starts the second service on the network side, the terminal starts timing from the end of the second service, and transmits a virtual data packet to the network side before the timing time reaches the timing time. Here, the second service may be a second service that the terminal restarts after starting the first service. The terminal may start timing from the end of the second service, that is, the terminal may start timing from the end point of the second service. Since the method of determining the end point of the second service is similar to the method of determining the end point of the first service described above, in order to avoid duplication, the present embodiment does not specifically limit it. The terminal transmits a virtual data packet to the network side before the timing time reaches the timing time, that is, before the timing time exceeds the estimated timing time. When the network side receives the virtual data packet, it resets the current timing time of the inactivity timer to zero, and maintains the RRC connection between the terminal and the network side until the terminal shuts down. The RRC connection between the terminal and the network side is maintained unless the terminal shuts down. Thereby, when the terminal restarts the service, there is no need to re-establish the RRC connection, which reduces the delay of the service and meets the needs of services with high requirements for delay.
[0027] In one embodiment, the implementation manner of step 104 may be to start a time measurement from the end of the second service after the network side starts the second service, and send a virtual data packet to the network side before the time measurement reaches an anti-collision time corresponding to the timing time, where the anti-collision time is shorter than the timing time.
[0028] In a specific implementation, the anti-collision time may be set according to actual needs. For example, the anti-collision time may be set as a difference (Tt) between a timing time (denoted as T) and a preset time advance (denoted as t). In this embodiment, the time advance may be set according to actual needs without being specifically limited. After the second service is terminated, the terminal transmits a virtual data packet to the network side before Tt, which is advantageous to avoid the terminal colliding with the received RRC release message when data transmission is required.
[0029] In one example, the step of transmitting the virtual data packet to the network side before the time reaches the anti-collision time corresponding to the timing time includes the step of transmitting the virtual data packet to the network side when an RRC release message corresponding to the second service is not received before the time reaches the anti-collision time corresponding to the timing time. Here, the RRC release message corresponding to the second service may be an RRC release message transmitted after the second service is terminated and the network side has timed to a timing time actually set. For example, if the anti-collision time is Tt, the terminal determines whether or not it has received an RRC release message before Tt, and transmits the virtual data packet to the network side when it determines that it has not received an RRC release message before Tt. This is advantageous to ensure the transmission of the virtual data packet while avoiding collision with the RRC release message, and ensure that the virtual data packet is accurately transmitted to the network side.
[0030] In one embodiment, the step of transmitting a virtual data packet to the network side before the clocking time reaches an anti-collision time corresponding to the timing time includes the steps of: updating a timing time of the inactivity timer to obtain an updated timing time when an RRC release message corresponding to the second service is received before the clocking time reaches the anti-collision time corresponding to the timing time, the updated timing time being a duration between an end point of the second service and reception of an RRC release message corresponding to the second service; and starting a clock from the end of the third service after starting a third service on the network side, and transmitting a virtual data packet to the network side if an RRC release message corresponding to the third service is not received before the clocking time reaches an anti-collision time corresponding to the updated timing time. Here, the third service may be a service that the terminal starts after the end of the second service. That is, if the terminal receives an RRC release message corresponding to the second service before the clocking time reaches the anti-collision time corresponding to the timing time, it indicates that the timing time estimated by the terminal is not very accurate. In this case, the terminal updates the previously estimated timing time to a duration between an end point of the second service and reception of an RRC release message corresponding to the second service. It is advantageous for the terminal to update the timing time to obtain a more accurate timing time of the inactivity timer actually set on the network side.
[0031] In a specific implementation, after the network side starts the third service, if the terminal starts timing from the end of the third service and receives an RRC release message corresponding to the third service before the timing reaches the anti-collision time corresponding to the updated timing time, it indicates that the updated timing time is still inaccurate. In this case, the terminal may re-update the timing time to the duration between the time when the third service ends and the time when the terminal receives an RRC release message corresponding to the third service. Here, the RRC release message corresponding to the third service may be an RRC release message that the network side sends after timing up to the timing time actually set after the third service ends. By determining the accuracy of the estimated timing time, the terminal continues to update the estimated timing time, and starts timing from the end of a certain service. If the terminal does not receive an RRC release message corresponding to the service before the timing reaches the anti-collision time corresponding to the updated timing time, the terminal stops updating the estimated timing time.
[0032] In one embodiment, as shown in Fig. 3, the terminal includes a control unit 301 and a modem unit 302. The modem unit 302 is configured to report relevant information for estimating a timing time to the control unit 301. The relevant information includes the time of the last ACK received or transmitted and the time when the network side issues an RRC release message. The control unit 301 is configured to calculate and store the timing time T of the estimated inactivity timer from the relevant information notified by the modem unit 302, and is also configured to issue a virtual data packet to the modem unit 302. The modem unit 302 transmits the virtual data packet to the network side.
[0033] In one embodiment, a flow chart of the link maintenance method is shown in FIG. 4, which specifically includes steps 401-405.
[0034] Step 401: A terminal normally powers on, registers with a network, and starts service. Here, the service that is started when the terminal is normally powered on and registered with the network may be understood as the above-mentioned first service, or may be understood as the first service that is started after the terminal is normally powered on and registered with the network.
[0035] Step 402: The terminal calculates a T value starting from the last ACK sent or received and ending from the reception of an RRC release message issued by the network side. Here, the T value is the timing time of the inactivity timer set on the network side, estimated by the terminal.
[0036] Step 403: The terminal restarts the service. Here, the service that the terminal restarts may be the second service described above, that is, the service that is started after the first service is terminated.
[0037] Step 404: The terminal determines whether it receives an RRC release message before Tt.
[0038] Here, t is a time advance preset to avoid collision between the data to be transmitted by the terminal and the RRC release message. Tt is a collision prevention time corresponding to the above timing time. In this embodiment, the time advance is not specifically limited, but may be set according to actual needs. If the terminal determines in step 404 that it has received the RRC release message before Tt, it indicates that the previously estimated T value is inaccurate and needs to be re-evaluated. For example, it may return to step 402 and recalculate and update the T value. If the terminal determines that it has not received the RRC release message before Tt, it indicates that the previously estimated T value is accurate, and step 405 is executed.
[0039] Step 405: The terminal sends a virtual data packet to the network side so as not to release the RRC connection.
[0040] In a specific implementation, the RRC connection between the terminal and the network side remains connected until the terminal is shut down.
[0041] In this embodiment, there is no need to modify the network side, and the terminal itself estimates the timing time of the inactivity timer on the network side, and updates the timing time according to actual needs, so that the estimated timing time approaches and finally becomes equal to the actual timing time of the inactivity timer on the network side. This is advantageous for making the terminal always connected to reduce the service delay, and mainly meeting the requirement of low-delay service. In addition, considering that when the data to be transmitted by the terminal collides with the RRC release message received by the terminal, the terminal cannot determine whether it needs to transmit data at present or to disconnect the RRC connection, in this embodiment, the collision between the data to be transmitted by the terminal and the RRC release message received by the terminal can be avoided by setting an anti-collision time Tt corresponding to the estimated timing time T.
[0042] It should be noted that the above examples in the embodiments of the present application are merely illustrative examples for ease of understanding, and do not limit the technical solutions of the present application.
[0043] The division of steps in the above various methods is merely for clarity, and may be integrated into one step or some steps may be divided into multiple steps when implemented, as long as they contain the same logical relationship, all of them are within the scope of protection of this patent. Making insignificant modifications to the algorithm or flow, or introducing insignificant designs, but not changing the core design of the algorithm and flow, are all within the scope of protection of this patent.
[0044] The embodiment of the present application also provides a link maintenance device. As shown in FIG. 5, the link maintenance device includes a first determination module 501, a second determination module 502, an estimation module 503, and a sending module 504. The first determination module 501 is configured to determine an end time of the first service after causing a network side to start the first service. The second determination module 502 is configured to determine a time when the RRC release message corresponding to the first service is received when the RRC release message is received and sent by the network side. The estimation module 503 is configured to estimate a timing time of an inactivity timer set by the network side based on the end time and the time when the RRC release message is received. The sending module 504 is configured to start a time from the end of the second service after causing the network side to start a second service, and send a virtual data packet to the network side before the time reaches the timing time to maintain an RRC connection between the terminal and the network side.
[0045] It should be noted that this embodiment is an apparatus embodiment corresponding to the above method embodiment, and this embodiment may be implemented in cooperation with the above method embodiment. The relevant technical details and technical effects mentioned in the above method embodiment are still valid in this embodiment, and will not be described in detail here to reduce duplication. Therefore, the technical details described in this embodiment may be applied to the above method embodiment.
[0046] An embodiment of the present application also provides a link maintenance system. As shown in FIG. 6, the link maintenance system includes a terminal 601 and a network side 602. The terminal 601 is configured to determine an end time of the first service after causing the network side 602 to start the first service. The network side 602 is configured to transmit an RRC release message corresponding to the first service to the terminal 601. The terminal 601 is also configured to determine a time when the RRC release message is received, and estimate a timing time of an inactivity timer set by the network side based on the end time and the time when the RRC release message is received. The terminal 601 is also configured to start a time from the end of the second service after causing the network side 602 to start a second service, and transmit a virtual data packet to the network side 602 before the time exceeds the timing time. The network side 602 is also configured to set a current time of the inactivity timer to zero after receiving the virtual data packet, and maintain an RRC connection between the terminal 601 and the network side 602.
[0047] It should be noted that this embodiment is a system embodiment corresponding to the above method embodiment, and this embodiment may be implemented in cooperation with the above method embodiment. The relevant technical details and technical effects mentioned in the above method embodiment are still valid in this embodiment, and will not be described in detail here to reduce duplication. Therefore, the technical details described in this embodiment may be applied to the above method embodiment.
[0048] The embodiment of the present application also provides a terminal. As shown in Fig. 7, the terminal includes at least one processor 701 and a memory 702 connected in communication with the at least one processor 701. The memory 702 stores instructions executable by the at least one processor 701, and the instructions are executed by the at least one processor 701 to enable the at least one processor 701 to perform the link maintenance method in the above embodiment.
[0049] Here, the memory 702 and the processor 701 are connected in a bus manner, which may include any number of interconnected buses and bridges connecting together various circuits of one or more processors 701 and memories 702. The bus may also connect together various other circuits such as peripherals, voltage regulators and power management circuits. These are all well known in the art and will not be described further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver may be one element or multiple elements such as multiple receivers and transmitters, providing a unit configured to communicate with various other devices over a transmission medium. The data processed by the processor 701 is transmitted over a wireless medium via an antenna. Furthermore, the antenna receives data and transmits data to the processor 701.
[0050] The processor 701 is responsible for bus management and general processing and may provide a variety of functions including timing, peripheral interfacing, voltage regulation, power management and other control functions, while the memory 702 may be configured to store data used by the processor 701 in performing its operations.
[0051] An embodiment of the present application also provides a computer readable storage medium storing a computer program, which, when executed by a processor, implements the above method embodiment.
[0052] That is, the implementation of all or part of the steps in the method of the above embodiment can be achieved by the program instructing the associated hardware. The program is stored in one storage medium and includes several instructions for causing one device (which may be a single-chip computer, chip, etc.) or a processor to execute all or part of the steps of the method of the various embodiments of the present application. Meanwhile, the above storage medium includes various media capable of storing program code, such as a USB memory, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.
[0053] In the embodiment of the present application, after the network side starts the first service, the end time of the first service is determined, and when an RRC release message corresponding to the first service sent by the network side is received, the time when the RRC release message is received is determined, and the timing time of the inactivity timer set by the network side is estimated based on the end time and the time when the RRC release message is received. In the embodiment of the present application, a method is provided in which the terminal estimates the timing time of the inactivity timer by itself, taking into consideration that the timing time of the inactivity timer actually set by the network side is a network side parameter and is not transmitted to the terminal with signaling. That is, the method is a method of estimating the timing time of the inactivity timer rationally by taking the end time of the first service as the start point and the time when the RRC release message is received as the end point. After the network side starts the second service, the timing is started from the end of the second service, and before the timing time reaches the timing time, a virtual data packet is transmitted to the network side to maintain the RRC connection between the terminal and the network side. In the embodiment of the present application, there is no need to modify the network side, the terminal times itself, and before the timing time reaches the timing time, it sends a virtual data packet to the network side, so that the current timing time of the inactivity timer is set to zero after the network side receives the virtual data packet, so that the RRC connection between the terminal and the network side can be maintained, the terminal and the network side can be always connected, the service delay can be reduced, and the needs of services with high delay requirements can be met.
[0054] The above embodiments are merely examples of implementing the present application, and various changes in form and detail may be made in actual applications without departing from the spirit and scope of the present application.
Claims
1. A link maintenance method applied to a terminal, comprising: determining an end time of the first service after starting the first service on the network side; When receiving a radio resource control release (RRC) message corresponding to the first service transmitted by the network side, determining a time when the RRC release message is received; estimating a timing period of an inactivity timer configured on the network side based on the end time and a time when the RRC release message is received; after starting a second service on the network side, starting timing from the end of the second service, and transmitting a virtual data packet to the network side before the timing time reaches the timing time, thereby maintaining an RRC connection between the terminal and the network side.
2. The step of starting a time count from the end of the second service and transmitting a virtual data packet to the network side before the time count reaches the timing time, 2. The link maintenance method according to claim 1, further comprising a step of starting a time measurement from the end of the second service, and transmitting a virtual data packet to the network side before the time measurement reaches a collision prevention time corresponding to the timing time, the collision prevention time being shorter than the timing time.
3. The step of transmitting a virtual data packet to the network side before the clocking time reaches a collision prevention time corresponding to the timing time includes:
3. The link maintenance method according to claim 2, further comprising: if an RRC release message corresponding to the second service is not received before a time counting time reaches an anti-collision time corresponding to the timing time, sending a virtual data packet to the network side.
4. The step of transmitting a virtual data packet to the network side before the clocking time reaches an anti-collision time corresponding to the timing time includes: updating a timing time of the inactivity timer to obtain an updated timing time when an RRC release message corresponding to the second service is received before the measured time reaches an anti-collision time corresponding to the timing time, the updated timing time being a time difference between an end point of the second service and receiving an RRC release message corresponding to the second service; and after starting a third service on the network side, starting time measurement from an end of the third service, and transmitting a virtual data packet to the network side if an RRC release message corresponding to the third service is not received before the time measurement reaches a collision prevention time corresponding to the updated timing time.
5. The step of determining an end time of the first service comprises: determining a last acknowledgement signal (ACK) corresponding to the first service, the last ACK being the last ACK sent by the terminal to the network side or the last ACK received by the terminal and sent by the network side; 2. The link maintenance method according to claim 1, further comprising the step of: determining a time point at which the final ACK is transmitted or received as an end time point of the first service.
6. 2. The method of claim 1, wherein the first service is a first service that the terminal starts after powering on and successfully registering with a network.
7. A link holding device, A first determination module configured to determine an end time of the first service after causing a network side to start the first service; a second determination module configured to, when receiving a radio resource control release (RRC) message corresponding to the first service sent by the network side, determine a time when the RRC release message is received; an estimation module configured to estimate a timing period of an inactivity timer set on the network side based on the end time and a time when the RRC release message is received; a transmission module configured to, after starting a second service on the network side, start timing from the end of the second service, and transmit a virtual data packet to the network side before the timing time reaches the timing time, thereby maintaining an RRC connection between the link maintenance device and the network side.
8. A link maintenance system including a terminal and a network side, The terminal is configured to determine an end time of the first service after causing the network side to start the first service; The network side is configured to send an RRC release message corresponding to the first service to the terminal; The terminal is also configured to determine a time when the RRC release message is received, and estimate a timing period of an inactivity timer configured by the network side based on the end time and the time when the RRC release message is received; The terminal is also configured to, after causing the network side to start a second service, start timing from the end of the second service, and transmit a virtual data packet to the network side before the timing time exceeds the timing time, thereby maintaining an RRC connection between the terminal and the network side.
9. At least one processor; a memory communicatively connected to the at least one processor; A terminal, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a link maintenance method according to any one of claims 1 to 6.
10. A computer-readable storage medium storing a computer program which, when executed by a processor, implements the link maintenance method according to any one of claims 1 to 6. 。
Citation Information
Patent Citations
Base station, intermittent reception control method, and timer control method
JP2016046599A
Apparatus, System and Method for Optimized Tune Away Procedures
US20160345351A1
Estimating intervals at which to transmit keep-alive messages from a wireless station to an access point
US20170332318A1
Techniques for maintaining connected state
US20200344838A1