背景技术
在EPS(Evolved Packet System,演进分组系统)中,CN(Core Network,核心网)通过寻呼过程请求与处于空闲(IDLE)状态的UE(User Equipment,用户设备)建立NAS(Non-Access Stratum,非接入层)信令连接。
寻呼时,核心网的移动性管理实体MME(Mobility Management Entity)使用S1接口协议(S1 Application Protocol,S1-AP)向相关eNodeB(evolved Node B,演进的B节点,即基站)发送Paging消息,每条Paging消息中携带被寻呼UE的信息。eNodeB在接收到Paging消息后,解读其中的内容,从而得到被寻呼UE的TAI(Tracking Area Identity,跟踪区域标识)列表,并在所列出的跟踪区域下属的小区进行空口寻呼。
正常情况下,MME使用S-TMSI(System Architecture Evolution-Temporary Mobile Subscriber Identity,系统架构演进临时识别码)标识UE并对处于空闲态的UE发起寻呼。UE在收到指示S-TMSI的Paging消息后,使用Service Request(服务请求)消息进行响应。该处理流程的示意图如图1所示。
然而,在实际运行过程中,网络侧节点(如MME)可能发生故障,重启复位之后,MME将丢失所服务UE的全部上下文信息。在这种异常情况下,MME从其他节点处获得所服务UE的相关信息并使用IMSI(International Mobile Subscriber Identification Number,国际移动用户识别码)标识对处于空闲态的UE发起寻呼。UE在收到指示IMSI的Paging消息后,使用Attach Request(附着请求)消息进行响应。该处理流程的示意图如图2所示。
由于故障或掉电等原因,核心网的MME可能发生失效,这样,MME将丢失先前维护、管理的所有UE的上下文信息。根据现有GTP(General Packet Radio Service Tunnel Protocol,通用分组无线服务技术隧道协议)操作流程,S-GW(Serving Gateway,服务网关)通过GTP Echo(GTP回响)消息检测到MME失效之后,将删除本地维护的与失效MME相关的所有UE的承载信息,从而,对用户的EPC(Evolved Packet Core,演进分组核心网)服务造成不利影响。
为了确保用户的EPC业务体验不受MME失效的影响,现有技术提出了一种在MME复位后恢复UE的上下文信息的方法,其流程图如图3所示,具体包括以下步骤:
步骤S301、在会话建立及修改过程中,MME将UE最新的TA list(Tracking Area list,跟踪区域列表)发送给S-GW。
步骤S302、当MME失效时,S-GW临时性的保存与失效MME相关的所有UE的IMSI及TA list信息,释放UE的其他上下文信息及资源。
步骤S303、S-GW通知P-GW清除所维护的UE上下文信息。
步骤S304、当MME复位时,S-GW通过Paging Notification(寻呼通知)消息将所保存的与该MME相关的所有UE的[IMSI,TA list]信息发送给MME。
步骤S305、当接收到包含[IMSI,TA list]信息的Paging Notification消息时,MME在TA list包含的TA中发起指示IMSI的Paging过程。
步骤S306、当接收到指示IMSI的Paging消息时,UE按照3GPP TS 24.301协议规范发起Attach过程。
为了保持所记录消息的新鲜性及有效性,在检测到MME失效时S-GW可以启动一个时长较短的定时器,在定时器超时后将所保留的UE的[IMSI,TAlist]信息删除。
在实现本发明实施例的过程中,申请人发现现有技术至少存在以下问题:
采用S-GW保存UE的IMSI标识及TA list并在MME复位后触发MME发起指示IMSI的Paging过程的机制,能够在失效后恢复的MME处有效的建立起原始用户的上下文信息,进而确保较高质量的用户体验。
然而,上述方法存在重复发起指示IMSI的Paging过程而造成UE再次附着的风险,具体发生过程如图4所示。
在MME失效之后,网络中处于IDLE态的UE可能在MME复位之前向网络发起TAU(Tracking Area Update,跟踪区域更新)或Service Request(服务请求)过程。
此时,由于MME正处于失效状态,UE的请求将得不到网络响应。对于用户而言,在无法获得网络服务情况下,很可能的一种做法是重新启动UE。这样,UE将发起Attach(附着)过程并附着至一个正常工作的新的MME来使用网络提供的通信服务。然而,当旧的MME从失效状态恢复之后,按照上述方法,该MME将根据S-GW通过Paging Notification消息提供的信息,对UE发起指示IMSI的Paging过程。这将促使UE进行本地去附着过程,并再次触发UE发起Attach过程,给用户体验造成不利影响。
具体实施方式
如背景技术所述,在EPS系统中,为了确保MME失效对用户体验不造成较为严重的负面影响,现有的技术方案提出在MME在复位后根据S-GW存储 的终端IMSI,TA list信息发起寻呼过程,促使终端设备重新附着至网络,从而,重新建立因失效而丢失的终端设备的上下文信息。
然而,如果终端设备在原有MME失效期间已附着至新MME,这样的优化机制会导致终端设备重复发起附着过程,而给用户体验造成不利影响。
为此,本发明实施例基于计时控制机制,提出了一种能够有效解决终端设备无谓响应IMSI Paging消息,而重复发起网络附着请求问题的方法。
如图5所示,为本发明实施例提出的一种IMSI Paging消息的处理方法的流程示意图,该方法具体包括以下步骤:
步骤S501、终端设备附着到网络中的MME。
步骤S502、终端设备判断当前所附着的MME是否与先前所附着的MME相同。
如果判断的结果为不相同,执行步骤S503;
如果判断的结果为相同,执行步骤S504。
在具体的应用场景中,本步骤中的判断处理过程,具体如下:
终端设备接收当前所附着的MME分配的GUTI(Globally Unique Temporary UE Identity,全球唯一临时终端标识)。
终端设备根据当前所附着的MME分配的GUTI和先前所附着的MME分配的GUTI中的信息,判断当前所附着的MME是否与先前所附着的MME相同。
具体的,EPS系统核心网的MME为UE分配的GUTI具有如下结构:
<GUTI>=<GUMMEI><M-TMSI>,
其中,<GUMMEI>=<MCC><MNC><MME Identifier>,
<MME Identifier>=<MME Group ID><MME Code>。
对不同的MME所分配的GUTI,其中的MME Identifier信息必然不同,所以,通过比较GUTI中的MME Identifier信息,可以进行当前附着的MME是否发生变化的判断。
步骤S503、终端设备启动计时操作,在计时操作结束前,终端设备拒绝响应接收到的IMSI Paging消息。
其中,计时操作所持续的时间长度为计时周期。
如果计时操作结束,则执行步骤S504。
在实际应用中,根据计时周期的配置方案差别,本步骤的具体处理过程包括以下两种情况:
情况一、终端设备在自身的数据卡获取预设的计时周期,并根据计时周期所对应的时间进行计时操作。
在此种情况下,计时周期是预配置的,运营商可以直接将适当的计时周期信息存储于数据卡中,例如,(U)SIM(Universal Subscriber Identity Module,全球用户身份单元)卡。
情况二、终端设备获取接收到的配置消息中所携带的计时周期,并根据计时周期所对应的时间进行计时操作。
对于此种情况,计时周期是可以动态配置的,网络侧可以根据网络系统当前的运行情况,为终端设备配置适合当前网络系统状态的计时周期,具体的配置方式可以是通过动态配置机制向终端设备发送携带计时周期的配置信息,终端设备通过该配置信息获取计时周期的相关信息,并在需要进行计时操作时,根据计时周期进行计时操作。
在具体的应用场景中,上述的计时操作可以通过启动定时器的方式来完成,该定时器所设定的时间长度等于计时周期。
需要进一步指出的是,上述的计时周期的大小,具体通过以下方式确定:
方式一、设定计时周期的大小等于S-GW检测到MME失效后为防止所保存的终端设备信息过时所设置定时器的时间长度大小。
这是一种定值确定方式,在确定S-GW中定时器的时间长度后,计时周期的大小也随之确定,
此种方式保持了终端侧和网络侧对于MME复位过程所需的最大延迟时间的统一。该时间范围是MME在复位后从S-GW接收终端相关信息的最大时间区间。超过该时间区间后,复位后的MME不会从S-GW接收到终端的相关信息,终端也将不会再接收到复位后的MME发送的IMSI Paging消息,自然,也就不会出现终端设备无谓响应IMSI Paging消息的情况。
方式二、根据系统统计信息,确定计时周期的大小。
这是一种非定值确定方式,根据不同的网络系统状态,甚至统计网络系统在不同时期的状态信息,都可能确定出不同大小的计时周期。
这样的方式需要综合考虑网络系统中的各项统计信息,并结合相应的运行维护和管理经验,进而确定相应的计时周期,这样的确定过程中,还会加入确定者的主观因素,确定者的经验以及对当前情况的判断的准确性,都会对最终确定的计时周期的大小产生影响。
在具体的应用场景中,具体应用上述的哪种方式进行计时周期的确定可以根据实际需要进行设定和调整,这样的变化并不影响本发明的保护范围。
步骤S504、当终端设备接收到IMSI Paging消息时,终端设备响应接收到的IMSI Paging消息。
与现有技术相比,本发明实施例具有以下优点:
通过应用本发明实施例的技术方案,在终端设备附着到网络中的MME之后,如果所附着的MME发生了变化,则终端设备启动计时操作,并在计时操作结束前,拒绝响应接收到的IMSI Paging消息,从而,能够在MME复位的情况下,有效解决终端设备无谓响应IMSI Paging消息,而重复发起网络附着请求过程的问题,并且该技术方案具有对现有操作流程修改小,易于实现的特点。
下面,结合具体的应用场景,对本发明实施例所提出的技术方案进行说明。
UE先前所附着的MME失效之后,如果UE发起新的Attach过程附着至一个新的MME,那么,新的MME将通过Attach Accept(附着接受)消息携带为该UE分配的新的GUTI发送给该UE。
而对于UE而言,在收到Attach Accept消息之后,通过将新GUTI与旧GUTI中的MME Identifier做比较,便可以确定当前自身已附着至一个新的MME上。为了避免响应旧的MME在复位后发送的IMSI Paging消息,UE在判断自身已附着至新的MME之后,应在一段时间之内对网络发送的IMSIPaging消息不进行响应。
为了方便说明,本发明实施例通过图6和图7共同对上述的技术方案进行说明。
如图6所示,为本发明实施例所提出的一种具体应用场景下的UE上定时器处理机制的流程示意图,具体包括以下步骤:
步骤S601、UE在先前所附着的MME失效后,重新发起Attach过程。
步骤S602、UE接收到Attach Accept消息。
Attach Accept消息中携带有分配给UE的GUTI,而GUTI中携带有分配该GUTI的MME的MME Identifier信息。
步骤S603、UE判断所附着的MME是否发生了改变。
在步骤S601之前,UE中存储有先前MME分配的GUTI,所以,在本步骤中,UE可以比较新旧GUTI,判断其中的MME Identifier信息是否发生了变化,从而,确定,在重新发起Attach过程前后,所附着的MME是否发生了改变。
如果发生了改变,执行步骤S604;
如果没有发生改变,直接执行步骤S605。
需要进一步指出的是,如果UE在步骤S601之前没有存储先前MME分配的GUTI,或者所存储的先前MME分配的GUTI的信息无法正常用于后续的比较,则UE直接确定所附着的MME没有发生改变,执行步骤S605。
步骤S604、UE启动定时器。
在定时器超时之前,如果UE接收到网络发送的IMSI Paging消息,UE对其不响应。
当定时器超时后,执行步骤S605。
步骤S605、UE进行正常的后续处理。
由前述的技术方案可知,实现本步骤的前提有两种情况,一种是步骤S603中的判断结果为MME没有发生改变,另一种是步骤S604中所设定的定时器超时,无论是上述的哪种情况,在本步骤的处理中,如果UE接收到网络发送的IMSI Paging消息,UE都会对其进行响应。
需要进一步指出的是,在前述的步骤S604中,UE所启动的定时器中的 时长可以采取以下的两种方式进行配置,具体说明如下:
方式一、预配置。
运营商将适当的定时器的时长参数预先存储于(U)SIM卡中,UE在需要启动定时器时,从(U)SIM卡读取相关参数信息。
需要进一步指出的是,上述的预配置信息不仅可以存储在(U)SIM卡中,也可以存储在STK(SIM TOOL KIT,用户识别应用发展工具)卡、UTK(User identity model card Tool Kit,用户识别模块卡开发工具包)卡,以及其他类型的数据卡,甚至UE自身所带的存储空间中,凡是可以使UE在需要启动定时器时,能够获取到时长参数的存储方式,都属于本发明的保护范围。
方式二、动态配置。
运营商可以根据网络系统运行情况通过动态配置机制将定时器时长参数配置到终端中,其中,具体的动态配置机制,可以如OMA DM(Open Management Architecture Device Management,开放管理架构下的设备管理)机制。
除此之外,其他能够为终端动态配置定时器时长参数的方式也可以应用于本发明实施例所提出的技术方案中,这样的变化并不影响本发明的保护范围。
另一方面,通过上述方式所配置的时长信息的具体大小也可以通过以下两种方式确定:
1、运营商将UE中定时器的时长参数设置为与前述的S-GW所使用定时器相同的值。
2、运营商根据系统运行、维护、管理经验或网络系统统计数据为终端确定合适的定时器时长参数值。
除此之外,其他能够确定时长参数具体大小的方式也可以应用于本发明实施例所提出的技术方案中,这样的变化并不影响本发明的保护范围。
基于上述的定时器处理机制,如图7所示,为本发明实施例所提出的一种具体应用场景下的UE接收到IMSI Paging消息后的处理流程的示意图,具体包括以下步骤:
步骤S701、UE接收到IMSI Paging消息。
步骤S702、UE判断当前是否启动了定时器。
一方面,可以判断是否存在定时器,另一方面,如果定时器始终存在,则可以进一步判断当前定时器是否超时,具体说明如下:
如果UE中的机制是在UE超时后即取消定时器,那么,可以直接通过是否存在定时器完成本步骤的判断。
如果UE中始终存在定时器,并且定时器存在启动与停止两种状态时,本步骤的判断则是判断当前定时器是否处于启动状态,或是否超时。
如果判断结果为是,则执行步骤S703;
如果判断结果为否,则执行步骤S704。
步骤S703、UE拒绝响应该IMSI Paging消息。
步骤S704、UE响应该IMSI Paging消息。
需要指出的是,上述的操作过程不仅局限于EPS系统,也可以扩展至GPRS(General Packet Radio Service)系统,具体的操作流程与此相似,不再赘述。
与现有技术相比,本发明实施例具有以下优点:
通过应用本发明实施例的技术方案,在终端设备附着到网络中的MME之后,如果所附着的MME发生了变化,则终端设备启动计时操作,并在计时操作结束前,拒绝响应接收到的IMSI Paging消息,从而,能够在MME复位的情况下,有效解决终端设备无谓响应IMSI Paging消息,而重复发起网络附着请求过程的问题,并且该技术方案具有对现有操作流程修改小,易于实现的特点。
为了实现本发明实施例的技术方案,本发明实施例还提出了一种终端设备,其结构示意图如图8所示,具体包括:
判断模块81,用于当终端设备附着到网络中的MME后,判断当前所附着的MME是否与先前所附着的MME相同;
计时模块82,用于在判断模块81的判断结果为不相同时,启动计时操作, 其中,计时操作所持续的时间长度为计时周期;
通信模块83,用于在计时模块82所启动的计时操作结束前,拒绝响应接收到的IMSI Paging消息。
其中,如果判断模块81的判断结果为相同,或计时模块82的计时操作已结束,则通信模块83还用于当接收到IMSI Paging消息时,响应接收到的IMSI Paging消息。
在具体的应用场景中,通信模块83,还用于接收当前所附着的MME分配的GUTI。
在此种情况下,判断模块81,具体用于根据通信模块83所接收到的当前所附着的MME分配的GUTI和先前所附着的MME分配的GUTI中的信息,判断当前所附着的MME是否与先前所附着的MME相同。
需要指出的是,计时模块82,具体用于进行以下两种处理:
1、在自身的数据卡获取预设的计时周期,并根据计时周期所对应的时间进行计时操作。
2、获取接收到的配置消息中所携带的计时周期,并根据计时周期所对应的时间进行计时操作。
在此种情况下,通信模块83,还用于接收携带计时周期的配置消息,携带时长信息的配置消息为网络侧根据当前系统状态通过动态配置机制发送给终端设备的消息;
计时模块82,还用于在通信模块83所接收到的配置消息中获取计时周期。
在上述的两种处理过程中,计时周期的大小,具体等于S-GW检测到MME失效后为防止所保存的终端设备信息过时所设置定时器的时间长度大小,或根据系统统计信息进行确定。
在具体的应用场景中,计时模块82进行计时处理的具体方式可以为启动定时器进行计时,其中,定时器所设定的时间长度等于计时周期。
与现有技术相比,本发明实施例具有以下优点:
通过应用本发明实施例的技术方案,在终端设备附着到网络中的MME之后,如果所附着的MME发生了变化,则终端设备启动计时操作,并在计时 操作结束前,拒绝响应接收到的IMSI Paging消息,从而,能够在MME复位的情况下,有效解决终端设备无谓响应IMSI Paging消息,而重复发起网络附着请求过程的问题,并且该技术方案具有对现有操作流程修改小,易于实现的特点。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明实施例可以通过硬件实现,也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解,本发明实施例的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明实施例各个实施场景所述的方法。
本领域技术人员可以理解附图只是一个优选实施场景的示意图,附图中的模块或流程并不一定是实施本发明实施例所必须的。
本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中,也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
上述本发明实施例序号仅仅为了描述,不代表实施场景的优劣。
以上公开的仅为本发明实施例的几个具体实施场景,但是,本发明实施例并非局限于此,任何本领域的技术人员能思之的变化都应落入本发明实施例的业务限制范围。