CN106604295A - 一种用户服务请求方法及移动性管理实体装置 - Google Patents
一种用户服务请求方法及移动性管理实体装置 Download PDFInfo
- Publication number
- CN106604295A CN106604295A CN201510663290.2A CN201510663290A CN106604295A CN 106604295 A CN106604295 A CN 106604295A CN 201510663290 A CN201510663290 A CN 201510663290A CN 106604295 A CN106604295 A CN 106604295A
- Authority
- CN
- China
- Prior art keywords
- sgw
- modification
- bearing
- request message
- indicate
- 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.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/02—Arrangements for optimising operational condition
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/18—Management of setup rejection or failure
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种用户服务请求的方法及移动性管理实体装置。本发明方法包括:移动性管理实体MME根据用户设备UE发送的服务请求,指示所述UE的服务基站与所述UE建立无线资源控制RRC连接,并指示所述UE的服务网关SGW根据所述UE的上下文修改所述UE的承载;若所述MME接收到所述SGW返回的修改承载失败响应,则指示所述SGW为所述UE创建默认承载,并在确认创建成功后指示所述SGW根据所述UE的上下文修改所述UE的默认承载。本发明解决了现有技术中存在的用户服务请求过程中出现的消息交互陷入闭环死循环以及服务请求始终失败的问题。
Description
技术领域
本发明涉及通信技术领域,尤其涉及一种用户服务请求方法及移动性管理实体装置。
背景技术
在LTE(Long Term Evolution,长期演进)架构下,如图1所示,UE(UserEquipment,用户设备,也可称为终端)通过ENB(evolved Node B,演进基站)向LTE网络发起附着过程,附着成功后,UE便可以访问网络。当UE中断使用网络业务,为了节省LTE的带宽资源,ENB随即针对该UE向MME(MobilityManagement Entity,移动性管理实体)发起S1释放请求(S1UE Context ReleaseRequest),用于断开信令连接和释放用户承载。MME发送释放承载请求(Release Access Bearers Request)到SGW(Serving GateWay,服务网关)请求释放该UE相关的S1-U承载,在接收到SGW返回的承载释放响应(ReleaseAccess Bearers Response)后发送释放UE上下文命令(S1UE Context ReleaseCommand)到ENB进行S1释放,如图2中的步骤1至步骤4所示,MME在接收到ENB发送的UE上下文释放完成(S1UE Context Release Complete)消息后确认S1释放(S1Release)。UE跟ENB的RRC(Radio Resource Control,无线资源控制)连接断开,该UE在MME和ENB间的信令连接断开,如图2中的步骤5所示。当UE又需要进行上网业务时,ENB向MME发送封装有该UE服务请求消息的初始UE消息(S1-AP:Initial UE Message)。MME接收到后向ENB发起初始上下文建立请求(S1-AP Initial Context Setup Request)激活S1承载,如图3中的步骤1至步骤3所示。MME接收到ENB返回的初始上下文建立成功消息(S1-AP message Initial Context Setup Complete)后向SGW发送修改承载请求(Modify Bearer Request)。MME接收到SGW返回的修改承载成功响应(Modify Bearer Response)后,该UE又可以进行上网等业务,如图3中的步骤4至步骤6所示。
但在LTE大规模实验网测试时,出现了在该UE的S1释放后,在服务器端对该UE发起长ping操作时,即在网络侧的服务器上给UE的IP地址发IP包,该UE服务请求不成功的情况。又由于服务器长ping该UE终端,UE又会再次发起服务请求,而每次的服务请求过程同第一次一样,UE的服务请求始终失败,并不断的重复上述流程,造成了UE和网络形成消息交互的闭环死循环,占用了大量的ENB的空口资源,同时UE始终无法接入网络。
因此,如何解决上述场景中用户服务请求过程的消息交互陷入闭环死循环以及服务请求始终失败的问题,是亟待业界研究的。
发明内容
本发明实施例提供了一种用户服务请求的方法及移动性管理实体装置,用以解决现有技术中存在的用户服务请求过程中出现的消息交互陷入闭环死循环以及服务请求始终失败的问题。
本发明的一个实施例提供的用户服务请求方法,包括:
移动性管理实体MME根据用户设备UE发送的服务请求,指示所述UE的服务基站与所述UE建立无线资源控制RRC连接,并指示所述UE的服务网关SGW根据所述UE的上下文修改所述UE的承载;
若所述MME接收到所述SGW返回的修改承载失败响应,则指示所述SGW为所述UE创建默认承载,并在确认创建成功后指示所述SGW根据所述UE的上下文修改所述UE的默认承载。
本发明的一个实施例提供的移动性管理实体装置,包括:
第一指示单元,用于根据用户设备UE发送的服务请求,指示所述UE的服务基站与所述UE建立无线资源控制RRC连接;
第二指示单元,用于指示所述UE的服务网关SGW根据所述UE的上下文修改所述UE的承载;以及用于在接收到所述SGW返回的修改承载失败响应时,指示所述SGW为所述UE创建默认承载,并在确认创建成功后指示所述SGW根据所述UE的上下文修改所述UE的默认承载。
本发明的上述实施例中的用户服务请求过程,MME根据UE发送的服务请求,指示UE的服务基站与UE建立RRC连接,并指示UE的SGW根据UE的上下文修改UE的承载,若接收到SGW返回的修改承载失败响应,则指示SGW为UE创建默认承载,并在确认创建成功后指示SGW根据UE的上下文修改UE的默认承载。可以看出,在用户服务请求过程中,如果MME接收到SGW返回的修改承载失败响应后,并没有向该UE的服务基站发起该UE的上下文释放,而是向SGW发起创建默认承载的请求,当接收到SGW创建默认承载成功响应后再根据该UE的上下文发起修改承载请求,此时在SGW中有该UE的默认承载,因此能够返回修改承载成功响应,从而用户服务请求流程成功。本发明实施例提出的用户服务请求方法解决了在用户服务请求失败时在UE和服务基站、服务基站和MME、MME和SGW之间突发大量消息,消息来回发送并无法停止死循环的问题,并且可以使用户服务请求流程一次处理成功,消耗网络资源少,UE能够再次进行上网等其他业务操作,提高了用户体验性。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简要介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为LTE非漫游架构示意图;
图2为现有技术中UE的S1释放处理流程示意图;
图3为现有技术中UE发起服务请求处理流程示意图;
图4为现有技术中用户服务请求失败造成消息往复循环的流程示意图;
图5为本发明实施例提供的用户服务请求方法流程示意图;
图6为本发明实施例中的服务基站向MME返回的初始上下文创建成功消息的格式示意图;
图7为本发明实施例中MME向SGW发送的修改承载请求消息的格式示意图;
图8为本发明实施例中创建默认承载请求消息的消息头格式示意图;
图9为本发明实施例提供的用户服务请求方法具体应用的流程示意图;
图10为本发明实施例提供的移动性管理实体装置的结构示意图。
具体实施方式
为了使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明作进一步地详细描述,显然,所描述的实施例仅仅是本发明一部份实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本发明保护的范围。
在LTE大规模实验网测试中,出现了UE的S1释放后,通过网络侧在服务器端做长ping终端UE的操作后,UE的上网业务始终无法恢复的问题,通过深入的研究和定位发现,当在服务器端对该UE进行发起长ping操作后,由于PGW(PDN GateWay,包数据网关)侧的该UE的P58承载处于激活态,ping信令可以从PGW发给SGW,而SGW侧该UE的S1-U承载处于去激活态,因此SGW在收到该UE的ping信令消息后,认为该UE的S1-U承载与PGW侧不一致,进行资源稽核一致性检查处理,从而进行了该UE的SGW侧的S1-U异常资源的释放。因此,在UE发来服务请求的情况下,MME收到服务基站初始上下文建立成功响应后,向SGW发起修改承载请求,而SGW收到修改承载请求后检查该UE的该承载在SGW侧已经不存在了,所以只能返回修改承载失败响应,如图4中的步骤1至步骤6所示。MME收到SGW的修改承载失败响应后,随即发起S1释放流程,UE服务请求失败,如图4中的步骤7和步骤8所示。而S1释放流程完成之后,UE再次发起服务请求流程,服务请求流程的处理和上面图4所示的步骤1至步骤8所述的流程完全一致,因此服务请求仍然失败,失败原因也和上面一致。UE不断的发起服务请求流程,然后不断的在网络侧处理失败,然后再次不断的发起服务请求过程,再次不断的处理失败,不仅造成了UE和网络间的消息交互来回闭环死循环,占用了大量网络资源,而且导致用户始终无法获取网络服务,影响了终端用户的体验性。
为了解决以上问题,本申请提出一种用户服务请求方法及移动性管理实体装置。
在本发明实施例中,在用户服务请求过程中,当MME接收到SGW修改承载失败响应时,并不是向服务基站发起该UE的上下文释放,而是指示SGW为所述UE创建默认承载,并在确认创建成功后指示所述SGW根据所述UE的上下文修改所述UE的默认承载,当接收到SGW创建默认承载成功响应后再根据该UE的上下文发起修改承载请求,由于此时在SGW中已经创建了该UE的默认承载,因此能够返回修改承载成功响应,从而使得用户服务请求流程成功,避免了在接收到SGW返回的修改承载失败响应时,MME发起UE上下文释放造成UE与网络间信息交互死循环并始终不能接入网络的问题。
下面结合附图对本发明实施例进行详细描述。
图5示出了本发明实施例提供的用户服务请求方法的流程示意图,该流程包括如下步骤:
步骤501:MME根据UE发送的服务请求,指示所述UE的服务基站与所述UE建立RRC连接,并指示所述UE的SGW根据所述UE的上下文修改所述UE的承载。
具体地,UE发送服务请求到服务基站,该UE可以是手机等具有无线通信功能的设备。服务基站将接收到的UE的服务请求封装在初始UE消息(S1-AP:Initial UE Message)中并发送给MME。MME接收到包含服务请求的初始UE消息后向服务基站发起初始上下文建立请求(S1-AP Initial ContextSetup Request)激活S1承载,用于指示UE的服务基站与UE建立RRC连接。
MME在接收到服务基站返回的初始上下文建立成功消息(S1-AP messageInitial Context Setup Complete)后向SGW发送修改承载请求(Modify BearerRequest),用于指示SGW根据该请求修改该UE的承载。
其中,服务基站向MME返回的初始上下文创建成功消息格式如图6所示,其中,在IE/Group Name(信息单元/组名称)为E-RAB ID(演进的无线接入承载标识),Transport Layer Address(传输层地址)和GTP-TEID(GPRS隧道协议-隧道标识)的字段中包含了该服务基站为请求服务的UE建立的S1-U侧的信息。
具体地,MME向SGW发送修改承载请求消息,该修改承载请求消息用于指示SGW根据UE的上下文信息修改UE的信令面承载和/或用户面承载。MME接收SGW根据所述修改承载请求消息返回的修改承载请求响应消息,该修改承载请求响应消息用于指示承载修改成功或失败。
其中,MME向SGW发送的修改承载请求消息格式如图7所示,其中,在S1eNodeB F-TEID字段中包含了服务基站返回给MME的初始上下文创建成功消息里所携带的该服务基站为请求服务的UE建立的S1-U侧的信息。
步骤502:若所述MME接收到所述SGW返回的修改承载失败响应,则指示所述SGW为所述UE创建默认承载,并在确认创建成功后指示所述SGW根据所述UE的上下文修改所述UE的默认承载。
具体地,MME接收到所述SGW返回的修改承载失败响应后,向SGW发送创建默认承载请求消息,该创建默认承载请求消息用于指示SGW为该UE创建信令面承载和用户面承载。MME接收所述SGW根据创建默认承载请求消息返回的创建默认承载请求响应消息,该创建默认承载请求响应消息用于指示承载创建成功或失败。
具体的,所述修改承载失败响应可以是因为所述SGW中不存在该UE承载或者该UE承载缺失等导致SGW无法正常进行修改承载操作的原因,从而返回MME修改承载失败响应。
例如,下面所述的场景会导致SGW返回修改承载失败响应:
LTE大规模实验网测试中,当UE进行S1释放后,在服务器端对该UE进行发起长ping操作。由于PGW侧的该UE的P58承载处于激活态,ping信令从PGW发给SGW,而SGW侧该UE的S1-U承载处于去激活态,因此SGW在收到该UE的ping信令消息后,认为该UE的S1-U承载与PGW侧不一致,进行资源稽核一致性检查处理,从而进行了该UE的SGW侧的S1-U异常资源的释放。在UE发来服务请求的情况下,MME收到服务基站初始上下文建立成功响应后,向SGW发起修改承载请求,而SGW收到修改承载请求后检查到该UE承载在SGW中已经不存在了,因此,SGW返回修改承载失败响应。
具体地,创建默认承载请求消息中的SGW的TEIDC(Tunnel EndpointIdentifier,隧道端点标识)取值为0。该TEIDC为0是用于告知SGW针对该UE创建默认承载,即为该UE分配信令资源和承载业务面资源,而不是寻找已有UE的承载并更新。如果该TEIDC不为0,则SGW不能对该UE创建默认承载,返回创建默认承载失败响应消息,从而当MME再次发送修改承载请求时,由于SGW中没有该UE的默认承载,所以仍然得不到修改承载成功响应。
具体地,所述创建默认承载请求消息的消息头格式如图8所示,其中TunnelEndpoint Identifier(1st Octet),Tunnel Endpoint Identifier(2st Octet),TunnelEndpoint Identifier(3st Octet)和Tunnel Endpoint Identifier(4st Octet)为该消息中的SGW的隧道端点标识TEIDC,上述参数在本发明实施例提出的用户服务请求方法中取值为0。
具体地,若MME接收到的是SGW返回的修改承载成功响应,则可以更新该UE在所述MME中的状态为注册且连接态。
具体地,所述MME向SGW发送修改承载请求消息,该修改承载请求消息中包含UE的上下文信息,该修改承载请求消息用于指示SGW根据UE的上下文信息修改UE的信令面默认承载和/或用户面默认承载;
MME接收SGW根据所述修改承载请求消息返回的修改承载请求响应消息,所述修改承载请求响应消息用于指示承载修改成功或失败。
通过以上描述可以看出,本发明实施例在用户服务请求过程中,当MME接收到SGW修改承载失败响应时,指示SGW为UE创建默认承载,在确认创建成功后指示SGW根据所述UE的上下文修改UE的默认承载,接收到SGW创建默认承载成功响应后再根据该UE的上下文再次发起修改承载请求。通过上述过程,当MME再次向SGW发送修改承载请求时,由于此时SGW中创建了该UE的默认承载,因此SGW能够向MME返回修改承载成功响应,从而使得用户服务请求流程成功,避免了现有技术中当MME接收到SGW返回修改承载失败时,MME向服务基站发起UE上下文释放所造成UE与网络间信息交互死循环并始终不能接入网络的问题。
为了更清楚地理解上述的用户服务请求流程,下面基于图5所示的流程,描述本发明实施例的具体实现流程。
图9示出了本发明实施例提供的用户服务请求方法在具体应用中的流程。如图所示,步骤1中,UE向服务基站发送服务请求消息(NAS:Service Request),步骤2中,服务基站将该服务请求消息封装在的初始UE消息(S1-AP:Initial UEMessage)中转发给MME,步骤3中,MME接收到后向服务基站发起初始上下文建立请求(S1-AP Initial Context Setup Request)激活无线和S1承载,步骤4中,MME接收到服务基站返回的初始上下文建立成功消息(S1-AP messageInitial Context Setup Complete),此时该UE的无线承载建立,步骤5中,MME向SGW发送修改承载请求(Modify Bearer Request),步骤6中,MME接收到SGW返回的修改承载失败响应(Modify Bearer Response),步骤7中,该MME向SGW发起创建默认承载请求,指示该SGW为所述UE创建默认承载,步骤8中,SGW接收到该创建默认承载请求后为所述UE分配信令面资源和用户面资源,创建默认承载成功后返回创建默认承载成功响应,步骤9中,MME接收到此响应后再次向SGW发起修改承载请求,步骤10中,由于此时SGW中存在该UE的默认承载,因此在修改默认承载成功后向MME返回修改承载成功响应,从而该场景下的用户服务请求成功。
通过上述流程可以看出,在本发明的实施例场景中,MME根据UE发送的服务请求,指示UE的服务基站与UE建立RRC连接,并指示UE的SGW根据UE的上下文修改UE的承载,若接收到SGW返回的修改承载失败响应,则指示SGW为UE创建默认承载,并在确认创建成功后指示SGW根据UE的上下文修改UE的默认承载。本发明实施例提出的用户服务请求方法解决了在用户服务请求失败时在UE和网络间消息交互死循环并始终不能接入网络的问题,并且可以使用户服务请求流程一次处理成功,消耗网络资源少,提高了用户体验性。
基于相同的技术构思,本发明实施例还提供了一种装置,该装置可执行上述方法实施例。本发明实施例提供的装置如图10所示。
参见图10,为本发明实施例提供的移动性管理实体装置的结构示意图,该装置可包括:第一指示单元1001、第二指示单元1002,其中:
第一指示单元1001,用于根据用户设备UE发送的服务请求,指示所述UE的服务基站与所述UE建立无线资源控制RRC连接;
第二指示单元1002,用于指示所述UE的服务网关SGW根据所述UE的上下文修改所述UE的承载;以及用于在接收到所述SGW返回的修改承载失败响应时,指示所述SGW为所述UE创建默认承载,并在确认创建成功后指示所述SGW根据所述UE的上下文修改所述UE的默认承载。
具体地,第二指示单元1002向SGW发送修改承载请求消息,该修改承载请求消息用于指示SGW根据UE的上下文信息修改UE的信令面承载和/或用户面承载;第二指示单元1002接收SGW根据所述修改承载请求消息返回的修改承载请求响应消息,该修改承载请求响应消息用于指示承载修改成功或失败。
具体地,第二指示单元1002在接收到SGW返回的修改承载失败响应时,向SGW发送创建默认承载请求消息,该创建默认承载请求消息用于指示SGW为UE创建信令面资源和用户面资源;第二指示单元1002接收SGW根据所述创建默认承载请求消息返回的创建默认承载请求响应消息,该创建默认承载请求响应消息用于指示承载创建成功或失败。
具体地,所述第二指示单元1002发送的创建默认承载请求消息中的SGW的隧道端点标识TEIDC取值为0。
具体地,所述第二指示单元1002向SGW发送修改承载请求消息,该修改承载请求消息中包含UE的上下文信息,该修改承载请求消息用于指示所述SGW根据UE的上下文信息修改UE的信令面默认承载和/或用户面默认承载;第二指示单元1002接收SGW根据修改承载请求消息返回的修改承载请求响应消息,该修改承载请求响应消息用于指示承载修改成功或失败。
综上所述,本发明的上述实施例中,MME根据UE发送的服务请求,指示UE的服务基站与UE建立RRC连接,并指示UE的SGW根据UE的上下文修改UE的承载,若接收到SGW返回的修改承载失败响应,则指示SGW为UE创建默认承载,并在确认创建成功后指示SGW根据UE的上下文修改UE的默认承载。可以看出,在MME接收到SGW返回的修改承载失败响应后,向SGW发起创建默认承载的请求,在接收到SGW创建默认承载成功响应后再根据该UE的上下文发起修改承载请求,此时在SGW中有该UE的默认承载,因此能够返回修改承载成功响应,从而用户服务请求流程成功,解决了在用户服务请求失败时UE与网络间信息交互死循环并始终不能接入网络的问题,并且可以使用户服务请求流程一次处理成功,消耗网络资源少,提高了用户体验性。
本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。
Claims (10)
1.一种用户服务请求的方法,其特征在于,该方法包括:
移动性管理实体MME根据用户设备UE发送的服务请求,指示所述UE的服务基站与所述UE建立无线资源控制RRC连接,并指示所述UE的服务网关SGW根据所述UE的上下文修改所述UE的承载;
若所述MME接收到所述SGW返回的修改承载失败响应,则指示所述SGW为所述UE创建默认承载,并在确认创建成功后指示所述SGW根据所述UE的上下文修改所述UE的默认承载。
2.如权利要求1所述的方法,其特征在于,所述指示UE的SGW根据所述UE的上下文修改所述UE的承载,包括:
所述MME向所述SGW发送修改承载请求消息,所述修改承载请求消息用于指示所述SGW根据所述UE的上下文信息修改所述UE的信令面承载和/或用户面承载;
所述MME接收所述SGW根据所述修改承载请求消息返回的修改承载请求响应消息,所述修改承载请求响应消息用于指示承载修改成功或失败。
3.如权利要求1所述的方法,其特征在于,所述指示所述SGW为所述UE创建默认承载,包括:
所述MME向所述SGW发送创建默认承载请求消息,所述创建默认承载请求消息用于指示所述SGW为所述UE创建信令面承载和用户面承载;
所述MME接收所述SGW根据所述创建默认承载请求消息返回的创建默认承载请求响应消息,所述创建默认承载请求响应消息用于指示承载创建成功或失败。
4.如权利要求3所述的方法,其特征在于,所述创建默认承载请求消息中的SGW的隧道端点标识TEIDC取值为0。
5.如权利要求1所述的方法,其特征在于,所述指示所述SGW根据所述UE的上下文修改所述UE的默认承载,包括:
所述MME向所述SGW发送修改承载请求消息,所述修改承载请求消息中包含所述UE的上下文信息,所述修改承载请求消息用于指示所述SGW根据所述UE的上下文信息修改所述UE的信令面默认承载和/或用户面默认承载;
所述MME接收所述SGW根据所述修改承载请求消息返回的修改承载请求响应消息,所述修改承载请求响应消息用于指示承载修改成功或失败。
6.一种移动性管理实体装置,其特征在于,包括:
第一指示单元,用于根据用户设备UE发送的服务请求,指示所述UE的服务基站与所述UE建立无线资源控制RRC连接;
第二指示单元,用于指示所述UE的服务网关SGW根据所述UE的上下文修改所述UE的承载;以及用于在接收到所述SGW返回的修改承载失败响应时,指示所述SGW为所述UE创建默认承载,并在确认创建成功后指示所述SGW根据所述UE的上下文修改所述UE的默认承载。
7.如权利要求6所述的移动性管理实体装置,其特征在于,所述第二指示单元,具体用于:
向所述SGW发送修改承载请求消息,所述修改承载请求消息用于指示所述SGW根据所述UE的上下文信息修改所述UE的信令面承载和/或用户面承载;
接收所述SGW根据所述修改承载请求消息返回的修改承载请求响应消息,所述修改承载请求响应消息用于指示承载修改成功或失败。
8.如权利要求6所述的移动性管理实体装置,其特征在于,所述第二指示单元,具体用于:
向所述SGW发送创建默认承载请求消息,所述创建默认承载请求消息用于指示所述SGW为所述UE创建信令面资源和用户面资源;
接收所述SGW根据所述创建默认承载请求消息返回的创建默认承载请求响应消息,所述创建默认承载请求响应消息用于指示承载创建成功或失败。
9.如权利要求8所述的移动性管理实体装置,其特征在于,所述创建默认承载请求消息中的SGW的隧道端点标识TEIDC取值为0。
10.如权利要求6所述的移动性管理实体装置,其特征在于,所述第二指示单元,具体用于:
向所述SGW发送修改承载请求消息,所述修改承载请求消息中包含所述UE的上下文信息,所述修改承载请求消息用于指示所述SGW根据所述UE的上下文信息修改所述UE的信令面默认承载和/或用户面默认承载;
接收所述SGW根据所述修改承载请求消息返回的修改承载请求响应消息,所述修改承载请求响应消息用于指示承载修改成功或失败。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510663290.2A CN106604295A (zh) | 2015-10-14 | 2015-10-14 | 一种用户服务请求方法及移动性管理实体装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510663290.2A CN106604295A (zh) | 2015-10-14 | 2015-10-14 | 一种用户服务请求方法及移动性管理实体装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN106604295A true CN106604295A (zh) | 2017-04-26 |
Family
ID=58553050
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510663290.2A Pending CN106604295A (zh) | 2015-10-14 | 2015-10-14 | 一种用户服务请求方法及移动性管理实体装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN106604295A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110784942A (zh) * | 2018-07-31 | 2020-02-11 | 华为技术有限公司 | 一种连接建立方法及装置 |
CN113411913A (zh) * | 2020-03-16 | 2021-09-17 | 华为技术有限公司 | 通信方法及终端设备 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101541097A (zh) * | 2008-03-19 | 2009-09-23 | 华为技术有限公司 | 恢复承载的方法、装置及*** |
CN101631344A (zh) * | 2008-07-16 | 2010-01-20 | 华为技术有限公司 | 隧道管理方法、装置及通信*** |
CN101815359A (zh) * | 2009-12-18 | 2010-08-25 | 华为技术有限公司 | 承载创建方法、去活方法、服务网关和移动通信*** |
CN102281519A (zh) * | 2010-06-12 | 2011-12-14 | 中兴通讯股份有限公司 | 一种承载修改方法及*** |
-
2015
- 2015-10-14 CN CN201510663290.2A patent/CN106604295A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101541097A (zh) * | 2008-03-19 | 2009-09-23 | 华为技术有限公司 | 恢复承载的方法、装置及*** |
CN101631344A (zh) * | 2008-07-16 | 2010-01-20 | 华为技术有限公司 | 隧道管理方法、装置及通信*** |
CN101815359A (zh) * | 2009-12-18 | 2010-08-25 | 华为技术有限公司 | 承载创建方法、去活方法、服务网关和移动通信*** |
CN102281519A (zh) * | 2010-06-12 | 2011-12-14 | 中兴通讯股份有限公司 | 一种承载修改方法及*** |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110784942A (zh) * | 2018-07-31 | 2020-02-11 | 华为技术有限公司 | 一种连接建立方法及装置 |
CN110784942B (zh) * | 2018-07-31 | 2022-04-12 | 华为技术有限公司 | 一种连接建立方法及装置 |
CN113411913A (zh) * | 2020-03-16 | 2021-09-17 | 华为技术有限公司 | 通信方法及终端设备 |
CN113411913B (zh) * | 2020-03-16 | 2023-07-07 | 华为技术有限公司 | 通信方法及终端设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110035498B (zh) | 一种通信方法,设备及其*** | |
CN107645779B (zh) | 一种数据发送、传输方法及装置 | |
CN103188742B (zh) | 通信切换方法、用户设备与基站 | |
CN109891919A (zh) | 在无线通信***中确定emm模式的方法及其设备 | |
CN109076330A (zh) | 无线通信***中跟踪区域更新的方法及其装置 | |
CN107241815B (zh) | 处理无线资源控制连结恢复程序的装置及方法 | |
CN108370604A (zh) | 无线通信***中支持扩展空闲模式不连续接收激活的方法及其装置 | |
CN102202405B (zh) | 一种切换时无线资源的配置方法及装置 | |
CN108391321A (zh) | 处理无线通信***中状态不匹配的装置及方法 | |
CN104105219B (zh) | 一种数据传输方法及装置 | |
CN107635258A (zh) | 一种数据或者信令发送、传输方法及装置 | |
CN107231623A (zh) | 一种数据调度方法、基站及*** | |
CN107396455A (zh) | 连接处理方法及装置 | |
CN109547944A (zh) | 数据传输的方法及装置 | |
JP2009232457A (ja) | Rrc接続プロセスを改善する方法及び通信装置 | |
CN103974429B (zh) | 一种终端间的邻近通信的路径建立方法及设备 | |
CN108616880A (zh) | 一种数据传输的方法、装置及*** | |
CN104301106B (zh) | 无线通信***及其认证方法 | |
CN107046734A (zh) | Nas承载数据的传输方法及装置 | |
CN107027174B (zh) | 处理寻呼程序的装置及方法 | |
CN109547955A (zh) | 一种下行信息的发送方法、amf实体及nf实体 | |
CN106604295A (zh) | 一种用户服务请求方法及移动性管理实体装置 | |
CN108307429A (zh) | 一种基站用户数据恢复的方法及装置 | |
CN109802982B (zh) | 一种双连接实现方法、装置及*** | |
CN108377522A (zh) | 一种信息前转方法及基站 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20170426 |