WO2019161780A1

WO2019161780A1 - Method and apparatus for setting dormancy period of service

Info

Publication number: WO2019161780A1
Application number: PCT/CN2019/075853
Authority: WO
Inventors: 相海涛
Original assignee: 中兴通讯股份有限公司
Priority date: 2018-02-23
Filing date: 2019-02-22
Publication date: 2019-08-29
Also published as: CN108260194A

Abstract

Provided are a method and apparatus for setting a dormancy period of a service. The method comprises: determining a service model of a device based on service information of the device, wherein the service model is used for identifying the type of the service; acquiring a dormancy parameter of the service corresponding to the service model; and setting the dormancy period of the service based on the dormancy parameter.

Description

Method and device for setting sleep cycle of business

The present disclosure claims priority to Chinese Patent Application No. 20110015 563 3.8, filed on Jan. 23, 2011, the entire disclosure of which is hereby incorporated by reference.

Technical field

The present disclosure relates to the field of communication technologies, for example, to a method and apparatus for setting a sleep period of a service.

Background technique

The Internet of Things is rich in applications and has broad application prospects. However, in addition to supporting the application of the Internet of Things, traditional networks should also pay attention to the characteristics of the Internet of Things. With the increasing scarcity of wireless spectrum resources and the spurt of IoT devices, the Narrow Band-Internet of Things (NB-IOT) is increasingly becoming the trend of Internet of Things based on the field of mobile communications. Networking has also become one of the important topics of the 5th Generation mobile communication technology (5G).

IoT devices usually have the characteristics of power saving, less data transmission, lower mobility, and stronger bursting of access, because the application scenarios of IoT devices are very rich. The 3rd Generation Partnership Project (3GPP) proposes a Power Saving Mode (PSM) and Enhanced Discontinuous Reception (eDRX) after Rel-12 for the IoT power saving feature. It can achieve longer standby. The PSM mode is User Equipment (UE) PSM. It is similar to the fake shutdown state. It keeps the registration status but the signaling is unreachable. It does not need to reattach (ATTACH) or rebuild the packet data network (Packet). The Data Network (PDN) is connected so that the terminal stays in deep sleep for a longer period of time to save power. In fact, it can be regarded as a deep sleep state. eDRX is a new feature in Rel-13, which further extends the sleep cycle of the terminal in idle mode and reduces the unnecessary start of the receiving unit. Compared with the PSM, the reachability of the downlink communication link is greatly improved. Although these two methods can greatly improve the standby performance and standby time of the terminal, the application scenarios of the Internet of Things are complex. Different application scenarios have different requirements for the PSM cycle or the eDRX cycle. However, the traditional 3GPP defaults through the network static allocation method is not flexible enough, the traditional 3GPP essence Adopting a configuration parameter for all terminals accessing the network cannot solve all the problems, and although the 3GPP considers providing an Attention (AT) command to hand over the parameter setting to the developer, but for the NB-IOT terminal. There are many manufacturers, different business areas of different manufacturers, and different business characteristics. It is unrealistic to expect users from different industries to understand and calculate reasonable parameters for 3GPP. At the same time, different parameter selections have a great impact on the battery life of NB-IOT terminals, involving different products. Battery selection and product costing issues.

It can be seen from the above that there is a problem in the related art that the sleep parameter corresponding to the service cannot be determined according to the type of the service.

Summary of the invention

The present disclosure provides a method and an apparatus for setting a sleep period of a service, so as to at least solve the problem that the sleep parameter corresponding to the service cannot be determined according to the type of the service in the related art.

The present disclosure provides a method for setting a sleep period of a service, including: determining a service model of the device based on service information of the device, where the service model is used to identify a type of the service; and acquiring a service model corresponding to the service model a sleep parameter of the service; setting a sleep cycle of the service based on the sleep parameter.

The present disclosure further provides a method for setting a sleep period of a service, including: receiving, by using an access network, a sleep parameter request message sent by a terminal; and determining, according to the service information of the device carried in the sleep parameter request message, a dormancy parameter of the service corresponding to the service model, where the service model is determined by the terminal based on the service information of the device, and is used to identify the type of the service; and the dormant parameter is sent to the terminal by using the access network, Instructing the terminal to set a sleep period of the service by using the sleep parameter. The present disclosure further provides a setting device for a sleep period of a service, including: a first determining module, configured to determine a service model of the device based on service information of the device, where the service model is used to identify a type of the service; And an obtaining module, configured to acquire a sleep parameter of the service corresponding to the service model, and a setting module, configured to set a sleep period of the service based on the sleep parameter.

The present disclosure further provides a setting device for a sleep period of a service, comprising: a receiving module, configured to receive a sleep parameter request message sent by the terminal through the access network; and a second determining module configured to: according to the sleep parameter request message The service information of the carried device determines a dormancy parameter of the service corresponding to the service model of the device, where the service model is determined by the terminal based on the service information of the device, and is used to identify the type of the service; the sending module is set to be The dormant parameter is sent to the terminal by using the access network to instruct the terminal to set a sleep period of the service by using the dormant parameter.

The present disclosure also provides a storage medium having stored therein a computer program configured to execute any of the methods described above at runtime.

The present disclosure also provides an electronic device comprising a memory and a processor, the memory storing a computer program, the processor being arranged to run the computer program to perform any of the methods described above.

DRAWINGS

1 is a block diagram showing a hardware structure of a mobile terminal for setting a sleep period of a service according to an embodiment;

2 is a flowchart of a method for setting a sleep period of a service according to an embodiment;

FIG. 3 is a flowchart of a method for setting a sleep period of another service according to an embodiment; FIG.

FIG. 4 is a schematic diagram of a service model abstraction system for NB-IOT network sleep cycle management according to an embodiment; FIG.

FIG. 5 is a schematic diagram of a sleep service management policy server according to an embodiment; FIG.

6 is a flowchart of a sleep parameter calculation method according to an embodiment;

FIG. 7 is a schematic diagram of an NB-IOT terminal according to an embodiment; FIG.

FIG. 8 is a schematic diagram of key information of a NB-IOT terminal side service according to an embodiment; FIG.

FIG. 9 is a flowchart of an NB-IOT terminal side service key information abstracting method according to an embodiment; FIG.

FIG. 10 is a flowchart of a NB-IOT terminal service model classification method according to an embodiment; FIG.

11 is a flowchart of a NB-IOT terminal service model calculation method according to an embodiment;

FIG. 12 is a structural block diagram of a device for setting a sleep cycle according to an embodiment; FIG.

FIG. 13 is a structural block diagram of another apparatus for setting a sleep period according to an embodiment.

Detailed ways

The present disclosure will be hereinafter described with reference to the drawings in conjunction with the embodiments.

The terms "first", "second" and the like in the specification and claims of the present disclosure and the above-mentioned figures are used to distinguish similar objects, and are not necessarily used to describe a particular order or order.

Example 1

The method embodiments provided by the present disclosure may be implemented in a mobile terminal, a computer terminal, or the like. Taking a mobile terminal as an example, FIG. 1 is a hardware structural block diagram of a mobile terminal for setting a sleep period of a service according to an embodiment. As shown in FIG. 1, mobile terminal 10 may include one or more (only one of which is shown in FIG. 1) processor 102 (processor 102 may include, but is not limited to, a Microcontroller Unit (MCU) or a programmable logic device. A processing device such as a Field-Programmable Gate Array (FPGA) or a memory 104 provided to store data. In an embodiment, the mobile terminal may further include a transmission device 106 and a input and output device 108 for communication functions. It will be understood by those skilled in the art that the structure shown in FIG. 1 is merely illustrative and does not limit the structure of the above mobile terminal. For example, the mobile terminal 10 may also include more or fewer components than those shown in FIG. 1, or have a different configuration than that shown in FIG.

The memory 104 may be configured to store a computer program, such as a software program of a application software and a module, such as a computer program corresponding to a setting method of a sleep cycle of a service in the embodiment of the present disclosure, the processor 102 running a computer stored in the memory 104 The program, thereby performing at least one functional application and data processing, implements the above method. Memory 104 may include high speed random access memory, and may also include non-volatile memory such as one or more magnetic storage devices, flash memory, or other non-volatile solid state memory. In some examples, memory 104 can include memory remotely located relative to processor 102, which can be connected to mobile terminal 10 over a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

Transmission device 106 is arranged to receive or transmit data via a network. The above-described network specific example may include a wireless network provided by a communication provider of the mobile terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC) that can be connected to other network devices through a base station to communicate with the Internet. In one example, the transmission device 106 can be a Radio Frequency (RF) module configured to communicate with the Internet wirelessly.

FIG. 2 is a flowchart of a method for setting a sleep cycle of another service according to an embodiment. As shown in FIG. 2, the process includes the following steps.

Step S202: Determine, according to service information of the device, a service model of the device, where the service model is used to identify a type of the service.

Step S204: Acquire a sleep parameter of the foregoing service corresponding to the foregoing service model.

Step S206, setting a sleep period of the foregoing service based on the sleep parameter.

Through the above steps, the terminal in the narrowband Internet of Things determines the service model of the device based on the service information of the device, wherein the service model is used to identify the type of the service; then, the sleep parameter of the service corresponding to the service model is acquired; and the service is set based on the sleep parameter. Sleep cycle. That is, the obtained dormant parameter is corresponding to the service. Therefore, the problem that the dormant parameter corresponding to the service cannot be determined according to the type of the service can be solved, and the effect of reasonably selecting the dormant parameter and improving the user experience is achieved.

In an embodiment, the execution body of the above steps may be a terminal or the like, but is not limited thereto.

In an embodiment, before determining the service model of the device based on the service information of the device, the method further includes: determining service information of the device by: determining a type of the device; acquiring the foregoing corresponding to the type of the device The service information, wherein the service information is related to the sleep parameter. In this embodiment, the sleep parameter needs to be calculated through the service information.

In an embodiment, determining the service model of the device based on the service information of the device includes: determining the service model according to the reason for performing the foregoing service included in the service information, where the service model includes one of the following: The reason for the service is that the service model is event-driven when the timer expires; when the reason for executing the service is triggered by the sensor, the service model is determined to be a periodic report type; the reason for executing the service is timing. In the case of device timeout and sensor triggering, it is determined that the above business model is a mixed report type. In this embodiment, the category of the service model may also be determined by using other information in the service information.

In an embodiment, acquiring the dormancy parameter of the foregoing service corresponding to the foregoing service model includes: acquiring, in the case that the service model is found in the preset database, obtaining the corresponding to the service model in the preset database. The sleep parameter of the foregoing service; or, in response to determining that the service model is not found in the preset database, sending the sleep parameter request message to the core network device through the access network; receiving the core network device according to the foregoing device The service information determines the sleep parameter returned by the access network after the sleep parameter of the service is determined, where the sleep parameter request message includes the service information of the device. In this embodiment, the preset database is a database in which the terminal side sets up and stores data.

In an embodiment, after receiving the sleep parameter returned by the access network after the core network device determines the sleep parameter of the service according to the service information of the device, the method further includes: performing the sleep parameter and the foregoing The business model is correspondingly stored in the above preset database. In this embodiment, the preset database is dynamically changed, that is, the operation of adding, deleting, and modifying can be performed.

In one embodiment, the service information includes at least one of the following: a battery capacity of the device, a sending traffic of the device, a period in which the device sends data, a reason for the device to send data, and a remote control interface information of the device, The number of peripheral sensor interfaces of the above device, the sensor classification of the above device, the power of the data transmitted by the device, and the intensity information of the received signal of the device.

In one embodiment, the sleep parameter includes at least one of the following: a power save mode PSM cycle, and an enhanced discontinuous receive eDRX cycle.

In one embodiment, the device is a device that is used in a narrowband Internet of Things NB-IOT terminal.

FIG. 3 is a flowchart of a method for setting a sleep cycle of another service according to an embodiment. As shown in FIG. 3, the process includes the following steps.

Step S302: Receive a sleep parameter request message sent by the terminal through the access network.

Step S304, determining, according to the service information of the device carried in the dormant parameter request message, a dormant parameter of the service corresponding to the service model of the device, where the service model is determined by the terminal based on the service information of the device, and is used to identify the service. Types of.

Step S306, the dormant parameter is sent to the terminal through the access network, to instruct the terminal to set a sleep period of the service by using the sleep parameter.

Through the above steps, the core network device receives the sleep parameter request message sent by the terminal through the access network; and determines the sleep parameter of the service corresponding to the service model of the device according to the service information of the device carried in the sleep parameter request message, where the service model It is determined by the terminal based on the service information of the device, and is used to identify the type of the service. The dormant parameter is sent to the terminal through the access network, to indicate that the terminal uses the dormancy parameter to set the sleep period of the service. That is, the obtained dormant parameter is corresponding to the service. Therefore, the problem that the dormant parameter corresponding to the service cannot be determined according to the type of the service can be solved, and the effect of reasonably selecting the dormant parameter and improving the user experience is achieved.

In an embodiment, the execution body of the foregoing steps may be a core network device or the like, but is not limited thereto.

In one embodiment, determining the dormancy parameter of the service corresponding to the service model of the device according to the service information of the device includes: determining a service model of the device according to the service information of the device, where the service model includes one of the following: The reason for executing the above-mentioned service is the event-driven type when the timer expires. The reason for executing the above-mentioned service is the periodic report type when the sensor is triggered. The reason for executing the above-mentioned service is the mixed report type of the timer timeout and the sensor trigger; The business model determines the above sleep parameters.

In one embodiment, the service information includes at least one of the following: a battery capacity of the device, a sending traffic of the device, a sending data cycle of the device, a reason for the device to send data, and a remote control interface information of the device, The number of peripheral sensor interfaces of the above device, the classification of the sensors of the above devices, the power of the data transmitted by the devices, and the strength information of the signals received by the devices.

The present disclosure is described below in conjunction with the exemplary embodiments.

Exemplary embodiment 1:

In the NB-IOT network, the 3GPP protocol specifies that the PSM or eDRX cycle parameters are all ATTACH ACCEPET or TAU after the terminal is powered on for ATTACH or Tracking Area Update (TAU). The acceptance (TAU ACCEPT) message primitive is assigned to the terminal, and the general network adopts a static default value allocation method. At the same time, 3GPP provides developer AT commands for parameter modification.

Although the two methods can greatly improve the standby performance and the standby time of the terminal, the NB-IOT application scenario is complex. Different application scenarios have different requirements for the PSM cycle or the eDRX cycle. However, the traditional 3GPP defaults through the network static allocation mode is not flexible enough, the traditional 3GPP Essentially, a configuration parameter is adopted for all terminals accessing the network, which cannot solve all the problems. At the same time, although the 3GPP considers providing a peripheral AT and the like to hand over the parameter setting to the developer, the 3GPP solution does not first consider the The change lies in the different application scenarios of the NB-IOT terminal, and the requirements for the dormant attribute parameters are different. The related technology applies a unified default static allocation method for any NB-IOT terminal or IoT terminal, and many NB-IOT terminal manufacturers. Different business areas of different manufacturers have different business characteristics. It is unrealistic to expect users from different industries to understand and calculate reasonable parameters for 3GPP. At the same time, different parameter selections have a great impact on battery life of NB-IOT terminals, involving different product battery selection. And product costing and other issues, According to different parameters critical to choose a different business. For example, if the eDRX cycle parameter is extended from about 10 seconds (s) to about 20 minutes (min) in the laboratory, the life of the battery can be extended for about 90 days in the smart parking service application scenario, so that different strategies can be used for different application scenarios. It can effectively reduce the energy consumption level of the product, improve the user experience and reduce the cost of use.

In view of the above technical deficiencies, the present embodiment proposes an NB-IOT service model abstraction method and system, for example, for NB-IOT network NB-IOT terminal eDRX cycle and PSM cycle management, the method can be upgraded by preset The NB-IOT business model factory library, for the characteristics of the NB-IOT industry application domain, generates an eXtensible Markup Language (XML) file of the business model of the business through abstract computing, and interacts with the network at the NB-IOT terminal. The signaling carries the service model, and the dormant service management policy server is introduced in the core network. When the core network device receives the service model signaling message from the terminal, the service model is transmitted to the dormant service management policy server by decoding, and the server passes the service. Characteristics and business requirements, generate and calculate dynamically adjustable eDRX and PSM cycle parameters and calculate the theoretical service life of the service model based on the built-in power consumption model, and return it to the NB-IOT terminal, and execute different calculations by the terminal. The eDRX and PSM cycles are dormant management.

This embodiment includes: a terminal side and a system core network side. The terminal side includes at least: an NB-IOT access module, a sleep management module, an NB-IOT service model abstraction module, an NB-IOT service model factory library, an NB-IOT service model generation module, and an initialization module. The system side at least includes: a base station (eNodeB), a core network device, and a dormant service management policy server (corresponding to the second determining module in the foregoing).

The main implementation method of this embodiment is as follows.

1. The NB-IOT terminal device is initialized, and the initialization module acquires device information.

The device information includes the International Mobile Equipment Identity (IMEI) number of the device, and the International Mobile Subscriber Identification Number_Mobile Country in the Subscriber Identification Module (SIM) card. Code, IMSI_MCC) and International Mobile Subscriber Identification Number_Mobile Network Code (IMSI_MNC), device classification number, battery life expectancy Lexpect. This information is pre-configured by the Original Equipment Manufacturer (OEM) vendor to the NB-IOT terminal equipment. The equipment classification number is represented by numbers, especially the industry field of NB-IOT terminal applications. By classifying the NB-IOT business applications abstractly, according to the business field, it can be divided into Meters (0x1) and Tracker (Tracker). 0x2), Gateway (0x3) three categories. Meters, that is, meter industry applications, such as water meters, electricity meters, gas meter data collection, saving manual meter reading resources; Tracker, tracking industry applications, such as shared bicycle tracking applications, package tracking, logistics tracking industry applications; Gateway, That is, the gateway application is mainly to assist peripheral devices or sensors to transmit data.

2. The NB-IOT business model abstraction module extracts business key information.

The NB-IOT business model abstraction module may be one or more business processes inside the terminal, and the NB business model abstraction module has access code administrator authority, and the module extracts business key in key business code by accessing the terminal device management unit and the service source code. Information, such as sending data, receiving data, entering PSM, exiting PSM, timer timeout and other source code, extracting information including: battery capacity, sending traffic, sending data cycle, reason for sending data, presence of remote control interface, peripheral sensor interface Number, sensor classification. This key information forms the key data of the business model.

3. The NB-IOT business model abstraction module validates the business model based on key information characteristics.

The NB-IOT service abstraction module abstracts the NB-IOT industry application business model into event-driven, periodic report-type and hybrid report-type models according to the business model of different industry applications, and confirms different business models by judging the reason for sending data. If the reason for sending data is that the timer expires, the service model is confirmed to be periodic report type; if the reason for sending data is triggered by the peripheral sensor, the service model is confirmed to be event-driven report type; if the data is sent, both the timer expires and the sensor triggers. , confirm that the business model is a hybrid escalation model.

4. The NB-IOT business model abstraction module requests to match the NB-IOT business model factory library (corresponding to the preset database in the above) according to the business model and key parameters.

The NB-IOT business model factory library is a scalable terminal local NB-IOT business model database. The NB-IOT business model factory library is built into the NB-IOT terminal and contains some common business model parameters if the terminal can retrieve If the service model is matched, the PSM and eDRX cycle parameters corresponding to the service model are directly executed, and the parameter is used as the default setting, and the default setting is carried in the terminal registration network ATTACH/RAU signaling message; if the service model cannot be matched, It is passed directly to the business generation module.

5. The NB-IOT service model generation module calculates and generates a service model of the terminal according to the key information extracted by the service abstraction module.

The NB-IOT business model generation module uses the extracted key information to generate a corresponding format business model description file, such as an XML file, and saves the business model in the terminal built-in NB-IOT business model factory library.

6. The NB-IOT access module extracts the service model and adds it to the system side eNodeB in the NB-IOT terminal signaling message element.

The NB-IOT access module adds the service model message element to the system side NodeB network element in the registration signaling ATTACH message according to the service model. The service model message element is a newly added message element describing the terminal service model, and includes at least the above-mentioned business model key information: battery capacity, transmission traffic volume, transmission data period, reason for transmitting data, presence of a remote control interface, number of peripheral sensor interfaces , sensor classification, transmit power size, received signal strength information.

7. The system side eNodeB network element transparently transmits information to the system core network device, and the core network device decodes the terminal service model and sends the message to the dormant service management policy server.

After receiving the registration request, the eNodeB network element is transparently transmitted to the core network device. After the core network device decodes the service model network element in the registration signaling message, the eNodeB network element directly sends the message to the dormant service management policy server.

8. The system side sleep service management policy server calculates a reasonable sleep period through the service model.

The sleep service management policy server at least needs to include a service analysis module, a power consumption estimation module, a sleep cycle management module, a battery consumption theory database, an upgrade module, and a communication module. These modules may be one or more processes of the sleep management policy server, and the sleep management policy server derives the theoretical lifetime L of the battery capacity based on the built-in battery consumption theory database. The battery consumption theory database is the theoretical test data of multiple manufacturers' chips, which mainly includes the power corresponding to the transmission power, the current of the PSM state, and the average current data of the standby state.

Assuming that the battery capacity is Ib, the PSM current is Ip, the standby reception state current of the NB-IOT terminal is Ir, and the transmission power tx in the terminal service model is received, and the current corresponding to the transmission power tx in the power consumption model is checked by comparison. The send byte is N. If the power consumption of the terminal per day is Id, the battery life can be calculated by dividing the battery capacity by the daily power consumption, expressed as L=Ib/Id, in units of days.

If the terminal service model is periodically reported and the data period Tdata is less than 24 hours, the key is to calculate the daily power consumption Id. According to the characteristics of the NB-IOT terminal, Id=Ip*t1+Ir*t2+N*It* can be calculated. T3, and t1+t2+t3=24 hours, t1 is the target PSM period value, t2 is the time when the terminal enters standby, t3 is the time when the terminal sends data, t3 is usually the lab manufacturer's laboratory test data or theoretical data, generally Can be considered constant, then the key solution t1, t1 is 24-t2-t3, if in pursuit of the maximum power saving strategy, the smaller the theoretical t2 is more power-saving, and according to the protocol eDRX cycle can be set to a fixed minimum of 12.56 seconds, That is, the smaller t2 is, the larger t1 is, the longer the sleep time of the terminal is, the more power is saved, and finally the optimal solution is obtained.

Similarly, if the sending data period is less than 24 hours and less than 48 hours, the key is to calculate the power consumption every 2 days, and so on. The key to the consumption of Tdata is to calculate the power consumption per (Tdata/24+1) days.

If the terminal service abstraction is event-driven report type or mixed report type, it is not recommended to use PSM, only set the eDRX cycle, because the PSM status is similar to shutdown, the peripheral sensor data is triggered when the power is off, and it is hoped that the data will be sent at this time, but the communication module At this time, it is impossible to directly send data to the network, and only wait for the PSM cycle to time out. If the peripheral hardware circuit forcibly wakes up the terminal to exit the PSM state, the current is much larger than the standby current after the wake-up according to the experimental result, and the PSM frequently wakes up and cannot achieve the purpose of power saving. The present disclosure uses the off PSM to enable only the eDRX cycle policy, and if there is no remote control parameter at this time, the eDRX cycle can be set to the network allowable maximum value, and if there is a remote control interface, it can be set to the maximum tolerance time allowed by the remote control.

In an embodiment, the power consumption estimating module may also be built in the terminal, and the terminal independently estimates the PSM and eDRX cycles. The present disclosure implements the main considerations on the system side in order to facilitate adaptation of multiple manufacturer terminals, and facilitates model upgrade without affecting the terminal. .

9. The system side sleep service management policy server returns the calculation result to the core network device, and the core network device generates a result message to send the eNodeB, and the eNodeB transmits the result to the NB-IOT terminal.

The system side sleep service management policy server returns the calculation result to the core network interface, and the core network device generates an ATTACH reply message and sends the eNodeB to the NB-IOT terminal.

10. The NB-IOT terminal executes the period specified by the sleep parameter.

IMSI_MCC and IMSI_MNC refer to the country code and network code of the SIM card home operator.

IMEI refers to the mobile device international identification code. IMEI is the only identifier that distinguishes mobile devices. It is stored in mobile devices and cannot be rewritten and erased. Usually distributed by the standard organization.

The device classification number is represented by a number indicating that the Meters are 0x1, the Tracker is 0x2, and the Gateway is 0x3.

The expected life of the battery Lexpect refers to the time that the manufacturer expects the battery of the device to be used.

The PSM mode is the UE Power Saving Mode. It is similar to the fake power off state. It keeps the registration status but the signaling is unreachable. It does not need to reattach or re-establish the PDN connection. The main purpose is to save power. It is the 3GPP power saving feature for the Internet of Things. Raised after REL12.

eDRX is an enhanced discontinuous reception. The eDRX is to extend the time period of the original discontinuous reception (DRX), so that the UE can reduce the number and frequency of DRX to achieve more power saving. Power saving characteristics, proposed after REL12.

The NB-IOT business model abstraction module can be one or more business processes inside the terminal, and the NB business model abstraction module has administrator rights and can extract code key information.

Battery capacity, transmission traffic, transmission data cycle, reason for transmitting data, presence of remote control interface, number of peripheral sensor interfaces, sensor classification.

The NB-IOT business abstraction module abstracts the NB-IOT industry application business model into three types: event-driven, periodic reporting, and hybrid reporting based on the business model of different industry applications.

The NB-IOT business model factory library is a scalable terminal local NB business model database. The NB-IOT business model factory library is built into the NB-IOT terminal and contains some common business model parameters.

The terminal registration network ATTACH/RAU signaling message refers to transmitting service data through Long Term Evolution (LTE) signaling bearer, which is different from other Transmission Control Protocol/Internet Protocol (TCP/IP). Protocol, traditional data transmission through data carrier transceiver, this method can save TCP / IP headers to improve transmission efficiency.

The sleep service management policy server needs to include at least a power consumption estimation module and a built-in battery consumption theory database, and the module may be one or more processes of the sleep management policy server, and mainly complete the sleep cycle calculation generation.

The battery consumption theory database is the theoretical test data of multiple manufacturers' chips, which mainly includes the power corresponding to the transmission power, the current of the PSM state, and the average current data of the standby state.

The transmit power corresponds to the power meter, which is the average value of the transmit power used by the NB-IOT terminal at different received signal levels, and the current value measured in the laboratory corresponding to the value.

The PSM state bottom current refers to the average value of the current measured after the NB-IOT terminal enters the PSM state.

The average current data received in the standby state refers to the average value of the current measured after the NB-IOT terminal enters the standby state.

In summary, the present embodiment relates to the field of wireless communications, for example, to an NB-IOT terminal eDRX cycle and a PSM cycle management method in a NB-IOT network in a wireless communication system, because different types of Machine-to-Machine (M2M) devices are based on services. Different types of delays have different requirements. At the same time, different application scenarios of the M2M device have different requirements for the PSM cycle or the eDRX cycle. The traditional static allocation method through the network is not flexible. This embodiment proposes a method for generating the NB-IOT service model. The system classifies the NB-IOT service applications into three categories according to the business field: Meters, Tracker, and Gateway. At the same time, the NB-IOT business model factory library is introduced on the terminal side, and the NB-IOT service is abstracted and selected. The business model of different industries is abstracted into an event-driven and periodic reporting model, and a dormant management policy server is introduced on the system side. The NB-IOT terminal carries abstract service model parameters through signaling messages in the ATTACH process. The device passes the business model parameters to the policy server, and the policy server is based on The policy rule generates a dynamic eDRX or PSM cycle by calculating the service model parameters and calculates the theoretical service life of the parameter corresponding to the service model through the built-in power consumption model, and finally returns the parameters to the NB-IOT terminal, and the terminal calculates and executes different The eDRX and PSM cycles are dormant management.

Through this embodiment, on the one hand, the development threshold and development cycle of the NB-IOT terminal manufacturer can be effectively reduced, so that the NB-IOT terminal manufacturer does not need to understand the details of the communication protocol, and concentrates on the development of the service model, and the system automatically calculates and selects a reasonable sleep period, and finally can Extend the standby time and life cycle of the NB-IOT device. On the other hand, it can perform different sleep parameters for different service type terminals, save network signaling resources, reduce the power consumption of the NB-IOT device, and improve the standby time of the NB-IOT terminal. Product cost increases product competitiveness.

This embodiment provides an NB-IOT service model abstraction method and system, for example, for the management of the NB-IOT terminal eDRX cycle and the PSM cycle in the NB-IOT network, by adopting a preset upgradeable NB service model factory library. According to the characteristics of the NB-IOT industry application domain, the business model XML file of the service is generated by abstract computing, the service model is carried in the NB-IOT terminal and the network interaction process signaling, and the sleep service management policy server is introduced in the core network. The core network device receives the service model signaling message from the terminal, and transmits the service model to the dormant service management policy server by decoding, and the server generates and calculates the dynamically adjustable eDRX and PSM cycle parameters through the service feature and the service requirement. The built-in power consumption model calculates the theoretical service life of the parameter corresponding to the service model, and returns it to the NB-IOT terminal, and the terminal calculates and executes different eDRX and PSM cycles for sleep management. The method can effectively solve the M2M access network load problem, perform different sleep parameters for different service type terminals, save network signaling resources, reduce the power consumption of the NB-IOT device, and improve the standby time of the NB-IOT terminal.

FIG. 4 is a schematic diagram of a service model abstraction system for NB-IOT network sleep cycle management according to an embodiment. In Figure 4, field 401 is an NB-IOT terminal. Field 402 is the access network eNodeB. Field 403 is the carrier core network device. Field 404 is a dormant traffic management policy server.

Exemplary embodiment 2:

Sleep business management policy server embodiment:

FIG. 5 is a schematic diagram of a sleep service management policy server according to an embodiment. As shown in FIG. 5, a sleep service management policy server provided by this embodiment includes: a service analysis module, a power consumption estimation module, a sleep cycle management module, a battery consumption theory database, an upgrade module, and a communication module.

Field 501 is a business analysis module that is responsible for parsing business model elements and extracting business critical data.

Field 502 is a power consumption estimation module that is responsible for calculating the current consumption of the corresponding business model and the sleep period.

Field 503 is a sleep cycle management module responsible for updating the sleep cycle parameters of the corresponding device.

The field 504 is a battery consumption theoretical database, and mainly includes a plurality of manufacturer chip theoretical test data, which mainly includes a power corresponding to the transmission power, a PSM state bottom current, and a standby current average current data.

Field 505 is an upgrade module that is responsible for the upgrade related.

Field 506 is a communication module.

Exemplary Embodiment 3:

Hibernation parameter calculation method embodiment:

FIG. 6 is a flowchart of a method for calculating a service-oriented sleep parameter according to an embodiment. Referring to FIG. 6, the sleep parameter calculation method provided in this embodiment includes the following steps.

Step 601: Determine whether the service model is a periodic report type. If the service model is a periodic report type, go to step 602. If the service model is not a periodic report type, go to step 605.

Step 602: Calculate the transmission period by day.

If the terminal service model is periodically reported, and the data period Tdaa is less than 24 hours, if the data period is less than 24 hours and less than 48 hours, the key is to calculate the power consumption every 2 days, and the key to the consumption of Tdata is the calculation. Every X = (Tdata / 24 + 1) days of power consumption.

Step 603: Calculate the total data transmission time of the transmission period X days.

The time at which the terminal sends data = the total amount of data in X days divided by the theoretical rate of the network. That is, the time required to send N bytes.

Step 604: Calculate the PSM sleep time.

Assuming that the power consumption Id is consumed every day, according to the characteristics of the NB-IOT terminal, Id=Ip*t1+Ir*t2+N*It*t3 can be calculated, and t1+t2+t3=24*X hours.

T1 is the target PSM period value, t2 is the terminal standby time, t3 is the time when the terminal sends data, and t3 is usually the chip manufacturer's laboratory test data or theoretical data, which can generally be considered as a constant.

Assume that the battery capacity is Ib, the PSM current is Ip, the standby reception state current of the NB terminal is Ir, and the transmission power tx in the terminal service model is received, and the current corresponding to the transmission power tx in the power consumption model is checked by comparison, every X days. The send byte is N. If the power consumption of the terminal per day is Id, the battery life can be calculated by dividing the battery capacity by the daily power consumption, expressed as L=Ib/Id, in units of X days.

Then the PSM sleep time is t1, t1 is 24*X-t2-t3. If the pursuit of the maximum power saving strategy, the smaller the theoretical t2 is, the more power is saved, and the eDRX cycle can be set to the fixed minimum value of 12.56 seconds according to the protocol. That is, the smaller t2 is, the larger t1 is, the longer the terminal sleeps, the more power is saved, and finally the optimal solution is obtained.

Step 605: If the service type is event reporting or hybrid reporting, the PSM is closed, and is set to 0.

Step 606: Check whether the service model has a remote control interface. If the service model does not have a remote control interface, step 607 is performed; if the service model has a remote control interface, step 608 is performed.

Step 607: Set the eDRX cycle to the network maximum.

Step 608: Set the eDRX cycle to the remote control interface timeout time.

Step 609: Calculate the power consumption per day.

Step 610: Estimate battery life and time.

Battery life can be calculated by dividing battery capacity by the amount of electricity consumed per day.

Step 611: End.

Exemplary Embodiment 4:

NB-IOT terminal embodiment:

FIG. 7 is a schematic diagram of an NB-IOT terminal according to an embodiment. Referring to FIG. 7, the terminal provided in this embodiment includes the following modules.

701: Initializing module, responsible for initializing multiple modules, reading terminal configuration and related software and hardware information.

702: NB-IOT business model abstraction module.

The NB-IOT business model abstraction module may be one or more business processes inside the terminal, and the NB-IOT business model abstraction module has access code administrator authority, and the module extracts key business code by accessing the terminal device management unit and the service source code. Business critical information.

703: NB-IOT business model factory library.

The NB-IOT business model factory library is a scalable terminal local NB-IOT business model database. The NB business model factory library is built into the NB-IOT terminal and contains some common business model parameters.

704: NB-IOT business model generation module.

The NB-IOT business model generation module calculates and generates a business model of the terminal according to the key information extracted by the service abstraction module, generates a corresponding format business model description file, such as an XML file, and saves the business model in the terminal built-in NB-IOT business model factory library. in.

705: Sleep management module.

The sleep management module is responsible for the startup and maintenance of the sleep timer, and completes the PSM sleep and the timer timeout wakeup action as required by the timer.

706: NB-IOT access module.

Exemplary Embodiment 5:

NB-IOT terminal side business key information embodiment:

FIG. 8 is a schematic diagram of key information of an NB-IOT service according to an embodiment. Referring to FIG. 8, the service key information provided in this embodiment includes the following information.

Field 801 is the device classification number.

The device classification number is represented by numbers. According to the industry field of the terminal application, the NB-IOT service application can be classified into three categories: Meters (0x1), Tracker (0x2), and Gateway (0x3). Meters, that is, meter industry applications, such as water meters, electricity meters, gas meter data collection, saving manual meter reading resources; Tracker, tracking industry applications, such as shared bicycle tracking applications, package tracking, logistics tracking industry applications; Gateway, That is, the gateway application is mainly to assist peripheral devices or sensors to transmit data.

Field 802 is the battery capacity.

Field 803 is a single transmission traffic.

Field 804 is the transmit data period.

Field 805 is the reason for sending data.

Field 806 is the presence of a remote control interface.

Field 807 is the number of peripheral sensor interfaces.

Field 808 is a sensor classification.

Field 809 is the desired battery life.

This key information forms the key data of the business model.

Exemplary Embodiment 6:

NB-IOT terminal side business key information abstract method embodiment.

FIG. 9 is a flowchart of a method for abstracting key information of a NB-IOT terminal service according to an embodiment. Referring to FIG. 9, the method provided in this embodiment includes the following steps.

Step 901: The NB-IOT service abstraction module is initialized.

Step 902: Start static analysis.

Step 903: Perform source code parsing.

Step 904: Retrieve key data keyword information.

Step 905: Compile a keyword information index.

Step 906: Check the index information. If it is the PSM-related index information, go to step 907. If it is PSM-independent index information, go to step 908.

Step 907: Extract sleep parameter information.

Step 908: Check whether there is a data sending interface. If there is a data sending interface, go to step 909; if there is no data sending interface, go to step 910.

Step 909: Extract the reason for sending the data.

Step 910: Check if there is a remote control interface. If there is a remote control interface, go to step 911. If there is no remote control interface, go to step 912.

Step 911: Extract remote control interface parameters.

Step 912: Perform dynamic analysis.

Step 913: Extract the prototype classification number.

Step 914: Extract the peripheral information of the prototype, the number of batteries, the number of sensors, and the type information.

Step 915: End.

Exemplary Embodiment 7:

NB-IOT terminal side service model classification method embodiment

Please refer to FIG. 10. FIG. 10 is a flowchart of a NB-IOT terminal service model classification method according to an embodiment. The method provided in this embodiment includes the following steps.

Step 1001: Check the data transmission cause identifier.

Step 1002: Check if the timer expires. If it times out, go to step 1003. If there is no timeout, go to step 1004.

Step 1003: Periodic report type.

Step 1004: Check if the sensor is triggered, if yes, go to step 1005; if it is not the sensor trigger, go to step 1006.

Step 1005: Event triggered type.

Step 1006: Check if there is both a sensor trigger and a timer timeout reason. If yes, go to step 1007; if there is no sensor trigger or timer timeout reason, go to step 1008.

Step 1007: Mix the report type.

Step 1008: End.

Exemplary Embodiment 8:

NB-IOT terminal side business model calculation method embodiment

Please refer to FIG. 11. FIG. 11 is a flowchart of a NB-IOT terminal service model calculation method according to an embodiment. The method provided in this embodiment includes the following steps.

Step 1101: The NB-IOT terminal device is initialized, and the initialization module acquires device information.

Step 1102: The NB-IOT business model abstraction module extracts business key information.

The NB-IOT business model abstraction module may be one or more business processes inside the terminal, and the NB-IOT business model abstraction module has access code administrator authority, and the module extracts key business code by accessing the terminal device management unit and the service source code. Business critical information, such as sending data, receiving data, entering PSM, exiting PSM, timer timeout and other source code, extracting information including: battery capacity, sending traffic, sending data cycle, reason for sending data, presence of remote control interface, peripheral Number of sensor interfaces, sensor classification. This key information forms the key data of the business model.

Step 1103: The NB-IOT business model abstraction module confirms the business model according to key information characteristics.

The NB-IOT service abstraction module abstracts the NB-IOT industry application business model into event-driven, periodic report-type and hybrid report-type models according to the business model of different industry applications, and confirms different business models by judging the reason for sending data. When the reason for sending data is that the timer expires, the service model is confirmed to be a periodic report type; when the reason for transmitting data is triggered by a peripheral sensor, the service model is confirmed to be an event-driven report type; If the device times out and there is a sensor trigger, the business model is confirmed to be a mixed report type.

Step 1104: The NB-IOT service model abstraction module requests to match the NB-IOT service model factory library according to the service model and key parameters. If the matching succeeds, step 1106 is performed; if the matching fails, step 1105 is performed.

The NB-IOT business model factory library is a scalable terminal local NB-IOT business model database. The NB-IOT business model factory library is built into the NB-IOT terminal and contains some common business model parameters if the terminal can retrieve If the service model is matched, the PSM and eDRX cycle parameters corresponding to the service model are directly executed, and the parameter is used as the default setting; if the service model cannot be matched, it is directly transmitted to the service generation module.

Step 1105: The NB-IOT service model generation module calculates and generates a service model of the terminal according to the key information extracted by the service abstraction module.

Step 1106: The NB-IOT access module extracts the service model and adds it to the system side eNodeB in the NB-IOT terminal signaling message element.

Exemplary Embodiment 9:

NB-IOT terminal and system interaction method embodiment:

The present embodiment provides an embodiment of a method for interacting with a NB-IOT terminal and a system, including the following steps.

Step 11101: The terminal carries a service model element, and constructs an ATTACH request message sending network.

Step 11102: The eNB transparently transmits the message to the core network device.

Step 11103: The core network device parses the service model element to send the dormancy policy server.

Step 11104: The sleep policy module calculates a sleep parameter according to the service model.

Step 11105: The calculation result is sent to the core network device.

Step 11106: The core network device generates a reply message.

Step 11107: The eNB transparently transmits a message to the terminal.

Step 11108: The terminal performs a sleep policy according to the calculation result.

Through the above embodiments, on the one hand, the development threshold and development cycle of the NB-IOT terminal manufacturer can be effectively reduced, so that the NB terminal manufacturer does not need to understand the details of the communication protocol, and concentrates on the development of the service model, and the system automatically calculates and selects a reasonable sleep period, and finally can extend the NB. - IOT device standby time and life cycle, on the other hand, different sleep parameters can be executed for different service type terminals, saving network signaling resources, reducing power consumption of NB-IOT devices, increasing standby time of NB-IOT terminals, and reducing product cost. Improve product competitiveness.

Through the description of the above embodiments, those skilled in the art can understand that the method according to the foregoing embodiment can be implemented by means of software plus a general hardware platform, or by hardware. Based on such understanding, the technical solution of the present disclosure may be embodied in the form of a software product stored in a storage medium (such as Read-Only Memory (ROM) / Random Access Memory (Random Access Memory). , RAM, disk, CD-ROM, including a plurality of instructions for causing a terminal device (which may be a cell phone, a computer, a server, or a network device, etc.) to perform the method described in any of the embodiments of the present disclosure.

Example 2

In this embodiment, a device for setting a sleep period of a service is also provided, and the device is used to implement the foregoing embodiment, and details are not described herein. As used below, the term "module" may implement a combination of software and/or hardware of a predetermined function. Although the devices described in the following embodiments may be implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.

FIG. 12 is a structural block diagram of a setting device for a sleep cycle according to an embodiment. As shown in FIG. 12, the device includes: a first determining module 1202, an obtaining module 1204, and a setting module 1206. The device will be described below.

The first determining module 1202 is configured to determine a service model of the device based on the service information of the device, where the service model is used to identify a type of the service, and the obtaining module 1204 is connected to the first determining module 1202 in the foregoing, and is configured to obtain The sleep parameter of the service corresponding to the foregoing service model; the setting module 1206 is connected to the obtaining module 1204 in the above, and is configured to set a sleep period of the service based on the sleep parameter.

In an embodiment, the foregoing apparatus further includes: a service information acquiring module, configured to determine, according to the device-based service information, the service information of the device, by determining the service information of the device by: determining the type of the device; The service information corresponding to the type of the device, where the service information is related to the sleep parameter.

In an embodiment, the first determining module 1202 is configured to determine the service model of the device based on the device-based service information by determining the service model according to the reason for performing the foregoing service included in the foregoing service information, where The foregoing service model includes one of the following: when the reason for executing the foregoing service is that the timer expires, the service model is determined to be event-driven; and when the reason for executing the service is triggered by the sensor, determining that the service model is Periodic report type; when the reason for executing the above service is timer timeout and sensor triggering, it is determined that the foregoing service model is a mixed report type.

In an embodiment, the obtaining module 1204 is configured to obtain a sleep parameter of the foregoing service corresponding to the foregoing service model by acquiring the foregoing preset in response to determining that the service model is found in a preset database. The sleep parameter corresponding to the foregoing service model in the database; or, in response to determining that the service model is not found in the preset database, sending the sleep parameter request message to the core network device through the access network; The dormant parameter returned by the core network device after the dormancy parameter of the service is determined by the network device according to the service information of the device, where the dormant parameter request message includes the service information of the device.

In an embodiment, the device further includes a storage module, configured to: after receiving the sleep parameter returned by the core network after determining the sleep parameter of the service according to the service information of the device, the sleep parameter and the service The model is correspondingly stored in the above preset database.

In one embodiment, the service information includes at least one of the following: a battery capacity of the device, a sending traffic of the device, a period in which the device sends data, a reason for the device to send data, and a remote control interface information of the device, The number of peripheral sensor interfaces of the above device, the sensor classification of the above device, the power of the data transmitted by the device, and the strength information of the signal received by the device.

In one embodiment, the sleep parameter includes at least one of the following: a power save mode PSM, an enhanced discontinuous receive eDRX.

FIG. 13 is a structural block diagram of another apparatus for setting a sleep period according to an embodiment. As shown in FIG. 13, the apparatus includes: a receiving module 1302, a second determining module 1304, and a sending module 1306. Description.

The receiving module 1302 is configured to receive the sleep parameter request message sent by the terminal through the access network, and the second determining module 1304 is connected to the receiving module 1302 in the foregoing, and is configured to determine, according to the service information of the device carried in the sleep parameter request message. a dormant parameter of the service corresponding to the service model of the device, where the service model is determined by the terminal based on the service information of the device, and is used to identify the type of the service; the sending module 1306 is connected to the second determining module 1304, And being configured to send the sleep parameter to the terminal by using the foregoing access network, to instruct the terminal to set a sleep period of the service by using the sleep parameter.

In an embodiment, the second determining module 1304 is further configured to determine a service model of the device according to the service information of the device, where the service model includes one of the following: an event-driven type in which the service is executed because the timer expires. The reason for performing the above-mentioned service is the periodic report type when the sensor is triggered. The reason for executing the above-mentioned service is the mixed report type when the timer expires and the sensor is triggered; the sleep parameter is determined based on the type of the service model.

The above multiple modules may be implemented by software or hardware. For the latter, the foregoing may be implemented by, but not limited to, the above multiple modules are all located in the same processor; or, the above multiple modules are in any combination. The forms are located in different processors.

The embodiment further provides a storage medium in which a computer program is stored, the computer program being arranged to execute any of the above methods at runtime.

In the present embodiment, the above storage medium may be arranged to store a computer program for performing any of the above steps.

In this embodiment, the foregoing storage medium may include, but is not limited to, at least one medium that can store a computer program, such as a USB flash drive, a ROM, a RAM, a mobile hard disk, a magnetic disk, or an optical disk.

The embodiment further provides an electronic device comprising a memory and a processor, the memory storing a computer program, the processor being arranged to run a computer program to perform any of the above methods.

In an embodiment, the electronic device may further include a transmission device and an input and output device, wherein the transmission device is connected to the processor, and the input and output device is connected to the processor.

In an embodiment, the processor may be arranged to perform any of the above steps by a computer program.

For specific examples in this embodiment, reference may be made to the examples described in the foregoing embodiments and exemplary embodiments, and details are not described herein again.

The at least one module or at least one step of the above-described disclosure may be implemented by a general-purpose computing device, and the at least one module or at least one step may be centralized on a single computing device or distributed over a network of multiple computing devices. . In an embodiment, the at least one module or at least one step may be implemented by program code executable by the computing device, such that the at least one module or at least one step may be stored in the storage device to be executed by the computing device, and In some cases, the steps shown or described may be performed in an order different than that herein, or the at least one module or the at least one step described above may be separately fabricated into at least one integrated circuit module, or at least one of the above-described at least one module or at least At least one of the steps or steps in a step is fabricated as a single integrated circuit module. As such, the disclosure is not limited to any specific combination of hardware and software.

Claims

A method for setting a sleep cycle of a service, including:

Determining a service model of the device based on the service information of the device, where the service model is used to identify a type of the service;

Obtaining a sleep parameter of the service corresponding to the service model;

A sleep period of the service is set based on the sleep parameter.
The method according to claim 1, before determining the service model of the device based on the service information of the device, further comprising: determining service information of the device by:

Determining the type of the device;

Obtaining the service information corresponding to the type of the device, where the service information is related to the sleep parameter.
The method according to claim 1 or 2, wherein determining the service model of the device based on the service information of the device comprises:

Determining the service model according to a reason for performing the service included in service information of the device, where the service model includes one of the following:

When the reason for executing the service is that the timer expires, determining that the service model is event-driven;

When the reason for executing the service is a sensor triggering, determining that the service model is a periodic report type;

In the case that the reason for executing the service is timer timeout and sensor triggering, it is determined that the service model is a hybrid report type.
The method of claim 1, wherein acquiring a sleep parameter of the service corresponding to the service model comprises:

Acquiring to obtain the service model in the preset database, and acquiring a sleep parameter of the service corresponding to the service model in the preset database; or

Responding to determining that the service model is not found in the preset database, sending a dormancy parameter request message to the core network device through the access network; and receiving the core network device to determine the service according to the service information of the device The dormancy parameter is returned by the access network, and the dormant parameter request message includes the service information of the device.
The method according to claim 4, after receiving the sleep parameter returned by the access network after the core network device determines the sleep parameter of the service according to the service information of the device, the method further includes:

And storing the sleep parameter in the preset database corresponding to the service model.
The method of claim 1, wherein the service information comprises at least one of the following:

The battery capacity of the device, the sending traffic of the device, the period during which the device sends data, the reason for the device to send data, the remote control interface information of the device, and the number of peripheral sensor interfaces of the device The sensor classification of the device, the power of the device to transmit data, and the strength information of the device receiving the signal.
The method of any of claims 1-6, wherein the sleep parameter comprises at least one of:

Power save mode PSM cycle, and enhanced discontinuous receive eDRX cycle.
The method of any of claims 1-7, wherein the device is a device applied in a narrowband Internet of Things NB-IOT terminal.
A method for setting a sleep cycle of a service, including:

Receiving, by the access network, a sleep parameter request message sent by the terminal;

And determining, according to the service information of the device carried in the dormant parameter request message, a dormancy parameter of the service corresponding to the service model of the device, where the service model is determined by the terminal based on the service information of the device, and is used to identify Type of business;

And sending the dormant parameter to the terminal by using the access network to instruct the terminal to set a sleep period of the service by using the dormant parameter.
The method of claim 9, wherein determining a sleep parameter of the service corresponding to the service model of the device according to the service information of the device comprises:

Determining a service model of the device according to the service information of the device, where the service model includes one of the following: the reason for executing the service is an event-driven type in which the timer expires, and the reason for executing the service is a sensor trigger. The periodic report type of the time, the reason for executing the service is a mixed report type when the timer expires and the sensor is triggered;

Determining a sleep parameter of the service corresponding to the service model based on the service model.
The method of claim 9, wherein the service information comprises at least one of the following:

The battery capacity of the device, the transmission traffic of the device, the data transmission period of the device, the reason for the device to send data, the remote control interface information of the device, and the number of peripheral sensor interfaces of the device The classification of the sensor of the device, the power of the device to transmit data, and the strength information of the device receiving the signal.
The method of any of claims 9-11, wherein the sleep parameter comprises at least one of:

Power save mode PSM cycle, and enhanced discontinuous receive eDRX cycle.
A method according to any of claims 9-12, wherein the device is a device applied in a narrowband Internet of Things NB-IOT terminal.
A device for setting a sleep period of a service, comprising:

a determining module, configured to determine a service model of the device based on service information of the device, where the service model is used to identify a type of the service;

An obtaining module, configured to acquire a sleep parameter of the service corresponding to the service model;

And a setting module, configured to set a sleep period of the service based on the sleep parameter.
A device for setting a sleep period of a service, comprising:

a receiving module, configured to receive, by using an access network, a sleep parameter request message sent by the terminal;

a determining module, configured to determine, according to service information of the device carried in the dormant parameter request message, a dormancy parameter of a service corresponding to a service model of the device, where the service model is determined by the terminal based on service information of the device Used to identify the type of business;

And a sending module, configured to send the sleep parameter to the terminal by using the access network, to instruct the terminal to set a sleep period of the service by using the sleep parameter.
A storage medium storing a computer program, the computer program being arranged to perform the method of any one of claims 1 to 8 at runtime, or the computer program being arranged to execute claim 9 at runtime The method described in any of the items 13.
An electronic device comprising a memory and a processor, wherein the memory stores a computer program, the processor being arranged to execute the computer program to perform the method of any one of claims 1 to 8, or The processor is arranged to execute the computer program to perform the method of any one of claims 9 to 13.