基于临时处理隧道表的上行数据处理方法、MME和SGW与流程

本发明涉及通信技术领域，尤其涉及基于临时处理隧道表的上行数据处理方法mme和sgw。

背景技术：

核心网设备主要功能是为建立用户的承载，完成用户的管理和承载管理，其中包括多个网元实体，有mme(mobilitymanagemententity，移动管理实体)网元，sgw(servinggateway，服务网关)网元，pgw(pdngateway，pdn网关)网元，pcrf((policyandchargingrulefunction，策略和计费规则功能)网元。用户接入后，为用户分配并建立承载信息，其中用户接入过程就通过各个网元信令消息交互来完成，可以简单描述为网元间信令消息传递和各个网元用户承载信息配置。

对于核心网来说，bhca(busyhourcallattempt，忙时每小时起呼次数)参数表示了本设备能够接入用户的频率，即固定时间内能接入用户的个数。如何提高bhca参数是每个通信设备厂商所面临的共同问题。对于指定的硬件条件，提高bhca参数只能依靠软件优化。

用户建立过程，即附着过程，核心网从接收到基站上来承载建立请求，到配置完成本地用户信息后回复完成响应到基站，核心网内部信令流程和业务配置流程经过多个网元，并在完成业务实体的配置后才能完成。

如图1所示，在终端接入后，发起承载创建请求，信令交互流程需要通过mme网元、sgw网元、pgw网元、pcrf网元，配置pgw业务实体、sgw业务实体，然后再回复响应消息到mme网元，然后回复承载创建响应。从承载创建请求到响应，核心网内部经历多次网元间消息收发(如图1的1到10)，随着消息接入频率增加，消息的累加，必然导致消息处理时长的增加。

现有技术中，至少存在以下限制：

限制一：核心网内部完成业务实体配置后，才回复响应消息，从接收到承载创建请求到回复响应之前，核心网内部必须完成sgw、pgw业务处理实体的承载配置，如果未完成配置即回复响应，会导致上行业务数据到sgw业务处理实体后，找不到对应的承载信息，即会触发errorindication流程。

当sgw或者enb业务处理节点接收到一个不存在eps(evolvedpacketsystem，演进的分组系统)承载上下文的gtpu隧道数据，此业务处理节点需要丢弃gtpu数据并给发送节点返回一个gtpuerrorindication。当发送节点接收到errorindication后，认为接续的对端没有该用户的承载上下文，会删除本端对应的承载信息。

限制二：用户接入频率加快，消息队列过长，用户接入频率越高，要求每个网元处理消息的速度越快，每个网元处理的总速率就是核心网处理消息的速率，如果核心网处理消息速率低于用户接入速率，就会导致接入消息的冗余，未处理的消息会缓存在网元子系统的消息队列中，即待处理消息不能从消息队列中取出。消息队列中消息过多，导致信令处理流程变慢，也有可能产生丢失消息的情况。

可见，现有技术中至少存在如下技术问题：在基站需要给核心网设备发送上行数据时，用户接入频率越高，核心网设备处理消息的速度就会变慢，这样会导致信令处理流程变慢以及上行数据丢包。

技术实现要素：

本发明实施例通过提供基于临时处理隧道表的上行数据处理方法mme和sgw，用于解决现有技术中在基站需要给核心网设备发送上行数据时，用户接入频率越高，核心网设备处理消息的速度就会变慢，这样会导致信令处理流程变慢以及上行数据丢包的技术问题。

第一方面，本发明一实施例提供了一种基于临时处理隧道表的上行数据处理方法，应用于核心网设备中的服务网关sgw，所述方法包括：

在满足预设条件时，创建临时处理隧道表；

将接收到的基站发送的上行数据缓存在所述临时处理隧道表作为上行缓存数据；

若与所述上行缓存数据的隧道标识匹配的正常隧道表创建成功，通过所述正常隧道表上行传输所述上行缓存数据。

可选的，所述核心网设备具体为单服务器核心网设备，所述单服务器核心网设备还包括移动管理实体mme，所述满足预设条件具体为：

接收到所述mme发送的用于表征创建临时处理隧道表的请求消息。

可选的，所述若与所述上行缓存数据的隧道标识匹配的正常隧道表创建成功，通过所述正常隧道表上行传输所述上行缓存数据，具体为：

在接收到所述mme发送的删除所述临时处理隧道表的指示信息时，通过所述正常隧道表上行传输所述上行缓存数据；

在所述通过所述正常隧道表上行传输所述上行缓存数据之后，删除所述临时处理隧道表。

可选的，所述核心网设备为atca架构的核心网设备，所述满足预设条件具体为：

接收到所述基站发送的上行数据。

可选的，所述若与所述上行缓存数据的隧道标识匹配的正常隧道表创建成功，通过所述正常隧道表上行传输所述上行缓存数据，具体为：

在预设时间段后，若查找到与所述上行缓存数据的隧道标识匹配的正常隧道表，通过所述正常隧道表上行传输所述上行缓存数据；

在所述通过所述正常隧道表上行传输所述上行缓存数据后，删除所述临时处理隧道表。

第二方面，本发明一实施例提供了一种基于临时处理隧道表的上行数据处理方法，应用于核心网设备中的mme，所述方法包括：

接收到基站发送的承载创建请求，确定与所述mme连接的sgw是否需要创建临时处理隧道表；

在为是时，直接回复基站用于表征承载创建成功的消息，从而使得所述sgw在满足预设条件时，创建临时处理隧道表。

可选的，所述核心网设备具体为单服务器核心网设备，所述方法还包括：

在针对所述承载创建请求的正常隧道表创建成功或者失败时，指示所述sgw删除所述临时处理隧道表。

可选的，所述核心网设备具体为单服务器核心网设备，在所述接收到基站发送的承载创建请求，确定与所述mme连接的sgw是否需要创建临时处理隧道表之前，所述方法还包括：

确定当前承载创建请求，判断接收到所述当前承载创建请求至针对所述当前承载创建请求创建正常隧道表成功所使用的时长tsum是否大于第一阈值；

在为是时，计算需要创建临时处理隧道表的第一比例。

可选的，所述计算需要创建临时处理隧道表的第一比例，包括:

获取接收到所述承载创建请求至直接回复基站用于表征承载创建成功的消息所需的时长t1；

基于公式p＝1/(1+(tmax–t1)/(tsum-tmax))确定所述第一比例p，其中tmax为所述核心网设备在忙时每小时起呼次数bhca最大情况下的允许承载处理时长。

可选的，所述接收到基站发送的承载创建请求，确定与所述mme连接的sgw是否需要创建临时处理隧道表，具体为：

接收到基站发送的承载创建请求，按照所述第一比例确定对接收到的承载创建请求与所述mme连接的sgw是否需要创建临时处理隧道表。

第三方面，本发明一实施例提供了一种服务网关sgw，所述sgw属于核心网设备，所述sgw包括：

创建模块，用于在满足预设条件时，创建临时处理隧道表；

缓存模块，用于将接收到的基站发送的上行数据缓存在所述临时处理隧道表作为上行缓存数据；

上行传输模块，用于若与所述上行缓存数据的隧道标识匹配的正常隧道表创建成功，通过所述正常隧道表上行传输所述上行缓存数据。

可选的，所述核心网设备具体为单服务器核心网设备，所述单服务器核心网设备还包括移动管理实体mme，所述满足预设条件具体为：

接收到所述mme发送的用于表征创建临时处理隧道表的请求消息。

可选的，所述sgw还包括删除模块：

所述上行传输模块具体用于在接收到所述mme发送的删除所述临时处理隧道表的指示信息时，通过所述正常隧道表上行传输所述上行缓存数据；

所述删除模块，用于在所述通过所述正常隧道表上行传输所述上行缓存数据之后，删除所述临时处理隧道表。

可选的，所述核心网设备为atca架构的核心网设备，所述满足预设条件具体为：

接收到所述基站发送的上行数据。

可选的，所述sgw还包括删除模块：

所述上行传输模块，具体用于在预设时间段后，若查找到与所述上行缓存数据的隧道标识匹配的正常隧道表，通过所述正常隧道表上行传输所述上行缓存数据；

所述删除模块，用于在所述通过所述正常隧道表上行传输所述上行缓存数据后，删除所述临时处理隧道表。

第四方面，本发明一实施例提供了一种移动管理实体mme，所述mme属于核心网设备，所述mme包括：

接收模块，用于接收到基站发送的承载创建请求，确定与所述mme连接的sgw是否需要创建临时处理隧道表；

回复模块，用于在为是时，直接回复基站用于表征承载创建成功的消息，从而使得所述sgw在满足预设条件时，创建临时处理隧道表。

可选的，所述核心网设备具体为单服务器核心网设备，所述mme还包括：

指示模块，用于在针对所述承载创建请求的正常隧道表创建成功或者失败时，指示所述sgw删除所述临时处理隧道表。

可选的，所述核心网设备具体为单服务器核心网设备，所述mme还包括：

判断模块，用于在所述接收到基站发送的承载创建请求，确定与所述mme连接的sgw是否需要创建临时处理隧道表之前，确定当前承载创建请求，判断接收到所述当前承载创建请求至针对所述当前承载创建请求创建正常隧道表成功所使用的时长tsum是否大于第一阈值；

计算模块，用于在为是时，计算需要创建临时处理隧道表的第一比例。

可选的，所述计算模块包括:

获取子模块，用于获取接收到所述承载创建请求至直接回复基站用于表征承载创建成功的消息所需的时长t1；

确定子模块，用于基于公式p＝1/(1+(tmax–t1)/(tsum-tmax))确定所述第一比例p，其中tmax为所述核心网设备在忙时每小时起呼次数bhca最大情况下的允许承载处理时长。

可选的，所述接收模块具体用于：

接收到基站发送的承载创建请求，按照所述第一比例确定对接收到的承载创建请求与所述mme连接的sgw是否需要创建临时处理隧道表。

第五方面，本发明一实施例提供了一种计算机装置，所述装置包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如第一方面实施例所述方法的步骤。

第六方面，本发明一实施例提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面实施例所述方法的步骤。

本发明实施例中提供的一个或多个技术方案，至少具有如下技术效果或优点：

采用本发明的技术方案，简化了核心网消息处理流程，并根据消息处理时长进行动态控制，提高了上行数据传输的效率。

附图说明

图1为现有技术中承载建立过程中信令处理流程图；

图2为本发明实施例提供的承载建立过程中信令直接回复流程图；

图3a为本发明实施例提供的mme侧基于临时处理隧道表的上行数据处理方法的第一流程图；

图3b为本发明实施例提供的mme侧基于临时处理隧道表的上行数据处理方法的第二流程图；

图3c为本发明实施例提供的核心网设备中各个信令实体消息队列分析图；

图3d为本发明实施例提供的承载创建请求到承载创建响应的时序图；

图3e为本发明实施例提供的mme侧按照比例进行优化传输的流程图；

图4为本发明实施例提供的mme信令处理实体的执行流程图；

图5为本发明实施例提供的mme侧基于临时处理隧道表的上行数据处理方法的第三流程图；

图6为本发明实施例提供的sgw侧基于临时处理隧道表的上行数据处理方法的第一流程图；

图7a为本发明实施例提供的sgw业务处理实体的执行流程图；

图7b为本发明实施例提供的sgw侧基于临时处理隧道表的上行数据处理方法的第二流程图；

图7c为本发明实施例提供的sgw业务处理实体触发建立临时处理隧道表的执行方法的流程图。

图8为本发明实施例提供的mme的示意图；

图9为本发明实施例提供的sgw的示意图。

具体实施方式

为了解决上述技术问题，本发明实施例中的技术方案的总体思路如下：

如图2所示，核心网设备中的mme信令处理实体，在接收到承载创建请求后，处理完本地资源后直接回复成功，如图2中流程1，再进行核心网设备内部消息的转发配置，如上图流程2到11，这样可以有效提升消息的处理速度。然后利用建立临时处理隧道表的方案，缓存2到10流程中收到此用户承载的业务报文，在创建完成或者超时后，删除临时处理隧道表。在核心网业务流程找不到本端隧道后，先缓存数据报文，等待建立完成后，或者超时后再发送缓存数据。

为了更好的理解上述技术方案，下面将结合说明书附图以及具体的实施方式对上述技术方案进行详细的说明。

如图3a所示，本发明实施例一提供了一种基于临时处理隧道表的上行数据处理方法，应用于核心网设备中的mme，所述方法包括：

s101，接收到基站发送的承载创建请求，确定与所述mme连接的sgw是否需要创建临时处理隧道表；

s102，在为是时，直接回复基站用于表征承载创建成功的消息，从而使得所述sgw在满足预设条件时，创建临时处理隧道表。

对于本实施例中的方法，现有技术中是接收到基站发送的承载创建请求，等正常隧道表创建成功后，再向基站发送承载创建响应。而本申请中，在接收到基站发送的承载创建请求时，如果确定与所述mme连接的sgw是否需要创建临时处理隧道表，则直接回复基站用于表征承载创建成功的消息。不需要等正常隧道表建立后再向基站发送承载创建响应。

根据核心网设备的不同形态，上述方法具体可以分为以下两种实现方式：

方式一：核心网设备为单服务器的核心网设备，mme信令处理实体和sgw业务处理实体，以及各个信令、业务处理实体都部署在一个服务器上。所述满足预设条件具体为：sgw接收到所述mme发送的用于表征创建临时处理隧道表的请求消息。如图3b所示，该方法具体为：

s201，接收到基站发送的承载创建请求，确定是否需要建立临时处理隧道表；

s202，在为是时，直接回复基站用于表征承载创建成功的消息，向sgw业务处理实体发送用于表征创建临时处理隧道表的请求消息。

这样使得sgw在接收到所述mme发送的用于表征创建临时处理隧道表的请求消息时，创建临时处理隧道表。

具体地，对于步骤s201，接收到基站发送的承载创建请求，由核心网设备确定针对接收到的承载创建请求是否需要建立临时处理隧道表。例如，由优化标识(优化标识可以由数值或者其他形态来表示)决定对接收的承载创建请求是否建立临时处理隧道表。优化标识为0，不建立；优化标识为1，对每个承载创建请求都建立；优化标识为2，按照一定比例(该比例大于0小于等于1)建立临时处理隧道表(例如在每接收的100个承载创建请求中，选择39个建立临时处理隧道表)。

在执行步骤s201之前，核心网设备可以根据自身处理数据的速度和系统的接入用户数量的具体情况，确定优化标识。核心网对自身处理数据的速度和系统的接入用户数量的具体情况的检测是实时的，因此，优化标识也会发生变化。具体可以分为以下几种情形：

情形1，核心网设备根据自身对数据的处理情况发现从接收到承载创建请求至针对该承载创建请求建立正常隧道表成功所使用的时长tsum不大于第一阈值，则核心网设备可以确定优化标识为0，从而不对下一个接收到的承载创建请求建立临时处理隧道表，从而不进行上行数据传输的优化。

情形2，例如，核心网设备根据自身对数据的处理情况发现从接收到承载创建请求至针对该承载创建请求建立正常隧道表成功所使用的时长tsum大于第一阈值时，确定对接收到的每个承载创建请求都建立临时处理隧道表，这样能够有效的提升用户接入速度，但是先回复成功响应，有可能在核心网处理之后，产生失败流程，此失败流程依靠errorindication来回滚操作。如果一概使用技术发明点一，在系统负荷增加时，会造成过多核心网内部承载创建的回滚操作，进而影响整个核心网的系统处理性能。

情形3，核心网设备确定当前承载创建请求，判断接收到所述当前承载创建请求至针对所述当前承载创建请求建立正常隧道表成功所使用的时长tsum是否大于第一阈值；

在为是时，计算需要建立临时处理隧道表的承载创建请求的第一比例。

具体的计算第一比例的方式为：获取接收到所述承载创建请求至直接回复基站用于表征承载创建成功的消息所需的时长t1；

基于公式p＝1/(1+(tmax–t1)/(tsum-tmax))确定所述第一比例p，其中tmax为所述核心网设备在bhca最大情况下的允许承载处理时长。

具体地，在核心网设备处理承载创建请求的时候，从各个信令实体消息队列分析如图3c所示：承载创建消息的核心网处理时长，是接收到承载创建请求接收到发送承载创建响应回复的时间差值，如果接收到的承载创建请求过多，则会在mme信令处理实体的消息队列中缓存过多的消息，基于这个时间处理时长和承载创建响应的结果，动态控制(即按一定比例选择部分承载创建请求确定需要创建临时处理隧道表)。

参见图3d，从处理时长看，从承载创建请求到承载创建响应，经历多个处理节点，每个节点处理时长如下图所示：t0标识mme信令处理实体收到承载创建请求的时间，t1标识mme信令处理实体处理时长，最后，t7标识mme信令处理在最终发送承载创建响应的处理时长，t8标识承载创建响应发送的时长。

例如，在不建立临时处理隧道表时，采用图1中的执行流程，核心网内部处理承载创建请求的时长：

tsum＝t8–t0；

根据核心网处理性能，即用户接入频率(此时理解为bhca参数，忙时用户每小时起呼次数)，以400k为例，可以测试出在此设备在bhca最大情况下的允许承载处理时长tmax。

如果采用步骤s201-s206中的方案，mme信令子系统完成本地处理后，直接回复承载创建成功的响应，此时处理时长tsum＝t1，

如果调整一次用户接入，直接回复创建响应，只耗费时长t1，能保证之后n个用户的处理时长，得到如下公式：

t1+n*tsum＝tmax*(n+1)

得出：n＝(tmax–t1)/(tsum-tmax)

根据如上关系，得出使用优化的用户比例为：p＝1/(1+n)，利用此比例因素进行优化。

例如：本核心网支持的bhca为400k，换算到秒，则每次用户接入时长为400*1024/3600，计算结果为每秒接入113个用户，即每个用户处理时长小于1/113,为8.8ms。减去标准的基站处理时延4ms，减去系统间消耗1.8ms，可以得出在此设备在bhca最大情况下的允许承载处理时长tmax＝3ms；如果此时处理已经超时，tsum为4.8ms；而t1在mme信令处理时长可以实时计算得出，t1为0.2ms；n＝(tmax–t1)/(tsum-tmax)＝(3–0.2)/(4.8-3)＝1.56，即表示1次优化接入可以保证后续1.56个用户接入，此时采用比例优化，优化比例p为：1/(1+1.56)＝0.39,即按照39％进行优化接入方案。在每100个用户中，选择39个用户进行优化处理。

在实际应用中，mme接收到承载创建请求的数量很大，可以以定时器例如在连续的一段时间内对收到的承载创建请求按比例均匀分配，例如第一比例是25％，则每收到四个承载创建请求选择每四个请求中的第一个请求(也可以是第二个等，)作为需要优化的请求。针对tsum的检测是实时的，可以给tsum设置一个浮动范围，在某个浮动范围内时，不调整优化比例，在超出范围后，修改优化比例。

具体的按照比例进行优化的流程参见图3e，具体流程如下：

s301，收到请求。即接收到承载创建请求。

s302，查看优化标识。优化标识为0和2，0标识对下一个承载创建请求不执行s202-s206的优化。2表示根据比例计算是否优化。

s303，根据优化标识判断是否进行优化。优化标识为2，执行s304，优化标识为0，执行s305。

s304，根据比例计算对之后的承载创建请求是否优化，在为是时，执行s3041，在为否时，执行步骤s305；

s3041，直接回复成功响应。

s3042，走后续业务流程。

s305，走后续业务流程。即该承载创建请求按照现有技术中的正常方式进行处理，然后执行s3051。

s3051，重新计算处理时长t1。即接收到承载创建请求到回复承载请求创建成功使用的时长。

s3052，根据时长重新确定优化标识。根据确定的优化标识，在优化标识为2时，确定优化比例。

对于单服务器核心网设备中的mme，接收到承载创建请求时的具体处理流程分别如图4所示。

如图4所示，mme信令处理实体执行的具体处理流程是：

s401，mme信令收到承载创建请求；

s402，给sgw业务发送临时处理隧道表创建请求；

s403，直接回复创建响应；

s404，走承载创建流程。即针对所述承载创建请求进行正常隧道表的创建；当接收到上行数据时，若所述上行数据匹配不到正常隧道表，将接收到上行数据缓存在所述临时处理隧道表。

s405，判断。即判断针对所述承载创建请求建立的正常隧道表是否创建成功。若创建成功，执行步骤s4061-s4062，若创建失败执行步骤s4071-s4073。

s4061，给sgw业务发送指示消息释放该隧道缓存数据；

s4062，数据报文继续走上行业务流程；

s4071，删除核心网资源；

s4072，给sgw业务发送指示消息丢弃该隧道缓存数据；

s4073，基站资源等到上行数据触发errorindication流程触发删除。

方式二：对于atca架构的核心网设备，该方法的流程图如图5所示，具体如下，

s501，接收到基站发送的承载创建请求，确定是否需要建立临时处理隧道表；

s502，在为是时，直接回复基站用于表征承载创建成功的消息。

从而使得sgw在接收到基站发送的上行数据时，创建临时处理隧道表。

具体地，atca架构下的核心网设备，mme信令处理实体和sgw业务处理实体不部署在同一块板卡上，mme信令处理实体到sgw业务处理实体的消息需要通过交换板来转发，其转发路径等同于mme信令处理实体到基站的路径，如果通过mme信令处理实体到sgw业务处理实体的消息触发临时隧道表的创建流程，必须等待响应消息后再给基站发送承载创建响应，多板的板间交互消息反而增加了系统间的开销。

鉴于如上因素，承载创建时，mme信令处理实体先给基站回复创建响应，sgw业务处理实体收到报文后，查找不到正常隧道表的信息，由sgw业务处理实体触发建立临时处理隧道表，缓存此数据，并设置超时时间等待承载创建，等待超时的时间到达后，将缓存的数据报文取出，继续走上行流程，如果承载已经创建完成，则能够匹配到已建立的隧道，完成传输。

如图6所示，本发明实施例二提供了一种基于临时处理隧道表的上行数据处理方法，应用于核心网设备中的服务网关sgw，所述方法包括：

s601，在满足预设条件时，创建临时处理隧道表；

s602，将接收到的基站发送的上行数据缓存在所述临时处理隧道表作为上行缓存数据；

s603，若与所述上行缓存数据的隧道标识匹配的正常隧道表创建成功，通过所述正常隧道表上行传输所述上行缓存数据。

根据核心网设备的不同形态，该方法具体包括以下两种实现方式：

方式a：核心网设备为单服务器的核心网设备，mme信令处理实体和sgw业务处理实体，以及各个信令、业务处理实体都部署在一个服务器上。

满足预设条件具体为：

接收到所述mme发送的用于表征创建临时处理隧道表的请求消息。

具体地，对应于前述步骤s601，在接收到mme发送的用于表征创建临时处理隧道表的请求消息后，创建临时处理隧道表。

在针对承载创建请求创建临时处理隧道表时，针对该承载创建请求也开始正常隧道表的创建。然后等到epc内部配置流程完成，即11完成。

在执行完步骤s601后，收到上行数据时，若所述上行数据匹配不到正常隧道表，将接收到上行数据缓存在所述临时处理隧道表。例如，核心网设备中的业务面收到上行数据后，查找不到正常隧道信息，再查看临时处理隧道表，而正常隧道表正在创建中，则缓存此上行数据，等待信令完全建立完成。

然后在接收到所述mme发送的删除所述临时处理隧道表的指示信息时，通过所述正常隧道表上行传输所述上行缓存数据；

在所述通过所述正常隧道表上行传输所述上行缓存数据之后，删除所述临时处理隧道表。具体地，判断针对所述承载创建请求建立的正常隧道表是否创建成功。如果创建成功，由mme信令处理实体给sgw业务处理实体发送消息，触发删除临时隧道表(此时仅为触发，尚未删除)。例如mme信令处理实体触发删除临时隧道表的同时，判断针对所述承载创建请求建立的正常隧道表是否创建成功；在为是时，查看缓存数据，触发缓存数据发送，此时上行数据能够匹配到已建立的正常隧道表中的数据，进行上行传输。

对于临时处理隧道表的删除，其可以在在针对所述承载创建请求创建的正常隧道表创建成功，读出临时处理隧道表中的数据进行上行传输后进行删除，也可以在读出临时处理隧道表中的数据就进行删除，可以根据实际需要进行设定。

对于单服务器核心网设备中的sgw业务处理实体，接收到承载创建请求时的具体处理流程分别如图7a所示。

如图7a所示，sgw业务处理实体执行的具体处理流程是：

s701，收到业务报文；

s702，查找本地隧道信息，判断是否查找成功。若查找失败，执行步骤s703；若查找成功，执行步骤s704；

s703，查找临时处理隧道表，判断是否查找成功。若查找成功，执行步骤s705和s706；若查找失败执行步骤s707。

s704，走业务流程。

s705，缓存数据报文。即将数据报文缓存在临时处理隧道表中。

s706，等待释放或者丢弃指示。

s707，触发errorindication。

由于mme信令处理实体到sgw业务实体的消息在服务器内传输，必然快于mme信令处理实体到基站的消息，所以临时处理隧道表的创建必然快于基站响应消息的传输，能够保证在基站上行数据到达核心网sgw业务处理实体前，配置完成。

方式b：对于atca架构的核心网设备，该方法的流程图如图7b所示，具体如下，

s801，当接收到上行数据时，若所述上行数据匹配不到针对所述承载创建请求创建的正常隧道表，创建临时处理隧道表且将接收到上行数据缓存在所述临时处理隧道表；

s802，在一预设时间段后，将缓存在所述临时处理隧道表的上行数据进行上行传输，判断所述上行数据是否能够匹配到针对所述承载创建请求创建的正常隧道表。

s803，在为是时，利用所述正常隧道表传输缓存在本地的上行数据。

具体地，atca架构下的核心网设备，mme信令处理实体和sgw业务处理实体不部署在同一块板卡上，mme信令处理实体到sgw业务处理实体的消息需要通过交换板来转发，其转发路径等同于mme信令处理实体到基站的路径，如果通过mme信令处理实体到sgw业务处理实体的消息触发临时隧道表的创建流程，必须等待响应消息后再给基站发送承载创建响应，多板的板间交互消息反而增加了系统间的开销。

鉴于如上因素，承载创建时，mme信令处理实体先给基站回复创建响应，在sgw业务处理实体收到上行数据后，查找不到正常隧道表的信息，由sgw业务处理实体触发建立临时处理隧道表，缓存此数据，并设置超时时间等待承载创建，等待超时的时间到达后，将缓存的数据报文取出，继续走上行流程，如果承载已经创建完成，则能够匹配到已建立的隧道，完成传输。

具体处理流程参见图7c，具体如下：

s901，收到业务报文；

s902，查找本地隧道信息，判断是否查找成功。若查找失败，执行步骤s903；若查找成功，执行步骤s904；

s903，查找临时处理隧道表，判断是否查找成功。若查找成功，执行步骤s905；若查找失败执行步骤s9061-s9063。

s904，走业务流程。

s905，对比创建时间，判断是否超时。若超时，执行s907。若不超时，执行s9063。

s9061，建立临时处理隧道表。s9062，缓存数据报文。即将数据报文缓存在临时处理隧道表中。s9062，走上行流程。

s907，释放数据报文。然后执行s708。

s908，查找本地隧道信息，判断是否查找成功。若查找成功，执行步骤s9063。若查找失败，执行步骤s909。

s909，触发errorindication。

上述方式a和方式b中，对于临时处理隧道表的删除，其可以在在针对所述承载创建请求创建的正常隧道表创建成功，读出临时处理隧道表中的数据进行上行传输后进行删除，也可以在读出临时处理隧道表中的数据就进行删除，可以根据实际需要进行设定。

如图8所示，本发明实施例三提供了移动管理实体mme，所述mme属于核心网设备，所述mme包括：

接收模块101，用于接收到基站发送的承载创建请求，确定与所述mme连接的sgw是否需要创建临时处理隧道表；

回复模块102，用于在为是时，直接回复基站用于表征承载创建成功的消息，从而使得所述sgw在满足预设条件时，创建临时处理隧道表。

在该核心网设备具体为单服务器核心网设备，该mme还包括：

指示模块，用于在针对所述承载创建请求的正常隧道表创建成功或者失败时，指示所述sgw删除所述临时处理隧道表。

该mme还包括：判断模块，用于在所述接收到基站发送的承载创建请求，确定与所述mme连接的sgw是否需要创建临时处理隧道表之前，确定当前承载创建请求，判断接收到所述当前承载创建请求至针对所述当前承载创建请求创建正常隧道表成功所使用的时长tsum是否大于第一阈值；

计算模块，用于在为是时，计算需要创建临时处理隧道表的第一比例。

其中，计算模块包括:

获取子模块，用于获取接收到所述承载创建请求至直接回复基站用于表征承载创建成功的消息所需的时长t1；

确定子模块，用于基于公式p＝1/(1+(tmax–t1)/(tsum-tmax))确定所述第一比例p，其中tmax为所述核心网设备在忙时每小时起呼次数bhca最大情况下的允许承载处理时长。

接收模块101具体用于：

接收到基站发送的承载创建请求，按照所述第一比例确定对接收到的承载创建请求与所述mme连接的sgw是否需要创建临时处理隧道表。

该mme对上行数据传输进行处理时执行的步骤流程与实施例一中的方法相同，在此不再赘述。

如图9所示，本发明实施例四提供了一种服务网关sgw，所述sgw属于核心网设备，所述sgw包括：

创建模块201，用于在满足预设条件时，创建临时处理隧道表；

缓存模块202，用于将接收到的基站发送的上行数据缓存在所述临时处理隧道表作为上行缓存数据；

上行传输模块203，用于若与所述上行缓存数据的隧道标识匹配的正常隧道表创建成功，通过所述正常隧道表上行传输所述上行缓存数据。

根据核心网设备的不同形态，具体包括以下两种实现方式：

方式一：所述核心网设备为单服务器的核心网设备，所述满足预设条件具体为：接收到所述mme发送的用于表征创建临时处理隧道表的请求消息。所述sgw还包括删除模块：

所述上行传输模块203具体用于在接收到所述mme发送的删除所述临时处理隧道表的指示信息时，通过所述正常隧道表上行传输所述上行缓存数据；

所述删除模块，用于在所述通过所述正常隧道表上行传输所述上行缓存数据之后，删除所述临时处理隧道表。方式二：所述核心网设备为atca架构的核心网设备，所述满足预设条件具体为：接收到所述基站发送的上行数据。所述上行传输模块203具体用于：在预设时间段后，若查找到与所述上行缓存数据的隧道标识匹配的正常隧道表，通过所述正常隧道表上行传输所述上行缓存数据；

所述sgw还包括删除模块，用于在所述通过所述正常隧道表上行传输所述上行缓存数据后，删除所述临时处理隧道表。

该sgw还包括删除模块，用于在所述通过所述正常隧道表上行传输所述上行缓存数据后，删除所述临时处理隧道表。

该sgw对上行数据传输进行处理时执行的步骤流程与实施例二中的方法相同，在此不再赘述。

本发明实施例五提供了一种计算机装置，所述装置包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如实施例一或实施例二所述方法的步骤。

本发明实施例六提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如实施例一或实施例二所述方法的步骤。

上述本发明实施例中的技术方案，至少具有如下的技术效果或优点：

采用本发明的技术方案，简化了核心网消息处理流程，并根据消息处理时长进行动态控制，提高了上行数据传输的效率。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。