CN101938847A - 一种长期演进系统中业务承载建立失败的处理方法和装置 - Google Patents

Abstract

本发明涉及一种长期演进系统中建立专用承载的方法和装置，不论是UE主动发起的还是核心网主动发起的专用承载建立请求，如果核心网未收到用户UE的响应，等待超时后，重新发送并等待，如果重发4次还是收不到UE的激活专用EPS承载上下文应答消息，则核心网发起承载释放流程，通知UE和eNB释放刚建立起来的EPS承载和DRB资源(即释放刚刚核心网未成功建立的专用承载)，从而UE、eNB和核心网资源保持一致，有效降低了UE、eNB和核心网承载不一致错误的处理方法。

Description

一种长期演进系统中业务承载建立失败的处理方法和装置

技术领域  本发明涉及通信领域，尤其涉及一种长期演进系统(LTE)中业务承载建立失败的处理方法和装置。

背景技术  第三代合作伙伴(3GPP)LTE系统主要由终端(UE)、基站(eNB)和核心网(Evolved Packet Core，即EPC)组成，如图1所示为LTE系统各网元连接示意图，UE与eNB间为空中无线接口(Uu口)，eNB之间为X2接口，eNB与EPC间为S1接口。

在3GPP LTE系统中，业务承载分为默认承载和专用承载，UE注册(attach)成功后，就建立了一个默认承载，后续可以根据业务QoS(Quality of Service)需要发起专用承载建立。其中，UE和核心网可发起业务承载的建立、修改和释放；eNB只能发起承载释放。

业务承载在UE和核心网就是EPS承载(Evolved Packet System，EPSbearer)，在eNB即E-RAB承载(Evolved-Radio Access bearer)，EPS承载、E-RAB承载和DRB(Data Radio Bearer，数据无线承载)一一对应。

当前3GPP LTE系统中，UE主动发起的专用EPS承载建立流程如图2所示，包括如下步骤：步骤201，用户发送上行直传消息提出承载资源分配请求，经过基站eNB送到核心网EPC；步骤202，核心网EPC处理承载分配请求，步骤203，核心网EPC然后发出E-RAB建立请求给基站eNB，包含激活专用EPS承载上下文请求消息，步骤204，核心网EPC再启动T3485；步骤205，基站发起RRC连接重配(包含激活专用EPS承载上下文请求信息)给用户；步骤206，用户发出RRC连接重配完成消息给基站；步骤207，基站发出E-RAB建立响应给核心网；步骤208，用户发出上行直传消息(激活专用EPS承载上下文应答)；步骤209，基站发送上行直传消息(激活专用EPS承载上下文应答)；步骤210，核心网停止T3485，步骤211，核心网再处理承载分配响应。

核心网主动发起的专用EPS承载建立流程如图3所示，包括如下步骤，首先核心网EPC建立承载分配请求，然后在步骤301发出E-RAB建立请求(包含激活专用EPS承载上下文请求消息)给基站；步骤302，基站发送RRC连接重配(包含激活专用EPS承载上下文请求消息)给用户；步骤303，用户发起RRC连接重配完成消息给基站；步骤304，基站发出E-RAB建立响应给核心网；步骤305，用户发起上行直传消息(激活专用EPS承载上下文应答)到基站，然后在步骤306再到核心网；由核心网处理承载分配响应。

当核心网发送激活专用EPS承载上下文请求消息203时，会启动T3485204，等待UE的响应，收到激活专用EPS承载上下文应答消息209时，专用承载建立成功，则停止T3485209；如果未收到激活专用EPS承载上下文应答消息时，处理的流程见图4所示，包括如下步骤：当T3485超时，则核心网会重发激活专用EPS承载上下文请求消息(如步骤403)，并再次启动T3485(如步骤404)，等待响应。如果此时无线环境比较差，UE回复的激活专用EPS承载上下文应答消息，核心网都没有收到，则前4次T3485超时时对应图4中的步骤402、405、408、411，核心网都重发激活专用EPS承载上下文请求消息，对应图4中的步骤403、406、409、412，直至第5次超时时(如步骤414)，当前技术的做法是核心网放弃该过程，本地释放可能分配的资源，进入承载上下文去激活(BEARER CONTEXT INACTIVE)状态(如步骤415)。

上面所述的建立专用承载失败时的处理方法是不完备的：因为当核心网重发4次后仍然收不到UE的响应，如果核心网释放资源，放弃该过程，对于核心网来说，该专用承载并没有建立起来；但对于UE来说，发送完激活专用EPS承载上下文应答消息后(如步骤208)，就认为该专用承载已经成功建立(激活专用EPS承载上下文应答消息有可能是在UE发给eNB时丢掉了，即208丢了)，那么UE和核心网就出现了专用承载不一致的现象，后续UE有可能使用该专用承载来发送数据，必然会导致数据发不到对端的错误。并且，对于UE和eNB来说，该专用承载对应的DRB也已经建立起来了，但实际上该专用承载并不能成功发送数据，也造成了无线资源浪费。

发明内容  针对上述现有技术的缺陷，本发明提出一种长期演进系统中业务承载建立失败的处理方法和装置，可以有效避免UE、eNB和核心网的承载不一致。

本发明公开的一种长期演进系统中业务承载建立失败的处理方法，包括如下步骤：

所述核心网EPC发起承载释放流程，通知所述用户UE和基站eNB释放资源；所述用户UE和所述基站eNB根据所述承载释放流程释放EPS承载和DRB资源。

在本发明公开的一个实施例中，所述核心网EPC发起承载释放流程的步骤进一步包括：

(1)所述核心网EPC发起带有释放的E-RAB列表和去激活EPS承载上下文请求的E-RAB释放命令，给所述基站eNB；

(2)所述基站eNB收到消息后，释放E-RAB对应的DRB，并发送带有释放的DRB以及去激活EPS承载上下文请求的RRC连接重配消息，给所述用户UE；

(3)所述用户UE收到消息后，去激活该EPS承载，并释放对应的DRB；

(4)所述用户UE发送RRC重配完成消息给所述基站eNB，所述基站eNB收到后回E-RAB释放响应给所述核心网EPC；

(5)所述用户UE发送回复去激活EPS承载上下文应答的上行直传消息，所述基站eNB回传所述上行直传消息给所述核心网；

(6)所述核心网在预定时间内收到所述去激活EPS承载上下文应答后，去激活该EPS承载。

在所述步骤(6)中，如果所述核心网EPC没有在预定时间内收到所述去激活EPS承载上下文应答消息，则：

所述核心网EPC重发去激活EPS承载上下文请求消息，并在预定的时间内等待；如此重复4次后，本地释放该承载。

所述核心网EPC发起承载释放流程的前提是：

在所述核心网EPC发送激活专用EPS承载上下文请求消息以后，定时等待所属用户UE的响应；如果在预定时间内未收到激活专用EPS承载上下文应答消息，则重新发送激活专用EPS承载上下文请求消息，并再次定时等待；如此反复四次，始终收不到激活专用EPS承载上下文应答消息。

在全部所述步骤之前首先由所述用户UE发送上行直传消息带承载资源分配请求，经过所述基站eNB送到所述核心网EPC，所述核心网EPC发送激活专用EPS承载上下文请求消息。

本发明还公开了一种长期演进系统中业务承载建立失败的处理装置，包括：

承载释放模块，用于发起承载释放流程通知用户UE和基站eNB释放资源；所述用户UE和所述基站eNB根据所述承载释放流程释放EPS承载和DRB资源。

在本发明公开的一个实施例中，业务承载建立失败的处理装置还可以包括定时模块，用于启动定时器，等待所述用户UE的响应；所述承载释放模块还用于接收去激活EPS承载上下文应答消息；

所述承载释放模块发起承载释放流程以后，所述定时模块启动定时器等待所述用户UE的响应；如果在预定时间内没有收到去激活EPS承载上下文应答消息，则，重发去激活EPS承载上下文请求消息，所述定时模块再次启动定时器等待；如此重复4次后，本地释放该承载。

在本发明公开的一个实施例中，业务承载建立失败的处理装置还可以包括承载建立模块，用于发送激活专用EPS承载上下文请求消息，和接收激活专用EPS承载上下文应答消息；

所述承载建立模块发送激活专用EPS承载上下文请求消息，所述定时模块启动定时器等待所述用户UE的响应；

如果所述承载建立模块在预定时间内未收到激活专用EPS承载上下文应答消息，则重新发激活专用EPS承载上下文请求消息，并且所述定时模块再次启动定时器等待；如此反复四次。

本发明公开的所述的处理装置，是所述核心网EPC中的部分。

本发明公开的一种长期演进系统中业务承载建立失败的处理方法和装置，当核心网在预定时间内都没有收到UE的激活EPS承载上下文应答消息时，就发起E-RAB释放命令(而不是本地释放资源)，来通知UE和eNB释放资源。eNB和UE收到消息后，相继释放DRB资源和EPS承载，这样UE、eNB和核心网的资源保持一致。

附图说明

图1为LTE系统各网元连接示意图。

图2为UE主动发起的专用承载建立流程图。

图3为核心网主动发起的专用承载建立流程图。

图4为现有技术的承载建立失败处理方法。

图5为本发明的承载建立失败处理方法。

图6为去激活承载失败的处理方法。

图7为本发明的处理承载业务建立失败的装置结构示意图。

具体实施方式  下面结合附图和具体实施方式对本发明作进一步详细说明。此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明的目的是介绍一种专用承载建立失败的处理方法，可以尽可能的使得UE、eNB和核心网的资源保持一致，增加系统的可靠性。本发明具有很强的可操作性和实用性。

本发明实施例中所述方法是当核心网重发4次激活专用EPS承载上下文请求后，如果还收不到UE的响应，则第5次T3485超时时发起去激活EPS承载请求，来释放刚刚建立失败的承载。如图5所示包括如下步骤：

步骤501，第一次T3485超时时，核心网未收到UE的响应，核心网重发激活专用EPS承载上下文请求；

步骤502，第二次T3485超时时，核心网未收到UE的响应，核心网重发激活专用EPS承载上下文请求；

步骤503，第三次T3485超时时，核心网未收到UE的响应，核心网重发激活专用EPS承载上下文请求；

步骤504，第四次T3485超时时，核心网未收到UE的响应，核心网重发激活专用EPS承载上下文请求；

步骤505，第五次T3485超时时，核心网未收到UE的响应，核心网发起E-RAB释放命令(带释放的E-RAB列表和去激活EPS承载上下文请求)给eNB；

步骤506和507，eNB收到消息后(如步骤505)，释放E-RAB对应的DRB，并发RRC连接重配消息(带释放的DRB以及去激活EPS承载上下文请求)给UE；

步骤508，UE收到消息后，去激活该EPS承载，并释放对应的DRB；

步骤509和510，UE发送RRC重配完成消息给eNB，eNB收到后回E-RAB释放响应给核心网；

步骤511和512，UE发送上行直传消息，回复去激活EPS承载上下文应答，eNB回传该消息给核心网；

步骤513，核心网收到后，去激活该EPS承载；

如上所述，在步骤505～513中保证了UE和核心网的EPS承载资源一致，并且UE和eNB对应的DRB资源也被释放。

进一步考虑，如果在步骤512中核心网没有收到UE回复的去激活EPS承载上下文应答消息，处理流程具体见图6所示，当T3495超时，核心网会重发去激活EPS承载上下文请求消息，重发4次如图6中的步骤601、602、603和604，第5次T3495超时，核心网本地释放该承载(如步骤605)，这样可以保证承载资源一致。

如图7所示是本发明的在长期演进系统中承载建立失败的处理装置的结构示意图，包括：

承载释放模块，用于发起承载释放流程通知用户UE和基站eNB释放资源；用户UE和基站eNB根据所述承载释放流程释放EPS承载和DRB资源。

定时模块，用于启动定时器，等待用户UE的响应；承载释放模块还用于接收去激活EPS承载上下文应答消息；承载释放模块发起承载释放流程以后，定时模块启动定时器等待所述用户UE的响应；如果在预定时间内没有收到去激活EPS承载上下文应答消息，则，重发去激活EPS承载上下文请求消息，定时模块再次启动定时器等待；如此重复4次后，本地释放该承载。

承载建立模块，用于发送激活专用EPS承载上下文请求消息，和接收激活专用EPS承载上下文应答消息；承载建立模块发送激活专用EPS承载上下文请求消息，定时模块启动定时器等待所述用户UE的响应；如果承载建立模块在预定时间内未收到激活专用EPS承载上下文应答消息，则重新发激活专用EPS承载上下文请求消息，并且所述定时模块再次启动定时器等待；如此反复四次。是所述核心网EPC中的部分。

将现有技术与本发明的实施方案进行对比，可充分突出本发明方案的优越性。如图4所示，在现有技术中，专用承载建立时，如果核心网未收到UE的激活EPS承载上下文应答消息时，T3485超时，核心网当重发4次都没有收到响应时，就放弃该过程，本地释放该EPS承载资源，进入承载上下文去激活(BEARER CONTEXT INACTIVE)状态。但是对于UE来说，发送完激活EPS承载上下文应答消息时，专用承载就认为建立成功，这样UE和核心网的承载状态就出现不一致的错误。

本发明实施方案中，当核心网重发4次都没有收到UE的激活EPS承载上下文应答消息时，第5次T3485超时时，就发起E-RAB释放命令(而不是本地释放资源)，来通知UE和eNB释放资源。eNB和UE收到消息后，相继释放DRB资源和EPS承载，这样UE、eNB和核心网的资源保持一致。

本发明所述的业务承载建立失败的处理方法，并不仅仅限于说明书及实施方案中所列运用，他完全可以被用于各种适合本发明之领域。因此，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种长期演进系统中业务承载建立失败的处理方法，其特征在于，包括如下步骤：

所述核心网EPC发起承载释放流程，通知所述用户UE和基站eNB释放资源；所述用户UE和所述基站eNB根据所述承载释放流程释放EPS承载和DRB资源。

2.如权1所述的处理方法，其特征在于，所述核心网EPC发起承载释放流程的步骤进一步包括：

(1)所述核心网EPC发起带有释放的E-RAB列表和去激活EPS承载上下文请求的E-RAB释放命令，给所述基站eNB；

(2)所述基站eNB收到消息后，释放E-RAB对应的DRB，并发送带有释放的DRB以及去激活EPS承载上下文请求的RRC连接重配消息，给所述用户UE；

(3)所述用户UE收到消息后，去激活该EPS承载，并释放对应的DRB；

(4)所述用户UE发送RRC重配完成消息给所述基站eNB，所述基站eNB收到后回E-RAB释放响应给所述核心网EPC；

(5)所述用户UE发送回复去激活EPS承载上下文应答的上行直传消息，所述基站eNB回传所述上行直传消息给所述核心网；

(6)所述核心网在预定时间内收到所述去激活EPS承载上下文应答后，去激活该EPS承载。

3.如权2所述的处理方法，其特征在于，在所述步骤(6)中，如果所述核心网EPC没有在预定时间内收到所述去激活EPS承载上下文应答消息，则：

所述核心网EPC重发去激活EPS承载上下文请求消息，并在预定的时间内等待；如此重复4次后，本地释放该承载。

4.如权1、2或者3所述的处理方法，其特征在于，所述核心网EPC发起承载释放流程的前提是：

在所述核心网EPC发送激活专用EPS承载上下文请求消息以后，定时等待所属用户UE的响应；如果在预定时间内未收到激活专用EPS承载上下文应答消息，则重新发送激活专用EPS承载上下文请求消息，并再次定时等待；如此反复四次，始终收不到激活专用EPS承载上下文应答消息。

5.如权4所述的处理方法，其特征在于，包括：在所述步骤之前首先由所述用户UE发送上行直传消息带承载资源分配请求，经过所述基站eNB送到所述核心网EPC，所述核心网EPC发送激活专用EPS承载上下文请求消息。

6.一种长期演进系统中业务承载建立失败的处理装置，其特征在于，包括：

承载释放模块，用于发起承载释放流程通知用户UE和基站eNB释放资源；所述用户UE和所述基站eNB根据所述承载释放流程释放EPS承载和DRB资源。

7.如权6所述的处理装置，其特征在于，还包括定时模块，用于启动定时器，等待所述用户UE的响应；所述承载释放模块还用于接收去激活EPS承载上下文应答消息；

所述承载释放模块发起承载释放流程以后，所述定时模块启动定时器等待所述用户UE的响应；如果在预定时间内没有收到去激活EPS承载上下文应答消息，则，重发去激活EPS承载上下文请求消息，所述定时模块再次启动定时器等待；如此重复4次后，本地释放该承载。

8.如权6或者7所述的处理装置，其特征在于，还包括承载建立模块，用于发送激活专用EPS承载上下文请求消息，和接收激活专用EPS承载上下文应答消息；

所述承载建立模块发送激活专用EPS承载上下文请求消息，所述定时模块启动定时器等待所述用户UE的响应；

如果所述承载建立模块在预定时间内未收到激活专用EPS承载上下文应答消息，则重新发激活专用EPS承载上下文请求消息，并且所述定时模块再次启动定时器等待；如此反复四次。

9.如权8所述的处理装置，其特征在于，是所述核心网EPC中的部分。

Images