CN106162943B - 一种保活消息处理方法、装置、系统和相关设备 - Google Patents

一种保活消息处理方法、装置、系统和相关设备 Download PDF

Info

Publication number
CN106162943B
CN106162943B CN201510205959.3A CN201510205959A CN106162943B CN 106162943 B CN106162943 B CN 106162943B CN 201510205959 A CN201510205959 A CN 201510205959A CN 106162943 B CN106162943 B CN 106162943B
Authority
CN
China
Prior art keywords
message
keep
alive
network side
random access
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.)
Active
Application number
CN201510205959.3A
Other languages
English (en)
Other versions
CN106162943A (zh
Inventor
陈亚迷
李刚
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Mobile Communications Group Co Ltd
Original Assignee
China Mobile Communications Group Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by China Mobile Communications Group Co Ltd filed Critical China Mobile Communications Group Co Ltd
Priority to CN201510205959.3A priority Critical patent/CN106162943B/zh
Publication of CN106162943A publication Critical patent/CN106162943A/zh
Application granted granted Critical
Publication of CN106162943B publication Critical patent/CN106162943B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Mobile Radio Communication Systems (AREA)

Abstract

本发明公开了一种保活消息处理方法、装置、系统和相关设备,用以在发送保活消息过程中,降低网络信令开销的同时兼容现有的网络设计。保活消息处理方法包括:在接收到第三方服务器发送的保活触发消息时,向UE发送寻呼消息;在接收到所述UE根据所述寻呼消息发起的随机接入过程中发送的连接建立请求后,根据其中携带的用户标识确定所述随机接入过程为保活寻呼消息触发时,向所述UE发送连接终止消息指示所述UE终止与网络侧建立连接,并向所述第三方服务器发送保活确认消息。

Description

一种保活消息处理方法、装置、系统和相关设备
技术领域
本发明涉及无线通信技术领域,尤其涉及一种保活消息处理方法、装置、系统和相关设备。
背景技术
随着移动互联网的发展,越来越多的“永远在线”业务应运而生。实现这种“永远在线”体验的最重要而直接的方法是实施应用层周期保活机制,使得网络能够实时地了解应用的无线链路状态(例如,应用在线、下线、位于网络覆盖空洞不可达),从而确定是否有必要/有能力同该应用进行即时交互;这种类型的应用包含新闻更新、聊天信息等。
基于表1所示的参考业务评估模型,同时假设LTE(Long Term Evolution,长期演进)的RRC((Radio Resource Control,无线资源控制协议)闲置计时器设置为5s、用户每分钟跨越一个小区范围(也就是对于站间距ISD=500m,用户的移动速率是30km/h),得到保活消息同其他不同业务的信令开销评估比较,如表2所示。
表1参考业务评估模型
表2不同业务信令开销评估表
其中,数据信令比(DSR)=数据量/信令开销,RRC建链拆链信令开销(%)=RRC连接释放信令(bit)/总信令开销(bit),切换信令开销(%)=切换信令(bit)/总信令开销(bit),RRC维护信令开销=RRC维护信令(bit)/总信令开销(%)。
从表2中可以看到:单个保活消息的数据信令比为0.1075,即传输一份保活数据需要附上10份信令。具体地,如果一个蜂窝范围内有200个用户需要发送保活消息,产生的信令开销大约为2.5个视频用户的数据传输量。特别地,保活信令的开销有90%以上是由RRC的建链拆链引发的,这是因为在RRC闲置计时时钟的控制(用于管理RRC连接状态下的用户在没有业务多长时间之后释放RRC连接,进入到RRC空闲态)下,保活消息的业务特征使得用户需要不断同网络建链拆链,引发大的RRC开销。保活消息这一业务特征一方面容易给造成网络信令的拥塞,另一方面加剧终端耗电。
为解决上述问题,3GPP(3rd Generation Partnership Project,第三代合作伙伴计划)在R12中展开了“面向MTC((Machine-type Communications,及其类型通信)和小数据包优化的研究议题”提出:在支持永远在线用户体验的心跳信息传输优化方面,建议在网络中引入应用层次的代理网关,维护终端内部IP和外部IP的半静态/静态映射关系;或者通过应用服务器触发核心网元维持而不释放用户的PDP(Packet Data Protocol,分组报文协议)上下文(终端IP地址及其具有特定QoS的逻辑承载)。此外,也有观点认为可以通过CS(Circuit Switched,电路交换)域通知推送信息的到达,降低应用永远在线业务需求。
如图1其分别为支撑NAS层传递小数据包的信令流程示意图,包括以下步骤:
S11、UE(用户设备)向MME(Mobility Management Entity,移动性管理实体)提交小数据包处理操作请求。
S12、UE向基站(eNB)发送随机接入请求。
S13、eNB向UE返回随机接入响应。
S14、UE向eNB发送RRC连接建立请求。
S15、eNB向UE返回RRC连接建立指示。
S16、UE与eNB建立RRC连接。
S17、eNB向MME发送UE初始化消息。
其中,携带有S-TMSI,KSI、EPS Bear ID,UDP/IP packet。
S18、MME向P-GW/S–GW(分组数据网关/业务网关)发送GTP-U。
其中,携带有TEID,UDP/IP packet。
S19、P-GW/S–GW向MME发送下行数据传输通知消息。
其中携带有Bear ID,UDP/IP response packet。
S110、MME向eNB发送下行数据非接入层传输消息。
S111、eNB向UE发送RRC连接释放指示。
其中,携带有UDP/IP response packet。
如图2所示,其为改进后的传输MT数据包的信令流程示意图,包括以下步骤:
步骤a)、P-GW/S–GW向MME发送下行数据传输通知消息。
步骤b1)-步骤b2)MME向eNB发送paging(寻呼消息),eNB向UE发送paging,UE向MME发送服务反馈消息。
其中,paging中携带有小数据包标记信息。
步骤c)、MME向eNB发送下行数据非接入层传输消息,eNB向UE发送下行非接入层传输消息。
步骤d)、MME向P-GW/S–GW发送下行数据通知确认消息。
此外,R12“面向MTC和小数据包优化的研究议题”议题中提出的依赖NAS(Non-Access Stratum,非接入层)信令来承载小数据包的方式也可以应用到保活小消息包的传递,可以大幅度节约信令的开销。但是,该方案需要对现有的LTE终端进行较大改动。
尽管3GPP提出的保活机制可以较好解决保活触发消息的开销问题,但是由于无线链路环境的不可靠性,通过核心网配置维护用户连接的方式,并不能真实反映用户的可达性。保活信息(无论什么形式存在)依然是需要的、用于保证更高“永远在线”体验。而通过NAS信令传递保活消息以及其他小数据包确实能够大幅降低信令开销,估计为将RRC信令开销从200多字节减少到50多个字节,但是其需要对终端进行较大改动。
综上,如何在降低网络信令开销的同时兼容现有的网络设计成为现有技术亟待解决的技术问题之一。
发明内容
本发明实施例提供一种保活消息处理方法、装置、系统和相关设备,用以在发送保活消息过程中,降低网络信令开销的同时兼容现有的网络设计。
本发明实施例提供网络侧实施的保活消息处理方法,包括:
在接收到第三方服务器发送的保活触发消息时,向用户设备UE发送寻呼消息;
在接收到所述UE根据所述寻呼消息发起的随机接入过程中发送的连接建立请求后,根据其中携带的用户标识确定所述随机接入过程为保活寻呼消息触发时,向所述UE发送连接终止消息指示所述UE终止与网络侧建立连接,并向所述第三方服务器发送保活确认消息。
其中,所述寻呼消息中携带有标记所述寻呼消息为保活寻呼消息的标记信息。
其中,按照以下过程确定接收到的消息为保活触发消息:
确定接收到的消息中携带有标记所述消息为保活触发消息的标记信息;或者
确定通过预设的保活触发消息应用程序接口API接收到所述消息;或者
利用深度包检测DPI技术确定接收到的消息为保活触发消息。
所述第三方服务器包括用于维护用户状态的用户状态服务器或者提供应用的应用服务器。
本发明实施例提供第一种保活消息处理装置,包括:
第一发送单元,用于在接收到第三方服务器发送的保活触发消息时,向用户设备UE发送寻呼消息;
第二发送单元,用于在接收到所述UE根据所述寻呼消息发起的随机接入过程中发送的连接建立请求后,根据其中携带的用户标识确定所述随机接入过程为保活寻呼消息触发时,向所述UE发送连接终止消息指示所述UE终止与网络侧建立连接,并向所述第三方服务器发送保活确认消息。
所述第一发送单元,具体用于确定接收到的消息中携带有标记所述消息为保活触发消息的标记信息时,确定接收到的消息为保活触发消息;或者确定通过预设的保活触发消息应用程序接口API接收到的消息为保活触发消息;或者利用深度包检测DPI技术确定接收到的消息为保活触发消息。
本发明实施例提供一种无线接入网络设备,包括上述第一种保活消息处理装置。
本发明实施例提供一种用户设备实施的保活消息处理方法,包括:
接收网络侧发送的寻呼消息;
根据所述寻呼消息向网络侧发起随机接入过程中,接收到所述网络侧发送的连接终止消息时,终止与网络侧建立连接。
其中,所述寻呼消息中携带有标记所述寻呼消息为保活寻呼消息的标记信。
按照以下方法向网络侧发起随机接入:
向所述网络侧发送随机接入请求;
接收所述网络侧返回的随机接入响应;
根据所述随机接入响应向所述网络侧发送连接建立请求;
接收所述网络侧发送的连接终止消息,其中,所述连接终止消息为所述网络侧确定所述随机接入过程为所述保活触发消息触发时发送的。
所述连接建立请求中携带有用户标识;以及所述保活确认消息为所述网络侧根据所述用户标识确定所述随机接入过程为所述保活触发消息触发时发送的。
本发明实施例提供第二种保活消息处理装置,包括:
接收单元,用于接收网络侧发送的寻呼消息;
通信单元,用于根据所述寻呼消息向网络侧发起随机接入过程中,接收到所述网络侧发送的连接终止消息时,终止与网络侧建立连接。
所述通信单元,包括:
发送子单元,用于向所述网络侧发送随机接入请求;以及在接收子单元接收到所述网络侧返回的随机接入响应后,向所述网络侧发送连接建立请求;
接收子单元,用于接收所述网络侧根据所述随机接入响应返回的随机接入响应;以及接收所述网络侧发送的连接终止消息,其中,所述连接终止消息为所述网络侧确定所述随机接入过程请求为所述保活触发消息触发时发送的。
本发明实施例提供一种用户设备,包括上述第二种保活消息处理装置。
本发明实施例提供一种包括消息处理方法,包括:
向网络侧发送保活触发消息;
接收所述网络侧返回的保活确认消息,所述保活确认消息为所述网络侧在接收到所述保活触发消息后向用户设备UE发送寻呼消息以及在接收到所述UE根据所述寻呼消息发起的随机接入过程中发送的连接建立请求后发送的,所述保活确认消息用于指示所述UE终止与网络侧建立连接。
向网络侧发送保活触发消息,具体包括:
在向网络侧发送的消息中携带标记所述消息为保活触发消息的标记信息;或者
通过预设的保活触发消息应用程序接口API向所述网络侧发送所述保活触发消息。
本发明实施例提供第三种保活消息处理装置,包括:
发送单元,用于向网络侧发送保活触发消息;
接收单元,用于接收所述网络侧返回的保活确认消息,所述保活确认消息为所述网络侧在接收到所述保活触发消息后向用户设备UE发送寻呼消息以及在接收到所述UE根据所述寻呼消息发起的随机接入过程中发送的连接建立请求后发送的,所述保活确认消息用于指示所述UE终止与网络侧建立连接。
所述发送单元,具体用于在向网络侧发送的消息中携带有标记所述消息为保活触发消息的标记信息;或者用于通过预设的保活触发消息应用程序接口API向所述网络侧发送所述保活触发消息。
本发明实施例提供一种服务器,包括上述第三种保活消息处理装置。
本发明实施例提供一种保活消息处理系统,包括上述的无线接入网络设备、用户设备和服务器。
本发明实施例提供的保活消息处理方法、装置、系统和相关设备,当网络侧接收到第三方服务器发送的保活触发消息时,通过寻呼消息触发UE发起随机接入流程,网络侧在接收到UE根据该寻呼消息发起的随机接入过程中发送的连接建立请求后,根据其中携带的用户标识确定该随机接入过程为保活寻呼消息触发时,向UE发送连接终止消息指示UE终止与网络侧建立连接;并向第三方服务器发送保活确认消息。上述过程中,由于UE并未与网络侧真正建立连接,从而节约了UE与网络侧建链拆链等所需的信令开销,同时,本发明实施例提供的方法对UE改动较小,从而能够兼容现有的网络设计。
本发明的其它特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本发明的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1为现有技术中,支撑NAS层传递小数据包的信令流程示意图;
图2为现有技术中,改进后的传输MT数据包的信令流程示意图;
图3为本发明实施例中,保活消息处理流程示意图;
图4为本发明实施例中,无线接入网络设备实施保活消息处理的实施流程示意图;
图5为本发明实施例中,第一种保活消息处理装置的结构示意图;
图6为本发明实施例中,用户设备实施保活消息处理的实施流程示意图;
图7为本发明实施例中,第二种保活消息处理装置的结构示意图;
图8a为本发明实施例中,用户状态服务器实施保活消息处理的实施流程示意图;
图8b为本发明实施例中,应用服务器实施保活消息处理的实施流程示意图;
图9为本发明实施例中,第三种保活消息处理装置的结构示意图;
图10为本发明实施例中,保活消息处理系统的结构示意图。
具体实施方式
本发明实施例提供一种通过寻呼触发的保活消息处理方法,由服务器向无线接入网络设备发送保活触发消息,无线接入网络设备向用户设备(UE,UserEquipment)发送寻呼请求,其中携带有该寻呼请求为保活寻呼消息(即由保活触发消息触发的寻呼消息)的标记信息,当用户设备接收到寻呼消之后,发起传统的随机接入流程接入到网络中,在此过程中,UE向无线接入网络设备发送连接建立请求(MT,Mobile Terminate,下行触发业务)时,无线接入网络设备识别出UE下行寻呼是保活寻呼,发送连接终止消息,以指示UE终止正在建立的连接。并向第三方服务器发送保活确认消息,完成保活过程。
以下结合说明书附图对本发明的优选实施例进行说明,应当理解,此处所描述的优选实施例仅用于说明和解释本发明,并不用于限定本发明,并且在不冲突的情况下,本发明中的实施例及实施例中的特征可以相互组合。
如图3所示,为本发明实施例提供的保活处理消息的实施流程示意图,可以包括以下步骤:
S31、第三方服务器向无线接入网络设备发送保活触发消息。
其中,第三方服务器可以为运营商提供的用于维护用户状态的用户状态服务器,也可以为提供应用的应用服务器。
较佳的,具体实施时,第三方服务器在向无线接入网络设备发送的消息为保活触发消息时,则第三方服务器可以在发送的消息中携带有标记该消息为保活触发消息的标记信息;或者,第三方服务器在向无线接入网络设备发送保活触发消息时,可以通过预设的保活触发消息专用应用程序接口(API,Application Programmable Interface)发送该保活触发消息;当然,具体实施时,第三方服务器还可以以普通消息形式发送该保活触发消息,由无线接入网络设备接收该保活触发消息的API利用DPI(深度包检测)等技术检测其接收到的消息是否为保活触发消息。
S32、无线接入网络设备向UE发送寻呼消息。
具体的,无线接入网络设备确定接收到的消息为保活触发消息时,向UE发送寻呼消息。
与第三方服务器发送保活触发消息的方式相对应,这里无线接入网络设备也可以通过以下三种方式中的任一种确定第三方服务器发送的消息为保活触发消息。
第一种确定方式
如果第三方服务器在发送的消息中携带有标记该消息为保活触发消息的标记信息时,则无线接入网络设备可以根据该标记信息确定第三方服务器发送的消息为保活触发消息。
第二种确定方式
如果第三方服务器通过保活触发消息专用API发送消息时,则则无线接入网络设备可以根据接收到消息的API是否为保活触发消息专用API来判断第三方服务器发送的消息是否为保活触发消息。如果判断出第三方服务器为通过保活触发消息专用API发送的消息,则可以确定第三方服务器发送的消息为保活触发消息。
第三种确定方式
如果第三方服务器以普通消息形式发送保活触发消息,则无线接入网络设备可以利用DPI(深度包检测,Deep Packet Inspecion)技术检测其接收到消息是否为保活触发消息。
具体实施时,网络侧在向UE发送由保活触发消息触发的寻呼消息时,对UE来说可以是透明的,即网络侧向UE发送普通寻呼消息,而在UE根据寻呼消息在发起随机接入过程中发送的连接建立请求时,网络侧根据其中携带的用户标识识别出该UE为发送的随机接入为保活寻呼消息触发时,则向该UE发送连接终止消息,指示UE终止与网络侧建立。
为了便于描述,本发明实施例中将由保活触发消息触发的寻呼消息称为保活寻呼消息。
当然,无线接入网络设备可以在向UE发送的寻呼消息中携带有标记该寻呼消息为保活寻呼消息(即由保活触发消息触发的寻呼消息),以使得用户识别该寻呼消息为保活寻呼消息。
较佳的,由于保活寻呼消息有时需要面向大量UE的大范围寻呼,这种情况下,可以预先将UE按照用户标识进行分组,基于同一组UE进行保活寻呼,以节约寻呼开销。
S33、UE向无线接入网络设备发送随机接入请求。
具体的,UE根据接收到的寻呼消息向无线接入网络设备发送随机接入请求。
具体实施时,UE在接收到针对其个体或者针对其所属广播标识的寻呼消息之后,向无线接入网络设备发送随机接入请求。
S34、无线接入网络设备向该UE发送随机接入响应。
具体的,无线接入网络设备接收到UE发送的随机接入请求后,向该UE发送随机接入响应。
S35、UE向无线接入网络设备发送连接建立请求。
步骤S35中,UE在向无线接入网络设备发送的连接建立请求中携带自身的用户标识,使得无线接入网络设备可以根据该用户标识识别出其为保活寻呼消息的目标用户。
S36、无线接入网络设备向UE发送连接终止消息。
S37、无线接入网络设备向第三方服务器发送保活确认消息。
具体的,无线接入网络设备判断出UE发送的连接建立请求为寻呼保活触发消息触发时,则向用户发送连接终止消息用于指示用户终止后续的连接行为。并将保活确认消息同步至第三方服务器。如果无线接入网络设备未在预设时间内接收到所述UE发送的随机接入请求,或者第三方服务器在预设时间内未接收到保活确认消息,则认为用户保活中断。
与步骤S32中无线接入网络设备确定第三方服务器发送的消息为保活触发消息的确定方式相对应,无线接入网络设备向第三方服务器发送保活确认消息也可以由如下三种实现方式:
实现方式一、
无线接入网络设备向第三方服务器发送的保活确认消息中携带有标记该消息为保活确认消息的标记信息,使得第三方服务器可以根据该标记信息识别出接收到的消息为保活确认消息。
实现方式二、
无线接入网络设备通过保活确认消息专用API向第三方服务器反馈保活确认消息,该保活确认消息专用API可供第三方服务器查询用户状态。第三方服务器判断接收到的消息是否为通过保活确认消息专用API接收到,便可确定接收到的消息是否为保活确认消息。
实现方式三、
无线接入网络设备以普通的消息形式发送保活确认消息,由第三方服务器接收消息的API利用DPI技术检测接收到的消息是否为保活确认消息即可。
相应的,第三方服务器也可以按照以下三种方式中的任一种确定接收到的消息为保活确认消息:
方式一、
如果无线接入网络设备在向第三方服务器发送的消息中携带有标记该消息为保活确认消息的标记信息时,第三方服务器可以根据该标记信息识别出无线接入网络设备发送的消息为保活确认消息。
方式二、
如果无线接入网络设备通过保活确认消息专用API向第三方服务器反馈保活确认消息,则第三方服务器判断接收到的消息是否为通过保活确认消息专用API接收到,便可确定接收到的消息是否为保活确认消息。
方式三、
如果无线接入网络设备以普通的消息形式发送保活确认消息,则第三方服务器接收到消息的API可以利用DPI技术检测收到的消息是否为保活确认消息。
需要说明的是,无线接入网络设备向UE和第三方服务器发送保活确认消息不分先后,两者也可以同时执行。
S38、UE接收到保活确认消息后,终止与网络侧建立连接。
本发明实施例提供的保活触发消息处理方法,网络侧在接收到保活触发消息时,通过保活寻呼消息触发UE随机接入流程,在该UE发送连接建立请求之后,网络侧向UE发送终止连接的保活确认消息,由此,UE无须与网络侧频繁的执行建链拆链操作,减少了网络信令开销,且对UE改动较小,因此能够兼容现有的网络设计。
本发明实施例提供的寻呼保活处理方法使得网络能够结合网络的状态(网络忙时和网络闲时)以及应用对保活的需求触发保活行为,一方面,可以保证保活触发消息不会给网络造成大的负担,另一方面,使得保活行为按需为下行推送服务。另外,本发明实施例提供的寻呼保活处理方法,尽可能节约由于发送保活触发消息而造成的网络信令开销,另一方面,对于UE改动相对较小,UE只需要识别网络最后发送的保活确认消息,并根据保活确认消息终止与网络侧建立的连接。
基于同一发明构思,本发明实施例分别提供了一种无线接入网络侧、UE侧和第三方服务器侧实施的保活消息处理方法、装置和设备以及一种保活消息处理系统,由于上述方法、装置、设备和系统解决问题的原理与上述的保活消息处理方法相似,因此上述方法、装置、设备和系统的实施可以参见方法的实施,重复之处不再赘述。
如图4所示,为无线接入网络侧实施保活消息处理方法的实施流程示意图,可以包括以下步骤:
S41、在接收到第三方服务器发送的保活触发消息时,向UE发送寻呼消息。
较佳的,可以在向UE发送的寻呼消息中携带有标记所述寻呼消息为保活寻呼消息的标记信息。
S42、在接收到UE根据接收到的寻呼消息发起的随机接入过程中发送的连接建立请求后,根据其中携带的用户标识确定该随机接入过程为保活寻呼消息触发时,向该UE发送连接终止消息指示该UE终止与网络侧建立连接,并向第三方服务器发送保活确认消息。
具体实施时,可以按照以下任一方式向无线接入网络设备发送保活触发消息:
第三方服务器在向无线接入网络设备发送保活触发消息时,在发送的消息中携带有标记该消息为保活触发消息的标记信息;或者,第三方服务器在需要向无线接入网络设备发送保活触发消息时,可以通过预设的保活触发消息专用应用程序接口(API,Application Programmable Interface)发送该保活触发消息;当然,具体实施时,第三方服务器还可以以普通消息形式发送该保活触发消息,由无线接入网络设备接收该保活触发消息的API检测其接收到的消息是否为保活触发消息。
相应的,步骤S41中,可以按照以下任一方式确定接收到的消息为保活触发消息:
第一种确定方式
如果第三方服务器在发送的消息中携带有标记该消息为保活触发消息的标记信息时,则无线接入网络设备可以根据该标记信息确定第三方服务器发送的消息为保活触发消息。
第二种确定方式
如果第三方服务器通过保活触发消息专用API发送消息时,则则无线接入网络设备可以根据接收到消息的API是否为保活触发消息专用API来判断第三方服务器发送的消息是否为保活触发消息。如果判断出第三方服务器为通过保活触发消息专用API发送的消息,则可以确定第三方服务器发送的消息为保活触发消息。
第三种确定方式
如果第三方服务器以普通消息形式发送保活触发消息,则无线接入网络设备可以利用DPI(深度包检测,Deep Packet Inspecion)技术检测其接收到消息是否为保活触发消息。
无线接入网络设备在向UE发送的寻呼消息中携带有标记该寻呼消息为保活寻呼消息(即由保活触发消息触发的寻呼消息)。较佳的,由于保活寻呼消息有时需要面向大量UE的大范围寻呼,这种情况下,可以预先将UE按照用户标识进行分组,基于同一组UE进行保活寻呼,以节约寻呼开销。
UE在接收到针对其个体或者针对其所属广播标识的保活寻呼消息之后,向无线接入网络设备发送随机接入请求。无线接入网络设备接收到UE发送的随机接入请求后,向该UE发送随机接入响应。UE在向无线接入网络设备发送的连接建立请求中携带自身的用户标识,使得无线接入网络设备可以根据该用户标识识别出其为保活寻呼消息的目标用户。这样,无线接入网络设备判断出UE发送的连接建立请求为寻呼保活触发消息触发时,则向UE发送连接终止消息用于指示UE终止后续的连接行为,并向第三方服务器发送保活确认消息。如果无线接入网络设备未在预设时间内接收到所述UE发送的随机接入请求,或者第三方服务器在预设时间内未接收到保活确认消息,则认为用户保活中断。
与上述无线接入网络设备确定第三方服务器发送的消息为保活触发消息的确定方式相对应,无线接入网络设备向第三方服务器发送保活确认消息也可以由如下三种实现方式:
实现方式一、
无线接入网络设备向第三方服务器发送的保活确认消息中携带有标记该消息为保活确认消息的标记信息,使得第三方服务器可以根据该标记信息识别出接收到的消息为保活确认消息。
实现方式二、
无线接入网络设备通过把保活确认消息专用API向第三方服务器反馈保活确认消息,该保活确认消息专用API可供第三方服务器查询用户状态。第三方服务器判断接收到的消息是否为通过保活确认消息专用API接收到,便可确定接收到的消息是否为保活确认消息。
实现方式三、
无线接入网络设备以普通的消息形式发送保活确认消息,由第三方服务器接收消息的API利用DPI技术检测接收到的消息是否为保活确认消息即可。
需要说明的是,无线接入网络设备向UE和第三方服务器发送保活确认消息不分先后,两者也可以同时执行。
如图5所示,为本发明实施例提供的第一种保活消息处理装置的结构示意图,包括:
第一发送单元51,用于在接收到第三方服务器发送的保活触发消息时,向UE发送寻呼消息;
第二发送单元52,用于在接收到所述UE根据所述寻呼消息发起的随机接入过程中发送的连接建立请求后,根据其中携带的用户标识确定所述随机接入过程为保活寻呼消息触发时,向所述UE发送连接终止消息指示所述UE终止与网络侧建立连接,并向所述第三方服务器发送保活确认消息。
其中,第一发送单元51,可以用于确定接收到的消息中携带有标记该消息为保活触发消息的标记信息时,确定接收到的消息为保活触发消息;或者确定通过预设的保活触发消息应用程序接口API接收到的消息为保活触发消息;或者利用深度包检测DPI技术确定接收到的消息为保活触发消息。
为了描述的方便,以上各部分按照功能划分为各模块(或单元)分别描述。当然,在实施本发明时可以把各模块(或单元)的功能在同一个或多个软件或硬件中实现。具体实施时,本发明实施例提供的第一种保活触发消息处理装置可以设置于无线接入网络设备。
如图6所示,为本发明实施例提供的UE侧实施保活消息处理方法的实施流程示意图,可以包括以下步骤:
S61、接收网络侧发送的寻呼消息。
较佳的,网络侧可以在该寻呼消息中携带有标记所述寻呼消息为保活寻呼消息的标记信息。
具体实施时,网络侧在接收到第三方服务器发送的保活触发消息时,向UE发送寻呼消息。
S62、根据寻呼消息向网络侧发起随机接入过程中,接收到网络侧发送的连接终止时,终止与网络侧建立连接。
较佳的,UE可以按照以下步骤向网络侧发起随机接入:
步骤一、UE向网络侧发送随机接入请求。
步骤二、UE接收网络侧返回的随机接入响应。
步骤三、UE根据接收到的随机接入响应向网络侧发送连接建立请求。
步骤四、UE接收网络侧发送的连接终止消息。
其中,连接终止消息为网络侧确定本次随机接入过程为保活寻呼消息触发时发送的。
具体的,UE根据接收到的寻呼消息向无线接入网络设备发送随机接入请求。无线接入网络设备接收到UE发送的随机接入请求后,向该UE发送随机接入响应。UE向无线接入网络设备发送连接建立请求。UE在向无线接入网络设备发送的连接建立请求中携带自身的用户标识,使得无线接入网络设备可以根据该用户标识识别出其为保活寻呼消息的目标用户。无线接入网络设备判断出UE发送的连接建立请求为寻呼保活触发消息触发时,则向用户发送连接终止消息用于指示用户终止后续的连接行为。UE接收到连接终止消息后,终止与网络侧建立连接。
如果无线接入网络设备未在预设时间内接收到UE发送的随机接入请求,则认为用户保活中断。
如图7所示,为本发明实施例提供的第二种保活消息处理装置的结构示意图,包括:
接收单元71,用于接收网络侧发送的寻呼消息;
通信单元72,用于根据该寻呼消息向网络侧发起随机接入过程中,接收到所述网络侧发送的连接终止消息时,终止与网络侧建立连接。
较佳的,通信单元72可以包括:
发送子单元,用于向所述网络侧发送随机接入请求;以及在接收子单元接收到所述网络侧返回的随机接入响应后,向所述网络侧发送连接建立请求;
接收子单元,用于接收所述网络侧根据所述随机接入响应返回的随机接入响应;以及接收所述网络侧发送的连接终止消息,其中,所述连接终止消息为所述网络侧确定所述随机接入过程为所述保活触发消息触发时发送的。
为了描述的方便,以上各部分按照功能划分为各模块(或单元)分别描述。当然,在实施本发明时可以把各模块(或单元)的功能在同一个或多个软件或硬件中实现。具体实施时,本发明实施例提供的第二种保活消息处理装置可以设置于用户设备中。
如图8a所示,为本发明实施例提供的用户状态服务器实施保活消息处理方法的实施流程示意图,可以包括以下步骤:
S81、用户状态服务器向网络侧发送保活触发消息。
具体实施时,用户状态服务器可以按照以下任一方式向网络侧的无线接入网络设备发送保活触发消息:
用户状态服务器在向无线接入网络设备发送保活触发消息时,在发送的消息中携带有标记该消息为保活触发消息的标记信息;或者,用户状态服务器在需要向无线接入网络设备发送保活触发消息时,可以通过预设的保活触发消息专用应用程序接口(API,Application Programmable Interface)发送该保活触发消息;当然,具体实施时,用户状态服务器还可以以普通消息形式发送该保活触发消息,由无线接入网络设备接收该保活触发消息的API检测其接收到的消息是否为保活触发消息。
S82、用户状态服务器接收网络侧返回的保活确认消息。
其中,保活确认消息为网络侧在接收到保活触发消息后向UE(用户设备)发送寻呼消息以及在接收到所述UE根据所述寻呼消息发起的随机接入过程中发送的连接建立请求后发送的,所述保活确认消息用于指示所述UE终止与网络侧建立连接。
具体实施时,与用户状态服务器发送保活触发消息的方式相对应,网络侧的无线接入网络设备也可以通过以下三种方式中的任一种确定用户状态服务器发送的消息为保活触发消息。
第一种确定方式
如果用户状态服务器在发送的消息中携带有标记该消息为保活触发消息的标记信息时,则无线接入网络设备可以根据该标记信息确定用户状态服务器发送的消息为保活触发消息。
第二种确定方式
如果用户状态服务器通过保活触发消息专用API发送消息时,则则无线接入网络设备可以根据接收到消息的API是否为保活触发消息专用API来判断用户状态服务器发送的消息是否为保活触发消息。如果判断出用户状态服务器为通过保活触发消息专用API发送的消息,则可以确定用户状态服务器发送的消息为保活触发消息。
第三种确定方式
如果用户状态服务器以普通消息形式发送保活触发消息,则无线接入网络设备可以利用DPI(深度包检测,Deep Packet Inspecion)技术检测其接收到消息是否为保活触发消息。
无线接入网络设备确定接收到的消息为保活触发消息时,向UE发送寻呼消息。无线接入网络设备可以在向UE发送的寻呼消息中携带有标记该寻呼消息为保活寻呼消息(即由保活触发消息触发的寻呼消息)。
较佳的,由于保活寻呼消息有时需要面向大量UE的大范围寻呼,这种情况下,可以预先将UE按照用户标识进行分组,基于同一组UE进行保活寻呼,以节约寻呼开销。UE根据接收到的保活寻呼请求向无线接入网络设备发送随机接入请求。无线接入网络设备接收到UE发送的随机接入请求后,向该UE发送随机接入响应。UE向无线接入网络设备发送连接建立请求。UE在向无线接入网络设备发送的连接建立请求中携带自身的用户标识,使得无线接入网络设备可以根据该用户标识识别出其为保活寻呼消息的目标用户。无线接入网络设备判断出UE发起的随机接入为寻呼保活触发消息触发时,则向UE发送连接终止消息用于指示用户终止后续的连接行为。并向用户状态服务器发送保活确认消息。如果无线接入网络设备未在预设时间内接收到所述UE发送的随机接入请求,或者用户状态服务器在预设时间内未接收到保活确认消息,则认为用户保活中断。
与无线接入网络设备确定用户状态服务器发送的消息为保活触发消息的确定方式相对应,无线接入网络设备向用户状态服务器发送保活确认消息也可以由如下三种实现方式:
实现方式一、
无线接入网络设备向用户状态服务器发送的保活确认消息中携带有标记该消息为保活确认消息的标记信息,使得用户状态服务器可以根据该标记信息识别出接收到的消息为保活确认消息。
实现方式二、
无线接入网络设备通过把保活确认消息专用API向用户状态服务器反馈保活确认消息,该保活确认消息专用API可供用户状态服务器查询用户状态。用户状态服务器判断接收到的消息是否为通过保活确认消息专用API接收到,便可确定接收到的消息是否为保活确认消息。
实现方式三、
无线接入网络设备以普通的消息形式发送保活确认消息,由用户状态服务器接收消息的API利用DPI技术检测接收到的消息是否为保活确认消息即可。
相应的,用户状态服务器也可以按照以下三种方式中的任一种确定接收到的消息为保活确认消息:
方式一、
如果无线接入网络设备在向用户状态服务器发送的消息中携带有标记该消息为保活确认消息的标记信息时,用户状态服务器可以根据该标记信息识别出无线接入网络设备发送的消息为保活确认消息。
方式二、
如果无线接入网络设备通过保活确认消息专用API向用户状态服务器反馈保活确认消息,则用户状态服务器判断接收到的消息是否为通过保活确认消息专用API接收到,便可确定接收到的消息是否为保活确认消息。
方式三、
如果无线接入网络设备以普通的消息形式发送保活确认消息,则用户状态服务器接收到消息的API可以利用DPI技术检测收到的消息是否为保活确认消息。
以上为第三方服务器为由运营商提供的用于维护用户状态的用户状态服务器实施本发明实施例提供的保活触发消息处理方法的实施流程示意图。
具体实施时,第三方服务器还可以为提供应用的应用服务器,其实施发明实施例提供的保活触发消息处理方法的流程与上述用户状态服务器实施保活触发消息处理方法类似,可以包括以下步骤:
如图8b所示,为本发明实施例提供的应用服务器实施保活触发消息处理方法的实施流程示意图,可以包括以下步骤:
S801、应用服务器向网络侧发送保活触发消息。
具体实施时,应用服务器可以按照以下任一方式向网络侧的无线接入网络设备发送保活触发消息:
应用服务器在向无线接入网络设备发送消息时,如果该消息为保活触发消息,则应用服务器可以在发送的消息中携带有标记该消息为保活触发消息的标记信息;或者,
应用服务器在需要向无线接入网络设备发送保活触发消息时,可以通过预设的保活触发消息专用应用程序接口(API,Application Programmable Interface)发送该保活触发消息;
当然,具体实施时,应用服务器还可以以普通消息形式发送该保活触发消息,由无线接入网络设备接收该保活触发消息的API检测其接收到的消息是否为保活触发消息。
S802、应用服务器接收网络侧返回的保活确认消息。
其中,保活确认消息为网络侧在接收到保活触发消息后向UE(用户设备)发送寻呼消息以及在接收到所述UE根据所述寻呼消息发起的随机接入过程中发送的连接建立请求后发送的,所述保活确认消息用于指示所述UE终止与网络侧建立连接。
具体实施时,与应用服务器发送保活触发消息的方式相对应,网络侧的无线接入网络设备也可以通过以下三种方式中的任一种确定应用服务器发送的消息为保活触发消息。
第一种确定方式
如果应用服务器在发送的消息中携带有标记该消息为保活触发消息的标记信息时,则无线接入网络设备可以根据该标记信息确定应用服务器发送的消息为保活触发消息。
第二种确定方式
如果应用服务器通过保活触发消息专用API发送消息时,则则无线接入网络设备可以根据接收到消息的API是否为保活触发消息专用API来判断应用服务器发送的消息是否为保活触发消息。如果判断出应用服务器为通过保活触发消息专用API发送的消息,则可以确定应用服务器发送的消息为保活触发消息。
第三种确定方式
如果应用服务器以普通消息形式发送保活触发消息,则无线接入网络设备可以利用DPI(深度包检测,Deep Packet Inspecion)技术检测其接收到消息是否为保活触发消息。
无线接入网络设备确定接收到的消息为保活触发消息时,向UE发送寻呼消息。无线接入网络设备在向UE发送的寻呼消息中携带有标记该寻呼消息为保活寻呼消息(即由保活触发消息触发的寻呼消息)。较佳的,由于保活寻呼消息有时需要面向大量UE的大范围寻呼,这种情况下,可以预先将UE按照用户标识进行分组,基于同一组UE进行保活寻呼,以节约寻呼开销。UE根据接收到的保活寻呼请求向无线接入网络设备发送随机接入请求。无线接入网络设备接收到UE发送的随机接入请求后,向该UE发送随机接入响应。UE向无线接入网络设备发送连接建立请求。UE在向无线接入网络设备发送的连接建立请求中携带自身的用户标识,使得无线接入网络设备可以根据该用户标识识别出其为保活寻呼消息的目标用户。无线接入网络设备判断出UE发送的连接建立请求为寻呼保活触发消息触发时,则向用户发送连接终止消息用于指示用户终止后续的连接行为。并向应用服务器发送保活确认消息。如果无线接入网络设备未在预设时间内接收到所述UE发送的随机接入请求,或者应用服务器在预设时间内未接收到保活确认消息,则认为用户保活中断。
与无线接入网络设备确定应用服务器发送的消息为保活触发消息的确定方式相对应,无线接入网络设备向应用服务器发送保活确认消息也可以由如下三种实现方式:
实现方式一、
无线接入网络设备向应用服务器发送的保活确认消息中携带有标记该消息为保活确认消息的标记信息,使得应用服务器可以根据该标记信息识别出接收到的消息为保活确认消息。
实现方式二、
无线接入网络设备通过把保活确认消息专用API向应用服务器反馈保活确认消息,该保活确认消息专用API可供应用服务器查询用户状态。应用服务器判断接收到的消息是否为通过保活确认消息专用API接收到,便可确定接收到的消息是否为保活确认消息。
实现方式三、
无线接入网络设备以普通的消息形式发送保活确认消息,由应用服务器接收消息的API利用DPI技术检测接收到的消息是否为保活确认消息即可。
相应的,应用服务器也可以按照以下三种方式中的任一种确定接收到的消息为保活确认消息:
方式一、
如果无线接入网络设备在向应用服务器发送的消息中携带有标记该消息为保活确认消息的标记信息时,应用服务器可以根据该标记信息识别出无线接入网络设备发送的消息为保活确认消息。
方式二、
如果无线接入网络设备通过保活确认消息专用API向应用服务器反馈保活确认消息,则应用服务器判断接收到的消息是否为通过保活确认消息专用API接收到,便可确定接收到的消息是否为保活确认消息。
方式三、
如果无线接入网络设备以普通的消息形式发送保活确认消息,则应用服务器接收到消息的API可以利用DPI技术检测收到的消息是否为保活确认消息。
如图9所示为本发明实施例提供的第三种保活消息处理装置的结构示意图,可以包括:
发送单元91,用于向网络侧发送保活触发消息;
接收单元92,用于接收所述网络侧返回的保活确认消息.
其中,所述保活确认消息为所述网络侧在接收到所述保活触发消息后向用户设备UE发送寻呼消息以及在接收到所述UE根据所述寻呼消息发起的随机接入过程中发送的连接建立请求后发送的。
具体实施时,发送单元91,可以用于在向网络侧发送保活触发消息时,在发送的消息中携带有标记所述消息为保活触发消息的标记信息;或者用于通过预设的保活触发消息API向所述网络侧发送所述保活触发消息。
为了描述的方便,以上各部分按照功能划分为各模块(或单元)分别描述。当然,在实施本发明时可以把各模块(或单元)的功能在同一个或多个软件或硬件中实现。具体实施时,本发明实施例提供的第三种保活触发消息处理装置可以设置于用户状态服务器或者应用服务器中,由用户状态服务器或者应用服务器向无线接入网络设备查询用户状态。
如图10所示,为本发明实施例提供的保活消息处理系统的结构示意图,包括上述的无线接入网络设备101,用户设备102和第三方服务器103。
其中,无线接入网络设备101中设置有本发明提供的第一种保活消息处理装置,用户设备102中设置有本发明提供的第二种保活消息处理装置,第三方服务器103中设置有本发明提供的第三种保活消息处理装置。
本发明实施例提供的保活消息处理方法、装置、系统和相关设备,当网络侧接收到第三方服务器发送的保活触发消息时,通过寻呼消息触发UE发起随机接入流程,网络侧在接收到UE根据该寻呼消息发起的随机接入过程中发送的连接建立请求后,根据其中携带的用户标识确定该随机接入过程为保活寻呼消息触发时,向UE发送连接终止消息指示UE终止与网络侧建立连接,并向第三方服务器发送保活确认消息。上述过程中,由于UE并未与网络侧真正建立连接,从而节约了UE与网络侧建链拆链等所需的信令开销,同时,本发明实施例提供的方法对UE改动较小,从而能够兼容现有的网络设计。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。

Claims (17)

1.一种保活消息处理方法,其特征在于,包括:
在接收到第三方服务器发送的保活触发消息时,向用户设备UE发送寻呼消息,所述第三方服务器为用于维护用户状态的用户状态服务器或者提供应用的应用服务器;
在接收到所述UE根据所述寻呼消息发起的随机接入过程中发送的连接建立请求后,根据其中携带的用户标识确定所述随机接入过程为保活寻呼消息触发时,向所述UE发送连接终止消息指示所述UE终止与网络侧建立连接,并向所述第三方服务器发送保活确认消息。
2.如权利要求1所述的方法,其特征在于,所述寻呼消息中携带有标记所述寻呼消息为保活寻呼消息的标记信息。
3.如权利要求1所述的方法,其特征在于,按照以下方法确定接收到的消息为保活触发消息:
确定接收到的消息中携带有标记所述消息为保活触发消息的标记信息;或者
确定通过预设的保活触发消息应用程序接口API接收到的消息为保活触发消息;或者
利用深度包检测DPI技术确定接收到的消息为保活触发消息。
4.如权利要求1、2或3所述的方法,其特征在于,所述第三方服务器包括用于维护用户状态的用户状态服务器或者提供应用的应用服务器。
5.一种保活消息处理装置,其特征在于,包括:
第一发送单元,用于在接收到第三方服务器发送的保活触发消息时,向用户设备UE发送寻呼消息,所述第三方服务器为用于维护用户状态的用户状态服务器或者提供应用的应用服务器;
第二发送单元,用于在接收到所述UE根据所述寻呼消息发起的随机接入过程中发送的连接建立请求后,根据其中携带的用户标识确定所述随机接入过程为保活寻呼消息触发时,向所述UE发送连接终止消息指示所述UE终止与网络侧建立连接,并向所述第三方服务器发送保活确认消息。
6.如权利要求5所述的装置,其特征在于,
所述第一发送单元,具体用于确定接收到的消息中携带有标记所述消息为保活触发消息的标记信息时,确定接收到的消息为保活触发消息;或者确定通过预设的保活触发消息应用程序接口API接收到的消息为保活触发消息;或者利用深度包检测DPI技术确定接收到的消息为保活触发消息。
7.一种无线接入网络设备,其特征在于,包括权利要求5或6所述的保活消息处理装置。
8.一种保活消息处理方法,其特征在于,包括:
接收网络侧发送的寻呼消息,其中,所述寻呼消息为所述网络侧在接收到第三方服务器发送的保活触发消息时发送的,所述第三方服务器为用于维护用户状态的用户状态服务器或者提供应用的应用服务器;
根据所述寻呼消息向网络侧发起随机接入过程中,接收到所述网络侧发送的连接终止消息时,终止与网络侧建立连接,其中:按照以下方法向网络侧发起随机接入:向所述网络侧发送随机接入请求;接收所述网络侧返回的随机接入响应;根据所述随机接入响应向所述网络侧发送连接建立请求,所述连接建立请求中携带有用户标识;接收所述网络侧发送的连接终止消息,其中,所述连接终止消息为所述网络侧根据所述用户标识确定所述随机接入过程为所述保活触发消息触发时发送的。
9.如权利要求8所述的方法,其特征在于,所述寻呼消息中携带有标记所述寻呼消息为保活寻呼消息的标记信息。
10.一种保活消息处理装置,其特征在于,包括:
接收单元,用于接收网络侧发送的寻呼消息,其中,所述寻呼消息为所述网络侧在接收到第三方服务器发送的保活触发消息时发送的,所述第三方服务器为用于维护用户状态的用户状态服务器或者提供应用的应用服务器;
通信单元,用于根据所述寻呼消息向网络侧发起随机接入过程中,接收到所述网络侧发送的连接终止消息时,终止与网络侧建立连接,包括:发送子单元,用于向所述网络侧发送随机接入请求;以及在接收子单元接收到所述网络侧返回的随机接入响应后,向所述网络侧发送连接建立请求,所述连接建立请求中携带有用户标识;接收子单元,用于接收所述网络侧根据所述随机接入响应返回的随机接入响应;以及接收所述网络侧发送的连接终止消息,其中,所述连接终止消息为所述网络侧根据所述用户标识确定所述随机接入过程为所述保活触发消息触发时发送的。
11.一种用户设备,其特征在于,包括权利要求10所述的保活消息处理装置。
12.一种保活消息处理方法,其特征在于,包括:
第三方应用服务器向网络侧发送保活触发消息,所述第三方服务器为用于维护用户状态的用户状态服务器或者提供应用的应用服务器;
接收所述网络侧返回的保活确认消息,所述保活确认消息为所述网络侧在接收到所述保活触发消息后向用户设备UE发送寻呼消息以及在接收到所述UE根据所述寻呼消息发起的随机接入过程中发送的连接终止消息后发送的,其中:所述UE按照以下方法向网络侧发起随机接入:向所述网络侧发送随机接入请求;接收所述网络侧返回的随机接入响应;根据所述随机接入响应向所述网络侧发送连接建立请求,所述连接建立请求中携带有用户标识;接收所述网络侧发送的连接终止消息,其中,所述连接终止消息为所述网络侧根据所述用户标识确定所述随机接入过程为所述保活触发消息触发时发送的。
13.如权利要求12所述的方法,其特征在于,向网络侧发送保活触发消息,具体包括:
在向网络侧发送的消息中携带标记所述消息为保活触发消息的标记信息;或者
通过预设的保活触发消息应用程序接口API向所述网络侧发送所述保活触发消息。
14.一种保活消息处理装置,其特征在于,设置于第三方服务器中,所述第三方服务器为用于维护用户状态的用户状态服务器或者提供应用的应用服务器,包括:
发送单元,用于向网络侧发送保活触发消息;
接收单元,用于接收所述网络侧返回的保活确认消息,所述保活确认消息为所述网络侧在接收到所述保活触发消息后向用户设备UE发送寻呼消息以及在接收到所述UE根据所述寻呼消息发起的随机接入过程中发送的连接终止消息后发送的,其中:所述UE按照以下方法向网络侧发起随机接入:向所述网络侧发送随机接入请求;接收所述网络侧返回的随机接入响应;根据所述随机接入响应向所述网络侧发送连接建立请求,所述连接建立请求中携带有用户标识;接收所述网络侧发送的连接终止消息,其中,所述连接终止消息为所述网络侧根据所述用户标识确定所述随机接入过程为所述保活触发消息触发时发送的。
15.如权利要求14所述的保活消息处理装置,其特征在于,
所述发送单元,具体用于在向网络侧发送的消息中携带标记所述消息为保活触发消息的标记信息;或者用于通过预设的保活触发消息应用程序接口API向所述网络侧发送所述保活触发消息。
16.一种服务器,其特征在于,包括权要求14或15所述的保活消息处理装置。
17.一种保活消息处理系统,其特征在于,包括权利要求7所述的无线接入网络设备、权利要求11所述的用户设备和权要求16所述的服务器。
CN201510205959.3A 2015-04-27 2015-04-27 一种保活消息处理方法、装置、系统和相关设备 Active CN106162943B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510205959.3A CN106162943B (zh) 2015-04-27 2015-04-27 一种保活消息处理方法、装置、系统和相关设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510205959.3A CN106162943B (zh) 2015-04-27 2015-04-27 一种保活消息处理方法、装置、系统和相关设备

Publications (2)

Publication Number Publication Date
CN106162943A CN106162943A (zh) 2016-11-23
CN106162943B true CN106162943B (zh) 2019-08-16

Family

ID=57347313

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510205959.3A Active CN106162943B (zh) 2015-04-27 2015-04-27 一种保活消息处理方法、装置、系统和相关设备

Country Status (1)

Country Link
CN (1) CN106162943B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107770269B (zh) * 2017-10-20 2019-07-19 平安科技(深圳)有限公司 一种服务响应方法及其终端

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103096293A (zh) * 2011-11-04 2013-05-08 中兴通讯股份有限公司 应用数据处理方法及装置
WO2014066393A1 (en) * 2012-10-22 2014-05-01 Interdigital Patent Holdings, Inc. Method and apparatus for negotiating "keep-alive" message frequencies of applications running on a mobile station
CN104145466A (zh) * 2012-02-24 2014-11-12 诺基亚公司 用于动态服务器/客户端控制的连通性逻辑的方法和装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103096293A (zh) * 2011-11-04 2013-05-08 中兴通讯股份有限公司 应用数据处理方法及装置
CN104145466A (zh) * 2012-02-24 2014-11-12 诺基亚公司 用于动态服务器/客户端控制的连通性逻辑的方法和装置
WO2014066393A1 (en) * 2012-10-22 2014-05-01 Interdigital Patent Holdings, Inc. Method and apparatus for negotiating "keep-alive" message frequencies of applications running on a mobile station

Also Published As

Publication number Publication date
CN106162943A (zh) 2016-11-23

Similar Documents

Publication Publication Date Title
US11632788B2 (en) Data scheduling method, base station, and system
TWI681687B (zh) 處理尋呼的方法和裝置
US11122413B2 (en) Method and apparatus for efficiently transmitting small amounts of data in wireless communication systems
US20190082490A1 (en) Method and appratus for rrc state control
KR101930776B1 (ko) 무선 통신 시스템에서 상시 연결을 위한 시스템 및 방법
US11477633B2 (en) Method and apparatus for managing packet data network connection on basis of local area in wireless communication system
CN107172664B (zh) 数据传输方法、装置及系统
CN107231623B (zh) 一种数据调度方法、基站及系统
KR102165255B1 (ko) non-3gpp를 통해 5G네트워크에 접속하는 단말에 대한 registration 관리 방안
US20140237125A1 (en) Method, apparatus, and system for establishing device-to-device connection
WO2021203881A1 (zh) 一种通信方法及相关设备
WO2013091161A1 (en) A method and apparatus for mobility robustness optimization
US9681473B2 (en) MTC service management using NFV
WO2015018232A1 (zh) 设备到设备连接管理方法、装置及基站
WO2014019476A1 (zh) 一种非连续接收的实现方法及基站
CN104010381A (zh) 一种建立直接通信路径的方法、设备及系统
CN106162943B (zh) 一种保活消息处理方法、装置、系统和相关设备
KR102381375B1 (ko) 이동통신 시스템에서 Cellular IoT 서비스를 제공하는 방법 및 장치
WO2018087034A1 (en) Infrequent small data for battery saving wireless devices
WO2014121599A1 (zh) 传递蜂窝网络负荷信息的方法和相关设备
CN103582035B (zh) 一种无线资源配置的管理方法和系统
JP2019503132A (ja) グループ通信システムにおけるページング
WO2015066844A1 (zh) 传输、获取信息的方法、装置、应用服务器、基站及终端
WO2013113262A1 (zh) 资源调度的方法和装置

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant