WO2021180134A1 - Method for determining discontinuous reception (drx) parameter - Google Patents

Abstract

Provided in the present invention are a method for determining a DRX parameter and an electronic terminal. The electronic terminal determines a traffic transmission type on the basis of a traffic feature, determines candidate DRX parameters on the basis of the traffic transmission type, submits the candidate DRX parameters to a network device, and receives a determined DRX parameter from the network device. The present invention allows the determination of a fine-grained DRX parameter on the basis of different traffic transmission types or traffic transmission types of different applications or similar traffic features, thus increasing the power-saving effect of a terminal device.

Description

A Method for Determining Discontinuous Receiving DRX Parameters

This application claims the priority of a Chinese patent application filed with the State Intellectual Property Office of China with an application number of 202010169429.9 on March 12, 2020, and the priority of a Chinese patent application whose invention title is "A method for determining DRX parameters for discontinuous reception" , Its entire content is incorporated into this application by reference.

Technical field

This application relates to the field of mobile communications, and in particular to a method for determining Discontinuous Reception (DRX) parameters.

Background technique

The 5G communication network has large bandwidth and high power consumption requirements. The power consumption of the UE has become a key factor restricting the development of 5G ecology. Therefore, it is an important topic in 5G research to adopt a reasonable communication transmission method based on the actual needs of the business, and to reduce the power consumption of the UE without affecting the user experience.

Since the base station processes multiple terminal device resource scheduling requests at the same time, the burden is heavy. The current 5G standard has allowed the base station to adjust the communication parameters in conjunction with the auxiliary information reported by the end-side device to achieve the purpose of reducing power consumption of the UE. Although the adjustment of the DRX parameters of the UE by the base station can reduce the power consumption of the UE to a certain extent, the adjustment granularity of the DRX parameters of the UE by the base station is relatively coarse, and for the UE side, there is still room for further reduction in power consumption.

Summary of the invention

The purpose of the present invention is to provide a method and electronic device for determining DRX parameters, which can determine more fine-grained DRX parameters and improve the power saving effect of terminal equipment.

The above objectives and other objectives will be achieved through the features in the independent claims. Further implementations are embodied in the dependent claims, description and drawings.

In a first aspect, a method for determining DRX parameters is provided. The method includes: obtaining data stream characteristics; determining a data stream transmission type according to the data stream characteristics; determining candidate DRX parameters according to the data stream transmission type; sending the candidate DRX parameters to a network device ; Receive first information from the network device, where the first information indicates the determined DRX parameter; use the determined DRX parameter for data transmission.

The above-mentioned data flow may also be referred to as flow. The technical solution described in the first aspect can enable the electronic device to determine more fine-grained DRX parameters and improve the power saving effect.

According to the first aspect, in another possible implementation manner, the foregoing data streams are data streams of the same service type.

Through the foregoing implementation manner, the electronic device can determine more fine-grained DRX parameters according to different traffic transmission types of the same service type, thereby improving the power saving effect.

According to the first aspect, in another possible implementation manner, the above-mentioned data stream is a data stream of the same application.

Through the above implementation, the electronic device can determine more fine-grained DRX parameters according to the traffic transmission types of different applications, and improve the power saving effect.

According to the first aspect, in another possible implementation manner, the above-mentioned application is a foreground application.

Through the foregoing implementation manner, the electronic device can reduce the impact on the user experience while improving the power saving effect.

According to the first aspect, in another possible implementation manner, it further includes acquiring data stream characteristics and user operation events, and determining the data stream transmission type according to the data stream characteristics and/or user operation events.

Through the foregoing implementation manner, the electronic device can more accurately determine the data stream transmission type.

According to the first aspect, in another possible implementation manner, the data stream is a first-category data stream, where the first-category data stream is that the amount of data transmitted from the first moment to the second moment is greater than the first data amount threshold The data stream; where the first moment is the moment when the data transmission speed increases from equal to 0 to not equal to 0 or from less than the first speed threshold to equal or greater than the first speed threshold; the second moment is after the first moment The time when the data transmission speed for the first time drops to 0 or less than the first speed threshold, and the data transmission speed is 0 or less than the first speed threshold for the first continuous period from the second time.

Through the foregoing implementation manner, the electronic device can obtain the sampling sample more accurately.

According to the first aspect, in another possible implementation manner, the foregoing data stream characteristics include a time interval average value, a time interval variance, a data stream average value, and a data stream variance.

Through the foregoing implementation manner, the electronic device can acquire the characteristics of the sampled sample more accurately.

According to the first aspect, in another possible implementation manner, the data stream transmission type is determined according to the data stream characteristics and the first model; the candidate DRX parameter is determined according to the data stream transmission type and the first mapping table.

The foregoing first model may be a data stream transmission model, and the foregoing first mapping table may be a DRX parameter mapping table. Through the above implementation, the electronic device can respectively determine the data stream transmission type and candidate DRX parameters according to the corresponding model and mapping table.

According to the first aspect, in another possible implementation manner, the above-mentioned first model and the first mapping table are obtained from the second device.

Through the above implementation, the electronic device can obtain the ability to determine fine-grained DRX parameters from other devices.

According to the first aspect, in another possible implementation manner, the candidate DRX parameters are determined according to the data stream transmission type, operator information, and the first mapping table.

Through the foregoing implementation manner, the electronic device can further determine candidate DRX parameters according to different operators.

According to the first aspect, in another possible implementation manner, the candidate DRX parameter and the determined DRX parameter are the same or different.

Through the foregoing implementation manner, the electronic device can report the DRX parameter supported by the network device, or can report the DRX parameter not supported by the network device, which can be adjusted by the network device.

According to the first aspect, in another possible implementation manner, the candidate DRX parameter and the determined DRX parameter are one or more of the three parameters OnDuration, InactivityTimer, and DRXCycle.

Through the foregoing implementation manner, the electronic device can adjust all or part of the DRX parameters.

According to the first aspect, in another possible implementation manner, the candidate DRX parameter is reported to the network device when the data stream transmission type changes.

Through the foregoing implementation manner, the electronic device can reduce signaling transmission with the network device.

According to the first aspect, in another possible implementation manner, before sending the candidate DRX parameter to the network device, it further includes: performing data conversion on the candidate DRX parameter, and sending the data-converted DRX parameter to the network device.

Through the foregoing implementation manner, the electronic device can make the reported parameters meet the requirements of the network device.

According to the first aspect, in another possible implementation manner, the above-mentioned data stream is a continuous similar data stream of the first category.

Through the foregoing implementation manner, the electronic device can accurately count the characteristics of the data stream.

According to the first aspect, in another possible implementation manner, when the data stream characteristic exceeds the first threshold, it is determined that the data stream transmission type is the first type.

Through the foregoing implementation manner, the electronic device can determine the data stream transmission type through calculation.

According to the first aspect, in another possible implementation manner, candidate DRX parameters are determined according to data stream characteristics.

Through the foregoing implementation manner, the electronic device can determine the candidate DRX parameter through calculation.

In a second aspect, another method for determining DRX parameters is provided, which includes: receiving first information reported by an application program, the first information including application delay requirements; determining candidate DRX parameters according to the delay requirements; The parameter is sent to the network device; the determined DRX parameter is received from the network device; the determined DRX parameter is used for data transmission.

The technical solution described in the second aspect can enable the electronic device to determine more fine-grained DRX parameters and improve the power saving effect.

According to the second aspect, in a possible implementation manner, the DRX parameters are determined according to the delay requirement and the second model.

The above-mentioned second model may be a DRX parameter delay model. Through the foregoing implementation manner, the electronic device can determine more fine-grained DRX parameters and improve the power saving effect.

According to the second aspect, in another possible implementation manner, the above-mentioned second model is obtained from a second device.

Through the above implementation, the electronic device can obtain the ability to determine fine-grained DRX parameters from other devices.

According to the second aspect, in another possible implementation manner, the foregoing receiving the first information reported by the application further includes: receiving the first information reported by the application when the application is started.

Through the above implementation, the electronic device can obtain the application delay requirement in time.

In a third aspect, there is also provided an electronic device, including one or more processors; a memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to The one or more processors execute, and the one or more programs include instructions for executing any possible implementation manner in the first aspect or any possible implementation manner in the second aspect .

In a fourth aspect, there is also provided a computer-readable medium for storing one or more programs, wherein the one or more programs are configured to be executed by the one or more processors, and the one or more Each program includes instructions for executing any possible implementation manner in the first aspect or any possible implementation manner in the second aspect.

It should be understood that the description of technical features, technical solutions, advantages or similar language in the specification does not imply that all the features and advantages can be realized in any single embodiment. On the contrary, it can be understood that the description of features or advantages means that a specific technical feature, technical solution, or advantage is included in at least one embodiment. Therefore, the description of technical features, technical solutions, or advantages in this specification does not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and advantages described in the following embodiments can also be combined in any appropriate manner. Those skilled in the art will understand that the embodiments can be implemented without one or more specific technical features, technical solutions, or advantages of the specific embodiments. In other embodiments, additional technical features and advantages may also be identified in specific embodiments that do not embody all the embodiments.

Description of the drawings

In order to more clearly describe the technical solutions in the embodiments of the present application, the following will describe the drawings that need to be used in the embodiments of the present application.

Figure 1 is a schematic diagram of DRX principle;

FIG. 2 is a schematic diagram of different states of an on-demand service type at different times according to an embodiment of the application;

FIG. 3 is a schematic diagram of the architecture of a communication system provided by an embodiment of the application;

4 is a schematic structural diagram of an electronic device provided by an embodiment of this application;

FIG. 5 is a schematic flowchart of a method for determining DRX parameters according to an embodiment of the application;

FIG. 6 is a schematic diagram of a process for determining DRX parameters according to an embodiment of the application;

FIG. 7 is a schematic diagram of the first type of traffic provided by an embodiment of this application;

FIG. 8 is a system framework diagram for determining DRX parameters provided by an embodiment of the application;

FIG. 9 is a schematic diagram of different states of different applications of the same service type according to an embodiment of the application;

FIG. 10 is a schematic flowchart of another method for determining DRX parameters provided by an embodiment of this application;

FIG. 11 is a schematic flowchart of another method for determining DRX parameters provided by an embodiment of this application;

FIG. 12 is another principle diagram for determining DRX parameters provided by an embodiment of this application;

FIG. 13 is a schematic flowchart of another method for determining DRX parameters provided by an embodiment of the application.

Detailed ways

In order to make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in further detail below in conjunction with the accompanying drawings.

As used in this application, the terms "component", "module", "system", etc. are intended to refer to a computer-related entity, which can be hardware, firmware, a combination of hardware and software, software, or running software. software. For example, a component may be, but is not limited to: a process running on a processor, a processor, an object, an executable file, an executing thread, a program, and/or a computer. As an example, both an application running on a computing device and the computing device may be components. One or more components may exist in an executing process and/or thread, and the components may be located in one computer and/or distributed between two or more computers. In addition, these components can execute from various computer-readable media having various data structures thereon. These components can be based on, for example, having one or more data packets (for example, data from a component that interacts with another component in a local system, a distributed system, and/or via signals such as the Internet). The network interacts with other systems) signals to communicate in a local and/or remote process.

The implementation of the DRX mechanism in the idle state and the connected state is different. After the electronic device completes camping in a certain cell, the electronic device enters the idle state, and when the electronic device completes the random access process, the electronic device enters the connected state. The embodiments of this application mainly focus on the DRX mechanism in the connected state, namely Connected DRX (CDRX). The DRX mentioned in the embodiments of this application are all CDRX. Fig. 1 exemplarily shows the principle of DRX. As shown in Figure 1, when the electronic device receives traffic, it is in the Active state. When the electronic device is in the Active state for a period of time (the duration is InactivityTimer) without receiving traffic, the state of the electronic device is changed from Active Change to DRX Cycle state. In the DRX Cycle state, the electronic device periodically enters the sleep state (DRX Sleep), and does not monitor the PDCCH subframes in the sleep state to achieve the purpose of power saving. In addition, the electronic device periodically wakes up from the sleep state (DRX Sleep) and enters a short Active state (OnDuration time period). If data scheduling is monitored during the OnDuration time period, the electronic device changes from the DRX Cycle state to Active State, and the electronic device starts the InactivityTimer, and starts timing when there is no data transmission. When the InactivityTimer times out, that is, within the specified time range, no data transmission is monitored, and the electronic device enters the DRX Cycle state again; if no data transmission is monitored during the OnDuration time period, the electronic device enters the DRX Sleep state after this state.

Therefore, DRX Cycle mainly includes the following two states: OnDuration, where the electronic device is active during this time period and monitors PDCCH subframes, which has high power consumption; DRX Sleep, where the electronic device is in a sleep state during this time period and does not monitor PDCCH subframes. Frame, low power consumption.

LTE allows eNodeB to set different DRX parameters for different QCI service types. For example, for common service types, such as on-demand, live broadcast, audio call, or game services, they have different requirements for delay. Therefore, different DRX parameters can be set for their service types to save power consumption. . For example, the on-demand service has low requirements for delay, and it can set a longer time DRX parameter, such as DRXCycle=160ms, while the game has higher requirements for time delay, it can set a shorter time DRX parameter, its DRXCycle value No more than 100ms.

However, in the same service type, it has different traffic transmission types in different time periods. For example, taking the type of on-demand service as an example, as shown in Figure 2, the traffic transmission mode has different characteristics at least in the two stages of 0-T1 and T1-T2. In the 0-T1 stage, the video has just started to play, and the terminal has been downloading the video content and is in the buffering state. In this stage, the amount of data downloads of the electronic device 100 gradually increases over time, and the growth mode can be linear growth as shown in FIG. 1 or other non-linear growth methods. Because it has been downloading. In some other embodiments, the user can make the electronic device enter the download state by clicking or sliding on the screen. Taking the on-demand service as an example, the user clicks on a time node on the time axis in the video, and starts watching the video from the time node. Based on the click operation, the electronic device starts to download the subsequent data from the corresponding time node and starts to play. At this time, the electronic device has been downloading video content.

In the T1-T2 stage, the download volume of the video has exceeded the content currently being played. For example, the remaining cache can support watching the video for more than tens of seconds. At this stage, as shown in Figure 2, the electronic device does not need to be kept in the state of downloading data at high speed as in the previous stage, but can enter the state of downloading data periodically. As shown in Figure 2, in the t1-t2 stage, the electronic device does not download data, and in the t2-t3 stage, the electronic device downloads data. It can be seen that in the on-demand service type, the terminal presents different states in the two stages of time 0-T1 and T1-T2. Therefore, under the same service type, in different traffic transmission types, electronic devices can be configured to use different DRX parameters for data transmission. It is understandable that the duration of the electronic device not downloading data in each cycle may be the same or different; the duration of downloading data in each cycle may be the same or different. This embodiment does not make any limitation on this.

Fig. 3 exemplarily shows a communication system architecture provided by an embodiment of the present invention. As shown in FIG. 3, the communication system 10 includes an electronic device 100 and a network device 101. The electronic device 100 determines the candidate DRX parameter according to the current traffic transmission type, and reports the candidate DRX parameter to the network device 101. The network device 101 determines the DRX parameter to be used based on the candidate DRX parameter reported by the electronic device 100, and the determined DRX parameter The DRX parameters are sent to the electronic device 100. The network device 101 and the electronic device 100 perform data transmission according to the new DRX parameter.

Through the above-mentioned communication system, electronic devices can fine-grain DRX parameters according to their own business conditions, which more effectively reduces the power consumption of electronic devices; and in this system, network devices do not need to determine DRX parameters based on the content reported by electronic devices , Simplified signaling content reduces the burden on network equipment.

Among them, the electronic device 100 and the network device 101 can use Global System of Mobile Communications (GSM), Code Division Multiple Access (CDMA), and Wideband Code Division Multiple Access (WCDMA). ) Or long-term evolution (Long Term Evolution, LTE) network for wireless communication, or wireless communication through 5G network or next-generation network. The network device 101 may be a base station in the above-mentioned network, such as an evolved base station (eNodeB) or communication equipment such as a macro base station, a micro base station, a pico base station, and a home base station. It may also be an access point, a relay station, or a vehicle capable of providing network access. Network side equipment such as equipment. The electronic device 100 may be a portable electronic device, such as a mobile phone, a tablet computer, a laptop computer (Laptop), a wearable electronic device (such as a smart watch), etc., or other types of electronic devices, such as a vehicle-mounted device.

FIG. 4 exemplarily shows a schematic structural diagram of the electronic device 100.

The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, and an antenna 2. , Mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, earphone jack 170D, sensor module 180, buttons 190, motor 191, indicator 192, camera 193, display screen 194, and Subscriber identification module (subscriber identification module, SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, and ambient light Sensor 180L, bone conduction sensor 180M, etc.

It can be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than those shown in the figure, or combine certain components, or split certain components, or arrange different components. The illustrated components can be implemented in hardware, software, or a combination of software and hardware.

The embodiment of the present invention provides a method for an electronic device to determine DRX parameters according to a service type and a traffic transmission type. As shown in FIG. 5 and FIG. 6, the method includes the following steps:

S201: The electronic device 100 obtains traffic characteristics. The above-mentioned traffic is the traffic transmitted between the electronic device 100 and the network device 101. The electronic device 100 generally has multiple applications running at the same time during the running process, which can be divided into a foreground application and a background application. For example, multiple applications such as Tencent Video, WeChat, and Weibo are running on the mobile phone. When a user is watching a video using Tencent Video, the application is the foreground application, and WeChat and Weibo are the background applications. Among them, the traffic generated by the foreground application is the foreground traffic, and the traffic generated by the background application is the background traffic. Since background traffic generally has no impact on user experience, its requirements for latency are usually not high. The foreground application can interact with the user, so the transmission of its traffic affects the user experience. Therefore, in some embodiments, the electronic device 100 can obtain characteristic data corresponding to the traffic of the foreground application. In some other embodiments, the traffic may also be foreground traffic and specific types of background traffic or all traffic.

The electronic device 100 and the network device 101 transmit data in the form of data packets. Each data packet contains the time stamp, quintuple, data packet size and other parameters as shown in Table 1. Among them, the five-tuple is composed of source IP address, source port, destination IP address, destination port, and transmission protocol. In addition, the data packet may also include application information (such as application code), operator information, and other information.

Table 1

In some embodiments, the electronic device 100 may make statistics of the characteristics of the first type of traffic based on the parameters of the above-mentioned data packets.

As shown in Figure 7, the above-mentioned first type of traffic refers to: if the time when the traffic starts to be transmitted is t ₁ , when there is no data transmission for the duration of continuous T _x during the traffic transmission, or the data transmission speed is less than the threshold S, then It is considered that this traffic transmission is over. _{Record the time t 2} when the traffic transmission ends. If _{the traffic H transmitted during the time period of T b} =t ₂ -T _x -t ₁ is greater than the threshold H1, then the current traffic is considered to be the first-category traffic, and H is the size of the current first-category traffic. Among them, T _x , S and H1 are all preset parameters. In some embodiments, the above-mentioned parameters may be configured differently for different service types. For example, for a video-on-demand service, the amount of data transmitted is larger, and the value of H1 can be set to be larger, while for text browsing services, the amount of data transmitted is smaller, and the value of H1 can be set to be smaller.

At the end of each flow of the first category, a sampling sample is constructed for the flow of the first category. The electronic device 100 counts the time interval between each first-category traffic sampling sample, and calculates the _{average of the time interval between each first-category traffic sampling sample within a certain time period T s} , the time interval variance, and the value of the first-category traffic sampling sample Average flow and variance of flow, etc. Wherein T _s is a preset value, for example, T _s can be set to 30s, 60s, or 90s.

In some other embodiments, the electronic device 100 may construct a sampling sample within a fixed time window, and calculate the traffic characteristics according to the parameters of the data packet. For example, the electronic device 100 may construct a sampling sample every 1 second. Identify the first type of traffic from the collection of collected data packets, and count the characteristics of it, such as the first type of traffic time interval average, time interval variance, the average flow of the first category traffic, and the variance of the traffic.

In some other embodiments, the electronic device 100 may also count user operation events, such as user click events and/or user sliding events. In some embodiments, the electronic device 100 can count _{the characteristics of user operation events within a certain period of time T s} , such as the number of click events generated, the average time interval of click events, and/or the variance of the time interval of click events.

S202: The electronic device 100 determines the service type corresponding to the traffic.

Specifically, the electronic device 100 can identify the current service type according to technologies such as Deep Packet Inspection (DPI) or Deep Flow Inspection (DFI). Among them, the DPI technology mainly recognizes the service type by analyzing application layer messages, and the DFI technology mainly recognizes the service type based on the header information of the IP layer or the transport layer.

In some other embodiments, the electronic device 100 may determine the current service type based on the service recognition model. In some embodiments, the service identification model may be based on DPI or DFI technology to establish a mapping relationship between identification parameters (such as application layer packets or IP layer or transport layer header information) and service types. The service recognition model may be pre-stored in the electronic device 100, or may be obtained from the second device 102. Wherein, the second device 102 may be a server or a second electronic device. The electronic device 100 and the second device 102 may communicate through mobile communication networks such as LTE and 5G, or may communicate through wireless communication networks such as WiFi. In some other embodiments, the electronic device 100 and the second device 102 may communicate with each other through a short-range wireless communication technology such as Bluetooth.

Next, the electronic device 100 may perform step S203 or step S204.

S203: Determine whether there are multiple traffic transmission types for the service type. If the service type has multiple transmission modes, step S204 is executed; if the service type has only one traffic transmission type, then jump to step S205.

Specifically, the electronic device 100 can determine whether there are multiple traffic transmission types for the service type by querying the DRX parameter mapping table. The DRX parameter mapping table includes a mapping relationship between service types and traffic transmission types, where one service type can correspond to one traffic transmission type, and can also correspond to multiple traffic transmission types. The DRX parameter mapping table may be pre-stored in the electronic device 100, or may be obtained from the second device 102.

In some other embodiments, if the electronic device 100 does not find the corresponding service type in the DRX parameter mapping table, the electronic device 100 may not report the DRX parameter, or may report the default DRX parameter.

S204: Determine the current traffic transmission type. Specifically, the current traffic transmission type can be determined according to the traffic transmission model. The traffic transmission model may be stored in the electronic device 100 in advance, and it may be obtained by the electronic device 100 from the second device 102. The second device 102 may be a server or other electronic devices.

In some other embodiments, the electronic device 100 may perform step S204 after performing step S201,

In some embodiments, as shown in FIG. 8, the second device 102 may establish a traffic transmission model through the following methods:

S2041: Generate test data. The server simulates or collects various traffic data from the network, and records the timestamp, packet size, source IP address, destination IP address and other information of each data packet, as shown in Table 1. In some embodiments, since different operators may adopt different traffic transmission types for the same service type, when collecting traffic data, the operator information of the data packet can be counted. In some other embodiments, the traffic data simulated by the server or collected from the network can be classified by service type.

S2042: Calculate traffic characteristics according to the collected data. Specifically, the manner of counting traffic characteristics can refer to the manner of counting traffic characteristics in step S201. In some embodiments, the manner in which the server counts traffic characteristics may be consistent with the manner in which the electronic device 100 counts traffic characteristics, so as to ensure that the sampling samples generated by the electronic device 100 statistics can be applied to the traffic transmission model. In some other embodiments, the server may also generate a corresponding traffic transmission model for each method of counting traffic characteristics for the electronic device 100 to use.

S2043: Mark the traffic transmission type according to the traffic characteristics.

Specifically, according to the traffic characteristics counted in step S2042, they are statistically classified, and the traffic transmission types F ₁ -F _{N are obtained} . In some other embodiments, the above-mentioned traffic characteristics are traffic characteristics of the same service type. Among them, one type of service can correspond to one type of traffic transmission, and can also correspond to multiple types of traffic transmission. For example, for an on-demand service, the first type of traffic can be classified into two types of traffic transmission: "first type" and "second type". Each piece of sample data obtained in step S2042 is annotated with a traffic transmission type to form training sample data, as shown in Table 2.

Table 2

S2044: Based on the training sample data, use a training algorithm to obtain a traffic transmission model. The flow transmission model is used to determine the type of flow transmission based on the characteristics of the flow. The training algorithm can choose learning algorithms such as random forest and decision tree.

The electronic device 100 inputs the sampling samples obtained by statistics in step S201 into the traffic transmission model, and obtains the traffic transmission type corresponding to the sampling samples. In some other embodiments, the electronic device 100 determines in step S203 that the service type of the traffic has multiple traffic transmission types, then counts traffic characteristics and/or user operation events, obtains sample samples, and inputs the sample samples into the traffic transmission model Determine its corresponding traffic transmission type.

In some other embodiments, the electronic device 100 may determine the traffic transmission type of the current service type based on the user's operation events counted in step S201. For example, in the video-on-demand service type, when a user's click or slide operation is detected or the number of user's click or slide operation exceeds a certain threshold, the electronic device 100 may determine the current traffic transmission type as the "second type" ". In some other embodiments, the electronic device may determine the traffic transmission type of the current service type based on the user's operation time and data transmission status counted in step S201. Still taking the type of video-on-demand service as an example, when the traffic transmission type is judged to be the first type based on the current traffic characteristics, if a user's click or swipe operation is detected, the electronic device compares the user's click or swipe video playback position with the current one. The amount of buffered video data. If the amount of currently buffered video data can still support playing for tens of seconds from the above-mentioned playback position, then the traffic transmission type is determined as the first type.

In some other embodiments, if the electronic device 100 cannot determine the corresponding traffic transmission type according to the traffic transmission model, the electronic device 100 may not report the DRX parameter, or may report the default DRX parameter.

S205: The electronic device 100 determines the reported DRX parameter. Specifically, the electronic device 100 may determine the reported DRX parameter according to the DRX parameter mapping table.

The DRX parameter mapping table is used to determine the DRX parameters according to the service type and/or traffic transmission type. The DRX parameter mapping table may be stored in the electronic device 100 in advance, and it may be obtained by the electronic device 100 from the second device 102. The second device 102 may be a server or other electronic devices.

In some embodiments, the second device 102 may establish the DRX parameter mapping table by the following method:

S2051: Based on the training sample data obtained in step S2043, configure different DRX parameters for the sample data of each traffic transmission type, and simulate the electronic device to run the service. For each sample data, calculate the proportion of time that the electronic device is in the active state, and mark Business experience (Quality of Experience, QoE). In some other embodiments, based on the training sample data, the sample data of each traffic transmission type of the same service type is configured with different DRX parameters for simulation and labeling.

Among them, after configuring the DRX parameters, as shown in FIG. 1, the electronic device will periodically enter the power saving state, and periodically enter the short monitoring state to determine whether to activate the electronic device. The proportion of the time that the electronic device is in the active state is the proportion of the time that the electronic device is in the active state within the duration of the sample data. The lower the proportion of the electronic device in the active state, the lower the power consumption value of the electronic device, and the higher its power consumption gain. QoE is the user experience during the operation of the service type. Taking the on-demand service as an example, as shown in Figure 2, the on-demand service will periodically enter the state of downloading data in the first type of state. However, if the period of the configured DRX parameter is too long, the downloaded data may not be enough to support the playback progress, resulting in a stuck phenomenon. Therefore, the QoE can be determined by counting the number and/or duration of the freeze. In some other embodiments, QoE may also include factors such as packet loss and delay. QoE can be classified as E ₁ -E _M according to different degrees. For example, QoE can be marked as "good" or "bad" according to business experience. In some other embodiments, QoE has more categories. In some other embodiments, QoE is a comprehensive service experience during the entire video playback process. In the data statistics process, the server records data such as service type, traffic transmission type, configured DRX parameters, marked QoE, and active ratio, as shown in Table 3.

table 3

business type	Traffic transmission type	DRX parameters	QoE	Active ratio
S1	F1	D.1	E1	25%
S1	F1	D.2	E2	50%
S1	F1	D.3	E1	75%
...	...	...	...	...

For a service type with only one traffic transmission type, the same method can be used to test the DRX parameter configuration of the training sample data of the service type, and calculate the proportion of the time that the electronic device is in the active state and mark the QoE.

In order to enable DRX parameters to be used between the network device 101 and the electronic device 100, in some embodiments, the server may obtain the DRX parameter set supported by the network device 101, so as to select DRX parameters for configuration. In other embodiments, the server may also obtain DRX parameter sets supported by different operators. In some other embodiments, the DRX parameter set in the server may come from a protocol or other empirical values. The DRX parameter set is shown in Table 4:

Table 4

DRX parameter number	onDuration(ms)	InactivityTimer(ms)	DRX Cycle(ms)
D.1	8	20	160
D.2	8	40	160
D.3	8	100	160
D.4	10	80	320

It can be understood that the number and value of the DRX parameters are not limited to the parameters listed in Table 4. The embodiment of the present invention does not impose any limitation on this.

S2052: According to the data marked in step S2051 (as shown in Table 3), for each traffic transmission type, the optimal DRX parameter is selected to obtain the DRX parameter mapping table. In some other embodiments, the optimal DRX parameter may be selected for each traffic transmission type of each service type to obtain the DRX parameter mapping table.

Specifically, for the data of each traffic transmission type, you can select one or more QoE classifications (for example, select QoE marked as "good") labeled sample data that can indicate a good business experience, and select the electronic device to be active The DRX parameter corresponding to the sample data with the lowest state proportion is taken as the optimal DRX parameter. In some other embodiments, the above-mentioned traffic transmission types are classified according to the service types. Taking the on-demand service type as an example, the sample data corresponding to one or more QoE classifications that represent excellent service experience indicates that the video can be played normally during playback, and the lowest active state ratio indicates that the electronic device is the most economical to transmit data streams under this DRX parameter Power consumption. Therefore, the selected DRX parameters can enable the electronic device to obtain an optimal power saving scheme on the basis of maintaining a better service experience.

In some other embodiments, when selecting the QoE classification, the QoE marked in the sample data of the same traffic transmission type and configured with the same DRX parameters can be counted to indicate the proportion of good service experience. If the ratio is greater than the preset threshold, the DRX parameter is used to select the DRX parameter. In some embodiments, the threshold may be set to 99%.

After the above selection operation, the formed DRX parameter mapping table can be as shown in Table 5:

table 5

Traffic transmission type	DRX parameters
F1	D.1
F2	D.2
...	...
FN	D.3

As shown in Table 5, the DRX parameter mapping table contains the mapping relationship between each traffic transmission type and the DRX parameter. For each traffic transmission type, obtain its optimal DRX parameter and record it in the DRX parameter mapping table.

Combining the service type and the traffic transmission type, the DRX parameter mapping table shown in Table 6 can be formed:

Table 6

As shown in Table 6, the DRX parameter mapping table contains the mapping relationship between each traffic transmission type of the service type and the DRX parameter. For example, service type 1 has multiple traffic transmission types, and for each traffic transmission type, the optimal DRX parameter is obtained and recorded in the DRX parameter mapping table. Service type 2 has only one traffic transmission type. Therefore, the optimal DRX parameter corresponding to this service type is recorded in the DRX model.

In some other embodiments, the foregoing DRX parameter mapping table may configure two or more sets of DRX parameters for each traffic transmission type.

In some other embodiments, the DRX parameters included in the DRX parameter mapping table may have all three parameters, OnDuration, InactivityTimer, and DRXCycle, or may include one or two of them.

In some other embodiments, each operator base station provides different sets of DRX parameters. Therefore, the server can increase the operator dimension in the statistical process. That is, for each traffic transmission type of each operator, the DRX parameter corresponding to the lowest proportion of the electronic device in the active state when the QoE is good is selected as the optimal DRX parameter and stored in the DRX parameter mapping table. The formed DRX parameter mapping table is shown in Table 7:

Table 7

Among them, the DRX parameters DA1-DA3 of operator A and the DRX parameters DB1-DB3 of operator B can refer to the form of D.1-D.4 in Table 4. It is understandable that the value may not be Subject to the limitations of the parameters listed in Table 4.

In some other embodiments, the DRX parameter mapping table shown in Table 8 can be formed by combining the service type and the traffic transmission type:

Table 8

In some other embodiments, different mobile phone models have different hardware capabilities, such as baseband transmission capabilities. Therefore, the DRX parameter mapping table may also consider other dimensions, such as dimensions such as mobile phone model, etc., to provide a more fine-grained DRX configuration for electronic devices.

In some other embodiments, the above-mentioned traffic transmission model and the DRX parameter mapping table may be combined into one model. The combined model is used to output the corresponding DRX parameters after determining the traffic transmission model of the service type corresponding to the current traffic.

In some other embodiments, the second device 102 may periodically or irregularly send the updated traffic transmission model and DRX parameter mapping table to the electronic device 100, so that the electronic device 100 can apply the updated model to determine the traffic transmission type and DRX parameters. .

In some other embodiments, the second device 102 may determine the operator information used by the electronic device 100, and send the DRX parameter mapping table matching the operator information to the electronic device 100.

If the service type corresponding to the current traffic corresponds to a traffic transmission type, the electronic device 100 determines the corresponding DRX parameter in the DRX parameter mapping table according to the service type corresponding to the traffic determined in step S202; if the service type corresponding to the current traffic corresponds to more According to the traffic transmission type determined in step S204, the electronic device determines the corresponding DRX parameter in the DRX parameter mapping table.

In some other embodiments, if the electronic device 100 does not find a matching DRX parameter in the DRX parameter mapping table, the electronic device 100 may not report the DRX parameter, or may report the default DRX parameter.

S206: The electronic device 100 reports the candidate DRX parameter to the network device 101.

In some embodiments, the electronic device 100 may report candidate DRX parameters to the network device 101 when the service type changes, and may also report the candidate DRX parameters to the network device 101 when the traffic transmission type corresponding to the service type changes.

When the electronic device 100 reports DRX parameters to the network device 101 candidates, it can report all DRX parameters (Onduration, DRXCycle, and InactivityTimer), or part of DRX parameters (one or two of Onduration, DRXCycle, and InactivityTimer). When the electronic device 100 reports part of the DRX parameters to the network device 101, it means that the electronic device 100 only needs to adjust the part of the reported DRX parameters, and the unreported DRX parameters remain unchanged or are determined by the network device 101.

In some other embodiments, when the electronic device 100 reports candidate DRX parameters to the network device 101, it may report one set of DRX parameters or multiple sets of DRX parameters.

In some cases, the unit of the DRX parameter determined in the electronic device 100 is different from the unit of the DRX parameter in the network device 101. For example, the unit of the DRX parameter in the electronic device 100 is milliseconds, and the unit of the DRX parameter in the network device 101 is the number of PDCCH subframes. In this case, the electronic device 100 may perform corresponding data conversion first, and then report the DRX parameters to the network device 101. For example, in the above situation, if the InactivityTimer is 10 milliseconds, since the length of one PDCCH subframe is 0.5 milliseconds, the electronic device 100 may report 20 to the network device 101 to indicate the value of the InactivityTimer.

S207: The network device 101 determines the DRX parameter according to the reported candidate DRX parameter, and sends first information to the electronic device 100, where the first information may indicate the determined DRX parameter.

Wherein, the determined DRX parameter and the candidate DRX parameter may be the same or different. Specifically, when the candidate DRX parameter reported by the electronic device 100 belongs to the DRX parameter supported by the network device 101, the network device 101 may use the candidate DRX parameter reported by the terminal as the determined DRX parameter. At this time, the network device 101 may send the first information to the electronic device 100, and indicate in the first information that the determined DRX parameter is the same as the candidate DRX parameter reported by the electronic device 100. When the candidate DRX parameter reported by the electronic device 100 does not belong to the DRX parameter supported by the network device 101, the network device 101 may re-determine the new DRX parameter based on the candidate DRX parameter reported by the electronic device 100. In some embodiments, the network device 101 may select the parameter closest to the DRX parameter reported by the electronic device 100 as the new DRX parameter from the DRX parameter set it supports.

In some other embodiments, if the electronic device 100 reports multiple sets of candidate DRX parameters, the network device 101 selects one set of parameters from the multiple reported sets of DRX parameters as the determined DRX parameters, or determines according to the multiple reported sets of candidate DRX parameters A new DRX parameter, where the determined DRX parameter is different from the multiple groups of reported DRX parameters.

The DRX parameters finally determined by the network device 101 may differ in different traffic transmission types. Taking the two types of traffic transmission types "first type" and "second type" of the on-demand service type as an example, the DRXCycle duration corresponding to the DRX parameter in the first type state can be greater than the DRXCycle corresponding to the DRX parameter in the second type state Duration; and/or, the InactivityTimer duration corresponding to the DRX parameter in the first type state may be less than the InactivityTimer duration corresponding to the DRX parameter in the second type state. In some other embodiments, the OnDuration duration corresponding to the DRX parameter in the first type state may be less than the OnDuration duration corresponding to the DRX parameter in the second type state.

S208: The network device 101 and the electronic device 100 use the determined DRX parameters to perform data transmission.

Setting the corresponding DRX parameters according to the traffic transmission type enables the electronic device 100 to adjust the activation and sleep state time allocation scheme in a more fine-grained manner, which helps the electronic device 100 to save power consumption. Take the "first type" and "second type" traffic transmission types in the on-demand service type as an example, although the DRX parameters applied by the electronic device 100 when the traffic transmission type is "first type" will bring a larger delay However, since the electronic device 100 has already cached a sufficient amount of data when the traffic transmission type is the "second type", this delay will not affect the user experience.

In some embodiments, before the electronic device 100 sends the determined DRX parameters to the network device, the electronic device 100 may use the default DRX parameters for data transmission.

In some embodiments, when the traffic transmission type of the electronic device 100 is in the second type or changes from the first type to the second type, the default DRX parameters may be used. When the traffic transmission type changes from the second type to the first type, the DRX parameter may be reported to the network device 101.

Through the above solution, the electronic device can combine its own understanding of the business to provide the network device with DRX parameters that conform to its own traffic transmission type, which can more effectively save power consumption.

In actual applications, for different applications of the same service type running on the electronic device 100, their traffic transmission types may also be different. For example, FIG. 9 exemplarily shows the traffic transmission situation of two applications that provide video-on-demand services. The white and black dots represent the traffic transmitted at different times after application A and application B enter the first type stage. As shown in Figure 7, the traffic transmission of application A is mainly concentrated in four time intervals, and the time intervals T _A1 , T _A2 and T _{A3 during which} data is not transmitted between two adjacent time intervals for transmitting data. The data downloaded by application A in each time interval of data transmission is several megabytes. Application B transmits traffic once every 10 seconds or so (as shown by _TB1 and _TB2 in the figure), and the size of each traffic transmission is hundreds of kilobytes. It can be seen from the figure that when running the same service type, the amount of data transmitted by application A is greater than that of application B each time, and at the same time, the data transmission interval is greater than that of application B. Therefore, for the same service type, different applications have different types of traffic transmission.

The embodiment of the present invention provides a method for the electronic device 100 to determine DRX parameters according to applications and traffic transmission types. As shown in Figure 10, the method includes the following method steps:

S301: The electronic device 100 acquires characteristic data of the traffic corresponding to the application. The electronic device 100 generally has multiple applications running at the same time during the running process, which can be divided into a foreground application and a background application. Generally speaking, among multiple running applications, only one application is the foreground application. For example, when an application that provides a video-on-demand service is used as a foreground application, the traffic transmission of the application has a greater impact on the user experience, while the traffic transmission of other background applications has a smaller impact on the user experience. In some embodiments, the electronic device 100 may obtain characteristic data corresponding to the traffic of the foreground application. In some other embodiments, the electronic device 100 determines whether the foreground application is in the DRX parameter mapping table, and when the current station application is in the DRX parameter mapping table, it obtains the traffic and characteristic data corresponding to the application. For the specific content of acquiring the traffic characteristics, refer to step S201, which will not be repeated here.

S302: Determine whether the application supports multiple service types. Specifically, the electronic device 100 can determine the service type corresponding to the application by searching in the DRX parameter mapping table. Wherein, the DRX parameter mapping table may include the mapping relationship between the application and the service type supported by it. If the application has only one service type, the electronic device executes step S304; if the application supports multiple service types, the electronic device executes step S303.

S303: The electronic device 100 judges the service type corresponding to the traffic. For the specific content of this step, please refer to step S202, which will not be repeated here.

S304: Determine whether there are multiple traffic transmission types for the service type. Specifically, the electronic device 100 can determine the service type and traffic transmission type corresponding to the application by searching in the DRX parameter mapping table. Among them, the DRX parameter mapping table may include the mapping relationship between applications, service types, and traffic transmission types. For a service type with only one traffic transmission type, the DRX parameter mapping table may include the mapping relationship between the application and the service type. In some other embodiments, if the application includes only one service type, and the service type includes multiple traffic transmission types, the DRX parameter mapping table may include the mapping relationship applied to the traffic transmission type. If the service type has multiple traffic transmission types, step S305 is executed; if the service type has only one traffic transmission type, then jump to step S306. For the specific content of this step, please refer to step S203, which will not be repeated here.

In some other embodiments, the electronic device may directly perform step S305 after performing step S303.

S305: Determine the current traffic transmission type according to the traffic transmission model. For the specific operation of this step, refer to step S204. For the process of establishing the traffic transmission model by the second device 102, reference may be made to steps S2041-S2044. The application dimension can be added to the statistical data, so that the traffic transmission model can determine the traffic transmission type according to the traffic corresponding to the application. Specifically, the application may include parameters such as application name and/or application code. The finally generated traffic transmission model is used to determine the traffic transmission type according to the traffic characteristics of the application.

In some other embodiments, the electronic device 100 may perform step S305 after performing step 301, and determine its traffic transmission type according to the traffic characteristics of the application.

S306: The electronic device determines the reported DRX parameter according to the DRX parameter mapping table.

For the specific operation of this step, refer to step S205. For the process of establishing the DRX parameter mapping table by the second device 102, refer to steps S2051-S2052. The application dimension can be added to the statistical data, so that the DRX parameter mapping table can determine the DRX parameters according to the traffic transmission model corresponding to the application.

The formed DRX parameter mapping table is shown in Table 9:

Table 9

In some other embodiments, combined with service types, the formed DRX parameter mapping table is shown in Table 10:

Table 10

In some other embodiments, combined with the operator dimension, the formed DRX parameter mapping table is shown in Table 11:

Table 11

In some other embodiments, the electronic device 100 may obtain the above-mentioned traffic transmission model and the DRX parameter mapping table from the second device 102 through way A or way B or way C:

Manner A: After the electronic device 100 installs the application A, the electronic device 100 may send a model acquisition request to the second device 102, and the model acquisition request includes identification information of the application A, such as application code and/or application name. The request is used to obtain the traffic transmission model and DRX parameter mapping table of application A. After receiving the model acquisition request, the second device 102 sends the traffic transmission model of the application A and the DRX parameter mapping table to the electronic device 100. If the traffic transmission model and DRX parameter mapping table of application A are not stored in the second device 102, the second device 102 returns an acquisition failure message to the electronic device 100. In some embodiments, before sending the model acquisition request, the electronic device 100 may query whether the traffic transmission model and/or the DRX parameter mapping table stored in the electronic device 100 contains the traffic transmission model and/or the DRX parameter mapping table of application A. If not included, a model acquisition request is sent to the second device 102.

Method B: When the electronic device 100 runs application A, the electronic device 100 queries whether the traffic transmission model and/or DRX parameter mapping table stored in the electronic device 100 contains the traffic transmission model and/or DRX parameter mapping table of application A, if not Include, send a model acquisition request to the second device 102. After receiving the model acquisition request, the second device 102 sends the traffic transmission model and the DRX parameter mapping table to the electronic device 100. In some embodiments, before the query step, the electronic device 100 may send the second device to the second device after performing steps S301-S303, and after the traffic transmission model is not queried in the traffic transmission model in step S304 or S305, 102 sends a model acquisition request.

Manner C: The second device 102 learns that the electronic device 100 has installed the application A, and the second device 102 sends the traffic transmission model and the DRX parameter mapping table related to the application A to the electronic device 100. In some other embodiments, the second device 102 may periodically or irregularly send the updated traffic transmission model and DRX parameter mapping table related to the application A to the electronic device 100.

For the rest of the steps, please refer to step S206-step S208, which will not be repeated here. In some other embodiments, if the electronic device 100 does not have a matching application or traffic transmission type in the traffic transmission model, or the corresponding DRX parameter is not found in the DRX parameter mapping table, the electronic device 100 may not report the DRX parameter, or The default DRX parameters can be reported.

Through the above solution, the electronic device 100 can perform fine-grained DRX parameter adjustment for the traffic transmission type of the application. It helps the electronic device 100 to further save power consumption.

The embodiment of the present invention also provides a method for the electronic device 100 to determine DRX parameters according to the traffic characteristics of the first category, which can determine the DRX parameters adaptively with respect to the detected traffic characteristics of the first category.

As shown in FIG. 11, the method provided in this embodiment specifically includes the following method steps:

S401: Determine that the electronic device 100 enters a new traffic transmission type.

Specifically, the electronic device 100 may determine whether the electronic device 100 has entered a new traffic transmission type by determining whether the continuous first-category traffic belongs to similar first-category traffic. If the N consecutive first-type traffic belong to similar first-type traffic that is different from the previous traffic transmission type, it is determined that the electronic device 100 has entered the new traffic transmission type. N is a natural number, for example, N can take the value 3.

The electronic device 100 can determine similar first-category traffic through the following steps:

S4011: Determine the service type of each first type of traffic. The traffic of the first category for calculation must belong to the same service type. If the service types corresponding to the traffic of the first category are different, it is not similar traffic of the first category. In some other embodiments, this step may also be to determine whether each first type of traffic belongs to the same application. If the applications corresponding to each first-type traffic are different, they are not similar first-type traffic.

S4012: Determine similar first-category traffic according to the magnitude of the first-category traffic of the last n times. Specifically, if the ratio of the sizes of the two first-category traffic is less than the similarity threshold TH of the first-category traffic, the two first-category traffic can be considered to be similar first-category traffic. Among them, n and the similarity threshold TH are preset parameters.

For example, if n=3, the similarity threshold TH=0.3, the traffic size of the first category for the Nth time is 5M,

If the N-1th first category traffic size is 6M, its similarity is |6/5-1|=0.2. Since the similarity is less than the threshold 0.3, it can be considered that the N-1th first category traffic is the same as the first category traffic. The N-times traffic of the first category is similar to the traffic of the first category.

If the N-2th first category traffic size is 4M, its similarity is |4/5-1|=0.2. Since the similarity is less than the threshold 0.3, it can be considered that the N-2th first category traffic is the same as the first category traffic. The N-times traffic of the first category is similar to the traffic of the first category.

If the N-3th first category traffic size is 10M, its similarity is |10/5-1|=1. Since the similarity is greater than the threshold 0.3, it can be considered that the N-3th first category traffic is the same as the first category traffic. The N-time first-category traffic is not similar to the first-category traffic.

In some other embodiments, the ratio of the most recent n first-category traffic to the average value of the most recent n first-category traffic can be compared, and the first-category traffic whose ratio is less than the similarity threshold TH is regarded as the similar first-category traffic.

For example, if n=3, the similarity threshold TH=0.3, the M-th first-category traffic size is 6M, and the two first-category traffic sizes before the M-th first-category traffic are 10M and 4M, respectively. Then, the average value of the last three first-class traffic is about 6.67M.

For the M-2 first category traffic, if the traffic size is 10M, its similarity is |10/6.67-1|≈0.5, and the M-1 first category traffic size is 4M, then the similarity is |4/6.67-1|≈0.4, the M-th first-category traffic size is 6M, and its similarity is |6/6.67-1|≈0.1. Therefore, in the last three first-category traffic, only The M-th traffic is within the similarity threshold, and there is no similar traffic of the first category.

If the traffic size of the M+1 first category is 5M, the average value of the last three traffic of the first category is 5M.

For the M-1th first category traffic, its flow size is 4M, then its similarity is |4/5-1|=0.2, the M-th first category traffic size is 6M, then its similarity is |6 /5-1|=0.2, the M-th first-category traffic size is 5M, and its similarity is |5/5-1|=0. Therefore, the last three first-category traffic is at the similarity threshold Therefore, the M-1th, Mth, and M+1th first-category traffic is three consecutive first-category traffic.

In some other embodiments, the determination of similar first-category traffic may be based on other parameters other than the first-category traffic size, such as the first-category traffic interval, and/or the first-category traffic size variance, and/or the first category traffic size variance. Parameters such as the average value of the category flow interval.

When the electronic device 100 detects consecutive N similar first-category traffic, obtains the length of the N-1 first-category traffic interval between the N similar first-category traffic, calculates the average value and variance, and passes The traffic transmission model judges its traffic transmission type. If the determined traffic transmission type is different from the last determined traffic transmission type, it is determined that the electronic device 100 has entered the new traffic transmission type. Among them, the establishment process of the traffic transmission model can refer to step S204, which will not be repeated here.

In some other embodiments, the electronic device 100 may not perform step S4011, and determine the first type of traffic through S4012.

In some other embodiments, the electronic device 100 may determine the traffic transmission type based on the traffic characteristics. For example, when the size variance of the first category traffic is less than the preset size variance threshold and/or the first category traffic time interval variance is less than the preset interval variance threshold and/or similar first category traffic is greater than the preset quantity threshold , The corresponding traffic transmission type is the first type status.

S402: Determine the DRX parameter according to the time interval of similar first-type traffic.

Specifically, when it is determined that the electronic device 100 has entered a new traffic transmission type, the time interval of the next first category traffic is predicted according to the obtained time interval of similar first category traffic. Still taking N=3 as an example, as shown in Figure 12, the time interval between the M-1th first-category traffic and the M-th first-category traffic is T _M-1 , the M-th first-category traffic The time interval between the traffic of the first category and the M+1th traffic of the first category is _{TM , then the time interval TM+1} between the traffic of the M+1th and the M+2th traffic of the first category can be T _M+1 = (T _M +T _M-1 )/2. In some other embodiments, other methods may be used to predict the time interval of the next first-type traffic, which is not limited in the embodiment of the present invention.

Determine the parameter DRXCycle according to the predicted time interval of the next first category traffic. Specifically, DRXCycle<T _M+1 -Delta _adj . Among them, Delta _adj is the adjusted value, which is used to prevent the value of DRXCycle from being too large, which exceeds the time interval between adjacent first category traffic. In some embodiments, Delta _adj values may _{Delta adj = m * T M +} 1 + b. Among them, 0<m<1, b is the offset value, and m and b can be parameters preset by the system. For example, m=0.6, b=1000 (milliseconds).

In some embodiments, the electronic device 100 may select the largest value from the DRXCycle set supported by the network device 101 as the determined DRXCycle parameter on the basis of satisfying the foregoing conditions.

S403: Determine the InactivityTimer according to the time interval of the data packet.

Specifically, the InactivityTimer can be determined according to the following formula:

InactivityTimer=Avg(T _Service )+y*Var(T _Service )

Among them, T _{Service is} the data packet time interval of the service type, Avg (T _Service ) is the average value of the data packet time interval of the service type, Var (T _Service ) is the variance of the data packet time interval of the service type, and y is the pre- Set the constant, for example, y can take 3. Specifically, the electronic device 100 may select data packets generated by uplink, downlink, or uplink and downlink services according to the service type. For example, for the on-demand service type, data packets generated by the downlink service can be selected for measurement.

In some other embodiments, the electronic device 100 may save the value of the InactivityTimer parameter determined according to the service type, and use it to adjust the DRX parameter usage when the same service type is generated next time.

In some other embodiments, the electronic device 100 may determine the value of the corresponding InactivityTimer parameter according to the service types of different applications.

In some other embodiments, the second device 102 may determine the value of the InactivityTimer parameter corresponding to different service types, and send the correspondence between the service type and the InactivityTimer parameter to the electronic device 100, and the electronic device 100 selects the corresponding InactivityTimer according to the service type. The parameter value.

S404: Determine the parameter OnDuration. The value of OnDuration can be a fixed value or a value determined according to the business type. Wherein, the corresponding relationship between the service type and the value of OnDuration may be pre-stored in the electronic device 100, or may be generated by a server and sent to the electronic device 100.

The subsequent steps are the same as S206-S208, and will not be repeated here.

It is understandable that the electronic device 100 can determine the three parameters of DRXCycle, InactivityTimer, and OnDuration, and can also determine one or two of the above three parameters as required, that is, in the above steps S402, S403, and S404, The electronic device 100 can execute all of them, and the order of execution is in no particular order, and one or two of them can also be executed.

Through the above solution, the electronic device determines the traffic transmission type by calculating the characteristics of the first type of traffic, and determines the DRX parameters according to the characteristics of the traffic. The electronic device 100 can perform fine-grained DRX parameter adjustment for the traffic transmission type of the application. It helps the electronic device 100 to further save power consumption.

The embodiment of the present invention also provides a method for determining DRX parameters based on the time delay reported by the application. The application is an application program installed in an electronic device.

Different applications have different requirements for time delay. For example, games and live broadcast applications have high requirements for delay, while on-demand applications have relatively low requirements for delay. In order to ensure that the application can run smoothly, the electronic device can obtain the delay requirement of the application, such as the minimum delay requirement. On the basis of the aforementioned delay requirements, the electronic device can set corresponding DRX parameters. As shown in Figure 13, the method includes the following steps:

S501: The electronic device 100 obtains the delay requirement of the application. The application program can report the delay requirement corresponding to the application through the API interface provided by the electronic device 100 for it. The reported time can be when the application is started. The electronic device 100 may also obtain the corresponding delay requirement from the application through the API interface.

S502: The electronic device 100 may determine the DRX parameter according to the DRX parameter time delay model. Among them, the DRX parameter may be a DRX parameter set supported by the network device 101, or may be a DRX parameter set supported by an operator. The foregoing DRX parameters may include all three parameters, OnDuration, DRXCycle, and InactivityTimer, or may include one or two of the foregoing three parameters. In the DRX parameter delay model, the mapping relationship between the delay and the DRX parameter is established. The electronic device 100 obtains one or more sets of DRX parameters that satisfy the delay condition by querying the foregoing mapping relationship. In some other embodiments, the above-mentioned mapping relationship may be a functional relationship.

In some other embodiments, the electronic device 100 may determine the value of the DRXCycle parameter according to the DRX parameter time delay model. In some embodiments, the determined DRXCycle value is the maximum DRXCycle value that satisfies the delay condition without considering the two parameters of OnDuration and InactivityTimer. After that, the electronic device 100 selects the InactivityTimer parameter according to the inactivity time ratio requirement. In some embodiments, the electronic device 100 selects the largest value of InactivityTimer as the candidate DRX parameter from the combination of the determined DRXCycle parameter and multiple InactivityTimer parameters.

In some embodiments, the aforementioned DRX parameter delay model may be a model that takes a value for each OnDuration and represents the mapping relationship between the delay and the DRXCycle and InactivityTimer parameters.

In some embodiments, the DRX parameter delay model may be generated by the second device 102 and sent to the electronic device 100, or it may be pre-stored in the electronic device 100.

For the subsequent steps, please refer to steps S206-S208, which will not be repeated here.

Through the above solution, the electronic device determines the DRX parameter by applying the reported time delay. The electronic device can perform fine-grained DRX parameter adjustments according to the delay requirements of the application, which helps the electronic device to further save power consumption.

The various embodiments of the present invention can be combined arbitrarily to achieve different technical effects.

In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or instructions in the form of software. The steps of the method disclosed in combination with the embodiments of the present application may be directly embodied as being executed and completed by a hardware processor, or executed and completed by a combination of hardware and software modules in the processor. The software module can be located in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.

It should be understood that in the various embodiments of the present application, the size of the sequence number of the above-mentioned processes does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not correspond to the embodiments of the present application. The implementation process constitutes any limitation.

In the above-mentioned embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented by software, it can be implemented in the form of a computer program product in whole or in part. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center. Transmission to another website, computer, server or data center via wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or a data center integrated with one or more available media. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, and a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk (SSD)).

The above are only specific implementations of this application, but the protection scope of this application is not limited to this. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in this application. Should be covered within the scope of protection of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims (10)

1. A method for determining DRX parameters is characterized by:

   Obtain data flow characteristics;

   Determining the data stream transmission type according to the data stream characteristics;

   Determine candidate DRX parameters according to the data stream transmission type;

   Sending the candidate DRX parameters to the network device;

   Receiving first information from the network device, the first information indicating the determined DRX parameter;

   Use the determined DRX parameters for data transmission.
2. The method according to claim 1, wherein the data streams are data streams of the same service type.
3. The method of claim 1, wherein the data stream is a data stream of the same application.
4. The method according to any one of claims 1 to 3, wherein the data stream is a data stream of a first category, wherein the data stream of the first category is data transmitted from a first moment to a second moment A data stream with an amount greater than the first data amount threshold;

   Wherein, the first moment is the moment when the data transmission speed increases from equal to 0 to not equal to 0 or from less than the first speed threshold to equal or greater than the first speed threshold; the second moment is the first After the time, the first data transmission speed drops to 0 or less than the first speed threshold, and the data transmission speed is 0 or less than the first speed threshold for a continuous first time period from the second time.
5. The method according to any one of claims 1 to 3, wherein the determining the data stream transmission type according to the data stream characteristics further comprises:

   Determine the data stream transmission type according to the data stream characteristics and the first model;

   The determining candidate DRX parameters according to the data stream transmission type further includes:

   Determine the candidate DRX parameter according to the data stream transmission type and the first mapping table.
6. The method of claim 5, wherein the candidate DRX parameter is determined according to the data stream transmission type, operator information, and the first mapping table.
7. The method according to any one of claims 1 to 3, wherein the candidate DRX parameter and the determined DRX parameter are the same or different.
8. The method according to any one of claims 1 to 3, wherein the candidate DRX parameter and the determined DRX parameter are one or more of OnDuration, InactivityTimer, and DRXCycle.
9. An electronic device, characterized in that it comprises:

   One or more processors;

   Memory; and

   One or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs include instructions, and the instructions are used To perform the method according to claims 1-8.
10. A computer-readable medium, characterized in that it includes storing one or more programs, wherein the one or more programs are configured to be executed by the one or more processors, and the one or more programs include instructions , The instructions are used to execute the method according to claims 1-8.

Images