Data transmission method, related device and communication system

Abstract

The invention provides a data transmission method, a related device and a communication system. The terminal can align the sending time of the non-delay-sensitive data packets and send the non-delay-sensitive data packets in the RRC connection state set. In this way, fragmentary time slices without data transmission can be integrated into continuous time slices without data transmission, and the situation that a terminal needs to carry out continuous data transmission with network equipment is reduced. Wherein the terminal can actively release the RRC connection and enter the RRC non-connection state from the RRC connection state under the condition that no data transmission exists in the preset duration. According to the method, the duration of the terminal in the RRC non-connection state can be effectively prolonged, and the power consumption of the terminal is reduced.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to data transmission methods, related devices and communication systems. Background Technology

[0002] Before accessing the internet, mobile phones, tablets, and other mobile devices need to establish a Radio Resource Control (RRC) connection with network equipment (such as base stations and core networks). The RRC connection can be in an RRC connected state or an RRC disconnected state. When there is no data transmission between the terminal and the network device, the terminal and the network device can release the RRC connection to reduce the terminal's power consumption. However, current applications on mobile devices often require continuous data packet transmission. This results in the terminal being unable to release the RRC connection for extended periods, increasing power consumption and reducing standby time. This negatively impacts the user experience. Summary of the Invention

[0003] This application provides a data transmission method, related apparatus, and communication system. A terminal can configure the time periods during which services running on the terminal can send non-low-latency data packets. During these time periods, the services running on the terminal can send non-low-latency data packets. During these time periods, the services running on the terminal can stop sending non-low-latency data packets. In this way, the terminal can align the transmission times of non-low-latency data packets, reducing the likelihood of RRC connections remaining unreleased for extended periods due to intermittent sending of non-low-latency data packets by services running on the terminal, thereby reducing the terminal's power consumption.

[0004] In one aspect, this application provides a data transmission method. The method involves a terminal starting a first timer; when the first timer expires, the terminal instructs a service running on the terminal to stop sending non-low-latency data packets; the terminal determines a first time period, which is the period after the first timer expires; and the terminal sends a first set of data packets to a network device within the first time period, the first set of data packets including one or more non-low-latency data packets.

[0005] Before the first timer expires, the terminal may also send one or more non-low-latency data packets to the network device. The non-low-latency data packets sent by the terminal to the network device during the time period corresponding to the first timer can be found in this application. Figure 5A Data packets 512, 513, 516, and 517 are shown.

[0006] The first timer can be referenced in this application. Figure 5A Timer 1 is shown. The first time period can be referenced in this application. Figure 5A The data transmission period T1 is shown. The first group of data packets may include... Figure 5A One or more of the data packets 518, 519, and 521 shown.

[0007] At the start of the first time period, the terminal can instruct the services running on the terminal to resume sending non-low-latency data packets.

[0008] As can be seen, the above method sets a time period for sending non-low latency data packets, which can delay the sending of non-low latency data packets without affecting the operation of non-low latency services, align the sending time of non-low latency data packets, reduce the situation where the RRC connection cannot be released for a long time due to the intermittent sending of non-low latency data packets by the services running in the terminal, and thus reduce the power consumption of the terminal.

[0009] In conjunction with the first aspect, in some embodiments, the terminal sends a first data packet to the network device, the first data packet being a low-latency data packet; based on the transmission of the first data packet, the terminal starts a first timer. The timing for the terminal to start the first timer can be referenced to the starting method described in this application. Figure 5A The following is an introduction to Timer 1.

[0010] As can be seen, when there are low-latency data packets to be sent, the terminal can send them to the network device immediately. This avoids delays in sending low-latency data packets, which could affect low-latency services. Furthermore, the terminal can set the time period during which it can send non-low-latency data packets based on the low-latency data packets to be sent. This allows the sending time of non-low-latency data packets to be aligned with the sending time of low-latency data packets, reducing the likelihood of the terminal being in RRC connection state simply because service requires sending non-low-latency data packets.

[0011] In conjunction with the first aspect, in some embodiments, if there is no data transmission between the terminal and the network device within a first time period, the terminal releases the Radio Resource Control (RRC) connection with the network device.

[0012] As can be seen, the terminal can proactively release the RRC connection within the first time period when there is no uplink or downlink data transmission, without waiting for the network device to send a command to release the RRC connection. This allows the terminal to release the RRC connection instantly when there is no uplink or downlink data transmission, reducing the terminal's power consumption.

[0013] In conjunction with the first aspect, in some embodiments, the terminal determines a first time period based on a first set of delay times, the first set of delay times including the time during which data packets of one or more services in the terminal can be delayed in transmission; or, the terminal determines the first time period based on the timeout time of a first timer, wherein the time difference between the start time of the first time period and the timeout time of the first timer is a second duration, and the duration of the first time period is a third duration; or, after the first timer expires, the terminal sends a second data packet to the network device, the second data packet being a low-latency data packet, and based on the transmission of the second data packet, the terminal starts a second timer, wherein the first time period is the time period corresponding to the second timer.

[0014] The first set of delay times can include the time during which non-low-latency data packets to be sent by one or more services in the terminal after the first timer expires can be delayed. The first time period can be earlier than the latest time during which one or more non-low-latency data packets in the first set of delay times can be delayed.

[0015] This application can be used as a reference for the first time period. Figure 8 The time period shown is T21, or T22, or the time period corresponding to timer 2.

[0016] As can be seen, the terminal can determine the time to resume sending data packets after the first timer expires based on the time during which non-low-latency data packets from one or more services can be delayed. This not only delays the sending of non-low-latency data packets, integrating fragmented time segments without data transmission into continuous time segments without data transmission, but also ensures that non-low-latency data packets are sent before the latest possible delay time, thus avoiding impacting the operation of background services. Furthermore, the aforementioned time for resuming the sending of low-latency data packets can be preset or determined based on the time of low-latency data transmission. By setting the time period during which non-low-latency data packets can be sent, the terminal can align the transmission times of non-low-latency data packets, reducing the likelihood of RRC connections remaining unreleased for extended periods due to intermittent transmission of non-low-latency data packets by services running on the terminal, thereby reducing the terminal's power consumption.

[0017] In conjunction with the first aspect, in some embodiments, when the first time period ends, the terminal instructs the service running in the terminal to stop sending non-low-latency data packets.

[0018] As can be seen, services running on the terminal can send non-low-latency data packets only during the time periods set by the terminal for sending such packets. This aligns the sending times of non-low-latency data packets, reducing the likelihood of RRC connections remaining unreleased for extended periods due to intermittent sending of non-low-latency data packets by services running on the terminal, thereby reducing the terminal's power consumption.

[0019] In conjunction with the first aspect, in some embodiments, the terminal starts a third timer; before the third timer expires, the terminal sends a third data packet to the network device, the third data packet being a low-latency data packet; based on the sending of the third data packet, the terminal starts a fourth timer; when the fourth timer expires, the terminal instructs the service running in the terminal to stop sending non-low-latency data packets; the terminal determines a second time period, the second time period being the time period after the fourth timer expires; the terminal sends a second set of data packets to the network device during the second time period, the second set of data packets including one or more non-low-latency data packets.

[0020] The third timer mentioned above can be started by the terminal based on the transmission of low-latency data. The duration of the fourth timer can be the same as or different from the duration of the third timer. The third data packet can be referenced in this application. Figure 5B The data packet shown is 531.

[0021] Before the fourth timer expires, the terminal may send one or more low-latency data packets to the network device.

[0022] At the start of the second time period, the terminal may instruct the services running on the terminal to resume sending non-low-latency data packets. The method for determining the second time period can refer to the method for determining the first time period described above.

[0023] As can be seen, if a low-latency data packet is sent again before the timer set for low-latency data packet transmission expires, the terminal can restart a timer to extend the data transmission duration. This reduces the situation where the terminal has a series of low-latency data packets to send, but the RRC connection is released prematurely, requiring the re-establishment of the RRC connection to transmit low-latency data packets. The above embodiment can reduce the frequency of RRC connection establishment by the terminal in a short period of time, thereby reducing the terminal's power consumption.

[0024] In conjunction with the first aspect, in some embodiments, the terminal sends a fourth data packet to the network device within a first time period. The fourth data packet is a low-latency data packet. Based on the sending of the fourth data packet, the terminal starts a fifth timer. If the timeout of the fifth timer is later than the end time of the first time period, the terminal sends a third set of data packets to the network device before the timeout of the fifth timer. The third set of data packets includes one or more non-low-latency data packets.

[0025] The aforementioned fourth data packet can be referenced in this application. Figure 5C The data packet shown is 541.

[0026] As can be seen, low-latency data packets are unaffected by the time period during which non-low-latency data packets can be sent as set by the terminal. When there are low-latency data packets that need to be sent, the terminal can send them immediately to avoid affecting the user experience. If the terminal sends a low-latency data packet within the time period during which non-low-latency data packets can be sent as determined by the terminal, the terminal can start a timer based on the sending of the low-latency data packet, such as a fifth timer. If the timeout of the fifth timer is late, the terminal can extend the data transmission duration based on the fifth timer. This can reduce the situation where the terminal has a series of low-latency data packets to send, but the RRC connection is released too early, requiring the re-establishment of the RRC connection to transmit low-latency data packets. This avoids the terminal frequently establishing RRC connections in a short period of time, reducing the terminal's power consumption.

[0027] In conjunction with the first aspect, in some embodiments, the terminal is in an RRC disconnected state before the first time period; before the terminal sends the first set of data packets to the network device within the first time period, the terminal establishes an RRC connection with the network device.

[0028] In conjunction with the first aspect, in some embodiments, non-low-latency data packets include one or more of the following: data packets generated by a background service, data packets generated by the service in the absence of user operation, data packets corresponding to services in a first service list, wherein the first service list includes one or more non-low-latency services.

[0029] In conjunction with the first aspect, in some embodiments, the terminal operates a first service and a data delayed transmission service. The first service is used to generate data packets to be transmitted to the network device. When a first timer expires, the data delayed transmission service notifies the first service to stop sending non-low-latency data packets. When a first time period begins, the data delayed transmission service notifies the first service to resume sending non-low-latency data packets. When the first time period ends, the data delayed transmission service notifies the first service to stop sending non-low-latency data packets.

[0030] When a notification to stop sending non-low-latency data packets is received, the first service can cache subsequently generated non-low-latency data packets to be sent, and wait for a notification to resume sending non-low-latency data packets before sending the cached non-low-latency data packets to the data delay sending service. Alternatively, when a notification to stop sending non-low-latency data packets is received, the first service can pause the generation of non-low-latency data packets. After receiving a notification to resume sending non-low-latency data packets, the first service can continue to generate non-low-latency data packets to be sent and send them to the data delay sending service.

[0031] As can be seen, the data delay transmission service can notify the first service to resume or stop sending non-low-latency data packets. The first service can send non-low-latency data packets upon receiving the notification to resume sending, and stop sending them upon receiving the notification to stop sending. This aligns the transmission time of non-low-latency data packets, reducing the likelihood of RRC connections remaining unreleased for extended periods due to intermittent sending of non-low-latency data packets by services running in the terminal, thereby reducing terminal power consumption.

[0032] In conjunction with the first aspect, in some embodiments, the first service can delay sending data packets from the fourth group of data packets to the data delay sending service for a certain period of time. The fourth group of data packets includes non-low-latency data packets that the first service is expected to send after the first timer expires. The aforementioned first group delay time can include the time during which the non-low-latency data packets to be sent after the first timer expires can be delayed.

[0033] The first service can know the data packets it needs to send within a future time period based on its business operations. The first service can send the time for which it can delay the sending of one or more data packets within the future time period to the data delay service. The fourth set of data packets can be the data packets that the first service needs to send within the future time period.

[0034] The first service is a back-end service.

[0035] As can be seen, the first service can provide feedback to the data delay transmission service regarding the time during which data packets in the first service can be delayed. The data delay transmission service can determine the time to resume sending data packets based on the time during which non-low-latency data packets to be sent by the first service after the first timer expires. This not only delays the transmission of non-low-latency data packets, thus integrating fragmented time segments without data transmission into continuous time segments without data transmission, but also ensures that non-low-latency data packets are sent before the latest possible delay time, preventing disruption to non-low-latency services.

[0036] In conjunction with the first aspect, in some embodiments, the terminal acquires the fifth data packet during the sleep period of the discontinuous reception CDRX cycle in the first connected state. The fifth data packet is a non-low latency data packet. When entering the active period of the second CDRX cycle, the terminal sends the fifth data packet to the network device. The second CDRX cycle is the next CDRX cycle after the first CDRX cycle, or there is an interval of one or more discontinuous reception DRX cycles between the second CDRX cycle and the first CDRX cycle.

[0037] The first CDRX cycle can be referenced in this application. Figure 10B The CDRX cycle shown is 1. The second CDRX cycle can be referenced in this application. Figure 10B The CDRX cycle shown is 2, or Figure 10C The CDRX period k is shown.

[0038] As can be seen, when a non-low-latency data packet is acquired at the application layer, the terminal can cache the non-low-latency data packet during the CDRX sleep period and send the cached low-latency data packet to the network device after the terminal enters the CDRX active period. This allows the non-low-latency data packets to be aggregated and sent during the CDRX active period, thereby increasing the duration of the CDRX sleep period and reducing the terminal's power consumption.

[0039] In conjunction with the first aspect, in some embodiments, the terminal acquires the sixth data packet during the sleep period of the third CDRX cycle, the sixth data packet being a low-latency data packet; the terminal enters the active period from the sleep period within the third CDRX cycle and sends the sixth data packet to the network device.

[0040] In conjunction with the first aspect, in some embodiments, the terminal includes a Packet Data Convergence Protocol (PDCP) layer. The terminal acquires the fifth data packet during a sleep period of the first connected state discontinuous reception CDRX cycle. The PDCP layer receives the fifth data packet during the sleep period of the first CDRX cycle. Before the terminal sends the fifth data packet to the network device, the PDCP layer buffers the fifth data packet in the first buffer space.

[0041] In conjunction with the first aspect, in some embodiments, after entering the activation period of the second CDRX cycle, the PDCP layer reads one or more data packets from the first cache space in order of cache time from early to late, and sends the read data packets to the network device; or, the PDCP layer reads one or more data packets from the first cache space in order of data packet delay time from short to long, and sends the read data packets to the network device.

[0042] It can be seen that after the terminal's PDCP layer buffers non-low-latency uplink data packets into the data packet buffer space, it does not need to immediately send the buffered data packets during the CDRX activation period of the next CDRX cycle. The terminal can reasonably arrange the timing of sending data packets in the data packet buffer space based on factors such as the duration that data packets can be delayed. This can better increase the duration of the CDRX sleep period and reduce the terminal's power consumption.

[0043] In conjunction with the first aspect, in some embodiments, the terminal acquires a seventh data packet during the sleep period of the fourth CDRX cycle. The seventh data packet is a non-low latency data packet. If the first buffer space is exhausted, the terminal enters the active period from the sleep period during the fourth CDRX cycle and sends the seventh data packet to the network device, and / or sends one or more data packets read from the first buffer space to the network device.

[0044] Secondly, this application provides a terminal. The terminal may include a communication device, a memory, and a processor. The communication device can be used to communicate with network devices. The memory can be used to store computer programs. The processor can be used to invoke the computer program to execute any of the possible implementation methods described in the first aspect.

[0045] Thirdly, this application provides a computer-readable storage medium storing instructions that, when executed by a processor, can implement any of the possible implementations described in the first aspect.

[0046] Fourthly, this application provides a computer program product that may contain computer instructions that, when executed on a processor, can implement any of the possible implementation methods described in the first aspect.

[0047] Fifthly, this application provides a chip applied to a terminal, the chip including one or more processors, the processors being used to invoke computer instructions to cause the terminal to execute any of the possible implementation methods in the first aspect.

[0048] It is understood that the terminal provided in the second aspect, the computer-readable storage medium provided in the third aspect, the computer program product provided in the fourth aspect, and the chip provided in the fifth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0049] Figure 1 This is a schematic diagram of the communication system 10 provided in an embodiment of this application;

[0050] Figure 2A This is a schematic diagram of the communication protocol architecture 20 provided in an embodiment of this application;

[0051] Figure 2B This is a schematic diagram of the RRC status provided in the embodiments of this application;

[0052] Figure 3 This is a schematic diagram of the structure of the terminal 100 provided in the embodiments of this application;

[0053] Figure 4 This is a schematic diagram of data transmission provided in an embodiment of this application;

[0054] Figures 5A-5C This is a schematic diagram illustrating some data transmissions provided in the embodiments of this application;

[0055] Figure 6 This is a flowchart illustrating a method for a terminal 100 to actively release an RRC connection, as provided in an embodiment of this application.

[0056] Figure 7 This is a flowchart of a data transmission method provided in an embodiment of this application;

[0057] Figure 8 This is a flowchart of a data transmission method provided in an embodiment of this application;

[0058] Figure 9 This is a flowchart of a data transmission method provided in an embodiment of this application;

[0059] Figures 10A to 10C This is a schematic diagram illustrating some data transmissions provided in the embodiments of this application;

[0060] Figure 11 This is a flowchart illustrating a method for data transmission during the CDRX activation period, as provided in an embodiment of this application.

[0061] Figure 12 This is a schematic diagram of the structure of a terminal 100 provided in an embodiment of this application;

[0062] Figure 13 This is a schematic diagram of a communication system 1300 provided in an embodiment of this application;

[0063] Figure 14 This is a schematic diagram of another terminal 100 provided in the embodiments of this application. Detailed Implementation

[0064] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to limit the application. As used in the specification and appended claims of this application, the singular expressions "a," "the," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, "at least one" and "one or more" refer to one or more (including two). The term "and / or" is used to describe the relationship between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0065] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. The term "connection" includes direct connections and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0066] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0067] This application provides a data transmission method. The terminal can align the transmission times of non-latency-sensitive data packets and send them in a concentrated manner during the RRC connected state. That is, the terminal can delay the transmission of non-latency-sensitive data packets. This integrates fragmented time segments without data transmission into continuous time segments without data transmission, reducing the need for the terminal to continuously transmit data with network devices. Specifically, if there is no data transmission within a preset duration, the terminal can actively release the RRC connection and enter the RRC disconnected state. This method can effectively increase the duration the terminal is in the RRC disconnected state, reducing the terminal's power consumption.

[0068] The uplink data packets that a terminal needs to send to network devices can include latency-sensitive and non-latency-sensitive data packets. Latency-sensitive data packets need to be sent immediately to avoid affecting the user experience. For example, latency-sensitive data packets can include voice call data packets, game data packets, etc. Non-latency-sensitive data packets are not sensitive to latency and do not need to be sent immediately. Even if the terminal delays sending non-latency-sensitive data packets, the user will not perceive the delay. These non-latency-sensitive data packets can also be called non-low-latency data packets. The services corresponding to non-low-latency data packets can be called non-low-latency services. The latency-sensitive data packets can also be called low-latency data packets. The services corresponding to low-latency data packets can be called low-latency services.

[0069] A terminal may run one or more services, including foreground services and background services. Foreground services are those visible to the user. When a foreground service is running, the terminal can display the corresponding user interface on the screen. The user interface for a foreground service may include one or more human-machine interfaces (MMIs), such as controls that the user can click, swipe, or long-press. The user can interact with the foreground service through the MMI. Background services run in the background and are not visible to the user. Background services do not interact with the user.

[0070] In some embodiments, the terminal can switch a foreground service to a background service, or vice versa. For example, services running on the terminal include webpage display services for browser applications and product browsing services for shopping applications. If the terminal displays a user interface corresponding to the webpage display service but not the user interface corresponding to the product browsing service, then the webpage display service is a foreground service, and the product browsing service is a background service. When the terminal switches the content on the display screen from the user interface corresponding to the webpage display service to the user interface corresponding to the product browsing service, then the webpage display service switches from a foreground service to a background service, and the product browsing service switches from a background service to a foreground service. This application does not limit the method for switching between the foreground and background services described above.

[0071] An application may contain one or more services. An application that contains foreground services can be called a foreground application. An application that contains only background services can be called a background application. In some embodiments, a foreground application may contain both foreground and background services.

[0072] Since foreground services are visible to the user, the data they need to send is typically perceptible to the user. If the terminal processes the data sent by the foreground service slowly, it will negatively impact the user experience. For example, in the case of a video playback service, in response to the operation of playing video 1 online, the foreground service can generate a request to obtain playback data for video 1. The terminal can send this request to the corresponding video server via network devices. However, if the terminal delays sending this request, it will be unable to obtain the playback data for video 1 in a timely manner, resulting in a delayed playback of video 1. The user will clearly perceive this delayed playback of video 1.

[0073] Therefore, the data that the foreground service needs to send can be low-latency data. Low-latency data can be sent in the form of data packets. Sending low-latency data is also known as sending low-latency data packets.

[0074] Since background services are invisible to the user, the process of sending data is usually imperceptible to the user. That is, a delay in sending data to the network device will not affect the user experience. For example, in the case of a cloud photo album synchronization service, a terminal can send one or more images stored on its device to the cloud photo album synchronization server via the network device. Whether the terminal sends these images sooner or later does not affect the user's use of one or more services on the terminal. The user will not notice the delay in synchronizing the images to the cloud.

[0075] Therefore, the data that the backend service needs to send can be non-low-latency data. Non-low-latency data can be sent in the form of data packets. Sending non-low-latency data is equivalent to sending non-low-latency data packets.

[0076] In some embodiments, when a foreground service has data to send, the terminal can immediately send the foreground service's data. When a background service has data to send, the terminal can determine whether to send the background service's data immediately or delay sending it based on the RRC connection status. Specifically, if in an RRC disconnected state, the terminal can wait until it enters the RRC connected state before sending the background service's data, without immediately entering the RRC connected state when there is background service data to send.

[0077] The following section introduces the communication system and communication protocol architecture involved in this application.

[0078] Figure 1 A schematic diagram of the communication system 10 provided in this application is shown as an example.

[0079] like Figure 1 As shown, the communication system 10 can be a long term evolution (LTE) system, a 5G new radio (NR) system, a machine-to-machine (M2M) system, or a future evolution of the sixth generation communication system, etc. This application embodiment does not limit the type of the communication system 10.

[0080] The communication system 10 may include a terminal 100 and a network device 200. The network device 200 may include a base station 201, a core network device 202, etc.

[0081] Base station 201 can be used to convert received radio frames to and from Internet Protocol (IP) packets, and can also coordinate the attribute management of the air interface. For example, base station 201 can be an evolved Node B (eNB) in LTE, or a base station with a centralized-distributed architecture used in a 5G system. Base station 201 can also be an access point, a trans point (TRP), a central unit (CU), or other network entity, and can include some or all of the functions of the above network entities. In addition, base station 201 also includes a relay station, which is a station that receives data and / or other information from upstream stations and transmits data and / or other information to downstream stations. A relay station can also be a terminal that provides relay transmission for other terminals. A relay station can also be referred to as a repeater. The embodiments of this application do not limit the type of base station 201.

[0082] Base station 201 and terminal 100 can establish a wireless connection through a wireless air interface. This wireless air interface can be based on the LTE standard, or it can be based on the 5G standard, such as NR, or it can be a wireless air interface based on the next-generation mobile communication network technology standard of 5G.

[0083] Terminal 100 may be a device that provides data communication to users. Terminal 100 may be equipped with... Or devices with other operating systems, such as mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in autonomous driving, cellular phones, cordless phones, session initiation protocol (SIP) phones, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices, in-vehicle devices, smart home devices, wearable devices, etc. Terminal 100 can also be referred to as user equipment (UE). This application embodiment does not limit the type of terminal 100.

[0084] Terminal 100 can communicate with core network equipment 202 through the radio access network (RAN) provided by base station 201.

[0085] The data sent from terminal 100 to network device 200 can be referred to as uplink data. The data sent from network device 200 to terminal can be referred to as downlink data.

[0086] Figure 2A A schematic diagram of the communication protocol architecture 20 is shown as an example.

[0087] like Figure 2A As shown, the communication protocol architecture 20 may include an application (APP) layer, an non-access stratum (NAS) layer, a radio resource control (RRC) layer, a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, a media access control (MAC) layer, and a physical layer (PHY). The PHY layer belongs to layer 1 (L1). The MAC, RLC, and PDCP layers belong to layer 2 (L2). The RRC and NAS layers belong to layer 3 (L3).

[0088] The application layer can include one or more applications. Examples include calling applications, game applications, video playback applications, etc. The application layer can rely on services provided by L3, L2, and L1 to complete the reception and transmission of user plane data. The L3 layer relies on services provided by L2 and L1 to complete the reception and transmission of control plane signaling.

[0089] In terminal 100, application layer functions can be deployed in the application processor (AP). L3, L2, and L1 functions can be deployed in the modem.

[0090] The PHY is responsible for handling encoding / decoding, modulation / demodulation, multi-antenna mapping, and other functions of the telecommunications physical layer. The PHY is the lowest layer in the communication protocol architecture. It provides services to higher layers through the transport channel.

[0091] The MAC layer can handle hybrid automatic repeat request (HARQ) retransmission and uplink / downlink scheduling.

[0092] The RLC layer is responsible for segmentation and connection, retransmission processing, and order control of higher-layer data. Located between the PDCP and MAC layers, the RLC layer communicates with the PDCP through service access points (SAPs) and with the MAC layer through logical channels.

[0093] The PDCP layer is responsible for processing RRC messages in the control plane and IP packets in the user plane. The PDCP layer can perform functions such as message encryption / decryption, integrity protection and authentication, and message header decompression.

[0094] The RRC layer supports various signaling protocols between terminal 100 and network device 200. Specifically, the RRC layer can broadcast system messages from the NAS layer, perform paging, establish, maintain, and release RRC connections, establish, modify, and release end-to-end radio bearers, and perform mobility management functions (such as UE measurement reports, cell handover, UE cell selection and reselection). As a high-level layer in the communication protocol architecture 20, the RRC layer is responsible for controlling L1 and L2 layers to complete air interface resource transmission, relying on the services of L1 and L2 layers to perform RRC connection control functions, and providing information transmission services for the NAS.

[0095] The NAS is responsible for handling the transmission of information between the UE and the core network device 202.

[0096] In some embodiments, the state of an RRC connection may include an RRC connected state and an RRC disconnected state.

[0097] refer to Figure 2B , Figure 2B An example diagram of the RRC status is shown.

[0098] RRC Connected State: After terminal 100 completes its camping in the cell and completes the random access procedure (i.e., establishes an RRC connection), terminal 100 enters the RRC connected state. The RRC connected state can also be called the RRC service state, etc. In the RRC connected state, terminal 100 continuously monitors control signal messages from network device 200. Therefore, terminal 100 consumes more power in the RRC connected state.

[0099] In some embodiments, if terminal 100, which is in an RRC connected state, does not transmit data with network device 200 for an extended period, network device 200 may send a message to terminal 100 to release the RRC connection. After establishing an RRC connection between terminal 100 and network device 200, network device 200 may start an inactivity timer corresponding to terminal 100. The duration of the inactivity timer can be 10 seconds, 20 seconds, etc. This embodiment does not limit the duration of the inactivity timer. If network device 200 detects data transmission from terminal 100, network device 200 may restart the inactivity timer corresponding to terminal 100. If network device 200 does not detect data transmission from terminal 100 within the duration of the inactivity timer, network device 200 may send the aforementioned message to release the RRC connection to terminal 100. Terminal 100 can release the RRC connection and enter an RRC disconnected state based on the aforementioned message.

[0100] RRC Disconnected State: The RRC disconnected state can include the RRC Idle state (RRC-IDLE). In the RRC Idle state, the RRC connection between terminal 100 and network device 200 is disconnected. Terminal 100 can periodically send "small packets" or "keep connected" signals to network device 200 at specified time intervals to indicate that it is still online. It can also attempt to receive broadcast messages and information from network device 200 to receive emergency calls, SMS messages, and other important services. If a new data transmission stream needs to be established, terminal 100 needs to switch from the RRC Idle state to the RRC Connected state. In this process, terminal 100 needs to renegotiate the allocation of radio resources for data transmission with network device 200 to establish an RRC connection.

[0101] In some embodiments, the RRC disconnected state may further include the RRC inactive state (RRC-INACTIVE). The RRC inactive state may be a new RRC state introduced by the NR system to reduce terminal power consumption and system latency. The radio interface behavior of terminal 100 in the RRC inactive state and the RRC idle state is consistent. In the RRC idle state and the RRC inactive state, the power consumption of terminal 100 is low.

[0102] In some embodiments, terminal 100 may introduce discontinuous reception (DRX) functionality to save power. Without DRX, terminal 100 continuously monitors the physical downlink control channel (PDCCH) to check for messages from network device 200. The PDCCH can be used to transmit downlink control information, such as downlink control information (DCI). The DCI may contain resource allocation and other control information for one or more terminals. The downlink control information can indicate the physical downlink shared channel (PDSCH) used for transmitting downlink data, so that terminal 100 can receive downlink data through the corresponding PDSCH. However, data transmission between terminal 100 and network device 200 is not continuous. Continuous monitoring of the PDCCH by terminal 100 is power-intensive. With the introduction of DRX, terminal 100 can periodically enter a sleep state and not monitor the PDCCH. When monitoring the PDCCH is required, terminal 100 can enter an active state from the sleep state and begin monitoring the PDCCH. In this way, terminal 100 does not need to continuously monitor PDCCH, thereby reducing power consumption.

[0103] The DRX in the RRC connected state can be called CDRX (connected DRX). Terminal 100 can go through one or more CDRX cycles while in the RRC connected state (e.g., Figure 2B (CDRX cycle 1 and CDRX cycle 2 are shown). In some embodiments, terminal 100 can negotiate and align CDRX cycles with network device 200. Figure 2B As shown, a CDRX cycle can include a CDRX activation period and a CDRX sleep period. During the CDRX activation period, terminal 100 can monitor the PDCCH and receive downlink data and signaling sent by network device 200. During the CDRX sleep period, terminal 100 can stop monitoring the PDCCH and stop receiving downlink data and signaling sent by network device 200. It can be seen that the longer terminal 100 remains in the CDRX sleep period, the lower its power consumption.

[0104] In some embodiments, a timer corresponding to the CDRX activation period may be configured in the terminal 100. This timer may be called onDurationTimer. When entering the CDRX activation period, the terminal 100 may start onDurationTimer and enter the CDRX sleep period after onDurationTimer expires. The duration of onDurationTimer is not limited in this embodiment. For example, the duration of onDurationTimer may be the duration required to monitor 6 PDCCH frames.

[0105] Optionally, terminal 100 can also be configured with a DRX inactivity timer (InactivityTimer). During the operation of onDurationTimer, if there is data that needs to be transmitted between terminal 100 and network device 200, and this data cannot be transmitted before onDurationTimer expires, terminal 100 can start DRX-InactivityTimer to extend the CDRX activation period. Thus, if there is data between terminal 100 and network device 200 that has not been transmitted within onDurationTimer, terminal 100 can extend the CDRX activation period through DRX-InactivityTimer to continue transmitting data, thereby eliminating the need to wait for the CDRX activation period of the next CDRX cycle to arrive before transmitting data. Introducing the DRX-InactivityTimer mechanism can reduce the latency of service data processing.

[0106] In some embodiments, in the RRC connected state, devices such as the modem of terminal 100 are in an active state. In the RRC disconnected state, the modem of terminal 100 may be in a sleep state. During the CDRX active period, devices such as the receiver of terminal 100 may be in an active state. During the CDRX sleep period, the receiver of terminal 100 may be in a closed state.

[0107] Understandably, the above Figure 2A The communication protocol architecture 20 shown is merely an illustrative example of this application and should not be construed as limiting the scope of this application. The communication protocol architecture for data transmission between terminal 100 and network device 200 may include more than Figure 2A Show more or fewer layers.

[0108] Figure 3 An exemplary structural diagram of terminal 100 is shown.

[0109] like Figure 3As shown, terminal 100 may include processor 110, external memory interface 120, internal memory 121, universal serial bus (USB) interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, button 190, motor 191, indicator 192, camera 193, display screen 194, and subscriber identification module (SIM) card interface 195, etc.

[0110] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the terminal 100. In other embodiments of this application, the terminal 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0111] Processor 110 may include one or more processing units, such as application processors, modems, graphics processing units (GPUs), image signal processors (ISPs), controllers, memory, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0112] The controller can serve as the central nervous system and command center of the terminal 100. The controller can generate operation control signals based on the instruction opcode and timing signals to control the fetching and execution of instructions.

[0113] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0114] In this application, the memory may store a computer program for enabling a controller or processor to implement the data transmission method of this application through an interface or protocol. For example, the computer program in the memory may be used to: determine whether the data to be sent in the application layer is low-latency data; instruct the background service to send data to the network device 200 in a concentrated manner after receiving a notification to resume data transmission during a period when the foreground service has no data transmission; actively release the RRC connection when there is no data transmission with the network device 200 within a preset time period; cache the non-low-latency data when it is obtained during the CDRX sleep period, and then send the cached non-low-latency data after entering the CDRX active period, etc.

[0115] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge terminal 100, or to transfer data between terminal 100 and peripheral devices. It can also be used to connect headphones for audio playback.

[0116] The charging management module 140 receives charging input from a charger, which can be either a wireless charger or a wired charger. While charging the battery 142, the charging management module 140 can also supply power to the terminal 100 via the power management module 141.

[0117] The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, internal memory 121, external memory, display 194, camera 193, and wireless communication module 160, etc.

[0118] The wireless communication function of terminal 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem and baseband processor, etc.

[0119] Antennas 1 and 2 are used to transmit and receive electromagnetic wave signals. Each antenna in terminal 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0120] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the terminal 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low-noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0121] A modem may include a modulator and a demodulator. The modulator modulates a low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates a received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to a baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is passed to an application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through a display screen 194. In some embodiments, the modem may be a separate device. In other embodiments, the modem may be independent of the processor 110 and housed within the same device as the mobile communication module 150 or other functional modules. The modem may also be referred to as a modem / demodulation processor, etc.

[0122] The wireless communication module 160 can provide solutions for wireless communication applications on the terminal 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signals (e.g., downlink data and signaling sent by network device 200) to processor 110. The wireless communication module 160 can also receive signals to be transmitted from the processor 110 (e.g., uplink data to be transmitted in the application layer, information for establishing an RRC connection with the network device 200, mobility registration requests to be sent to the network device 200 after the terminal 100 actively releases the RRC connection, etc.), frequency modulate them, amplify them, and convert them into electromagnetic waves for radiation via the antenna 2.

[0123] In some embodiments, antenna 1 of terminal 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling terminal 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0124] Terminal 100 implements display functions through a GPU, display screen 194, and application processor. The GPU is a microprocessor for image processing, connecting the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering.

[0125] The display screen 194 is used to display images, videos, etc. The display screen 194 can be a liquid crystal display (LCD), an OLED display, etc. This application embodiment does not limit the material of the display screen 194. In some embodiments, the display screen 194 may also include a flexible foldable screen. In some embodiments, the terminal 100 may include one or N display screens 194, where N is a positive integer greater than 1.

[0126] Terminal 100 can implement shooting functions through an ISP, camera 193, video codec, GPU, display 194, and application processor. The ISP processes data fed back from the camera 193. For example, when taking a picture, the shutter is opened, light is transmitted through the lens to the camera's photosensitive element, the light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, converting it into a visible image. The camera 193 is used to capture still images or videos. In some embodiments, terminal 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0127] A digital signal processor (DSP) is used to process digital signals, including digital image signals and other digital signals. For example, when terminal 100 selects a frequency, the DSP performs Fourier transforms on the frequency energy. A video codec is used to compress or decompress digital video.

[0128] NPU stands for Neural Network (NN) Computing Processor. By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn itself. NPUs can enable intelligent cognitive applications in terminals, such as image recognition, facial recognition, speech recognition, text understanding, and latency tolerance for detecting non-low-latency data.

[0129] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the terminal 100. The external storage card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external storage card.

[0130] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of terminal 100 by running the instructions stored in internal memory 121.

[0131] Terminal 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0132] Audio module 170 is used to convert digital audio information into analog audio signal output, and also to convert analog audio input into digital audio signal. Audio module 170 can also be used for audio signal encoding and decoding. Speaker 170A, also called a "loudspeaker," is used to convert audio electrical signals into sound signals. Receiver 170B, also called a "handset," is used to convert audio electrical signals into sound signals. Microphone 170C, also called a "microphone" or "microphone unit," is used to convert sound signals into electrical signals. Headphone jack 170D is used to connect wired headphones.

[0133] The sensor module 180 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, etc.

[0134] Buttons 190 include a power button, volume buttons, etc. Motor 191 can generate vibration feedback. Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, and also to indicate messages, missed calls, notifications, etc.

[0135] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and detach from the terminal 100. The terminal 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1. The terminal 100 interacts with the network through the SIM card to achieve functions such as calls and data communication. In some examples, the terminal 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the terminal 100 and cannot be removed from the terminal 100.

[0136] In some embodiments, the terminal 100 can remain in the RRC connected state when there is data to be sent in the foreground and / or background services. If there is no data transmission between the terminal 100 and the network device 200 within a preset time period, the terminal 100 can release the RRC connection according to the message from the network device 200 to release the RRC connection, and enter the RRC disconnected state. When the terminal 100 is in the RRC disconnected state, and there is data to be sent in the foreground and / or background services of the terminal 100, the terminal 100 can immediately request the network device 200 to establish an RRC connection so as to immediately send the data from the foreground and / or background services.

[0137] refer to Figure 4 , Figure 4 An exemplary schematic diagram of data transmission is shown.

[0138] This explanation uses foreground application 1 and background application 2 in terminal 100 as examples. Foreground application 1 may include foreground service 1 and background service 2. The foreground application, background application, foreground service, and background service can be referred to the description in the foregoing embodiments.

[0139] like Figure 4 As shown, foreground service 1 generates data packet 411 to be sent at time t11. Background service 2 generates data packet 412 to be sent at time t12. Background application 2 generates data packet 416 to be sent at time t13. Terminal 100 can remain in RRC connection state from time t11 to time t13 to send data packets 411, 412, and 416 to network device 200 based on the RRC connection. After time t13, background service 2 also generates data packets 413, 414, and 415 to be sent; background application 2 also generates data packet 417 to be sent. The time interval between the generation of data packets 411 to 417 is less than a preset time length. Therefore, terminal 100 can remain in RRC connection state to send data packets 411 to 417 to network device 200 via the expected RRC connection.

[0140] The time at which data packet 415 is generated can be time t14. Data packet 415 can be the latest data packet sent to network device 200 among the aforementioned data packets 411 to 417. Within a preset time period after sending data packet 415, terminal 100 has no uplink data packets to send to network device 200, and network device 200 has no downlink data packets to send to terminal 100. Network device 200 can send an RRC connection release message to terminal 100. This embodiment of the application does not limit the duration of the aforementioned preset time period.

[0141] For example, terminal 100 receives an RRC connection release message from network device 200 at time t15. Terminal 100 can release the RRC connection.

[0142] After terminal 100 enters the RRC disconnected state, background application 2 generates data packet 418 to be sent at time t16. Therefore, terminal 100 can immediately request network device 200 to establish an RRC connection, transitioning from the RRC disconnected state to the RRC connected state. Then, terminal 100 can send data packet 418 to network device 200 based on the RRC connection. Similarly, if there is no data transmission between terminal 100 and network device 200 within a preset time period after sending data packet 418, network device 200 can send an RRC connection release message to terminal 100.

[0143] For example, terminal 100 receives an RRC connection release message from network device 200 at time t17. Terminal 100 can then release the RRC connection again.

[0144] It can be seen that during the time period from t11 to t15, the foreground and / or background services in terminal 100 intermittently have data to send, and terminal 100 remains in the RRC connected state. During the time period from t15 to t16, terminal 100 is in the RRC disconnected state. During the time period from t16 to t17, terminal 100 returns to the RRC connected state.

[0145] In the above embodiment, once terminal 100 generates an uplink data packet, it needs to enter the RRC connection state to send the uplink data packet to network device 200. When there is a continuous intermittent need to send data in the foreground and / or background services, terminal 100 cannot release the RRC connection for a long time. Furthermore, terminal 100 needs to wait for the network device 200's RRC connection release message before it can release the RRC connection. This results in terminal 100 remaining in the RRC connection state for an extended period, significantly shortening its standby time and impacting the user experience.

[0146] In some embodiments, when the foreground service receives data that needs to be sent, the terminal 100 can start a timer 1. When timer 1 expires, the terminal 100 can instruct the background service to stop sending data. The terminal 100 can actively release the RRC connection if there is no data transmission with the network device 200 within a duration of 1. The value of duration 1 can be preset. This embodiment does not limit the value of duration 1. The terminal 100 can also determine the time to resume sending data packets. When resuming sending data packets, the terminal 100 can send one or more data packets from the background service to the network device 200. If the terminal 100 is in an RRC disconnected state before resuming sending data packets, the terminal 100 can re-establish the RRC connection with the network device 200 upon resuming sending data packets.

[0147] refer to Figure 5A , Figure 5A An exemplary schematic diagram of data transmission is shown.

[0148] In some embodiments, terminal 100 includes an application processor (AP) and a modem. Foreground and background services in terminal 100 can send data packets to the AP. The AP of terminal 100 can then send the data packets from the foreground and background services to the modem, which processes them and then sends them to network device 200. Not limited to an AP, terminal 100 may also include other processing modules for sending data from foreground and background services to the modem. This application uses an AP as an example for illustration.

[0149] like Figure 5A As shown, foreground service 1 sends data packet 511 to AP at time t21. AP can start timer 1 at time t21. This embodiment does not limit the duration of timer 1. For example, the duration of timer 1 can be 600 milliseconds (ms), or 1 second, etc. The timeout period of timer 1 can be time t24. Not limited to starting timer 1 at time t21, AP can also start timer 1 at a time after time t21. For example, AP can start timer 1 after sending data packet 511 to the modem, or after terminal 100 sends data packet 511 to network device 200. Alternatively, AP can start timer 1 when the foreground service has no data packets to send.

[0150] In some embodiments, the AP can send the timeout period of Timer 1 to a background service (e.g., background service 2, the service of background application 2). The background service in terminal 100 can determine the data transmission strategy based on the timeout period of Timer 1.

[0151] In some embodiments, an application may include multiple services. The aforementioned notification of the timeout period for timer 1 to the background service can refer to notifying the application containing the background service of the timeout period for timer 1. That is, the application (AP) does not need to notify each background service of the timeout period for timer 1 individually.

[0152] Background service 2 generates data packet 512 to be sent at time t22, and generates data packet 513 to be sent after time t22. Background application 2 generates data packet 516 to be sent at time t23, and generates data packet 517 to be sent after time t23. Data packets 512, 513, 516, and 517 are all generated before timer 1 expires. Since timer 1 has not yet expired, background service 2 can send data packets 512 and 513 to the AP, and background application 2 can send data packets 516 and 517 to the AP. Then, the AP can send data packets 512, 513, 516, and 517 to the modem, and then transmit them to network device 200 via the RRC connection.

[0153] like Figure 5A As shown, after sending data packet 511 of the foreground service 1, and before time t24, the foreground service in terminal 100 does not generate any data packets to be sent. When timer 1 expires (i.e., at time t24), the AP of terminal 100 can notify the background service in terminal 100 to stop sending data. The above-mentioned notification to stop sending data can be used to instruct the background service in terminal 100 to suspend sending non-low-latency data packets.

[0154] In some embodiments, based on the aforementioned notification to stop sending data, the background service in terminal 100 can stop sending data packets to the AP. However, after receiving the notification to stop sending data, the background service in terminal 100 can still continue generating data packets to be sent. But the background service in terminal 100 can cache the data packets to be sent generated after receiving the notification to stop sending data. For example, such as... Figure 5A As shown, background service 2 generates data packets 514 and 515 to be sent after time t24. Background service 2 can retain data packets 514 and 515 and not send them yet.

[0155] Alternatively, upon receiving the aforementioned notification to stop sending data, the background service in terminal 100 (e.g., background service 2, background application 2) can pause the generation of data packets to be sent. For example, background service 2 may choose not to generate data packets 514 and 515. After receiving a notification to resume sending data, the background service in terminal 100 can continue generating data packets to be sent according to business needs.

[0156] In some embodiments, the AP can send the timeout duration of Timer 1 to the background service in terminal 100 before Timer 1 expires. Based on the timeout duration of Timer 1, the background service in terminal 100 can stop sending data packets to the AP after Timer 1 expires. In this way, the AP does not need to notify the background service to stop sending data when Timer 1 expires.

[0157] It can be seen that the AP of terminal 100 will not send the data packets to be sent to the modem for a period of time after timer 1 expires. If there is no uplink or downlink data transmission between terminal 100 and network device 200 within time period 1, terminal 100 can actively release the RRC connection. For example, as Figure 5AAs shown, terminal 100 can actively release the RRC connection at time t25. The method for terminal 100 to actively release the RRC connection will be described in subsequent embodiments. It will not be elaborated here. It should be noted that time t25 can be before time t24, after time t24, or the same time as time t24. Time t25 can be determined by the time of the most recent transmission of uplink data packets and / or downlink data packets between terminal 100 and network device 200, and the value of the aforementioned duration 1. This application embodiment does not limit the aforementioned time t25.

[0158] In some embodiments, a background service may send a tolerable period of its network inactivity to the AP. A tolerable period of network inactivity for a background service can be used to indicate how long packet transmission for that background service can be delayed. The AP can determine when to resume packet transmission based on one or more tolerable periods of network inactivity for background services.

[0159] The background service in terminal 100 can send its tolerable period of network non-use to the AP before timer 1 expires. A tolerable period of network non-use for a background service can include an earliest tolerable time and a latest tolerable time. The earliest tolerable time indicates the minimum time a data packet can be delayed (i.e., the data packet can be delayed until after the earliest tolerable time). The latest tolerable time indicates the maximum time a data packet can be delayed (i.e., the data packet cannot be delayed beyond the latest tolerable time). The tolerable period of network non-use for the background service can be related to the service being performed by the background service. For example, the service performed by the background service may require data packets to be sent to network device 200 within a certain period; otherwise, the functionality provided by the service may fail. The background service can determine its tolerable period of network non-use based on the time period during which the service requires data packets to be transmitted.

[0160] For example, such as Figure 5AAs shown, background service 2 can send a tolerable period T2 of network inactivity to the AP before time t24. The tolerable period T2 can be the time interval between time t27 and time t31. Here, time t27 is the earliest tolerable time for background service 2 to not use the network, and time t31 is the latest tolerable time. Background application 2 can send a tolerable period T3 of network inactivity to the AP before time t24. The tolerable period T3 can be the time interval between time t26 and time t32. Here, time t26 is the earliest tolerable time for background application 2 to not use the network, and time t32 is the latest tolerable time. The tolerable period for background application 2 to not use the network can be the tolerable period for one or more background services within background application 2 to not use the network. The AP can determine the time to resume sending data packets as data period T1 based on the tolerable periods T2 and T3. Data transmission period T1 can be the time interval between time t28 and time t29. The data transmission period T1 can be a shared time period of the tolerable periods T2 and T3. That is, time t28 is later than time t26 and t27, and time t29 is earlier than time t31 and t32. It is understood that, not limited to background service 2 and background application 2, if other background services are running in terminal 100, terminal 100 can combine the tolerable periods when more background services are not using the network to determine the time to resume sending data packets.

[0161] In some embodiments, the delay time for different data packets from a background service is different. The background service can send different delay times for different data packets to the AP. The AP can determine when to resume sending data packets based on the delay times for multiple data packets from the same background service or multiple background services.

[0162] The background service can determine the data packets that need to be sent within a future time period based on its operational activities. The background service can send the AP a delay time for one or more data packets that need to be sent within the future time period. This delay may include data that needs to be sent after Timer 1 expires (e.g., data that needs to be sent within the future time period). Figure 5A Data packets 514 and 515 are shown.

[0163] For example, before sending data packet 512, background service 2 knows that data packets 512 to 515 need to be sent within a future period. Background service 2 can send the delay time for data packet 512 to the delay time for data packet 515 to the AP before timer 1 expires. Before sending data packet 516, background application 2 knows that data packets 516, 517, etc., need to be sent within a future period. Background application 2 can send the delay time for each of data packets 516, 517, etc., to the AP before timer 1 expires.

[0164] Since data packets 512, 513, 516, and 517 were generated and sent to the AP before timer 1 expired, they can be immediately transmitted to network device 200 without waiting for the next data transmission resumption. The AP can determine the time to resume sending data packets based on the delay time that background service 2 and background application 2 can delay sending data packets that have not yet been sent to the AP after timer 1 expired (such as data packets 514 and 515).

[0165] The AP determines the time to resume sending data packets based on the tolerable periods of network inactivity reported by the backend service. This allows the AP to delay sending data packets for the backend service, thus integrating fragmented periods of no data transmission into continuous periods of no data transmission. Furthermore, the AP can send data packets for the backend service before the latest time that the backend service can tolerate, so as not to affect the business implementation of the backend service.

[0166] In some embodiments, the time for resuming data packet transmission after Timer 1 expires can be preset. The AP can determine the time corresponding to the elapsed duration 2 after Timer 1 expires as the start time for resuming data packet transmission; that is, the time difference between the timer 1 expires and the start time for resuming data packet transmission can be duration 2. For example, Figure 5A The time difference between the start time of data transmission period T1 (time t28) and the timeout time of timer 1 (time t24) is duration 2. Furthermore, the AP can determine the duration for data packet resumption as duration 3. For example, Figure 5A The duration of the data transmission period T1 shown is 3. The values ​​of duration 2 and duration 3 can both be preset. This embodiment of the application does not limit the values ​​of duration 2 and duration 3.

[0167] Optionally, the values ​​of duration 2 and / or duration 3 can also be related to the background service currently running on terminal 100. For example, terminal 100 may store the time during which data packets of different services can be delayed. The AP can read the time during which data packets of the currently running background service can be delayed from the memory of terminal 100, and then determine the duration 2 and / or duration 3.

[0168] In some embodiments, when data packet transmission resumes, the AP can notify the background service to resume data transmission. If terminal 100 is in an RRC disconnected state when data packet transmission resumes, the AP can also notify the modem to establish an RRC connection. In this way, terminal 100 can request the network device 200 to establish an RRC connection through the modem, so as to send data packets based on the RRC connection.

[0169] Optionally, the AP can also send the end time of data resumption to the background service. The background service in terminal 100 can determine the data transmission strategy based on the end time of data resumption.

[0170] For example, such as Figure 5A As shown, data transmission period T1 is the time period for resuming data transmission. The start time of data transmission period T1 is t28, and the end time is t29. The AP can notify background service 2 and background application 2 to resume data transmission at t28. Based on the notification to resume data transmission, background service 2 and background application 2 can send data packets to be sent to the AP. Specifically, background service 2 can send data packet 518 to the AP. Data packet 518 may include data packets 514 and / or 515, etc. Background application 2 can send data packet 519 to the AP. Data packet 519 may include data packets to be sent that background application 2 has buffered after timer 1 expires.

[0171] Background service 2 and background application 2 can send data packets generated during data transmission period T1 to the AP. For example, such as... Figure 5A As shown, background application 2 generates data packet 521 during data transmission period T1. Background application 2 can send data packet 521 to the AP. The AP can send the data packets received during data transmission period T1 to the modem, and then send these data packets to network device 200 through the RRC connection.

[0172] When the data transmission period T1 ends (i.e., at time t29), the AP of terminal 100 can notify the background service in terminal 100 to stop sending data. This notification to stop sending data can be used to instruct the background service in terminal 100 to stop sending non-low-latency data packets. The operations performed by the background service in terminal 100 after receiving the notification to stop sending data can be referred to the description in the foregoing embodiments. They will not be repeated here.

[0173] In some embodiments, the AP can send the end time of data transmission period T1 to the background service. Based on the end time of data transmission period T1, the background service in terminal 100 can stop sending data packets to the AP after the end of data transmission period T1. In this way, the AP does not need to notify the background service to stop sending data when data transmission period T1 ends.

[0174] In some embodiments, the background service may send a tolerable period of network inactivity to the AP before the end of the data transmission period T1. The AP can determine the time to resume sending data packets based on one or more tolerable periods of network inactivity provided by the background service. The AP can determine the time to resume sending data packets by referring to the description of determining the data transmission period T1 in the foregoing embodiments.

[0175] For example, a backend service can know the data packets that need to be sent within a future time period based on the business it performs. The backend service can send the AP a delay time for sending one or more data packets that need to be sent within the future time period. Figure 5A Data packet 520 can be a data packet that background service 2 needs to send after the data transmission period T1 ends, and data packet 522 can be a data packet that background application 2 needs to send after the data transmission period T1 ends. Background service 2 can send the delay time for data packet 520 to the AP. Background application 2 can send the delay time for data packet 522 to the AP. The AP can determine the time period for resuming data packet transmission based on the delay times for data packets 520, 522, etc.

[0176] It can be seen that terminal 100 can enter the RRC connected state from the RRC disconnected state at time t28. However, considering that it takes a certain amount of time for terminal 100 to establish an RRC connection with network device 200, the time when terminal 100 enters the RRC connected state may be slightly later than time t28.

[0177] like Figure 5A As shown, during data transmission period T1, the foreground service in terminal 100 has no data packets to send, and the background service in terminal 100 only sends data packets to the AP during data transmission period T1. After sending data packets 518, 519, and 521 to the modem, the AP does not send any more data packets to the modem for a considerable period. If, within a duration of 1 after terminal 100 sends data packets 518, 519, and 521 to network device 200, there is no uplink or downlink data transmission between terminal 100 and network device 200, terminal 100 can actively release the RRC connection. For example, as... Figure 5AAs shown, terminal 100 can actively release the RRC connection at time t30. Time t30 can be before, after, or the same as time t29. Time t30 can be determined by the time of the most recent transmission of uplink and / or downlink data packets between terminal 100 and network device 200, and the value of the aforementioned duration 1. This embodiment of the application does not limit the aforementioned time t30.

[0178] In some embodiments, when terminal 100 is in RRC disconnected state and foreground service generates data packets to be sent, terminal 100 can immediately establish an RRC connection with network device 200 and enter RRC connected state in order to send the foreground service data packets to network device 200.

[0179] For example, such as Figure 5A As shown, terminal 100 enters the RRC disconnected state at time t30. Foreground service 1 generates a data packet 523 to be sent at time t33. Foreground service 1 can send data packet 523 to the AP. The AP can start timer 1 based on the transmission of data packet 523. The AP can start timer 1 at time t33 or slightly later. Considering that it takes time for terminal 100 to establish an RRC connection with network device 200, the time when terminal 100 enters the RRC connected state may be slightly later than time t33.

[0180] If the start time for the next data packet transmission determined by the AP at the end of data transmission period T1 is later than time t33, then terminal 100 remains in the RRC disconnected state. The AP can instruct the modem to establish an RRC connection based on data packet 523. For example, terminal 100 enters the RRC connected state from the RRC disconnected state at time t33. The AP can send data packet 523 to the modem. The modem can then send data packet 523 to network device 200 via the RRC connection. This avoids delays in sending foreground service data packets, which could negatively impact user experience.

[0181] After starting Timer 1, the AP can notify the background service to resume data transmission. For example, Timer 1 can start at time t33 and time out at time t35. It can be seen that since the foreground service 1 needs to send data packet 523, the AP can notify the background service to resume data transmission in advance. This aligns the data packet transmission time of the background service with that of the foreground service, reducing the likelihood of terminal 100 being in RRC connection state simply because the background service needs to send data.

[0182] Based on the notification to resume data transmission, background service 2 and background application 2 can send the data packets to be transmitted that were held up before time t33 to the AP. Specifically, background service 2 can send data packet 524 to the AP. Data packet 524 may include data packet 520. Background application 2 can send data packet 525 to the AP. Data packet 525 may include data packet 522. Background service 2 and background application 2 can send data packets to the AP before timer 1 expires (i.e., at time t35).

[0183] In some embodiments, the background service may send a tolerable period of network inactivity to the AP before time t35. The AP can determine when to resume sending data packets after time t35 based on one or more tolerable periods of network inactivity for the background service. The AP's determination of when to resume sending data packets after time t35 can be found in the description of determining the data transmission period T1 in the foregoing embodiments. This will not be repeated here.

[0184] When timer 1 times out (i.e. at time t35), the AP can notify the background service (e.g., background service 2, background application 2) to stop sending data.

[0185] Optionally, the timer started by the AP based on packet 523 can be different from the timer started based on packet 511. That is, when packet 523 is received, the AP can start a different timer than timer 1.

[0186] It can be seen that within the time period corresponding to Timer 1 (i.e., the time period from t33 to t35), the foreground service in terminal 100 (e.g., foreground service 1) only needs to send data packet 523, while the background service in terminal 100 only sends data packets (e.g., data packets 524 and 525) to the AP within the time period corresponding to Timer 1. For a considerable period after the AP sends data packets 523 to 525 to the modem, it does not send any more data packets to the modem. If, within a duration of 1 after terminal 100 sends data packets 523 to 525 to network device 200, there is no uplink or downlink data transmission between terminal 100 and network device 200, terminal 100 can actively release the RRC connection. For example, as... Figure 5A As shown, terminal 100 can actively release the RRC connection at time t34. Time t34 can be before, after, or the same as time t35. Time t34 can be determined by the time of the most recent transmission of uplink and / or downlink data packets between terminal 100 and network device 200, and the value of the aforementioned duration 1. This embodiment of the application does not limit the specific time t34.

[0187] In some embodiments, the AP may run a data delayed transmission service. The aforementioned actions of setting Timer 1, sending the timeout time of Timer 1, notifications to stop data transmission, notifications to resume data transmission, and the end time of resumed data transmission to the background service in terminal 100, obtaining the tolerable period during which the background service does not use the network, and determining the time to resume data transmission based on the tolerable period during which the background service does not use the network can all be performed by the data delayed transmission service. The data delayed transmission service may be a service provided by the system of terminal 100. This application embodiment does not limit the name of the data delayed transmission service.

[0188] It should be noted that the data packets (e.g., data packets 511 to 525) in the above embodiments may include service data and / or signaling data generated by the services running in the terminal 100 to realize corresponding Internet access services. Internet access services include, but are not limited to: voice call services, video playback services, music playback services, instant messaging services, etc. This application embodiment does not limit the data contained in the data packets.

[0189] In some embodiments, the services running on the terminal 100 can adhere to the principle of shortest network availability, minimizing the time spent occupying network transmission resources when transmitting data, thereby reducing the problem of increased power consumption and overheating of the terminal 100 due to prolonged occupation of network transmission resources.

[0190] Depend on Figure 5A It is known that terminal 100 sets a time period for data transmission for the background service (e.g., the time period corresponding to timer 1, data transmission period T1). Outside of this data transmission period, the background service can retain data packets to be sent. During the data transmission period, the background service can centrally send the previously retained data packets to the AP. The AP can then send the background service's data packets to the modem, thereby sending them to network device 200 based on the RRC connection. In this way, when the background service intermittently generates data packets to be sent, terminal 100 does not need to be continuously in an RRC connected state. For example, when background service 2 generates data packets 514, 515, and 520 to be sent, and when the background application generates data packet 522, terminal 100 is in an RRC disconnected state.

[0191] The above embodiments can align the sending time of data packets in the background service, integrating fragmented time segments without data transmission into continuous time segments without data transmission, reducing the need for the terminal to continuously transmit data with network devices. This effectively increases the duration of the terminal 100 in the RRC disconnected state, reducing the terminal's power consumption.

[0192] In some embodiments, if the AP receives a data packet from the foreground service again after starting Timer 1 and before Timer 1 expires, the AP can restart Timer 1.

[0193] refer to Figure 5B , Figure 5B An example diagram illustrating another data transmission method is shown.

[0194] like Figure 5B As shown, foreground service 1 sends data packet 511 to AP at time t21. AP can start timer 1 at time t21. For example, if timer 1 is started at time t21, the timeout period of timer 1 can be... Figure 5B The time shown is t24. Data packet 511 and timer 1 can be referred to in the previous section. Figure 5A Introduction.

[0195] After time t21, background service 2 generates data packets 512, 513, 514, and 515 to be sent. After time t21, background application 2 generates data packets 516 and 517 to be sent. Data packets 512 to 517 can be referred to the description in the foregoing embodiment.

[0196] Before timer 1 expires (i.e., before time t24), foreground service 1 generates another data packet to be sent and sends it to the AP. For example, as Figure 5B As shown, foreground service 1 sends data packet 531 to AP at time t41. AP can restart timer 1 at time t41. The timeout period after timer 1 is restarted is... Figure 5B The time shown is t42.

[0197] In some embodiments, when timer 1 is restarted, the AP can notify the background service (e.g., background service 2, the service of background application 2) of the timeout period after timer 1 is restarted. The background service in terminal 100 can determine the data transmission strategy based on the timeout period after timer 1 is restarted.

[0198] Until a notification to stop sending data is received, the background service in terminal 100 can continue to send data packets to the access point (AP). For example, data packets 512 to 517 are all data packets generated before time t42. Background service 2 can send data packets 512 to 515 to the AP before time t42. Background application 2 can send data packets 516 and 517 to the AP before time t42. Then, the AP can send data packets 512 to 517 to the modem, and then to network device 200 via the RRC connection.

[0199] When Timer 1 expires after restarting (i.e., at time t42), the AP can notify background services such as Background Service 2 and Background Application 2 to stop sending data. The notification to stop sending data can be found in the previous section. Figure 5A Introduction.

[0200] In some embodiments, background service 2 and background application 2 may send a tolerable period of network inactivity to the AP before the restarted timer 1 expires. The tolerable period of network inactivity for a background service can be found in the description of the foregoing embodiments. The AP can determine the time to resume sending data packets based on one or more tolerable periods of network inactivity for background services. When resuming data packet transmission, the AP can notify background service 2 and background application 2 to resume data transmission. Alternatively, the AP can determine the time corresponding to duration 2 elapsed after the restarted timer 1 expires (i.e., time t42) as the start time for resuming data packet transmission. The duration for resuming data packet transmission can be duration 3. The method by which the AP determines the time to resume sending data packets can be found in the description of the foregoing embodiments.

[0201] In some embodiments, the AP may start another timer at time t41. The duration of this other timer may be the same as or different from that of timer 1. That is, if the foreground service in terminal 100 generates data packets to be sent again before timer 1 expires (i.e. before time t24), the AP can extend the data transmission duration by restarting timer 1 or starting another timer different from timer 1.

[0202] Depend on Figure 5B It is known that foreground service data packets are typically low-latency data packets. When a foreground service data packet is received, the AP can extend the data transmission duration (e.g., a service running in terminal 100 sends a data packet to the AP, and the AP sends data packets from one or more services to the modem) by restarting Timer 1. This reduces the likelihood of foreground services needing to send data packets one after another, and the RRC connection being released prematurely, requiring the re-establishment of the RRC connection to transmit foreground service data packets. The above embodiment can reduce the frequency of RRC connection establishment by terminal 100 in a short period of time, thereby reducing the power consumption of terminal 100.

[0203] In some embodiments, if the AP receives a data packet from the foreground service within a preset data recovery transmission period, or within a data recovery transmission period determined based on the tolerable period during which the background service does not use the network, the AP may start Timer 1. If the timeout of Timer 1 is later than the end time of the preset data recovery transmission period, or later than the end time of the data recovery transmission period determined based on the tolerable period during which the background service does not use the network, the AP may delay the data recovery transmission period until the timeout of Timer 1. That is, the AP may notify the background service to stop sending data after Timer 1 expires.

[0204] refer to Figure 5C , Figure 5C An example diagram illustrating another data transmission method is shown.

[0205] like Figure 5C As shown, foreground service 1 sends data packet 511 to AP at time t21. AP can start timer 1 at time t21. For example, if timer 1 is started at time t21, the timeout period of timer 1 can be... Figure 5B As shown at time t24. After time t21, background service 2 generates data packets 512, 513, 514, and 515 to be sent. Background application 2 generates data packets 516 and 517 to be sent after time t21. Background service 2 and background application 2 can send their tolerable periods of network inactivity to the AP before timer 1 expires (i.e., before time t24). When timer 1 expires (i.e., at time t24), the AP can notify background services such as background service 2 and background application 2 to stop sending data. The AP can determine the data transmission period T1 for resuming data transmission. Data packets 511 to 517 and the data transmission period T1 can be referenced from the previous description. Figure 5A Introduction.

[0206] The AP can notify background services such as background service 2 and background application 2 to resume data transmission at the start time of data transmission period T1 (i.e., time t28).

[0207] Upon receiving a notification to resume data transmission, background service 2 can send data packet 518 to the AP, and background application 2 can send data packets 519 and 521 to the AP. Data packets 518, 519, and 521 can be found in the preceding text. Figure 5A Introduction.

[0208] Before the end of data transmission period T1 (i.e., before time t29), foreground service 1 generates another data packet to be sent and sends it to the AP. For example, as Figure 5CAs shown, foreground service 1 sends data packet 541 to AP at time t51. Time t51 can fall between time t28 and t29. AP can start timer 1 at time t51. If timer 1 is started at time t51, the timeout period of timer 1 can be... Figure 5C The time shown is t52. Alternatively, the timer started by the AP at time t51 can be different from timer 1. This application does not limit the timer started by the AP. Here, we will specifically illustrate this by taking the AP starting timer 1 at time t51 as an example.

[0209] In some embodiments, if the timeout of Timer 1 is later than the end time of the aforementioned data transmission period T1 (i.e., time t52 is later than time t29), the AP can extend the time for resuming data transmission to the timeout of Timer 1. Optionally, after starting Timer 1 at time t51, the AP can notify background services such as background service 2 and background application 2 of the timeout of Timer 1 (i.e., time t52).

[0210] In this scenario, the background service in terminal 100 can continuously send data packets to the access point (AP) until a notification to stop sending data is received. For example, data packets 520 and 522 are both generated before time t52. Background service 2 can send data packet 520 to the AP before time t52. Background application 2 can send data packet 522 to the AP before time t52. The AP can then send data packets 520 and 522 to the modem, which in turn sends them to network device 200 via the RRC connection.

[0211] In some embodiments, background services such as background service 2 and background application 2 may also send to the AP a tolerable period during which they are not using the network before time t52. The AP can determine the time to resume sending data packets based on the tolerable periods during which one or more background services are not using the network.

[0212] In some embodiments, if the timeout of Timer 1 is earlier than the end time of the aforementioned data transmission period T1 (i.e., time t52 is earlier than time t29), the time to resume data transmission does not need to be extended and remains the same as the data transmission period T1. The AP does not need to notify the background service 2 and background application 2 of the timeout of Timer 1. The background service 2 and background application 2 can continuously send data packets to the AP before the end of the data transmission period T1. When the data transmission period T1 ends (i.e., at time t29), the AP can notify the background services, including the background service 2 and background application 2, to stop sending data.

[0213] Depend on Figure 5CIt is known that foreground service data packets are typically low-latency data packets. Foreground services can send data packets to the AP immediately, unconstrained by the data transmission period set by the AP. When a foreground service has data to send within the data transmission period designated by the AP for background services, the AP can start Timer 1 upon receiving the foreground service's data packet. If Timer 1's timeout is late, the AP can extend the data transmission duration based on Timer 1. This reduces the likelihood of foreground services needing to send data packets one after another, and the premature release of the RRC connection necessitating the re-establishment of an RRC connection to transmit foreground service data packets. This avoids terminal 100 frequently establishing RRC connections within a short period, reducing terminal 100's power consumption.

[0214] Figure 6 An exemplary flowchart illustrates a method for a terminal 100 to actively release an RRC connection.

[0215] S611, the L2 PDCP layer of terminal 100 detects the time when there is no uplink or downlink data transmission.

[0216] S612, the L2 PDCP layer of terminal 100 can send an indication message of no data transmission to the RRC layer.

[0217] In some embodiments, terminal 100 can utilize the transmission time interval (TTI) of the PDCP layer to detect whether uplink or downlink data transmission exists between terminal 100 and network device 200. For example, in an LTE system, the TTI value can be 1 ms. In an NR system, the TTI value can be 0.5 ms. Specifically, the PDCP layer can perform a service data transmission detection every N TTIs (i.e., a certain duration). If no uplink or downlink data transmission is detected, the PDCP layer can send a no-data-transmission indication message to the RRC layer. When the RRC receives the no-data-transmission indication message, it can record the current timestamp and determine whether no-data-transmission indication messages are received consecutively based on the time difference between the current timestamp and the time when the no-data-transmission indication message was last received. That is, the RRC layer can determine whether the time difference between two consecutive no-data-transmission indication messages is N TTIs. It is understandable that there may be a certain time deviation between the time difference between two no-data-transmission indication messages received by the RRC layer and the duration corresponding to N TTIs.

[0218] When the RRC layer receives M consecutive no-data-transmission indication messages, the RRC can determine that terminal 100 has no uplink or downlink data transmission within a preset duration. This preset duration can be a duration of 1. The value of M can be calculated based on the duration of 1. For example, duration 1 is 20 seconds. In the LTE system, if N is 5 and TTI is 1 ms, then the value of M can be 4000 (i.e., 20s / 5 / 1ms).

[0219] The method described above for detecting no uplink or downlink data transmission within a preset time period is merely an illustrative example of the embodiments of this application and should not be construed as limiting this application.

[0220] S613, the RRC layer of terminal 100 can release local resources of RRC connection if there is no uplink or downlink data transmission within a preset time period.

[0221] S614. The RRC layer of terminal 100 can send an instruction message to the L2 and L1 of the terminal to release RRC-related resources.

[0222] S615 and terminal 100's L2 and L1 can release RRC-related resources.

[0223] When releasing an RRC connection, the RRC layer can release its own resources, and L2 and L1 can release their own resources respectively.

[0224] S616, L2 and L1 of terminal 100 can send an indication message to the RRC layer indicating that the release of RRC-related resources is complete.

[0225] S617, the RRC layer of terminal 100 can send an indication message that the RRC connection has been released to the NAS.

[0226] The NAS of S618 and Terminal 100 can send a mobility registration request to the RRC layer.

[0227] S619, the RRC layer of terminal 100 can send a mobility registration request to network device 200.

[0228] The aforementioned mobility registration request can be used to instruct network device 200 to maintain synchronization of the RRC connection state. That is, after terminal 100 actively releases the RRC connection, it can instruct network device 200 to release the resources of terminal 100's RRC connection through the mobility registration request, so as to prevent network device 200 from not knowing that terminal 100 has released the RRC connection and sending an instruction to terminal 100 to release the RRC connection.

[0229] S620 and network device 200 can release the resources of terminal 100RRC connection.

[0230] As can be seen from the above method, terminal 100 can actively release the RRC connection when there is no uplink or downlink data transmission within a preset time period, without waiting for network device 200 to send a command to release the RRC connection. This enables terminal 100 to release the RRC connection instantly when there is no uplink or downlink data transmission, reducing the power consumption of terminal 100.

[0231] It should be noted that the method by which the terminal 100 actively releases the RRC connection is not limited in the embodiments of this application. For example, the terminal 100 may use the RRC connection release method described in the following patent document: application number 202010956218.X, entitled "A Method and Apparatus for Releasing an RRC Connection". The entire contents of the above patent document are incorporated herein by reference.

[0232] Figure 7 A flowchart of a data transmission method provided by an embodiment of this application is shown as an example.

[0233] like Figure 7 As shown, this data transmission method can be applied to a communication system including a terminal 100 and a network device 200. The terminal 100 may include a foreground application, a background application, an application processor, and a modem. The foreground application may include at least one foreground service. The foreground application may also include background services. The background application may include one or more background services.

[0234] S711, Terminal 100 establishes an RRC connection with Network Device 200 via a modem.

[0235] The method for establishing an RRC connection between terminal 100 and network device 200 is not limited in the embodiments of this application.

[0236] S712, the foreground service sends data packet p1 to the application processor.

[0237] When the foreground service generates a data packet p1 to be sent, the foreground service can immediately send the data packet p1 to the application processor.

[0238] S713, Application Processor Startup Timer 1.

[0239] Upon receiving data packet p1, the application processor can start timer 1. Data packet p1 can be referred to in the preceding text. Figure 5A The data packet shown is 511.

[0240] The duration of Timer 1 can be preset. In some embodiments, the duration of Timer 1 can be related to the foreground service that sends data packet p1. The duration of Timer 1 can be different for different foreground services. This application embodiment does not limit the duration of Timer 1.

[0241] Timer 1 can be started based on the transmission of data packet p1. This application embodiment does not limit the specific time for starting Timer 1. For example, the application processor can start Timer 1 after sending data packet p1 to the modem. Alternatively, the application processor can start Timer 1 after the terminal 100 sends data packet p1 to the network device 200. Or, the application processor can start Timer 1 if no foreground service data packet is received within a preset time period after receiving data packet p1.

[0242] S714, the application processor sends data packet p1 to the modem.

[0243] S715, the modem sends data packet p1 to network device 200 based on the RRC connection.

[0244] S716, the application processor sends the timeout for Timer 1 to the foreground application and the background application that contain background services.

[0245] In some embodiments, the foreground application and background application containing background services can determine the data transmission strategy based on the timeout period of Timer 1. Step S716 is optional. That is, the application processor may also choose not to send the timeout period of Timer 1 to the foreground application and background application containing background services.

[0246] S717, a background service in a foreground application can send data packet p2 to the application processor.

[0247] S718, background applications can send data packets p3 to the application processor.

[0248] Foreground and background applications that include background services can send the generated data packets (such as data packets p2 and p3, etc.) to the application processor before receiving a notification to stop sending data.

[0249] The S719 application processor can send data packets p2 and p3 to the modem.

[0250] The S720 modem sends data packets p2 and p3 to network device 200 based on the RRC connection.

[0251] S721. When Timer 1 expires, the application processor notifies the foreground application and background application containing background services to stop sending data.

[0252] A stop data transmission notification can be used to instruct a background service to cease transmitting data (i.e., non-low-latency data packets). The foreground service can still transmit data after receiving the stop data transmission notification.

[0253] If a foreground application and a background application that includes a background service receive a notification to stop sending data, and the background service generates a data packet to be sent, then the data packet is retained and not sent temporarily.

[0254] Alternatively, upon receiving a notification to stop sending data, the foreground application and background services within the background application can pause the generation of data packets to be sent. After receiving a notification to resume sending data, the foreground application and background services within the background application can then resume generating data packets according to business needs.

[0255] In some embodiments, background services in foreground and background applications can cache data packets to be sent after Timer 1 expires, and not send them to the AP immediately. For example, the background service can cache the data packets in its service memory or application memory that it can read and write. Alternatively, the background service can send the data packets to be sent after Timer 1 expires to the AP. The AP can cache the data packets to be sent from the background service after Timer 1 expires in a preset storage space. Optionally, the data packets to be sent from the background service after Timer 1 expires may carry a time limit for delaying the transmission of the data packets.

[0256] Step S721 is optional. In some embodiments, the application processor may execute step S716 as described above. Based on the timeout period of timer 1, the foreground application and background application containing background services may stop sending data to the application processor after timer 1 expires. In this way, the application processor may not need to execute step S721.

[0257] S722. If there is no uplink or downlink data transmission within a preset time period, the modem releases the resources of the local RRC connection.

[0258] In some embodiments, the modem can detect whether there is no uplink or downlink data transmission between the terminal 100 and the network device 200 within a preset time period, and then actively release the RRC connection if there is no uplink or downlink data transmission within the preset time period.

[0259] S723, the modem sends a mobility registration request to network device 200.

[0260] S724, Network device 200 releases resources for terminal 100RRC connection.

[0261] Steps S722 to S724 can be referred to the above. Figure 6 The method shown.

[0262] S725, The application processor determines the time period T11 for resuming data transmission.

[0263] In some embodiments, a foreground application and a background application that include background services can send to the AP a tolerable period during which they do not use the network. The AP can determine the time period T11 based on one or more tolerable periods during which the foreground application and the background application that include background services do not use the network.

[0264] Within this framework, each data packet from the background service has a corresponding time limit for delayed transmission. These delay times may differ for different data packets. Foreground and background applications containing background services can send the AP a tolerable period during which they are not using the network. This can include the time limit for delaying the transmission of one or more data packets that the background service within the foreground or background application needs to send after Timer 1 expires.

[0265] For example, if a background service in a foreground application has two data packets whose transmission time expires after Timer 1, then the background service in the foreground application can send the corresponding delayed transmission time for each of these two data packets to the AP. If a background service in a background application has three data packets whose transmission time expires after Timer 1, then the background service in the background application can send the corresponding delayed transmission time for each of these three data packets to the AP. Then, the AP can determine the aforementioned time period T11 based on the delayed transmission time of one or more received data packets.

[0266] Alternatively, the time period T11 can be a preset time period after timer 1 expires. The method by which the application processor determines the time period T11 can refer to the method for determining the data transmission time period T1 in the foregoing embodiments. It will not be repeated here.

[0267] S726. When data transmission is restored, the application processor notifies the foreground application and background application containing background services to resume sending data.

[0268] In some embodiments, the notification to resume data transmission may include the end time of the data transmission resumption, i.e., the end time of time period T11.

[0269] S727, A background service in a foreground application sends data packet p4 to the application processor.

[0270] S728, The background application sends data packet p5 to the application processor.

[0271] Upon receiving a notification to resume data transmission, the background service in terminal 100 can send one or more data packets to the application processor. The background service can send data packets to the application processor within a time period T11.

[0272] For example, a background service in a foreground application can send data packet p4 to the application processor. Data packet p4 can be referred to in the preceding text. Figure 5AThe data packet 518 is shown. The background application can send data packet p5 to the application processor. Data packet p5 can be referenced from the previous section. Figure 5A The data packet shown is 519.

[0273] S729, the application processor sends data packets p4 and p5 to the modem.

[0274] S730 and terminal 100 establish an RRC connection with network device 200 via a modem.

[0275] If terminal 100 is in RRC disconnected state, terminal 100 can establish an RRC connection with network device 200 through modem.

[0276] This application embodiment does not limit the execution order of steps S730 and S726-S729. For example, step S730 may be executed after step S729. Step S730 may be executed after the modem receives data packet p4 and / or data packet p5. Alternatively, step S730 and one or more of steps S726-S729 may be executed simultaneously. Wherein, after the application processor determines the time period T11 for resuming data transmission, it may send a message to the modem to instruct the modem to establish an RRC connection with the network device 200.

[0277] S731, the modem sends data packets p4 and p5 to network device 200 based on the RRC connection.

[0278] In some embodiments, a data delay transmission service may be running in the AP. Figure 7 The steps performed by the AP (e.g., steps S713, S714, S716, S721, S725, S726, and S729) shown can all be completed by a data delay transmission service. The data delay transmission service can be a service provided by the system of terminal 100. This application embodiment does not limit the name of the data delay transmission service.

[0279] As described above, the application processor of terminal 100 sets a time period for data transmission for the background service (e.g., the time period corresponding to timer 1, time period T11). If it is not within a time period for data transmission, the background service can retain data packets to be sent. If it is within a time period for data transmission, the background service can send the previously retained data packets to the AP in one go. Then, the AP can send the data packets from the background service to the modem, thereby sending them to network device 200 based on the RRC connection. In this way, when the background service intermittently generates data packets to be sent, terminal 100 does not need to be continuously in the RRC connected state. The above method can align the sending time of the background service data packets, realizing the integration of fragmented time segments without data transmission into continuous time segments without data transmission, reducing the need for the terminal to continuously transmit data with the network device. This can effectively increase the duration of terminal 100 in the RRC non-connected state and reduce the power consumption of terminal 100.

[0280] Figure 8 A flowchart of a data transmission method provided by an embodiment of this application is shown as an example.

[0281] S811: Obtain the data packet p11 that the foreground service needs to send, and send the data packet p11 to the network device 200 based on the RRC connection.

[0282] The AP in terminal 100 can acquire data packet p11 and send data packet p11 to the modem in terminal 100. The modem can then send data packet p11 to network device 200 based on the RRC connection.

[0283] S812, Based on the transmission of data packet p11, start timer 1.

[0284] In some embodiments, the AP may start timer 1 upon receiving data packet p11. Alternatively, the AP may start timer 1 after sending data packet p11 to the modem. Or, the AP may start timer 1 after the terminal 100 sends data packet p11 to the network device 200. That is, the timing at which the AP starts timer 1 may be related to the transmission time of data packet p11. This application embodiment does not specifically limit the timing of the AP starting timer 1.

[0285] Optionally, if the AP receives a data packet from the foreground service again before Timer 1 expires, the AP can restart Timer 1. See the previous section for details. Figure 5B Introduction.

[0286] S813. Before timer 1 expires, obtain the data packet p12 that the background service needs to send, and send the data packet p12 to network device 200 based on the RRC connection; after timer 1 expires, the background service stops sending data.

[0287] When Timer 1 expires, the AP can send a notification to the background service in Terminal 100 to stop sending non-low-latency data packets. Before receiving the notification to stop sending non-low-latency data packets (i.e., before Timer 1 expires), the background service in Terminal 100 can send the data packets to be sent to the AP. For example, the AP can receive data packet p12 from the background service. The AP can send data packet p12 to the modem, and then send data packet p12 to network device 200 based on the RRC connection. Data packet p12 can be referred to the above. Figure 5A Data packets 512, 513, 516, and 517 are shown.

[0288] The operations performed by the background service in terminal 100 after receiving the notification to stop sending non-low-latency data packets can be referred to the description in the foregoing embodiments. They will not be repeated here.

[0289] In some embodiments, the AP can send the timeout duration of Timer 1 to the background service in terminal 100 before Timer 1 expires. Based on the timeout duration of Timer 1, the background service in terminal 100 can stop sending non-low-latency data packets to the AP after Timer 1 expires. In this way, the AP does not need to send a notification to the background service in terminal 100 to stop sending non-low-latency data packets when Timer 1 expires.

[0290] S814: If there is no uplink or downlink data transmission within duration 1, release the resources of the local RRC connection.

[0291] The method for terminal 100 to release local RRC connection resources can be referred to the above. Figure 6 The method shown is described below.

[0292] The steps S815 to S817 described below can be three methods by which the AP determines that the background service can resume data transmission. These three methods are merely illustrative examples of this application and should not be construed as limiting the application. The AP may also use other methods to determine whether the background service can resume data transmission.

[0293] S815. Resume data transmission after the timer 1 expires for a period of 2, and determine the time period T21 for resuming data transmission.

[0294] The value of duration 2 and the duration of time period T21 can be preset. Among them, the time difference between the start time of time period T21 and the timeout time of timer 1 can be duration 2.

[0295] In some embodiments, the terminal 100 may preset multiple durations 2 with different values. The AP can determine the value of the duration 2 according to the corresponding conditions.

[0296] For example, terminal 100 can store durations 2a and 2b. Duration 2a is shorter than duration 2b. Duration 2a can be the duration corresponding to 7:00 to 22:00. Duration 2b can be the duration corresponding to 22:01 to 6:59 the next day. If the current time is between 7:00 and 22:00, the AP can resume data transmission after timer 1 expires for duration 2a. If the current time is between 22:01 and 6:59 the next day, the AP can resume data transmission after timer 1 expires for duration 2b. It is understandable that 22:01 to 6:59 the next day is usually the time when users sleep. The user will not be aware that terminal 100 delays sending background service data packets for a longer period. By extending the interval between two consecutive periods allowing background service to resume data transmission within the time period of 22:01 to 6:59 the next day, the AP can align the sending times of more data packets, increase the time terminal 100 is in RRC disconnected state, and thus reduce the power consumption of terminal 100.

[0297] For example, terminal 100 can store duration 2c and duration 2d. Duration 2c is shorter than duration 2d. Duration 2c can be the duration corresponding to terminal 100 being in a screen-on state. Duration 2d can be the duration corresponding to terminal 100 being in a screen-off state. If terminal 100 is in a screen-on state, the AP can resume data transmission after timer 1 expires for duration 2c. If terminal 100 is in a screen-off state, the AP can resume data transmission after timer 1 expires for duration 2d.

[0298] S816. Based on the tolerable period of network unuse reported by the backend service, determine the time period T22 for resuming data transmission.

[0299] In some embodiments, the background service may send the AP a tolerable period during which it does not use the network. The tolerable period during which the background service does not use the network can be referred to the foregoing. Figure 5A The introduction states that the AP of terminal 100 can determine the time period T22 based on the tolerable periods during which one or more background services do not use the network.

[0300] S817. After timer 1 expires, if it is detected that the foreground service needs to send data packet p13, data transmission is immediately resumed and timer 2 is started.

[0301] In some embodiments, after the AP instructs the background service to stop sending data, if the AP receives a data packet from the foreground service, the AP can immediately resume data transmission. For example, upon receiving data packet p13 from the foreground service, the AP can start timer 2 and notify the background service to resume sending data. Then, the background service can send previously reserved data packets to be sent, such as data packet p12 from step S813, to the AP. The AP in terminal 100 can send data packets from the foreground service and / or the background service to the modem. The start time of timer 2 can refer to the start time of timer 1 mentioned above. This application embodiment does not limit the start time of timer 2.

[0302] Data packet p13 can be referenced from the above. Figure 5A The data packet shown is 523.

[0303] The duration of Timer 2 can be the same as or different from that of Timer 1.

[0304] S818. When data transmission is restored, establish an RRC connection with network device 200.

[0305] If terminal 100 resumes data transmission based on data packet p13 from the foreground service in step S817, then after establishing an RRC connection with network device 200, terminal 100 can send data packet p13 to network device 200 based on the RRC connection.

[0306] It should be noted that it is optional for terminal 100 to establish an RRC connection with network device 200 when data transmission is restored.

[0307] If terminal 100 is in an RRC disconnected state before data transmission is restored, then terminal 100 can establish an RRC connection with network device 200 after data transmission is restored.

[0308] If terminal 100 is in RRC connection state before data transmission resumes, terminal 100 does not need to re-establish an RRC connection with network device 200. For example, within a time interval 1 following the most recent uplink or downlink data transmission between terminal 100 and network device 200, the AP of terminal 100 receives data packet p13 from the foreground service. Terminal 100 can remain in RRC connection state and restart the timer after sending data packet p13 to network device 200 to determine when to actively release the RRC connection.

[0309] S819. Within time period T21, or within time period T22, or before timer 2 expires, obtain the data packet p14 that the background service needs to send, and send the data packet p14 to network device 200 based on the RRC connection.

[0310] When data transmission resumes (i.e., at the start time of time period T21 or T22, or when timer 2 is started), the AP can send a notification of data transmission resumption to the background service in terminal 100. Upon receiving the notification, the background service can send data packets to the AP. These data packets may include those generated and cached by the background service before data transmission resumption. They may also include data packets generated by the background service after data transmission resumption.

[0311] For example, after data transmission is restored, the AP can receive data packet p14 from the background service. The AP can send data packet p14 to the modem, which in turn sends data packet p14 to network device 200 via the RRC connection. Data packet p14 can be referred to the aforementioned... Figure 5A Data packets 518, 519, and 521 are shown.

[0312] In some embodiments, the AP of terminal 100 can send the end time of data transmission recovery to the background service. If the time period T21 in step S815 is the data transmission recovery time period, then the end time of data transmission recovery can be the end time of time period T21. If the time period T22 in step S816 is the data transmission recovery time period, then the end time of data transmission recovery can be the end time of time period T2. If the time period corresponding to timer 2 in step S617 is the data transmission recovery time period, then the end time of data transmission recovery can be the timeout time of timer 2. The background service in terminal 100 can determine the data transmission strategy based on the end time of data transmission recovery.

[0313] S820. After time period T21 ends, or after time period T22 ends, or after timer 2 times out, the background service stops sending data.

[0314] When time period T21 ends, or time period T22 ends, or timer 2 times out, the AP can send a notification to the background service in terminal 100 to stop sending non-low-latency data packets. The operations performed by the background service in terminal 100 after receiving the notification to stop sending non-low-latency data packets can be referred to the description in the foregoing embodiments. They will not be repeated here.

[0315] As described above, terminal 100 can set a time period for data transmission for the background service (e.g., the time period corresponding to timer 1, time period T11). If it is not within a time period for data transmission, the background service can retain the data packets to be sent or stop generating data packets. If it is within a time period for data transmission, the background service can send the data packets to be sent to the AP. Then, the AP can send the data packets from the background service to the modem, thereby sending them to network device 200 based on the RRC connection. In this way, when the background service intermittently generates data packets to be sent, terminal 100 does not need to be continuously in the RRC connected state. The above method can align the sending time of the background service's data packets, integrating fragmented time segments without data transmission into continuous time segments without data transmission, reducing the need for the terminal to continuously transmit data with the network device. This can effectively increase the duration of terminal 100 in the RRC non-connected state and reduce the terminal's power consumption.

[0316] In some embodiments, the service running in terminal 100 can determine whether the uplink data packet to be sent is a low-latency data packet. For example, if the uplink data packet to be sent by the service is triggered by a user operation, then the uplink data packet is a low-latency data packet; otherwise, the uplink data packet is a non-low-latency data packet. As another example, if the service is a foreground service, then all uplink data packets of the service are low-latency data packets. If the service is a background service, then all uplink data packets of the service are non-low-latency data packets. Furthermore, if the service to which the uplink data packet belongs is a non-low-latency service, then the uplink data packet is a non-low-latency data packet. If the service to which the uplink data packet belongs is a low-latency service, then the uplink data packet is a low-latency data packet.

[0317] The AP of terminal 100 can determine the time period during which the service can send non-low-latency data packets (i.e., the time period during which non-low-latency data packets can be transmitted). When the time period during which the service can send non-low-latency data packets begins, the AP can notify the service running in terminal 100 to resume sending non-low-latency data packets. Upon receiving the notification to resume sending non-low-latency data packets, the service running in terminal 100 can begin sending non-low-latency data packets to the AP. When the time period during which the service can send non-low-latency data packets ends, the AP can notify the service running in terminal 100 to stop sending non-low-latency data packets. Upon receiving the notification to stop sending non-low-latency data packets, the service running in terminal 100 can stop sending non-low-latency data packets to the AP. However, upon receiving the notification to stop sending non-low-latency data packets, the service running in terminal 100 can buffer the non-low-latency data packets to be sent, waiting for the next resumption of data transmission before sending the buffered non-low-latency data packets to the AP.

[0318] Alternatively, the AP can send the end time of the period during which non-low-latency data packets can be sent to the service running in terminal 100. Based on the end time of this period, the service running in terminal 100 can stop sending non-low-latency data packets to the AP after the end of this period. In this way, the AP does not need to notify the service running in terminal 100 to stop sending non-low-latency data packets when the period ends.

[0319] In this way, the terminal 100 can align the transmission time of non-low latency data packets, reducing the situation where the RRC connection cannot be released for a long time due to the intermittent transmission of non-low latency data packets by the service running in the terminal 100, thereby reducing the power consumption of the terminal 100.

[0320] When terminal 100 is in RRC connection mode, terminal 100 can send one or more data packets of foreground services and / or background services to network device 200 based on the RRC connection.

[0321] In some embodiments, to reduce the power consumption of terminal 100, if terminal 100 is in CDRX sleep mode and the data packet to be sent is a non-low latency data packet, terminal 100 can cache the non-low latency data packet using L2 cache. After terminal 100 enters CDRX active mode, terminal 100 can send the aforementioned non-low latency data packet cached by L2 cache to network device 200.

[0322] Figure 9 A flowchart of a data transmission method provided by an embodiment of this application is shown as an example.

[0323] S911 and L2 received the uplink data packet.

[0324] In RRC connected state, the AP can send uplink packets from the application layer to the modem. The RRC layer in the modem can then send the uplink packets to the PDCP layer in L2.

[0325] Are S912 and Terminal 100 in the CDRX activation period?

[0326] S913, Immediately send uplink data packets.

[0327] If terminal 100 is in the CDRX active period, the PDCP layer can send the received uplink data packets to the network device through L1.

[0328] S914. Is the uplink data packet a low-latency data packet?

[0329] In some embodiments, the AP of terminal 100 can determine whether the service to which the uplink data packet belongs is a low-latency service. If the service to which the uplink data packet belongs is a low-latency service, the AP can instruct the modem to send the uplink data packet immediately, i.e., no further action is required. Figure 9 The steps S914 to S918 are shown. If the service to which the uplink data packet belongs is a non-low-latency service, the AP can instruct the modem to follow the instructions. Figure 9 The scheme shown determines when to send uplink data packets.

[0330] In some embodiments, uplink data packets sent by the AP to the modem may include latency indication information. The latency indication information of an uplink data packet can indicate whether the packet is a low-latency packet. For example, a latency indication of 1 indicates that the uplink data packet is a low-latency packet, while a latency indication of 0 indicates that the uplink data packet is not a low-latency packet. This application embodiment does not limit the value of the latency indication information described above. The PDCP layer can determine whether an uplink data packet is a low-latency packet based on the latency indication information in the uplink data packet.

[0331] The embodiments of this application do not limit the method for determining whether an uplink data packet is a low-latency data packet.

[0332] S915, immediately enter CDRX activation period and send uplink data packets.

[0333] If terminal 100 is in CDRX sleep mode and the uplink data packets received by the PDCP layer are low-latency data packets, then terminal 100 can immediately enter CDRX activation mode and send low-latency data packets to network device 200. Optionally, after entering CDRX activation mode, in addition to sending the aforementioned low-latency data packets to network device 200, terminal 100 can also read one or more data packets from the data packet buffer space and send them to network device 200. The data packet buffer space can be used to buffer non-low-latency data packets.

[0334] S916, is the data packet buffer space full?

[0335] If terminal 100 is in CDRX sleep mode and the uplink data packets received by the PDCP layer are not low-latency data packets, the PDCP layer can determine whether the data packet buffer space in terminal 100 is full. The aforementioned data packet buffer space can be used to buffer uplink data packets.

[0336] If the data packet buffer space is full, terminal 100 can execute the above step S915.

[0337] If the uplink data packet received in step S911 is a non-low-latency data packet and the data packet buffer space is full, then when the terminal 100 performs step S915, it can send the uplink data packet received in step S911 to the network device 200, and can also read one or more data packets from the data packet buffer space and send them to the network device 200; or, the terminal 100 can send one or more data packets read from the data packet buffer space to the network device 200, and store the uplink data packet received in step S911 in the data packet buffer space; or, the terminal 100 can send only the uplink data packet received in step S911.

[0338] If the data packet buffer space is not full, terminal 100 can execute the following step S917.

[0339] S917. Store the uplink data packets in the data packet buffer space.

[0340] If terminal 100 is in CDRX sleep mode and the uplink data packet received by the PDCP layer is a non-low latency data packet, the PDCP layer can store the non-low latency data packet in the data packet buffer space. Terminal 100 can remain in CDRX sleep mode continuously.

[0341] S918. When entering the CDRX activation period, send uplink data packets from the data packet buffer space to the network device.

[0342] In some embodiments, terminal 100 may enter the CDRX activation period according to a preset CDRX cycle. Alternatively, terminal 100 may enter the CDRX activation period when it is necessary to send low-latency data packets.

[0343] When the CDRX activation period begins, the PDCP layer can read uplink data packets from the packet buffer space and send the read uplink data packets to network device 200 via L1. The PDCP layer can also delete the read uplink data packets from the packet buffer space.

[0344] The PCDP layer can read uplink data packets in the order they are stored in the data packet buffer space. The earlier an uplink data packet is stored in the data packet buffer space, the earlier it can be read and sent to network device 200.

[0345] Alternatively, the PCDP layer can read uplink data packets according to the delay time for data packet transmission. The shorter the delay time for uplink data packets, the earlier the uplink data packet can be read and sent to network device 200. As described in the previous embodiments, the AP can receive tolerable periods of network inactivity sent by background services. The AP can determine the delay time for data packets of the background service based on these tolerable periods. Alternatively, terminal 100 can store the delay times for data packets of one or more services. The AP can determine the delay time for uplink data packets based on the service to which the uplink data packet belongs. The delay times for data packets of the aforementioned one or more services can be preset. This application embodiment does not limit the method for determining the delay time for uplink data packets. Uplink data packets sent by the AP to the modem may include delay time information. The delay time information of an uplink data packet can be used to indicate the delay time for that uplink data packet.

[0346] As can be seen from the above method, when a non-low-latency data packet from the application layer is obtained, the terminal 100 can cache the non-low-latency data packet during the CDRX sleep period, and then send the cached low-latency data packet to the network device 200 after the terminal 100 enters the CDRX active period. This allows the non-low-latency data packets to be aggregated and sent during the CDRX active period, thereby increasing the duration of the CDRX sleep period and reducing the power consumption of the terminal 100.

[0347] Figures 10A to 10C The illustration shows a schematic diagram of some data transmissions provided in the embodiments of this application.

[0348] In some embodiments, when terminal 100 is in CDRX sleep mode and uplink data packets are transmitted to the modem, terminal 100 can immediately enter CDRX active mode from CDRX sleep mode and send uplink data packets to network device 200.

[0349] like Figure 10A As shown, when entering the CDRX activation period of CDRX cycle 1, terminal 100 can start onDurationTimer. When onDurationTimer expires, terminal 100 can enter the CDRX sleep period from the CDRX activation period. During the CDRX sleep period of CDRX cycle 1, the AP of terminal 100 sends a non-low latency uplink data packet p21 to the modem. Upon receiving the non-low latency uplink data packet p21, the modem can activate devices such as the receiver in terminal 100. Terminal 100 is awakened and enters the CDRX activation period from the CDRX sleep period.

[0350] Similarly, after terminal 100 is woken up and enters the CDRX activation period, terminal 100 can start onDurationTimer.

[0351] Because it needs to send a non-low-latency uplink data packet p21, terminal 100 can send a scheduling request (SR) to network device 200. The SR can be used to request uplink authorization from network device 200. Once uplink authorization is granted, terminal 100 can send uplink data to network device 200. Terminal 100 can send uplink data via the physical uplink shared channel (PUSCH). The uplink data transmitted in the PUSCH can become a PUSCH frame. The PUSCH frame can include the aforementioned non-low-latency uplink data packet p21.

[0352] The non-low-latency uplink data packet p21 cannot be transmitted before the onDurationTimer expires. Therefore, terminal 100 can start the DRX-InactivityTimer to extend the CDRX activation period. When the non-low-latency uplink data packet p21 is transmitted, and there is no other uplink or downlink data transmission between terminal 100 and network device 200, and the DRX-InactivityTimer expires, terminal 100 can enter the CDRX sleep period from the CDRX activation period. That is to say, after the non-low-latency uplink data packet p21 is transmitted, terminal 100 still needs to wait for a period of time before entering the CDRX sleep period, and there is no uplink or downlink data transmission during this period.

[0353] In some embodiments, terminal 100 may enter the CDRX activation period of CDRX period 2 after CDRX period 1 ends, based on a preset duration of the CDRX period. Just before entering the CDRX activation period of CDRX period 2, the AP of terminal 100 sends a non-low latency uplink data packet p22 to the modem. The modem may then send the non-low latency uplink data packet p22 to network device 200 during the CDRX activation period of CDRX period 2.

[0354] Because a non-low-latency uplink data packet p22 needs to be sent, terminal 100 can send an SR to network device 200 after entering the CDRX activation period of CDRX cycle 2. Upon obtaining uplink authorization, terminal 100 can send the non-low-latency uplink data packet p22 to network device 200. The non-low-latency uplink data packet p22 cannot be transmitted before the onDurationTimer expires. Terminal 100 can start a DRX-InactivityTimer to extend the CDRX activation period. When the non-low-latency uplink data packet p22 is transmitted, and there is no other uplink or downlink data transmission between terminal 100 and network device 200, and the DRX-InactivityTimer expires, terminal 100 can enter the CDRX sleep period from the CDRX activation period.

[0355] Depend on Figure 10A It can be seen that during the period when it should have been in CDRX sleep mode, terminal 100 was forcibly woken up and entered CDRX active mode to send uplink data packets to network device 200 because it needed to send uplink data packets. The shortened CDRX sleep mode time of terminal 100 resulted in increased power consumption of terminal 100.

[0356] like Figure 10B As shown, when entering the CDRX activation period of CDRX cycle 1, terminal 100 can start onDurationTimer. When onDurationTimer expires, terminal 100 can enter the CDRX sleep period from the CDRX activation period. During the CDRX sleep period of CDRX cycle 1, the AP of terminal 100 sends non-low latency uplink data packet p21 to the modem. Since the non-low latency uplink data packet p21 is not sensitive to latency and is currently in the CDRX sleep period, the PDCP layer can buffer the non-low latency uplink data packet p21 and send it to network device 200 after terminal 100 enters the CDRX activation period. In this way, after entering the CDRX sleep period within CDRX cycle 1, terminal 100 can remain in the CDRX sleep period continuously. The CDRX sleep period can be uninterrupted by intermittently sent non-low latency data packets.

[0357] In some embodiments, terminal 100 may enter the CDRX activation period of CDRX period 2 after CDRX period 1 ends, based on a preset duration of the CDRX period. Just before entering the CDRX activation period of CDRX period 2, the AP of terminal 100 sends a non-low latency uplink data packet p22 to the modem. The modem may also send the non-low latency uplink data packet p22 to network device 200 during the CDRX activation period of CDRX period 2. Furthermore, the modem may also send one or more previously buffered data packets (e.g., non-low latency uplink data packet p21) to network device 200.

[0358] like Figure 10B As shown, since non-low-latency uplink data packets p21 and p22 need to be sent, terminal 100 can send an SR to network device 200 after entering the CDRX activation period of CDRX cycle 2. Upon obtaining uplink authorization, terminal 100 can send non-low-latency uplink data packets p21 and p22 to network device 200. That is, the PUSCH frame sent by terminal 100 may include non-low-latency uplink data packets p21, p22, and p22. However, non-low-latency uplink data packets p21 and p22 cannot be transmitted before the onDurationTimer expires. Terminal 100 can activate DRX-InactivityTimer to extend the CDRX activation period. When the above non-low latency uplink data packet p21 and non-low latency uplink data packet p22 are transmitted, and there is no other uplink or downlink data transmission between terminal 100 and network device 200, and the DRX-InactivityTimer times out, terminal 100 can enter the CDRX sleep period from the CDRX activation period.

[0359] Depend on Figure 10B It can be seen that when terminal 100 adopts the aforementioned Figure 9 The method shown performs data transmission in RRC connected state. Terminal 100 can aggregate non-low-latency data packets into the CDRX active period for transmission, thus avoiding interruptions to the CDRX sleep period by intermittently transmitted non-low-latency data packets to the modem. (Comparison) Figure 10A and Figure 10B It can be seen that, in Figure 10A In this scenario, terminal 100 sends non-low-latency uplink data packet p21 and non-low-latency uplink data packet p22 during two different CDRX activation periods. Terminal 100 needs to send SR twice. And... Figure 10BIn this process, terminal 100 aggregates non-low-latency uplink data packets p21 and p22 into the CDRX activation period of CDRX cycle 2 and sends them together. Terminal 100 only needs to send an SR to network device 200 once. After entering the CDRX activation period, terminal 100 typically needs to wait for a period of time without uplink or downlink transmission before re-entering the CDRX sleep period. Compared to Figure 10A , Figure 10B The data transmission process shown can increase the duration of the CDRX sleep period and reduce the power consumption of terminal 100.

[0360] In some embodiments, after the PDCP layer of terminal 100 caches non-low latency uplink data packets during the CDRX sleep period, it can send the cached non-low latency uplink data packets during the CDRX activation period after an interval of one or more DRX cycles. That is to say, after entering the CDRX activation period, terminal 100 does not need to send all the uplink data packets cached in the data packet cache space to network device 200 during the CDRX activation period.

[0361] like Figure 10C As shown, when entering the CDRX activation period of CDRX cycle 1, terminal 100 can start onDurationTimer. When onDurationTimer expires, terminal 100 can enter the CDRX sleep period from the CDRX activation period. During the CDRX sleep period of CDRX cycle 1, the AP of terminal 100 sends non-low latency uplink data packet p21 and non-low latency uplink data packet p22 to the modem sequentially. Since non-low latency uplink data packet p21 and non-low latency uplink data packet p22 are not sensitive to latency and are currently in the CDRX sleep period, the PDCP layer can buffer non-low latency uplink data packet p21 and non-low latency uplink data packet p22.

[0362] After one or more DRX cycles, terminal 100 enters the CDRX activation period of CDRX cycle k. Upon entering the CDRX activation period of CDRX cycle k, terminal 100 can start onDurationTimer. During the CDRX activation period of CDRX cycle k, terminal 100 can read non-low latency uplink data packets p21 and p22 from the packet buffer space and send them to network device 200. Because non-low latency uplink data packets p21 and p22 need to be sent, terminal 100 can send an SR to network device 200. Upon obtaining uplink authorization, terminal 100 can send a PUSCH frame to network device 200. The PUSCH frame may include non-low latency uplink data packets p21 and p22. Non-low latency uplink data packets p21 and p22 cannot be transmitted before onDurationTimer expires. Therefore, terminal 100 can start DRX-InactivityTimer to extend the CDRX activation period. When the transmission of non-low latency uplink data packet p21 and non-low latency uplink data packet p22 is completed, and there is no other uplink or downlink data transmission between terminal 100 and network device 200, and DRX-InactivityTimer times out, terminal 100 can enter the CDRX sleep period of CDRX cycle k.

[0363] It should be noted that during the aforementioned one or more DRX cycles, terminal 100 can remain in RRC connected state continuously, meaning that all of these one or more DRX cycles are CDRX cycles. Alternatively, during the aforementioned one or more DRX cycles, terminal 100 can undergo a process of switching from RRC connected state to RRC disconnected state, and then switching back from RRC disconnected state to RRC connected state; that is, these one or more DRX cycles can include CDRX cycles and the DRX cycles when terminal 100 is in RRC disconnected state.

[0364] In some embodiments, the time interval between CDRX period 1 and CDRX period k can be determined based on the time that non-low latency uplink data packet p21 and non-low latency uplink data packet p22 can be delayed in transmission. The longer the time that non-low latency uplink data packet p21 and non-low latency uplink data packet p22 can be delayed in transmission, the longer the time interval between CDRX period 1 and CDRX period k can be, that is, the more DRX periods can be spaced between CDRX period 1 and CDRX period k.

[0365] The time that can be delayed for non-low-latency uplink data packet p21 and non-low-latency uplink data packet p22 can be referred to the above. Figure 9 The following is an explanation of step S918.

[0366] Optionally, the timing of sending non-low-latency uplink data packets p21 and p22 can also be different. For example, the delay times for sending non-low-latency uplink data packets p21 and p22 can be different, and terminal 100 can send non-low-latency uplink data packets p21 and p22 during different CDRX activation periods. If the delay time for sending non-low-latency uplink data packets p22 is shorter than the delay time for sending non-low-latency uplink data packets p21, terminal 100 can send non-low-latency uplink data packets p22 to network device 200 during the CDRX activation period of CDRX period k, and send non-low-latency uplink data packets p21 to network device 200 during an activation period after the CDRX activation period of CDRX period k (e.g., the CDRX activation period of CDRX period k+2).

[0367] Depend on Figure 10C It can be seen that after the PDCP layer of terminal 100 buffers non-low-latency uplink data packets into the data packet buffer space, it does not need to immediately send the buffered data packets during the CDRX activation period of the next CDRX cycle. Terminal 100 can reasonably arrange the sending timing of data packets in the data packet buffer space according to factors such as the duration for which data packets can be delayed. This can better increase the duration of the CDRX sleep period and reduce the power consumption of terminal 100.

[0368] Figure 11 An exemplary flowchart of a method for data transfer during CDRX activation is shown.

[0369] S1111, Terminal 100 monitors PDCCH.

[0370] When CDRX is active, terminal 100 can monitor PDDCH to see if there are any messages from network device 200.

[0371] S1112, Network device 200 sends downlink data to terminal 100.

[0372] In some embodiments, when network device 200 needs to send downlink data, network device 200 first sends downlink control information to terminal 100 via PDCCH. The downlink control information can be used to indicate that network device 200 is about to send downlink data. Then, network device 200 sends the downlink data to terminal 100 via PDSCH.

[0373] S1113. Terminal 100 sends a scheduling request (SR) to network device 200.

[0374] When terminal 100 needs to send uplink data, terminal 100 can send an SR to network device 200 to request uplink authorization.

[0375] S1114. Network device 200 sends an uplink authorization message to terminal 100.

[0376] If network device 200 agrees to terminal 100 sending uplink data, network device 200 can send an uplink authorization message to terminal 100.

[0377] S1115, Terminal 100 sends a buffer status report (BSR) to network device 200.

[0378] Terminal 100 can send a buffer status report (BSR) to network device 200 based on the amount of uplink data to be sent. The BSR can be used to request a specified number of resource blocks (RBs) from network device 200. Network device 200 can determine the amount of data that terminal 100 needs to send based on the BSR, and thus allocate the corresponding number of RBs to terminal 100.

[0379] For example, in the aforementioned Figure 10A Within the CDRX cycle 1 shown, terminal 100 may send BSR1 to network device 200 before sending a PUSCH frame containing non-low-latency uplink data packet p21 to network device 200. BSR1 can be used to indicate the amount of data in the non-low-latency uplink data packet p21. (As described above...) Figure 10B Within the CDRX cycle 2 shown, terminal 100 may send BSR2 to network device 200 before sending a PUSCH frame containing non-low-latency uplink data packet p22 to network device 200. BSR2 can be used to indicate the amount of data in the non-low-latency uplink data packet p22. (As described above...) Figure 10B During CDRX cycle 2, as shown, terminal 100 may send BSR3 to network device 200 before sending a PUSCH frame containing non-low latency uplink data packet p21 and non-low latency uplink data packet p22. BSR3 can be used to indicate the amount of data in non-low latency uplink data packet p21 and non-low latency uplink data packet p22.

[0380] S1116. Network device 200 notifies terminal 100 to start sending data (UL Grant).

[0381] S1117. Terminal 100 sends uplink data to network device 200.

[0382] S1118, Network device 200 sends an acknowledgment message to terminal 100 confirming receipt of uplink data.

[0383] When receiving uplink data from terminal 100, network device 200 can send an acknowledgment message to terminal 100. This acknowledgment message can be transmitted via a physical hybrid ARQ indicator channel (PHICH). In some embodiments, if terminal 100 does not receive the acknowledgment message from network device 200 within a preset time period, terminal 100 can retransmit the uplink data to network device 200.

[0384] Figure 11 The method for transmitting data between terminal 100 and network device 200 during the CDRX activation period is merely an illustrative example of this application and should not be construed as limiting this application.

[0385] Figure 12 An exemplary schematic diagram of a terminal 100 provided in an embodiment of this application is shown.

[0386] like Figure 12 As shown, terminal 100 may include an application scenario decision module, a processing module, a storage module, an RRC management module, and a CDRX management module.

[0387] The application scenario decision module can be used to determine whether an uplink data packet to be sent is a low-latency data packet. Specifically, it can determine whether an uplink data packet is low-latency based on whether it was triggered by a user operation. If so, it is considered a low-latency data packet. The module can also determine whether an uplink data packet is low-latency based on whether the service it corresponds to is a foreground service. If it is, it is considered low-latency; if it is a background service, it is not. Finally, the module can determine whether the service to which the uplink data packet belongs is a low-latency service. If the service to which the packet belongs is not a low-latency service, it is considered a non-low-latency data packet.

[0388] The application scenario decision module can also be used to send to the processing module the tolerable period during which one or more background services in terminal 100 do not use the network. Alternatively, the application scenario decision module can send to the processing module the time during which non-low-latency data packets can be delayed.

[0389] The processing module can be used to determine the time period during which non-low-latency data packets can be transmitted. For example, when a low-latency data packet is received, the processing module can start a timer (refer to Timer 1 in the aforementioned embodiment). The time period corresponding to this timer can be the time period during which non-low-latency data packets can be transmitted. As another example, the processing module can determine the time period during which non-low-latency data packets can be transmitted based on the tolerable period during which the background service does not use the network. The method for determining the time period during which non-low-latency data packets can be transmitted can be referred to the aforementioned... Figure 8 The following is an introduction to steps S815 to S817.

[0390] The processing module can notify the service running in terminal 100 to resume sending non-low-latency data packets at the start of the transmission period when non-low-latency data packets can be transmitted. The processing module can also notify the service running in terminal 100 of the time when non-low-latency data packet transmission will stop. The service in terminal 100 can send the non-low-latency data packets to be sent to the processing module within the transmission period. When the transmission period ends, the processing module can notify the service running in terminal 100 to stop sending non-low-latency data packets. This aligns the transmission time of non-low-latency data packets, reducing the possibility of RRC connections remaining unreleased for extended periods due to intermittent transmission of non-low-latency data packets by the service running in terminal 100, thereby reducing the power consumption of terminal 100.

[0391] The processing module can also send uplink data packets from the services running in terminal 100 to the RRC management module, so that the RRC management module can send the uplink data packets to network device 200 based on the RRC connection.

[0392] The RRC management module can be used to control the RRC status of terminal 100, enabling terminal 100 to switch from RRC connected state to RRC disconnected state, or vice versa. Specifically, the RRC management module can detect whether there is any uplink or downlink data transmission between terminal 100 and network device 200 within a preset time period. If there is no uplink or downlink data transmission between terminal 100 and network device 200 within the preset time period, the RRC management module can actively release the RRC connection of terminal 100. The method for releasing the RRC connection can be referred to the aforementioned... Figure 6 The method shown is described below.

[0393] When in RRC disconnected state, the RRC management module can establish an RRC connection with the network device 200 after receiving uplink data packets from the processing module, and then send uplink data packets to the network device 200 through the RRC connection.

[0394] The CDRX management module can be used to control the CDRX status of terminal 100, enabling the terminal 100 to enter the CDRX sleep period or the CDRX active period when it is in the RRC connection state.

[0395] In some embodiments, after the CDRX management module controls the terminal 100 to enter the CDRX sleep period, the PDCP layer of the terminal 100 can buffer the received non-low-latency data packets to the storage module. This allows the CDRX management module to keep the terminal 100 in the CDRX sleep period without immediately waking it up to enter the CDRX active period when non-low-latency data packets are transmitted to the PDCP layer. When the CDRX management module controls the terminal 100 to enter the CDRX active period, the PDCP layer of the terminal 100 can read the non-low-latency data packets from the storage module and send them to the network device 200 based on the RRC connection. The terminal 100 can then delete the read non-low-latency data packets from the storage module. The method for the PDCP layer to read non-low-latency data packets from the storage module and send them to the network device 200 can be referred to the foregoing. Figure 9 , Figure 10B , Figure 10C Introduction.

[0396] Figure 12 The modules shown are merely illustrative examples of this application and should not be construed as limiting the scope of this application. Terminal 100 may include modules that are more advanced than those shown in the original text. Figure 12 Show more or fewer modules.

[0397] As can be seen, terminal 100 can extend the duration of the RRC disconnected state by setting the transmission time period for non-low-latency data packets and aligning the transmission times of these data packets. Furthermore, terminal 100 can aggregate non-low-latency data packets into the CDRX active period for transmission, thereby extending the CDRX sleep period. These extensions of the RRC disconnected state and CDRX sleep period reduce the power consumption of terminal 100 and increase its standby time.

[0398] Figure 13 A schematic diagram of a communication system 1300 provided in an embodiment of this application is shown as an example.

[0399] like Figure 13 As shown, the communication system 1300 may include a terminal 100 and a cloud server. The terminal 100 may include an application scenario decision module, a processing module, a storage module, an RRC management module, and a CDRX management module. The modules in the terminal 100 can be referenced... Figure 12 The introduction is omitted here.

[0400] In some embodiments, the cloud server may include a latency learning module. This latency learning model can determine the tolerable periods during which the service does not use the network based on big data learning. Optionally, the latency learning model can determine the time during which uplink data packets can be delayed based on big data learning. The terminal 100 can send information such as the service's running status (e.g., foreground or background operation), the service's associated business type, the tolerable periods during which the service does not use the network, and / or the time during which uplink data packets can be delayed to the cloud server. The cloud server can input the aforementioned information such as the service's running status, the service's associated business type, the tolerable periods during which the service does not use the network, and / or the time during which uplink data packets can be delayed into the latency learning model, and send the tolerable periods during which the service does not use the network and / or the time during which uplink data packets can be delayed determined by the learning model to the terminal 100. The terminal 100's processing module can determine the time period during which non-low-latency data packets can be transmitted based on the tolerable periods during which the service does not use the network and / or the time during which uplink data packets can be delayed determined by the learning model.

[0401] This application does not limit the method by which the cloud server determines the tolerable period of service not using the network and / or the time during which uplink data packets can be delayed based on big data learning.

[0402] The above method can more accurately determine the time period during which non-low latency data packets can be transmitted. This can effectively increase the duration of RRC disconnected state and CDRX sleep period without delaying the transmission of non-low latency data and avoiding the impact of delayed non-low latency data transmission on user experience, thereby better reducing the power consumption of terminal 100.

[0403] Figure 14 An exemplary schematic diagram of another terminal 100 provided in an embodiment of this application is shown.

[0404] like Figure 14 As shown, terminal 100 may include an application scenario decision module, a processing module, a storage module, an RRC management module, a CDRX management module, and a latency scenario learning module. The application scenario decision module, processing module, storage module, RRC management module, and CDRX management module can be referenced from the aforementioned... Figure 12 The introduction is omitted here.

[0405] In some embodiments, the latency scenario learning module may include a latency learning model. This latency learning model can determine the tolerable periods during which the service does not use the network based on big data learning. Optionally, the latency learning model can determine the acceptable delay time for uplink data packets based on big data learning.

[0406] The processing module can send information such as the service's running status (e.g., foreground or background operation), the associated business type, the tolerable period of network unuse reported by the service, and / or the allowable delay time for uplink data packet transmission to the latency scenario learning module. The latency scenario learning module can input this information into a latency learning model, thereby determining the tolerable period of network unuse and / or the allowable delay time for uplink data packet transmission. The latency scenario learning module then sends this determined information to the processing module. Finally, the processing module, based on this information, determines the time period during which non-low-latency data packets can be transmitted.

[0407] This application does not limit the method by which the latency scenario learning module determines the tolerable period of service not using the network and / or the time during which uplink data packets can be delayed based on big data learning.

[0408] The above method can more accurately determine the time period during which non-low latency data packets can be transmitted. This can effectively increase the duration of RRC disconnected state and CDRX sleep period without delaying the transmission of non-low latency data and avoiding the impact of delayed non-low latency data transmission on user experience, thereby better reducing the power consumption of terminal 100.

[0409] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the above-described method embodiments.

[0410] This application also provides a computer program product, including a computer program that, when run on a processor, can implement the steps in the various method embodiments described above.

[0411] This application also provides a chip system, which includes a processing circuit and an interface circuit. The interface circuit receives code instructions and transmits them to the processing circuit. The processing circuit executes the code instructions to enable the chip system to implement the steps of any method embodiment of this application. The chip system can be a single chip or a chip module composed of multiple chips.

[0412] It is understood that the user interfaces described in the embodiments of this application are merely example interfaces and do not constitute a limitation on the solution of this application. In other embodiments, the user interface may adopt different interface layouts, may include more or fewer controls, and may add or remove other functional options, as long as they are based on the same inventive concept provided in this application, they are all within the protection scope of this application.

[0413] It should be noted that, without causing contradictions or conflicts, any feature in any embodiment of this application, or any part of any feature, can be combined, and the combined technical solution is also within the scope of the embodiments of this application.

[0414] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A data transmission method, characterized in that, The method includes: The terminal starts the first timer; When the first timer expires, the terminal instructs the service running in the terminal to stop sending non-low latency data packets; The terminal determines a first time period, which is the time period after the first timer expires; The terminal sends a first set of data packets to the network device during the first time period. The first set of data packets includes one or more non-low latency data packets.

2. The method according to claim 1, characterized in that, The method further includes: The terminal sends a first data packet to the network device, the first data packet being a low-latency data packet; The terminal starts a first timer, specifically including: Based on the transmission of the first data packet, the terminal starts the first timer.

3. The method according to claim 1 or 2, characterized in that, The method further includes: If there is no data transmission between the terminal and the network device within a first time period, the terminal releases the Radio Resource Control (RRC) connection with the network device.

4. The method according to any one of claims 1-3, characterized in that, The terminal determines the first time period, specifically including: The terminal determines the first time period based on a first set of delay times, wherein the first set of delay times includes the time during which data packets of one or more services in the terminal can be delayed in being sent. Alternatively, the terminal determines the first time period based on the timeout of the first timer, wherein the time difference between the start time of the first time period and the timeout of the first timer is the second duration, and the duration of the first time period is the third duration. Alternatively, after the first timer expires, the terminal sends a second data packet to the network device. The second data packet is a low-latency data packet. Based on the sending of the second data packet, the terminal starts a second timer, wherein the first time period is the time period corresponding to the second timer.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: When the first time period ends, the terminal instructs the service running in the terminal to stop sending non-low latency data packets.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: The terminal starts a third timer; Before the third timer expires, the terminal sends a third data packet to the network device, the third data packet being a low-latency data packet; Based on the transmission of the third data packet, the terminal starts a fourth timer; When the fourth timer expires, the terminal instructs the service running in the terminal to stop sending non-low latency data packets; The terminal determines a second time period, which is the period after the fourth timer expires; The terminal sends a second set of data packets to the network device during the second time period. The second set of data packets includes one or more non-low latency data packets.

7. The method according to any one of claims 1-4, characterized in that, The method further includes: The terminal sends a fourth data packet to the network device within the first time period, and the fourth data packet is a low-latency data packet; Based on the transmission of the fourth data packet, the terminal starts the fifth timer; If the timeout of the fifth timer is later than the end time of the first time period, the terminal sends a third set of data packets to the network device before the fifth timer times out. The third set of data packets includes one or more non-low latency data packets.

8. The method according to any one of claims 1-7, characterized in that, The terminal is in an RRC disconnected state before the first time period; before the terminal sends the first set of data packets to the network device during the first time period, the method further includes: The terminal establishes an RRC connection with the network device.

9. The method according to any one of claims 1-8, characterized in that, The non-low latency data packets include one or more of the following: data packets generated by a background service, data packets generated by the service when not triggered by user operation, and data packets corresponding to services in the first service list, wherein the first service list includes one or more non-low latency services.

10. The method according to any one of claims 1-9, characterized in that, The terminal runs a first service and a data delay transmission service, wherein the first service is used to generate data packets to be transmitted to the network device; When the first timer expires, the terminal instructs the service running on the terminal to stop sending non-low-latency data packets, specifically including: When the first timer expires, the data delay transmission service notifies the first service to stop sending non-low latency data packets; The method further includes: When the first time period begins, the data delay transmission service notifies the first service to resume sending non-low latency data packets; When the first time period ends, the data delay transmission service notifies the first service to stop sending non-low latency data packets.

11. The method according to claim 10, characterized in that, The method further includes: The first service can delay the transmission of data packets in the fourth group of data packets to the data delay transmission service for a certain period of time. The fourth group of data packets includes non-low latency data packets that the first service is to send after the first timer expires.

12. The method according to claim 10 or 11, characterized in that, The first service is a background service.

13. The method according to any one of claims 1-12, characterized in that, The method further includes: The terminal acquires the fifth data packet during the sleep period of the discontinuous CDRX cycle in the first connection state. The fifth data packet is a non-low latency data packet. When the second CDRX cycle is activated, the terminal sends the fifth data packet to the network device, wherein the second CDRX cycle is the next CDRX cycle after the first CDRX cycle, or there is an interval of one or more discontinuous received DRX cycles between the second CDRX cycle and the first CDRX cycle.

14. The method according to claim 13, characterized in that, The method further includes: The terminal acquires the sixth data packet during the sleep period of the third CDRX cycle, and the sixth data packet is a low-latency data packet; The terminal enters the active period from the dormant period during the third CDRX cycle and sends the sixth data packet to the network device.

15. The method according to claim 13 or 14, characterized in that, The terminal includes a Packet Data Convergence Protocol (PDCP) layer. The terminal acquires the fifth data packet during the sleep period of the discontinuous CDRX cycle in the first connected state, specifically including: The PDCP layer receives the fifth data packet during the sleep period of the first CDRX cycle; Before the terminal sends the fifth data packet to the network device, the method further includes: The PDCP layer caches the fifth data packet in the first cache space.

16. The method according to claim 15, characterized in that, After entering the activation period of the second CDRX cycle, the method further includes: The PDCP layer reads one or more data packets from the first cache space in order of cache time from earliest to latest, and sends the read data packets to the network device; Alternatively, the PDCP layer may read one or more data packets from the first buffer space in ascending order of the data packet delay time, and send the read data packets to the network device.

17. The method according to claim 15 or 16, characterized in that, The method further includes: The terminal acquires the seventh data packet during the sleep period of the fourth CDRX cycle, and the seventh data packet is a non-low latency data packet; If the first cache space is exhausted, the terminal enters the active period from the sleep period during the fourth CDRX cycle and sends the seventh data packet to the network device, and / or sends one or more data packets read from the first cache space to the network device.

18. A terminal, characterized in that, The terminal includes a communication device, a memory, and a processor, wherein the communication device is used for the terminal to communicate with a network device; the memory is used to store a computer program; and the processor executes the computer program to implement the method of any one of claims 1-17.

19. A computationally readable storage medium storing instructions, characterized in that, When the instructions are executed by the processor, they implement the method of any one of claims 1-17.

20. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the method of any one of claims 1-17.

Images