CN113542380A - 一种高效能的心跳保活方法 - Google Patents
一种高效能的心跳保活方法 Download PDFInfo
- Publication number
- CN113542380A CN113542380A CN202110763032.7A CN202110763032A CN113542380A CN 113542380 A CN113542380 A CN 113542380A CN 202110763032 A CN202110763032 A CN 202110763032A CN 113542380 A CN113542380 A CN 113542380A
- Authority
- CN
- China
- Prior art keywords
- heartbeat packet
- heartbeat
- master device
- slave
- slave device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
- H04L67/145—Termination or inactivation of sessions, e.g. event-controlled end of session avoiding end of session, e.g. keep-alive, heartbeats, resumption message or wake-up for inactive or interrupted session
Abstract
本发明公开了一种高效能的心跳保活方法，包括以下具体步骤：步骤一：从设备周期性地向主设备发送心跳包，发送周期为T0；步骤二：主设备等待接收从设备发送的心跳包，并同步计时；步骤三：主设备判断等待接收心跳包时长是否超过预设值，若未超时，则将心跳包请求次数记为0，若超时，则需进一步判断心跳包请求次数；步骤四：在主设备判断心跳包请求超时后，查询心跳包请求次数是否超过心跳包请求次数上限N，若心跳包请求次数小于N，则主动向从设备发送心跳包请求消息，并将心跳包请求次数累加1；若心跳包请求次数大于N，则确定从设备已掉线。本发明使得心跳保活机制可以在不增加网络资源消耗的情况下，大幅提高主设备发现从设备掉线事件的响应效率。
Description
技术领域
本发明涉及信号传输技术领域，尤其涉及心跳保活方法。
背景技术
在电子技术领域，一个系统当中通常有多个功能模块共同协作，才能使整个系统正常地对外提供服务。而确定系统中的每一个功能模块的运行状态是否正常，则需要有相应的功能模块状态监测机制，业内通常的做法就是采用心跳保活机制。
在传统的心跳保活机制中，在系统当中设有一个专门负责管理其他所有功能模块的特殊功能模块，它通常被称为主设备，而其余的功能模块则被称为从设备。在这样的一套系统当中，从设备只需要周期性地向主设备发送心跳包。与之对应的，主设备只需要被动地接收从设备发来的心跳包，并且在收到心跳包的时候将心跳保活超时时长置为零即可。
然而，以上技术方案的网络资源消耗和响应效率是无法兼顾的。
如果将心跳包收发周期设置得较小，则可以提高系统的响应效率，但是网络资源的消耗会增加；如果将心跳包收发周期设置得较大，则可以减少网络资源的消耗，但是系统的响应效率会下降。
发明内容
本发明的目的在于克服现有心跳保活机制不能兼顾网络资源消耗和响应效率的问题，提供一种高效能的心跳保活方法，当主设备接收从设备心跳包超时的时候，主动向从设备发起询问。
本发明的目的是通过以下技术方案来实现的：
一种高效能的心跳保活方法，包括以下具体步骤：
步骤一：从设备周期性地向主设备发送心跳包，发送周期为T0；
步骤二：主设备等待接收从设备发送的心跳包，并同步计时；
步骤三：主设备判断等待接收心跳包时长是否超过预设值，若未超时，则将心跳包请求次数记为0，若超时，则需进一步判断心跳包请求次数；
步骤四：在主设备判断心跳包请求超时后，查询心跳包请求次数是否超过心跳包请求次数上限N，若心跳包请求次数小于N，则主动向从设备发送心跳包请求消息，并将心跳包请求次数累加1；若心跳包请求次数大于N，则确定从设备已掉线。
步骤二中所述同步计时具体为主设备在从设备传输心跳包的同时进行计时。
所述主设备等待心跳包时长预设值为T0+T1，T0为从设备心跳包发送周期时间，T1为心跳包传输时长。
所述T0和T1根据实际应用进行调节。
本发明的有益效果：
本发明兼顾了网络资源消耗和响应效率，使得心跳保活机制可以在不增加网络资源消耗的情况下，大幅提高主设备发现从设备掉线事件的响应效率。
附图说明
图1是本发明的方法流程图；
图2是传统从设备周期性发送心跳包流程图；
图3是传统主设备响应心跳包消息流程图；
图4是传统主设备等待心跳包流程图；
图5是从设备响应心跳包请求消息流程图。
具体实施方式
为了对本发明的技术特征、目的和效果有更加清楚的理解，现对照附图说明本发明的具体实施方式。
首先定义几个必要的常量：
| T0 | 心跳包发送周期 |
| T1 | 心跳包传输时长上限 |
| T2 | 心跳超时时长上限 |
| T3 | 消息接收周期 |
| N | 心跳包请求次数上限 |
表1常量定义列表
实施例1，如图1所示，一种高效能的心跳保活方法，包括以下具体步骤：
步骤一：从设备周期性地向主设备发送心跳包，发送周期为T0；
步骤二：主设备等待接收从设备发送的心跳包，并同步计时；
步骤三：主设备判断等待接收心跳包时长是否超过预设值，若未超时，则将心跳包请求次数记为0，若超时，则需进一步判断心跳包请求次数；
步骤四：在主设备判断心跳包请求超时后，查询心跳包请求次数是否超过心跳包请求次数上限N，若心跳包请求次数小于N，则主动向从设备发送心跳包请求消息，并将心跳包请求次数累加1；若心跳包请求次数大于N，则确定从设备已掉线。
步骤二中所述同步计时具体为主设备在从设备传输心跳包的同时进行计时。
所述主设备等待心跳包时长预设值为T0+T1，T0为从设备心跳包发送周期时间，T1为心跳包传输时长。
所述T0和T1根据实际应用进行调节。
在传统的心跳保活机制当中，如图2所示，从设备只需要周期性地向主设备发送心跳包；相应的，如图3所示，主设备也只需要被动地接收从设备发来的心跳包；当主设备发现心跳超时时长达到一定程度的时候，如图4所示，则可以断定从设备已经掉线。
在本发明中，从设备除了周期性地向主设备发送心跳包之外，还需要响应主设备发送来的心跳包请求消息。也就是说，从设备除了周期性地向主设备发送心跳包之外，还需要在收到主设备发来的心跳包请求消息的时候立即向主设备发送一个心跳包消息，其运行逻辑的流程图如附图5所示。
与之对应的，主设备也不再只是如附图4所示的流程图那样只是被动地等待心跳超时。而是在发现心跳超时时长达到从设备发送心跳包周期的时候，主动地向从设备发出心跳包请求消息，以便于快速地确认从设备当前是否在线，其运行逻辑的流程图如附图1所示。
简而言之，在传统的心跳保活机制当中，主设备的运行逻辑如附图3和附图 4所示，从设备的运行逻辑如附图2所示；在本发明的技术方案当中，主设备的运行逻辑如附图1和附图3所示，从设备的运行逻辑如附图2和附图5所示。
首先假定应用场景为通信基站内的软件系统，主设备为OAM进程，从设备为 PDCP进程。
这里需要注意的是，此处为便于表述，仅选择众多业务进程中的一个作为本实施例中的从设备。如果需要使OAM进程可以监测其他业务进程的运行状态，其实施方式与本实施例相同。
本实施例中，主设备为OAM进程，从设备为PDCP进程，定义心跳包发送周期T0为30s，心跳包传输时长上限T1为1s，心跳超时时长上限T2为90s，消息接收周期T3为0.1s，心跳包请求次数上限为3。
当从设备PDCP进程在线时，由于从设备PDCP进程会周期性地向主设备OAM 进程发送心跳包，从设备PDCP进程和主设备OAM进程之间仅需要每隔30s进行一次心跳包的收发操作。在此情景之下，本技术方案的表现与传统心跳保活机制完全一致。
当从设备PDCP进程掉线时主设备OAM进程将在等待31s(即T0+T1)之后，发现心跳包已超时，此时的主设备OAM进程将会以每秒1次的频率向从设备PDCP 进程发送心跳包请求消息。如果在此过程当中，主设备OAM进程接收到了来自从设备PDCP进程的心跳包，则重新回到被动等待从设备心跳包的循环当中。如果主设备OAM进程在连续3次向从设备PDCP进程发送心跳包请求消息之后，仍然没有接收到任何一个来自于从设备PDCP进程的心跳包，则可以断定从设备 PDCP进程已经掉线。
综上所述，当从设备PDCP进程在线的时候，本技术方案与传统的心跳保活机制一样，只需每隔30s进行一次心跳包的收发操作，因此网络资源消耗与传统的心跳保活机制相同。当从设备PDCP进程掉线的时候，传统心跳保活机制需要等待90s之后才能断定从设备PDCP进程已经掉线，而本技术方案仅需要 33s(30s+3*1s)即可断定从设备PDCP进程已经掉线，响应效率相较传统心跳保活机制大幅提升。
实施例2，如图1所示，一种高效能的心跳保活方法，包括以下具体步骤：
步骤一：从设备周期性地向主设备发送心跳包，发送周期为T0；
步骤二：主设备等待接收从设备发送的心跳包，并同步计时；
步骤三：主设备判断等待接收心跳包时长是否超过预设值，若未超时，则将心跳包请求次数记为0，若超时，则需进一步判断心跳包请求次数；
步骤四：在主设备判断心跳包请求超时后，查询心跳包请求次数是否超过心跳包请求次数上限N，若心跳包请求次数小于N，则主动向从设备发送心跳包请求消息，并将心跳包请求次数累加1；若心跳包请求次数大于N，则确定从设备已掉线。
步骤二中所述同步计时具体为主设备在从设备传输心跳包的同时进行计时。
所述主设备等待心跳包时长预设值为T0+T1，T0为从设备心跳包发送周期时间，T1为心跳包传输时长。
所述T0和T1根据实际应用进行调节。
在传统的心跳保活机制当中，如图2所示，从设备只需要周期性地向主设备发送心跳包；相应的，如图3所示，主设备也只需要被动地接收从设备发来的心跳包；当主设备发现心跳超时时长达到一定程度的时候，如图4所示，则可以断定从设备已经掉线。
在本发明中，从设备除了周期性地向主设备发送心跳包之外，还需要响应主设备发送来的心跳包请求消息。也就是说，从设备除了周期性地向主设备发送心跳包之外，还需要在收到主设备发来的心跳包请求消息的时候立即向主设备发送一个心跳包消息，其运行逻辑的流程图如附图5所示。
与之对应的，主设备也不再只是如附图4所示的流程图那样只是被动地等待心跳超时。而是在发现心跳超时时长达到从设备发送心跳包周期的时候，主动地向从设备发出心跳包请求消息，以便于快速地确认从设备当前是否在线，其运行逻辑的流程图如附图1所示。
简而言之，在传统的心跳保活机制当中，主设备的运行逻辑如附图3和附图 4所示，从设备的运行逻辑如附图2所示；在本发明的技术方案当中，主设备的运行逻辑如附图1和附图3所示，从设备的运行逻辑如附图2和附图5所示。
首先假定应用场景为通信基站内的软件系统，主设备为OAM进程，从设备为 PDCP进程。
这里需要注意的是，此处为便于表述，仅选择众多业务进程中的一个作为本实施例中的从设备。如果需要使OAM进程可以监测其他业务进程的运行状态，其实施方式与本实施例相同。
本实施例中，主设备为OAM进程，从设备为PDCP进程，定义心跳包发送周期T0为20s，心跳包传输时长上限T1为2s，心跳超时时长上限T2为60s，消息接收周期T3为0.1s，心跳包请求次数上限为3。
当从设备PDCP进程在线时，由于从设备PDCP进程会周期性地向主设备OAM 进程发送心跳包，从设备PDCP进程和主设备OAM进程之间仅需要每隔20s进行一次心跳包的收发操作。在此情景之下，本技术方案的表现与传统心跳保活机制完全一致。
当从设备PDCP进程掉线时主设备OAM进程将在等待22s(即T0+T1)之后，发现心跳包已超时，此时的主设备OAM进程将会以每两秒1次的频率向从设备 PDCP进程发送心跳包请求消息。如果在此过程当中，主设备OAM进程接收到了来自从设备PDCP进程的心跳包，则重新回到被动等待从设备心跳包的循环当中。如果主设备OAM进程在连续3次向从设备PDCP进程发送心跳包请求消息之后，仍然没有接收到任何一个来自于从设备PDCP进程的心跳包，则可以断定从设备 PDCP进程已经掉线。
综上所述，当从设备PDCP进程在线的时候，本技术方案与传统的心跳保活机制一样，只需每隔20s进行一次心跳包的收发操作，因此网络资源消耗与传统的心跳保活机制相同。当从设备PDCP进程掉线的时候，传统心跳保活机制需要等待90s之后才能断定从设备PDCP进程已经掉线，而本技术方案仅需要 26s(20s+3*2s)即可断定从设备PDCP进程已经掉线。
本实施例克服现有心跳保活机制不能兼顾网络资源消耗和响应效率的问题。当主设备接收从设备心跳包超时的时候，主动向从设备发起询问，兼顾了网络资源消耗和响应效率，使得心跳保活机制可以在不增加网络资源消耗的情况下，大幅提高主设备发现从设备掉线事件的响应效率。
实施例3，如图1所示，一种高效能的心跳保活方法，包括以下具体步骤：
步骤一：从设备周期性地向主设备发送心跳包，发送周期为T0；
步骤二：主设备等待接收从设备发送的心跳包，并同步计时；
步骤三：主设备判断等待接收心跳包时长是否超过预设值，若未超时，则将心跳包请求次数记为0，若超时，则需进一步判断心跳包请求次数；
步骤四：在主设备判断心跳包请求超时后，查询心跳包请求次数是否超过心跳包请求次数上限N，若心跳包请求次数小于N，则主动向从设备发送心跳包请求消息，并将心跳包请求次数累加1；若心跳包请求次数大于N，则确定从设备已掉线。
步骤二中所述同步计时具体为主设备在从设备传输心跳包的同时进行计时。
所述主设备等待心跳包时长预设值为T0+T1，T0为从设备心跳包发送周期时间，T1为心跳包传输时长。
所述T0和T1根据实际应用进行调节。
在传统的心跳保活机制当中，如图2所示，从设备只需要周期性地向主设备发送心跳包；相应的，如图3所示，主设备也只需要被动地接收从设备发来的心跳包；当主设备发现心跳超时时长达到一定程度的时候，如图4所示，则可以断定从设备已经掉线。
在本发明中，从设备除了周期性地向主设备发送心跳包之外，还需要响应主设备发送来的心跳包请求消息。也就是说，从设备除了周期性地向主设备发送心跳包之外，还需要在收到主设备发来的心跳包请求消息的时候立即向主设备发送一个心跳包消息，其运行逻辑的流程图如附图5所示。
与之对应的，主设备也不再只是如附图4所示的流程图那样只是被动地等待心跳超时。而是在发现心跳超时时长达到从设备发送心跳包周期的时候，主动地向从设备发出心跳包请求消息，以便于快速地确认从设备当前是否在线，其运行逻辑的流程图如附图1所示。
简而言之，在传统的心跳保活机制当中，主设备的运行逻辑如附图3和附图 4所示，从设备的运行逻辑如附图2所示；在本发明的技术方案当中，主设备的运行逻辑如附图1和附图3所示，从设备的运行逻辑如附图2和附图5所示。
本实施例中，主设备为OAM进程，从设备为SDAP进程，定义心跳包发送周期T0为30s，心跳包传输时长上限T1为1s，心跳超时时长上限T2为90s，消息接收周期T3为0.1s，心跳包请求次数上限为3。
当从设备SDAP进程在线时，由于从设备SDAP进程会周期性地向主设备OAM 进程发送心跳包，从设备SDAP进程和主设备OAM进程之间仅需要每隔30s进行一次心跳包的收发操作。在此情景之下，本技术方案的表现与传统心跳保活机制完全一致。
当从设备SDAP进程掉线时主设备OAM进程将在等待31s(即T0+T1)之后，发现心跳包已超时，此时的主设备OAM进程将会以每秒1次的频率向从设备PDCP 进程发送心跳包请求消息。如果在此过程当中，主设备OAM进程接收到了来自从设备SDAP进程的心跳包，则重新回到被动等待从设备心跳包的循环当中。如果主设备OAM进程在连续3次向从设备SDAP进程发送心跳包请求消息之后，仍然没有接收到任何一个来自于从设备SDAP进程的心跳包，则可以断定从设备 SDAP进程已经掉线。
综上所述，当从设备SDAP进程在线的时候，本技术方案与传统的心跳保活机制一样，只需每隔30s进行一次心跳包的收发操作，因此网络资源消耗与传统的心跳保活机制相同。当从设备SDAP进程掉线的时候，传统心跳保活机制需要等待90s之后才能断定从设备SDAP进程已经掉线，而本技术方案仅需要 33s(30s+3*1s)即可断定从设备SDAP进程已经掉线，响应效率相较传统心跳保活机制大幅提升。
本发明具有广泛应用价值，实施例3选取其他业务进程作为本实施例中的从设备，使OAM进程可以监测SDAP进程的运行状态。
以上显示和描述了本发明的基本原理和主要特征和本发明的优点，本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护的范围由所附的权利要求书及其等效物界定。
Claims (6)
1.一种高效能的心跳保活方法，其特征在于，包括以下具体步骤：
步骤一：从设备周期性地向主设备发送心跳包，发送周期为T0；
步骤二：主设备等待接收从设备发送的心跳包，并同步计时；
步骤三：主设备判断等待接收心跳包时长是否超过预设值，若未超时，则将心跳包请求次数记为0，若超时，则需进一步判断心跳包请求次数；
步骤四：在主设备判断心跳包请求超时后，查询心跳包请求次数是否超过心跳包请求次数上限N，若心跳包请求次数小于N，则主动向从设备发送心跳包请求消息，并将心跳包请求次数累加1；若心跳包请求次数大于N，则确定从设备已掉线。
2.根据权利要求1所述的一种高效能的心跳保活方法，其特征在于，步骤二中所述同步计时具体为主设备在从设备传输心跳包的同时进行计时。
3.根据权利要求1所述的一种高效能的心跳保活方法，其特征在于，所述主设备等待心跳包时长预设值为T0+T1，T0为从设备心跳包发送周期时间，T1为心跳包传输时长。
4.根据权利3所述的一种高效能的心跳保活方法，其特征在于，所述T0和T1根据实际应用进行调节。
5.根据权利要求1所述的一种高效能的心跳保活方法，其特征在于，步骤四中所述主设备主动向从设备发送心跳包请求消息的频率根据具体工作情况进行可选择设置。
6.根据权利要求1所述的一种高效能的心跳保活方法，其特征在于，所述主设备为OAM进程。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110763032.7A CN113542380A (zh) | 2021-07-06 | 2021-07-06 | 一种高效能的心跳保活方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110763032.7A CN113542380A (zh) | 2021-07-06 | 2021-07-06 | 一种高效能的心跳保活方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113542380A true CN113542380A (zh) | 2021-10-22 |
Family
ID=78126920
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110763032.7A Pending CN113542380A (zh) | 2021-07-06 | 2021-07-06 | 一种高效能的心跳保活方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113542380A (zh) |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1411247A (zh) * | 2001-09-29 | 2003-04-16 | 华为技术有限公司 | 互联网个人号码业务中“心跳”技术的实现方法 |
| US20070192652A1 (en) * | 2006-02-14 | 2007-08-16 | International Business Machines Corporation | Restricting devices utilizing a device-to-server heartbeat |
| CN101610529A (zh) * | 2009-07-16 | 2009-12-23 | 中兴通讯股份有限公司 | 策略控制系统和通信系统中的策略控制方法 |
| CN105635248A (zh) * | 2015-12-18 | 2016-06-01 | Tcl集团股份有限公司 | 一种tcp连接资源的释放方法及系统 |
| US20160165463A1 (en) * | 2014-12-03 | 2016-06-09 | Fortinet, Inc. | Stand-by controller assisted failover |
| CN109150588A (zh) * | 2018-07-25 | 2019-01-04 | 河北华沃通信科技有限公司 | 设备管理方法及装置 |
| CN110768844A (zh) * | 2019-10-31 | 2020-02-07 | 杭州迪普科技股份有限公司 | 一种认证服务器切换方法及装置 |
| CN110974204A (zh) * | 2019-12-25 | 2020-04-10 | 杭州涂鸦信息技术有限公司 | 一种实现双向心跳机制的方法及其系统和装置 |
| CN111181804A (zh) * | 2019-12-20 | 2020-05-19 | 中移（杭州）信息技术有限公司 | 智能设备离线状态自动检测方法、装置、电子设备及介质 |
| US20210126828A1 (en) * | 2019-10-23 | 2021-04-29 | Cisco Technology, Inc. | Integrity verification for managing network configurations |
-
2021
- 2021-07-06 CN CN202110763032.7A patent/CN113542380A/zh active Pending
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1411247A (zh) * | 2001-09-29 | 2003-04-16 | 华为技术有限公司 | 互联网个人号码业务中“心跳”技术的实现方法 |
| US20070192652A1 (en) * | 2006-02-14 | 2007-08-16 | International Business Machines Corporation | Restricting devices utilizing a device-to-server heartbeat |
| CN101610529A (zh) * | 2009-07-16 | 2009-12-23 | 中兴通讯股份有限公司 | 策略控制系统和通信系统中的策略控制方法 |
| US20160165463A1 (en) * | 2014-12-03 | 2016-06-09 | Fortinet, Inc. | Stand-by controller assisted failover |
| CN105635248A (zh) * | 2015-12-18 | 2016-06-01 | Tcl集团股份有限公司 | 一种tcp连接资源的释放方法及系统 |
| CN109150588A (zh) * | 2018-07-25 | 2019-01-04 | 河北华沃通信科技有限公司 | 设备管理方法及装置 |
| US20210126828A1 (en) * | 2019-10-23 | 2021-04-29 | Cisco Technology, Inc. | Integrity verification for managing network configurations |
| CN110768844A (zh) * | 2019-10-31 | 2020-02-07 | 杭州迪普科技股份有限公司 | 一种认证服务器切换方法及装置 |
| CN111181804A (zh) * | 2019-12-20 | 2020-05-19 | 中移（杭州）信息技术有限公司 | 智能设备离线状态自动检测方法、装置、电子设备及介质 |
| CN110974204A (zh) * | 2019-12-25 | 2020-04-10 | 杭州涂鸦信息技术有限公司 | 一种实现双向心跳机制的方法及其系统和装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107371264B (zh) | 一种上行数据传输的方法及设备 | |
| US10680956B2 (en) | Small data transmission method and user equipment using the same | |
| CN102761942B (zh) | 状态切换方法、非激活定时器启动方法和用户设备 | |
| EP2637365B1 (en) | Method for controlling internet services, and relevant device and system | |
| KR20070024302A (ko) | 셀룰러 시스템의 수면 모드 제어 장치 및 제어 방법 | |
| EP2537366A1 (en) | Method and apparatus for managing communications in a wireless communication system | |
| WO2008014122A2 (en) | Method and system for setting paging indication sequences in paging messages | |
| WO2018001281A1 (zh) | 传输方式的转换方法和装置 | |
| WO2012035144A1 (en) | Paging reading conflict management in dual standby handsets | |
| WO2007127560A2 (en) | Method and system to improve efficiency of mobile station during listening interval | |
| CN101796774A (zh) | 在ip网络上自动检查ip链接的连接状态的方法和系统 | |
| CN102164422A (zh) | 一种资源的释放方法、系统及基站 | |
| US8804541B2 (en) | Method for managing mobile radio resources for package receiving enhancement | |
| US20220394670A1 (en) | Paging method | |
| CN102711254B (zh) | 网络侧的资源释放控制方法及rnc | |
| CN102573018B (zh) | 一种移动终端省电的方法及其装置 | |
| WO2023160568A1 (zh) | 通信方法、装置、系统及存储介质 | |
| CN102883344B (zh) | 一种无线网络管理消息交互的方法及装置 | |
| CN102340762B (zh) | 终端位置更新方法、系统、以及基站 | |
| CN113542380A (zh) | 一种高效能的心跳保活方法 | |
| US7609683B2 (en) | Communication system, connection management server apparatus, and recording medium on which program is recorded | |
| WO2022127386A1 (zh) | 状态迁移的方法、网络设备及存储介质 | |
| KR20120128031A (ko) | 망 부하 감소를 위한 푸시 서비스 제공 시스템 및 방법 | |
| CN105142118A (zh) | Td-lte集群系统用户的快速随机接入方法 | |
| CN108599902B (zh) | 降低通信时延的方法、装置、用户设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |