CN101499966A - 一种信息处理方法以及服务网关 - Google Patents
一种信息处理方法以及服务网关 Download PDFInfo
- Publication number
- CN101499966A CN101499966A CNA2008101307825A CN200810130782A CN101499966A CN 101499966 A CN101499966 A CN 101499966A CN A2008101307825 A CNA2008101307825 A CN A2008101307825A CN 200810130782 A CN200810130782 A CN 200810130782A CN 101499966 A CN101499966 A CN 101499966A
- Authority
- CN
- China
- Prior art keywords
- downlink data
- data packet
- described downlink
- tunnel
- processing unit
- 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.)
- Granted
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种信息处理方法以及服务网关,用于避免下发不必要的消息,且不影响业务服务器发送的下行数据包。本发明方法包括:接收下行数据包;根据预置的下行隧道信息判断下行隧道无效时,根据所述下行数据包的类型处理所述下行数据包。本发明还提供一种服务网关。本发明可以有效地避免下发不必要的消息,且不影响业务服务器发送的下行数据包。
Description
技术领域
本发明涉及通讯领域,尤其涉及一种信息处理方法以及服务网关。
背景技术
无线演进网络的核心网,即系统架构演进(SAE,System ArchitectureEvolution)主要包含移动管理实体(MME,Mobility Management Entity)、服务网关(S-GW,Serving Gateway)、分组数据网络网关(P-GW,Packet datanetwork Gateway)三个逻辑功能体。
其中,MME负责非接入层(NAS,Non-Access Stadium)信令加密以及漫游、跟踪等功能,分配用户临时身份标识、安全功能等,它对应于当前通用移动通信系统(UMTS,Universal Mobile Telecommunications System)系统内部服务GPRS支持节点(SGSN,Serving GPRS Supporting Node)的控制平面部分;
S-GW负责本地的移动性锚点和第三代伙伴组织计划(3GPP,ThirdGeneration Partnership Projects)系统内部的移动性锚点以及合法监听相关信息;
P-GW负责策略执行和计费以及合法监听相关功能。
在上述的无线演进网络中,用户设备(UE,User Equipment)触发的服务请求流程如图1所示,其中包括:
101~102:UE发起服务请求流程,发送服务请求消息给MME;
103:NAS鉴权流程(可选流程);
104:MME发送初始上下文建立请求消息给演进基站eNodeB,恢复所有激活的演进分组系统(EPS,Evolved Packet System)承载的无线侧承载;
105:eNodeB和UE之间的无线承载的建立;
106:UE发送上行数据到P-GW;
107:eNodeB发送初始上下文建立完成消息,消息中携带的信元包括eNodeB的地址和隧道端点标识符(TEID,Tunnel Endpoint Identifier);
108:MME发送更新承载请求消息给S-GW,通知eNodeB的地址和TEID给S-GW;
这步之后,S-GW可以发送下行数据给UE。
109:S-GW回复更新承载响应给MME。
在上述的流程中,UE可能在以下两种情况下触发服务请求流程:
1、UE需要发送上行数据或信令;
2、UE被网络侧寻呼,UE发起服务请求作为寻呼应答。
其中,在第二种情况下,当S-GW收到P-GW发送的下行数据包后,如果下行隧道无效,对空闲Idle态用户,网络侧会发起寻呼,寻呼到的UE会触发服务请求流程来恢复空口的用户隧道,以传输下行数据。
具体的流程如图2所示,其中包括:
201:当用户处在Idle态时,P-GW发送下行数据包给S-GW。S-GW收到数据包后,判断该数据包对应的下行隧道无效,即缓存该下行数据包;
202:S-GW发送下行数据通知消息给MME;
203~204:MME向eNodeB发起寻呼,eNodeB寻呼到用户;
205:UE发起UE触发的服务请求流程。
由上述两个图中可以看出,当UE触发服务请求流程时,从步骤106开始UE即可传输上行数据包,该上行数据包可能会使得P-GW向S-GW下发一个下行数据包,作为对该上行数据包的响应,而到了步骤108,MME才会向S-GW发送更新承载请求以更新下行隧道的相关信息,若在步骤106与步骤108之间,假设S-GW接收到了P-GW下发的下行数据包,S-GW检测下行隧道无效,则S-GW会向MME下发一个下行数据通知消息,以请求对应的UE发起服务请求流程,但此时实际上UE已经发起了服务请求流程,只是S-GW还没有接收到MME发送的更新承载请求,因此S-GW发送的此下行数据通知消息是一个不必要的消息,该不必要的消息增加了MME的负荷。
现有技术中一种避免该不必要的消息的方式为:S-GW接收到下行数据后,如判断下行隧道无效,则延迟发送下行数据通知消息,在延迟的时间内,若S-GW接收到MME发送的更新承载请求,则S-GW不再下发下行数据通知消息,而是直接按照下行隧道下发下行数据包。
但是上述方案中,S-GW收到下行数据包时,若下行隧道无效,则延迟发送下行数据通知消息,但是,若该下行数据包是由网络侧业务服务器始发的数据包(例如是会话初始化协议(SIP,Session Initialization Protocol)呼叫或者是传输控制协议(Transmission Control Protocol)连接请求),S-GW同样会对该类数据包进行延迟,而这种延迟可能会影响呼叫的及时建立。
因此,由上述信息处理方法可以看出,现有技术中,S-GW接收到下行数据包之后,可以采取两种处理方式:一种为直接根据该下行数据包向MME下发下行数据通知,另一种为对该下行数据包进行延迟处理。
所以上述技术中并不能在避免下发不必要消息的同时且不影响业务服务器始发的下行数据包。
发明内容
本发明实施例提供了一种信息处理方法以及服务网关,能够避免下发不必要的消息,且不影响业务服务器发送的下行数据包。
本发明实施例提供的信息处理方法,包括:接收下行数据包;根据预置的下行隧道信息判断下行隧道无效时,根据所述下行数据包的类型处理所述下行数据包。
本发明实施例提供的服务网关,包括:下行数据包接收单元,用于接收下行数据包;下行隧道校验单元,用于根据预置的下行隧道信息判断下行隧道是否无效;下行数据包处理单元,用于根据所述下行数据包的类型对所述下行数据包进行处理。
从以上技术方案可以看出,本发明实施例具有以下优点:
本发明实施例中,在判断下行隧道无效的情况下,可以对接收到的下行数据包进行分类,即判断该下行数据包为业务服务器下行数据包还是用户下行数据包,所以可以针对不同类型的下行数据包进行不同的处理,从而不会对所有接收到的下行数据包均发送下行数据通知,因此可以避免下发不必要的消息;另外,由于对下行数据包进行分类处理,从而也不会对所有接收到的下行数据包均进行延迟处理,因此不会影响业务服务器下发的下行数据包。
附图说明
图1为现有技术中UE触发服务请求流程图;
图2为现有技术中网络侧触发服务请求流程图;
图3为本发明实施例中信息处理方法第一实施例流程图;
图4为本发明实施例中信息处理方法第二实施例流程图;
图5为本发明实施例中信息处理方法第三实施例流程图;
图6为本发明实施例中信息处理方法第四实施例流程图;
图7为本发明实施例中服务网关实施例示意图。
具体实施方式
本发明实施例提供了一种信息处理方法以及服务网关,用于避免下发不必要的消息,且不影响业务服务器发送的下行数据包。
本发明实施例中,在判断下行隧道无效的情况下,可以对接收到的下行数据包进行分类,即判断该下行数据包为业务服务器下行数据包还是用户下行数据包,所以可以针对不同类型的下行数据包进行不同的处理,从而不会对所有接收到的下行数据包均发送下行数据通知,因此可以避免下发不必要的消息;
另外,由于对下行数据包进行分类处理,从而也不会对所有接收到的下行数据包均进行延迟处理,因此不会影响业务服务器下发的下行数据包。
本发明实施例中的信息处理方法包括:
接收下行数据包;
根据预置的下行隧道信息判断下行隧道是否无效,若无效,则判断所述下行数据包的类型为用户下行数据包还是业务服务器下行数据包;
根据判断结果对所述下行数据包执行相应的操作。
需要说明的是,本实施例以及后续实施例中所述的用户下行数据包是指由用户设备发送的上行数据包引发的下行数据包,本实施例以及后续实施例中所述的业务服务器下行数据包是指由业务服务器侧始发的下行数据包。
上述方案既可以适用于EPS演进网络,也适用于采用直接隧道(directtunnel)技术的UMTS系统,下面以EPS演进网络为例进行说明:
上述实施例中,具体的判断所述下行数据包的类型的步骤可以分为四种,下面分别进行介绍:
一、根据时间差进行判断:
本实施例中,S-GW可以判断同一个承载上,接收到第一个下行数据包之前最近接收到上行数据包的第一时间以及接收到第一个下行数据包的第二时间之间的时间差是否大于预置的门限值,并由判断结果确定下行数据包的类型,具体请参阅图3,本发明实施例中信息处理方法第一实施例包括:
301、接收下行数据包;
本实施例中,S-GW从P-GW侧接收下行数据包。
302、判断下行隧道是否无效,若无效,则执行步骤304,若有效,则执行步骤303;
S-GW接收到下行数据包后,首先判断本地是否保存有接收该下行数据包的承载对应的下行隧道的相关信息,即判断下行隧道是否有效,若有相关信息,则下行隧道有效,若无相关信息,则下行隧道无效。
303、向对应的UE下发该下行数据包,并结束流程;
若S-GW接收到下行数据包后判断下行隧道有效,则通过该下行隧道将该下行数据包发送至对应的UE。
304、记录接收到下行数据包的第二时间;
若S-GW接收到下行数据包后判断下行隧道无效,则记录接收到该下行数据包的第二时间。
305、将该第二时间与接收到上行数据包的第一时间进行比较;
S-GW记录了该下行数据包的第二时间之后,与之前记录的从该承载上接收到的上行数据包的第一时间进行比较。
需要说明的是,本实施例中,在S-GW接收该下行数据包之前最近接收到上行数据包时,需要记录接收到该上行数据包的第一时间,如图1所示,当执行步骤106,上行数据包达到S-GW时,S-GW记录第一时间。
306、判断第一时间与第二时间的时间差是否大于预置的门限值,若是,则执行步骤307,若否,则执行步骤308;
S-GW在获取到第一时间与第二时间之后,判断该两个时间之间的时间差是否大于预置的门限值。
若下行数据包是由UE发送的上行数据包引起的,则S-GW上刚收到的下行包的时间和接收到该下行数据包之前最近收到此承载上的上行数据包的时间之间的差值会比较小,因此S-GW可以根据这个特点来区分两种类型的下行数据包。
本实施例中,预置的门限值可以根据实际应用进行确定,此处不作限定。
307、向对应的MME下发下行数据通知;
若时间差大于预置的门限值,则S-GW确定该下行数据包为业务服务器下行数据包,即由业务服务器始发的数据包,则S-GW立即向该下行数据包对应的MME下发下行数据通知,以请求MME控制相应的UE进行业务请求。
308、对下行数据包进行延迟处理。
若时间差小于或等于预置的门限值,则S-GW确定该下行数据包为用户下行数据包,即由上行数据包引起的下行数据包。
S-GW对该下行数据包进行延迟处理,具体的处理流程可以为:从获知该下行数据包为用户下行数据包为起点,设置一个时间周期,并在该时间周期内等待MME上传的更新承载请求(该更新承载请求中包含下行隧道的相关信息),若等待到,则根据下行隧道的相关信息通过下行隧道向对应的UE发送该下行数据包,若未等待到,则可判断UE并未触发服务请求,因此向对应的MME下发下行数据通知,使得MME控制对应的UE发起触发服务请求。
上述实施例中通过时间差对不同的下行数据包进行分类,对用户下行数据包进行延迟处理,对业务服务器下行数据包立即下发下行数据通知,因此避免下发不必要的消息,且不会影响业务服务器下发的下行数据包。
二、根据上行隧道状态进行判断:
本实施例中,S-GW在接收到下行数据包后,判断该下行数据包的承载是否已经建立对应的上行隧道,并根据该判断结果对下行数据包进行分类,具体请参阅图4,本发明实施例中信息处理方法第二实施例包括:
401、接收下行数据包;
本实施例中,S-GW从P-GW侧接收下行数据包。
402、判断下行隧道是否无效,若无效,则执行步骤404,若有效,则执行步骤403;
S-GW接收到下行数据包后,首先判断本地是否保存有接收该下行数据包的承载对应的下行隧道的相关信息,即判断下行隧道是否有效,若有相关信息,则下行隧道有效,若无相关信息,则下行隧道无效。
403、向对应的UE下发该下行数据包,并结束流程;
若S-GW接收到下行数据包后判断下行隧道有效,则通过该下行隧道将该下行数据包发送至对应的UE。
404、判断上行隧道是否已经建立,若是,则执行步骤406,若否,则执行步骤405;
S-GW在判断下行隧道无效之后,会根据之前从MME接收到的相关信息判断该承载的上行隧道是否建立。
需要说明的是,在UE触发服务请求流程中,当MME向演进基站发送初始化上下文建立请求之后,即如图1所示的步骤104之后,可以向S-GW发送更新承载请求或者是其他类型的信令,在该信令中包含有空口侧上行隧道的建立状态,若上行隧道已经建立,则在该信令中标识上行隧道已经建立,则S-GW可以根据接收到的该信令判断上行隧道是否已经建立。
405、向对应的MME下发下行数据通知;
若上行隧道尚未建立,则S-GW确定该下行数据包为业务服务器下行数据包,即由业务服务器始发的数据包,则S-GW立即向该下行数据包对应的MME下发下行数据通知,以请求MME控制相应的UE进行业务请求。
406、对下行数据包进行延迟处理。
若上行隧道已经建立,则S-GW确定该下行数据包为用户下行数据包,即由上行数据包引起的下行数据包。
本实施例中,S-GW需要将上行隧道的状态与下行隧道的状态相互独立,使得上行隧道的状态可以与下行隧道的状态不一致,则此时下行隧道无效,但上行隧道已经建立,则可认为该数据包为用户下行数据包。
但为了数据传输的需要,上行隧道的状态与下行隧道的状态最终会被设置为一致,所以在图1所示的流程中,当步骤108中MME向S-GW发送了更新承载请求之后,S-GW将上行隧道的状态与下行隧道的状态设置为始终相同,即当S-GW获取到下行隧道的相关信息后,将上行隧道与下行隧道的状态都设置为已经建立,当需要释放隧道时,则将上行隧道与下行隧道的状态都设置为释放。
S-GW对该下行数据包进行延迟处理,具体的处理流程可以为:从获知该下行数据包为用户下行数据包为起点,设置一个时间周期,并在该时间周期内等待MME上传的更新承载请求(该更新承载请求中包含下行隧道的相关信息),若等待到,则根据下行隧道的相关信息通过下行隧道向对应的UE发送该下行数据包,若未等待到,则可判断UE并未触发服务请求,因此向对应的MME下发下行数据通知,使得MME控制对应的UE发起触发服务请求。
上述实施例中通过上行隧道的建立状态对不同的下行数据包进行分类,对用户下行数据包进行延迟处理,对业务服务器下行数据包立即下发下行数据通知,因此避免下发不必要的消息,且不会影响业务服务器下发的下行数据包。
三、根据下行数据包的内容进行判断:
本实施例中,S-GW在接收到下行数据包后,从该下行数据包中包含的内容判断该下行数据包的类型,具体请参阅图5,本发明实施例中信息处理方法第三实施例包括:
501、接收下行数据包;
本实施例中,S-GW从P-GW侧接收下行数据包。
502、判断下行隧道是否无效,若无效,则执行步骤504,若有效,则执行步骤503;
S-GW接收到下行数据包后,首先判断本地是否保存有接收该下行数据包的承载对应的下行隧道的相关信息,即判断下行隧道是否有效,若有相关信息,则下行隧道有效,若无相关信息,则下行隧道无效。
503、向对应的UE下发该下行数据包,并结束流程;
若S-GW接收到下行数据包后判断下行隧道有效,则通过该下行隧道将该下行数据包发送至对应的UE。
504、判断下行数据包是否指示为业务服务器始发请求,若是,则执行步骤505,若否,则执行步骤506;
S-GW在判断下行隧道无效之后,会对接收到的下行数据包进行解析得到数据包类型,判断该数据包类型是否指示为业务服务器始发请求,若是,则确定所述下行数据包为业务服务器下行数据包,若否,则确定所述下行数据包为用户下行数据包。
其中,该标识可以为SIP INVITE请求,或者是TCP连接请求,或者是其他类型的业务服务器下发的数据包。
505、向对应的MME下发下行数据通知;
若下行数据包中的数据包类型指示为业务服务器始发请求,则S-GW确定该下行数据包为业务服务器下行数据包,即由业务服务器始发的数据包,则S-GW立即向该下行数据包对应的MME下发下行数据通知,以请求MME控制相应的UE进行业务请求。
506、对下行数据包进行延迟处理。
若下行数据包中的数据包类型指示不为业务服务器始发请求,则S-GW确定该下行数据包为用户下行数据包,即由上行数据包引起的下行数据包。
S-GW对该下行数据包进行延迟处理,具体的处理流程可以为:从获知该下行数据包为用户下行数据包为起点,设置一个时间周期,并在该时间周期内等待MME上传的更新承载请求(该更新承载请求中包含下行隧道的相关信息),若等待到,则根据下行隧道的相关信息通过下行隧道向对应的UE发送该下行数据包,若未等待到,则可判断UE并未触发服务请求,因此向对应的MME下发下行数据通知,使得MME控制对应的UE发起触发服务请求。
四、根据下行数据包对应的业务类型进行判断:
本实施例中,S-GW在接收到下行数据包后,从该下行数据包对应的承载上下文的QoS参数判断该下行数据包对应的业务类型,具体请参阅图6,本发明实施例中信息处理方法第四实施例包括:
601、接收下行数据包;
本实施例中,S-GW从P-GW侧接收下行数据包。
602、判断下行隧道是否无效,若无效,则执行步骤604,若有效,则执行步骤603;
S-GW接收到下行数据包后,首先判断本地是否保存有接收该下行数据包的承载对应的下行隧道的相关信息,即判断下行隧道是否有效,若有相关信息,则下行隧道有效,若无相关信息,则下行隧道无效。
603、向对应的UE下发该下行数据包,并结束流程;
若S-GW接收到下行数据包后判断下行隧道有效,则通过该下行隧道将该下行数据包发送至对应的UE。
604、判断下行数据包是否为预置业务对应的数据包,若是,则执行步骤605,若否,则执行步骤606;
在实际应用中,对于一些有特殊要求的业务而言,这些业务对应的下行数据包需要及时的向MME发送下行数据通知消息,以便能够及时对这些业务进行处理,为便于理解,下面以一具体实例进行说明:
语音业务对用户来说相当重要,当用户作为语音业务的被叫时,EPS网络需要尽快为用户建立承载连接来完成语音通话。本实施例中即以语音业务作为有特殊要求的业务为例进行说明。
IMS网络提供的语音业务是通过SIP信令来建立的,而在EPS网络中,SIP信令所对应的承载上下文的QoS参数中的服务质量等级标识(QCI,QoSClass Identifier)值是特定的。因此,S-GW收到数据包后,如果下行隧道无效,则可以通过分析数据包所对应的承载上下文的QoS参数中的QCI值来区分出该数据包是否是SIP信令对应的数据包(即语音业务对应的下行数据包),从而进行不同的处理。
本实施例中,判断下行数据包是否为预置业务对应的数据包的方式可以为:
S-GW分析数据包对应的承载上下文中的承载QoS参数,如果该承载QoS参数中的QCI值对应的是SIP信令,则S-GW确定该下行数据包为SIP信令对应的数据包(即语音业务对应的下行数据包)。
605、向对应的MME下发下行数据通知;
若下行数据包为预置的业务对应的数据包,则S-GW立即向该下行数据包对应的MME下发下行数据通知。
为了使得语音业务能够尽快被建立,如果S-GW确定该下行数据包是SIP信令对应的下行数据包(即语音业务对应的下行数据包),则正常向MME发送下行数据通知消息。
606、对下行数据包进行延迟处理。
若下行数据包不是预置的业务对应的数据包,则S-GW对该下行数据包进行延迟处理,具体的处理流程可以为:从获知该下行数据包不是预置的业务对应的数据包为起点,设置一个定时器,在定时器溢出前暂时停止向MME发送下行数据通知消息。
可以理解的是,在实际应用中同样还可以采用其他的方式对该下行数据包进行延迟处理。
本实施例是以语音业务为例进行说明的,可以理解的是,在实际应用中,本实施例还可以适用于S-GW通过用户承载上下文的QoS参数中的其他特定的QCI值或者QCI所属的范围来区分出收到的下行数据包是否是预置业务的数据包,如果S-GW确定该数据包是预置业务对应的数据包,则正常向MME发送下行数据通知消息;反之,如果S-GW确定该数据包不是预置业务的数据包,S-GW启动一个定时器,在定时器溢出前暂时停止向MME发送下行数据通知消息。
上述实施例中通过下行数据包中的数据包类型对下行数据包进行分类,对用户下行数据包进行延迟处理,对业务服务器下行数据包立即下发下行数据通知,因此避免下发不必要的消息,且不会影响业务服务器下发的下行数据包。
上述介绍了本发明实施例中的信息处理方法实施例,上述实施例中,在判断下行隧道无效的情况下,可以对接收到的下行数据包进行分类,即判断该下行数据包为业务服务器下行数据包还是用户下行数据包,所以可以针对不同类型的下行数据包进行不同的处理,从而不会对所有接收到的下行数据包均发送下行数据通知,因此可以避免下发不必要的消息;
另外,由于对下行数据包进行分类处理,从而也不会对所有接收到的下行数据包均进行延迟处理,因此不会影响业务服务器下发的下行数据包。
下面介绍本发明实施例中的服务网关装置实施例。
参阅图7,本发明实施例中服务网关实施例包括:
下行数据包接收单元701,用于接收下行数据包;
下行隧道校验单元702,用于根据预置的下行隧道信息判断下行隧道是否无效;
下行数据包处理单元703,用于根据所述下行数据包的类型对所述下行数据包进行处理。
本实施例中,下行数据包处理单元703还可以进一步包括:
第一处理单元7031,用于记录接收到所述下行数据包之前最近接收到用户设备发送的上行数据包的第一时间,记录接收到下行数据包的第二时间,判断所述第一时间与所述第二时间的差值是否大于预置的门限值,若大于,则向对应的移动管理实体发送下行数据通知,所述第一时间与所述第二时间的差值大于预置的门限值表示所述下行数据包的类型为业务服务器下行数据包。
或
第二处理单元7032,用于记录接收到所述下行数据包之前最近接收到用户设备发送的上行数据包的第一时间,记录接收到下行数据包的第二时间,判断所述第一时间与所述第二时间的差值是否大于预置的门限值,若小于或等于,则对所述下行数据包进行延迟处理,所述第一时间与所述第二时间的差值小于或等于预置的门限值表示所述下行数据包的类型为用户下行数据包。
或
第三处理单元7033,用于判断所述下行数据包对应的上行隧道是否已经建立,若尚未建立,则向对应的移动管理实体发送下行数据通知,所述下行数据包对应的上行隧道尚未建立表示所述下行数据包的类型为业务服务器下行数据包。
或
第四处理单元7034,用于判断所述下行数据包对应的上行隧道是否已经建立,若已建立,则对所述下行数据包进行延迟处理,所述下行数据包对应的上行隧道已经建立表示所述下行数据包的类型为用户下行数据包。
或
第五处理单元7035,用于对所述下行数据包进行解析得到数据包类型,判断所述数据包类型是否指示为业务服务器始发请求,若是,则向对应的移动管理实体发送下行数据通知,所述数据包类型指示为业务服务器始发请求表示所述下行数据包的类型为业务服务器下行数据包。
或
第六处理单元7036,用于对所述下行数据包进行解析得到数据包类型,判断所述数据包类型是否指示为业务服务器始发请求,若否,则对所述下行数据包进行延迟处理,所述数据包类型未指示为业务服务器始发请求表示所述下行数据包的类型为用户下行数据包。
或
第七处理单元7037,用于判断所述下行数据包是否为预置业务对应的数据包,若是,则向所述下行数据包对应的移动管理实体发送下行数据通知消息。
或
第八处理单元7038,用于判断所述下行数据包是否为预置业务对应的数据包,若否,则对所述下行数据包进行延迟处理。
本实施例中的服务网关还可以包括:
更新承载请求接收单元704,用于接收移动管理实体发送的更新承载请求消息,所述更新承载请求消息中携带上行隧道建立标识,所述上行隧道建立标识用于指示上行隧道已经建立。
为便于理解,下面对不同场景中的服务网关运行流程进行描述:
一、根据时间差进行判断:
下行数据包接收单元701从P-GW接收下行数据包,下行隧道校验单元702根据预置的下行隧道信息判断下行隧道是否无效,并将判断结果发送至下行数据包处理单元703,当下行隧道无效时,下行数据包处理单元703中的第一处理单元7031或第二处理单元7032记录接收到用户设备发送的上行数据包的第一时间,记录接收到下行数据包的第二时间;判断所述第一时间与所述第二时间的差值是否大于预置的门限值,若大于,则第一处理单元7031向对应的移动管理实体发送下行数据通知;
若小于或等于,则第二处理单元7032对所述下行数据包进行延迟处理。
二、根据上行隧道状态进行判断:
下行数据包接收单元701从P-GW接收下行数据包,下行隧道校验单元702根据预置的下行隧道信息判断下行隧道是否无效,并将判断结果发送至下行数据包处理单元703,当下行隧道无效时,下行数据包处理单元703中的第三处理单元7033或第四处理单元7034判断所述下行数据包对应的上行隧道是否已经建立,若已经建立,则第四处理单元7034对所述下行数据包进行延迟处理;
若尚未建立,则第三处理单元7033向对应的移动管理实体发送下行数据通知。
本实施例中第三处理单元7033或第四处理单元7034判断上行隧道是否建立的依据可以由更新承载请求接收单元704得到,更新承载请求接收单元704可以接收移动管理实体发送的更新承载请求消息,所述更新承载请求消息中携带上行隧道建立标识,所述上行隧道建立标识用于指示上行隧道已经建立。
三、根据下行数据包的内容进行判断:
下行数据包接收单元701从P-GW接收下行数据包,下行隧道校验单元702根据预置的下行隧道信息判断下行隧道是否无效,并将判断结果发送至下行数据包处理单元703,当下行隧道无效时,下行数据包处理单元703中的第五处理单元7035或第六处理单元7036对所述下行数据包进行解析得到数据包类型,判断所述数据包类型是否指示为业务服务器始发请求,若是,则第五处理单元7035向对应的移动管理实体发送下行数据通知;
若否,则第六处理单元7036对所述下行数据包进行延迟处理。
四、根据下行数据包对应的业务类型进行判断:
下行数据包接收单元701从P-GW接收下行数据包,下行隧道校验单元702根据预置的下行隧道信息判断下行隧道是否无效,并将判断结果发送至下行数据包处理单元703,当下行隧道无效时,下行数据包处理单元703中的第七处理单元7037或第八处理单元7038判断所述数据包是否为预置业务类型对应的数据包,若是,则第七处理单元7037向对应的移动管理实体发送下行数据通知;
若否,则第八处理单元7038对所述下行数据包进行延迟处理。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,该程序在执行时,包括如下步骤:
接收下行数据包;根据预置的下行隧道信息判断下行隧道无效时,根据所述下行数据包的类型处理所述下行数据包。
上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上对本发明所提供的一种信息处理方法以及服务网关进行了详细介绍,对于本领域的一般技术人员,依据本发明实施例的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。
Claims (24)
1、一种信息处理方法,其特征在于,包括:
接收下行数据包;
根据预置的下行隧道信息判断下行隧道无效时,根据所述下行数据包的类型处理所述下行数据包。
2、根据权利要求1所述的方法,其特征在于,所述根据所述下行数据包的类型处理所述下行数据包的步骤包括:
记录接收到所述下行数据包之前最近接收到用户设备发送的上行数据包的第一时间;
记录接收到下行数据包的第二时间;
判断所述第一时间与所述第二时间的差值是否大于预置的门限值,若大于,则向所述下行数据包对应的移动管理实体发送下行数据通知消息。
3、根据权利要求1所述的方法,其特征在于,所述根据所述下行数据包的类型处理所述下行数据包的步骤包括:
记录接收到所述下行数据包之前最近接收到用户设备发送的上行数据包的第一时间;
记录接收到下行数据包的第二时间;
判断所述第一时间与所述第二时间的差值是否小于或等于预置的门限值,若小于或等于,则对所述下行数据包进行延迟处理。
4、根据权利要求1所述的方法,其特征在于,所述根据所述下行数据包的类型处理所述下行数据包的步骤包括:
判断所述下行数据包对应的上行隧道是否已经建立,若已经建立,则对所述下行数据包进行延迟处理。
5、根据权利要求1所述的方法,其特征在于,所述根据所述下行数据包的类型处理所述下行数据包的步骤包括:
判断所述下行数据包对应的上行隧道是否未建立,若尚未建立,则向所述下行数据包对应的移动管理实体发送下行数据通知消息。
6、根据权利要求4或5所述的方法,其特征在于,所述接收下行数据包的步骤之前包括:
接收移动管理实体发送的上行隧道建立标识,所述上行隧道建立标识用于指示上行隧道已经建立。
7、根据权利要求6所述的方法,其特征在于,所述接收移动管理实体发送的上行隧道建立标识的步骤之前包括:
设置上行隧道状态与下行隧道状态相互独立。
8、根据权利要求1所述的方法,其特征在于,所述根据所述下行数据包的类型处理所述下行数据包步骤包括:
对所述下行数据包进行解析得到数据包类型;
判断所述数据包类型是否指示为业务服务器始发请求,若是,则向所述下行数据包对应的移动管理实体发送下行数据通知消息。
9、根据权利要求1所述的方法,其特征在于,所述根据所述下行数据包的类型处理所述下行数据包步骤包括:
对所述下行数据包进行解析得到数据包类型;
判断所述数据包类型是否指示为业务服务器始发请求,若否,则对所述下行数据包进行延迟处理。
10、根据权利要求8所述的方法,其特征在于,所述判断所述数据包类型指示为业务服务器始发请求的步骤包括:
判断所述数据包类型是否为会话初始化协议邀请信令,或传输控制协议连接请求,若是,则确定所述数据包类型指示为业务服务器始发请求。
11、根据权利要求1所述的方法,其特征在于,所述根据所述下行数据包的类型处理所述下行数据包步骤包括:
判断所述下行数据包是否为预置业务对应的数据包,若是,则向所述下行数据包对应的移动管理实体发送下行数据通知消息。
12、根据权利要求1所述的方法,其特征在于,所述根据所述下行数据包的类型处理所述下行数据包步骤包括:
判断所述下行数据包是否为预置业务对应的数据包,若否,则对所述下行数据包进行延迟处理。
13、根据权利要求11或12所述的方法,其特征在于,所述预置业务为会话发起协议业务;
所述判断所述下行数据包是否为预置业务对应的数据包的步骤包括:
对所述下行数据包进行解析得到所述下行数据包对应的承载上下文;
从所述承载上下文中获取服务质量参数;
从所述服务质量参数中获取服务质量等级标识QCI参数;
判断所述QCI参数是否对应会话发起协议业务,若是,则确定所述下行数据包为预置业务对应的数据包。
14、根据权利要求3,4,9或12中任一项所述的方法,其特征在于,所述对所述下行数据包进行延迟处理的步骤包括:
设置定时器;
当定时器达到预置的数值时,向所述下行数据包对应的移动管理实体发送下行数据通知消息。
15、一种服务网关,其特征在于,包括:
下行数据包接收单元,用于接收下行数据包;
下行隧道校验单元,用于根据预置的下行隧道信息判断下行隧道是否无效;
下行数据包处理单元,用于根据所述下行数据包的类型对所述下行数据包进行处理。
16、根据权利要求15所述的服务网关,其特征在于,所述下行数据包处理单元包括:
第一处理单元,用于记录接收到所述下行数据包之前最近接收到用户设备发送的上行数据包的第一时间,记录接收到下行数据包的第二时间,判断所述第一时间与所述第二时间的差值是否大于预置的门限值,若大于,则向对应的移动管理实体发送下行数据通知。
17、根据权利要求15所述的服务网关,其特征在于,所述下行数据包处理单元包括:
第二处理单元,用于记录接收到所述下行数据包之前最近接收到用户设备发送的上行数据包的第一时间,记录接收到下行数据包的第二时间,判断所述第一时间与所述第二时间的差值是否小于或等于预置的门限值,若小于或等于,则对所述下行数据包进行延迟处理。
18、根据权利要求15所述的服务网关,其特征在于,所述下行数据包处理单元包括:
第三处理单元,用于判断所述下行数据包对应的上行隧道是否未建立,若尚未建立,则向对应的移动管理实体发送下行数据通知。
19、根据权利要求15所述的服务网关,其特征在于,所述下行数据包处理单元包括:
第四处理单元,用于判断所述下行数据包对应的上行隧道是否已经建立,若已建立,则对所述下行数据包进行延迟处理。
20、根据权利要求15所述的服务网关,其特征在于,所述下行数据包处理单元包括:
第五处理单元,用于对所述下行数据包进行解析得到数据包类型,判断所述数据包类型是否指示为业务服务器始发请求,若是,则向对应的移动管理实体发送下行数据通知。
21、根据权利要求15所述的服务网关,其特征在于,所述下行数据包处理单元包括:
第六处理单元,用于对所述下行数据包进行解析得到数据包类型,判断所述数据包类型是否指示为业务服务器始发请求,若否,则对所述下行数据包进行延迟处理。
22、根据权利要求15所述的服务网关,其特征在于,所述下行数据包处理单元包括:
第七处理单元,用于判断所述下行数据包是否为预置业务对应的数据包,若是,则向所述下行数据包对应的移动管理实体发送下行数据通知消息。
23、根据权利要求15所述的服务网关,其特征在于,所述下行数据包处理单元包括:
第八处理单元,用于判断所述下行数据包是否为预置业务对应的数据包,若否,则对所述下行数据包进行延迟处理。
24、根据权利要求18或19所述的服务网关,其特征在于,所述服务网关还包括:
更新承载请求接收单元,用于接收移动管理实体发送的更新承载请求消息,所述更新承载请求消息中携带上行隧道建立标识,所述上行隧道建立标识用于指示上行隧道已经建立。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2008101307825A CN101499966B (zh) | 2008-01-28 | 2008-07-21 | 一种信息处理方法以及服务网关 |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200810006993 | 2008-01-28 | ||
CN200810006993.8 | 2008-01-28 | ||
CN2008101307825A CN101499966B (zh) | 2008-01-28 | 2008-07-21 | 一种信息处理方法以及服务网关 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101499966A true CN101499966A (zh) | 2009-08-05 |
CN101499966B CN101499966B (zh) | 2012-04-04 |
Family
ID=40946852
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2008101307825A Active CN101499966B (zh) | 2008-01-28 | 2008-07-21 | 一种信息处理方法以及服务网关 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101499966B (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2011050663A1 (zh) * | 2009-10-28 | 2011-05-05 | 中兴通讯股份有限公司 | 支持本地ip访问的通信系统中隧道更新方法与系统 |
CN102056142A (zh) * | 2009-11-09 | 2011-05-11 | 中兴通讯股份有限公司 | 一种建立本地ip访问下行数据通道的方法及系统 |
CN103118415B (zh) * | 2011-11-16 | 2016-06-29 | 华为终端有限公司 | 一种业务请求的处理方法和装置 |
WO2018233499A1 (zh) * | 2017-06-20 | 2018-12-27 | 华为技术有限公司 | 一种通信方法及装置 |
CN113543088A (zh) * | 2020-04-16 | 2021-10-22 | 上海泽辛信息技术有限公司 | 一种基于LoRaWAN多通道的数据传输方法 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100556191C (zh) * | 2006-03-20 | 2009-10-28 | 大唐移动通信设备有限公司 | 一种宽带无线移动通信系统及执行寻呼的方法 |
CN101047977A (zh) * | 2006-03-27 | 2007-10-03 | 华为技术有限公司 | 无线通信系统及方法以及在该系统中使用的寻呼方法 |
CN101090358B (zh) * | 2006-06-15 | 2011-02-02 | 华为技术有限公司 | 一种恢复用户面数传的方法 |
-
2008
- 2008-07-21 CN CN2008101307825A patent/CN101499966B/zh active Active
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2011050663A1 (zh) * | 2009-10-28 | 2011-05-05 | 中兴通讯股份有限公司 | 支持本地ip访问的通信系统中隧道更新方法与系统 |
CN102056136A (zh) * | 2009-10-28 | 2011-05-11 | 中兴通讯股份有限公司 | 支持本地ip访问的通信系统中隧道更新方法与系统 |
CN102056136B (zh) * | 2009-10-28 | 2014-04-09 | 中兴通讯股份有限公司 | 支持本地ip访问的通信系统中隧道更新方法与系统 |
CN102056142A (zh) * | 2009-11-09 | 2011-05-11 | 中兴通讯股份有限公司 | 一种建立本地ip访问下行数据通道的方法及系统 |
WO2011054264A1 (zh) * | 2009-11-09 | 2011-05-12 | 中兴通讯股份有限公司 | 一种建立本地ip访问下行数据通道的方法及系统 |
CN102056142B (zh) * | 2009-11-09 | 2014-07-02 | 中兴通讯股份有限公司 | 一种建立本地ip访问下行数据通道的方法及系统 |
CN103118415B (zh) * | 2011-11-16 | 2016-06-29 | 华为终端有限公司 | 一种业务请求的处理方法和装置 |
WO2018233499A1 (zh) * | 2017-06-20 | 2018-12-27 | 华为技术有限公司 | 一种通信方法及装置 |
US10785635B2 (en) | 2017-06-20 | 2020-09-22 | Huawei Technologies Co., Ltd. | Session management method, apparatus, and system |
US11218867B2 (en) | 2017-06-20 | 2022-01-04 | Huawei Technologies Co., Ltd. | Session management method, apparatus, and system |
CN113543088A (zh) * | 2020-04-16 | 2021-10-22 | 上海泽辛信息技术有限公司 | 一种基于LoRaWAN多通道的数据传输方法 |
Also Published As
Publication number | Publication date |
---|---|
CN101499966B (zh) | 2012-04-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
USRE49636E1 (en) | Method and apparatus of improving quality of calls in mobile communication system | |
CN101136835B (zh) | 一种空闲模式下承载建立方法 | |
CN101494848B (zh) | 业务挂起的方法、业务恢复的方法、系统及设备 | |
CN101534495B (zh) | 一种用户设备的业务承载建立方法及装置 | |
US10015834B2 (en) | Apparatus, device, and method for establishing connection to packet data network | |
CN101677470A (zh) | 服务请求的处理方法、装置及系统 | |
CN101499966B (zh) | 一种信息处理方法以及服务网关 | |
CN101272600B (zh) | 实现承载重建立的方法、及其相关设备 | |
WO2011026407A1 (zh) | 一种本地网际协议访问连接移动性支持的方法及系统 | |
CN102791000A (zh) | 一种控制负载转移的方法 | |
CN101547521A (zh) | 释放ue资源的方法 | |
WO2016165307A1 (zh) | 决策服务质量QoS的方法、网络侧网元及系统 | |
CN101534497B (zh) | 分组数据网连接中承载处理的方法及移动性管理实体设备 | |
CN101577970B (zh) | 一种无线资源释放的方法 | |
CN102014434B (zh) | 一种服务网关的负载重分配方法及系统 | |
JP4406204B2 (ja) | 2層通信ネットワークにおける接続解除 | |
CN101998567B (zh) | 终端转为连接态时更改服务网关的连接激活方法及系统 | |
CN111903180B (zh) | 在无线通信网络中为设备建立承载的方法和装置 | |
CN101621786B (zh) | 一种承载更新的方法、装置和系统 | |
CN102480799B (zh) | 一种无线通信网络及其通知机器类通信设备离线的方法 | |
CN111903179B (zh) | 在无线通信网络中为设备建立承载的方法和装置 | |
WO2011006395A1 (zh) | 一种部分故障处理的同步方法和系统 | |
CN102318384A (zh) | 移动性管理网元故障的处理方法、网络设备及网络系统 | |
KR101988473B1 (ko) | 이동 통신 시스템 및 그의 비정상 호 종료 처리 방법, 이를 지원하는 장치 | |
CN102761854A (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 | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
EE01 | Entry into force of recordation of patent licensing contract |
Application publication date: 20090805 Assignee: Apple Computer, Inc. Assignor: Huawei Technologies Co., Ltd. Contract record no.: 2015990000755 Denomination of invention: Information processing method and service gateway Granted publication date: 20120404 License type: Common License Record date: 20150827 |
|
LICC | Enforcement, change and cancellation of record of contracts on the licence for exploitation of a patent or utility model |