CN114125909B - 一种故障恢复方法及装置 - Google Patents
一种故障恢复方法及装置 Download PDFInfo
- Publication number
- CN114125909B CN114125909B CN202010898370.7A CN202010898370A CN114125909B CN 114125909 B CN114125909 B CN 114125909B CN 202010898370 A CN202010898370 A CN 202010898370A CN 114125909 B CN114125909 B CN 114125909B
- Authority
- CN
- China
- Prior art keywords
- network element
- cscf
- fault
- upf
- terminal equipment
- 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.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/04—Arrangements for maintaining operational condition
Abstract
本申请提供一种故障恢复方法及装置,用以解决由于UPF网元故障而导致呼叫终端设备失败的问题,其中方法包括:P‑CSCF网元通过第一UPF网元向终端设备发送呼叫终端设备的邀请消息;P‑CSCF网元若确定在预设时间长度内未接收到来自终端设备的邀请响应消息,则发送第一请求消息,第一请求消息用于确认是否存在发生故障的网元;P‑CSCF网元接收包括故障指示信息的第一响应消息时,发起容灾恢复流程,用于将终端设备重新注册上线。上面的流程中,P‑CSCF网元在呼叫终端设备的过程中,检测为终端设备服务的网元是否发生故障,从而实现快速探测、并进行容灾恢复,可以避免由于UPF网元故障而导致呼叫终端设备失败。
Description
技术领域
本申请涉及通信技术领域,尤其涉及一种故障恢复方法及装置。
背景技术
在第5代(the 5th generation,5G)移动通信系统中,在网际协议多媒体子系统(internet protocol multimedia subsystem,IMS)呼叫过程中,用于发起呼叫的邀请(INVITE)消息由代理呼叫会话控制功能(proxy-call session control function,P-CSCF)网元转发至用户面功能(user Plane function,UPF)网元,然后由UPF网元发起寻呼和服务请求(service request)流程,将INVITE消息发送给被叫的终端设备。P-CSCF网元在收到被叫的终端设备的183消息时,再发起语音或视频的专有承载建立。在呼叫过程中,如果UPF网元发生故障,则会导致呼叫失败。
目前,UPF网元发生故障后,会话管理功能(session management function,SMF)网元能检测UPF网元出现故障,但无法及时通知给P-CSCF网元。因为现有技术中,SMF网元需要周期性批量地将故障集中的通知给P-CSCF网元,因此,在SMF网元通知P-CSCF网元之前,如果UPF网元发生故障,由于P-CSCF网元不感知UPF网元的状态,会导致呼叫失败。
发明内容
本申请提供一种故障恢复方法及装置,用以解决由于UPF网元故障而导致呼叫终端设备失败的问题。
第一方面,本申请提供了一种方法,包括:P-CSCF网元通过第一UPF网元向终端设备发送邀请消息,所述邀请消息用于呼叫终端设备;P-CSCF网元若确定在预设时间长度内未接收到来自所述终端设备的邀请响应消息,则发送第一请求消息,所述第一请求消息用于确认所述P-CSCF网元至所述终端设备之间是否存在发生故障的网元;所述P-CSCF网元接收第一响应消息,若所述第一响应消息包括故障指示信息,则发起容灾恢复流程,所述容灾恢复流程用于使所述终端设备重新注册上线;所述故障指示信息用于指示P-CSCF网元至所述终端设备之间存在发生故障的网元。
通过上面的流程可知,P-CSCF网元在呼叫终端设备的过程中,检测为终端设备服务的UPF网元是否发生故障,从而实现快速探测、并进行容灾恢复,对各网元均无信令冲击。P-CSCF网元在确定无法接收到终端设备的响应消息时,对UPF网元进行故障确认,实现避免不清楚原因的情况下发起无效的容灾恢复,浪费网络资源。本申请实施例提供的方法能快速容灾恢复,终端设备无感知,可以提高用户体验。
一种可能的实现方式中,所述第一请求消息可为位置请求消息,用于请求所述第一UPF网元的位置信息。从而提供一种实现第一请求消息的情况。
一种可能的实现方式中,所述故障指示信息可为容灾错误码,所述容灾错误码用于指示发生故障的网元,不同网元发生故障时对应不同的容灾错误码。这样,可以简化故障指示信息的表示,并提供一种实现故障指示信息的可能方式。
一种可能的实现方式中,所述发生故障的网元可包括以下一项或多项:所述第一UPF网元;策略控制功能PCF网元;会话管理功能SMF网元;承载控制功能BSF网元。
一种可能的实现方式中,所述第一响应消息可为183消息。从而提供一种实现第一响应消息的情况。
第二方面,本申请还提供一种通信装置,其可以达到的技术效果请参照上述第一方面中的各种实现方式的效果,这里不再重复赘述。该通信装置具有实现上述第一方面提供的任一方法。该通信装置可以通过硬件实现,也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的单元或模块。
在一种可能的实现方式中,该通信装置包括:处理器,该处理器被配置为支持该通信装置执行以上所示方法中P-CSCF网元的相应功能。该通信装置还可以包括存储器,该存储可以与处理器耦合,其保存该通信装置必要的程序指令和数据。可选地,该通信装置还包括通信接口,该通信接口用于支持该通信装置与终端设备等设备之间的通信。
在一种可能的实现方式中,该通信装置包括相应的功能模块,分别用于实现以上方法中的步骤。功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块。
在一种可能的实施方式中,通信装置的结构中包括处理模块和通信模块,这些模块可以执行上述方法示例中相应功能,具体参见第一方面提供的方法中的描述,此处不做赘述。
第三方面,提供一种故障恢复方法,包括:SMF网元接收来自P-CSCF网元的第二请求消息,所述第二请求消息用于确认第一UPF网元是否发生故障;所述第一UPF网元是为终端设备服务的网元;所述P-CSCF网元为呼叫所述终端设备的网元;所述SMF网元若确认所述第一UPF网元发生故障,则为所述终端设备分配第二UPF网元。
通过上面的流程可知,SMF网元是在呼叫终端设备的过程中,确定无法接收到终端设备的响应消息时,对第一UPF网元进行故障确认,从而实现通过在呼叫终端设备的过程中,实现UPF故障的快速探测、并进行容灾恢复。整个处理的流程,是平滑、离散的,对各网元均无信令冲击。而且本申请实施例提供的方法能快速容灾恢复,终端设备无感知,可以提高用户体验。
一种可能的实现方式中,所述第二请求消息可为位置请求消息,用于请求所述第一UPF网元的位置信息。从而提供一种实现第二请求消息的情况。
一种可能的实现方式中,所述SMF网元确认所述第一UPF网元发生故障,包括:所述SMF网元确定SMF网元与所述第一UPF网元之间的心跳包丢失,则确认所述第一UPF网元发生故障。这样通过心跳包的收发情况,可以确定第一UPF网元是否发生故障,从而提供一种确定UPF网元是否发生故障的可实现方式。
一种可能的实现方式中,所述SMF网元为所述终端设备分配第二UPF网元,包括:所述SMF网元触发重建所述终端设备的网际协议多媒体子系统IMS默认承载流程,并在重建所述终端设备的IMS默认承载流程中为所述终端设备分配所述第二UPF网元。通过所述SMF网元在重建所述终端设备的IMS默认承载流程中为所述终端设备分配所述第二UPF网元,从而提供一种可以为终端设备分配第二UPF网元的可实现方式。
第四方面,本申请还提供一种通信装置,其可以达到的技术效果请参照上述第一方面中的各种实现方式的效果,这里不再重复赘述。该通信装置具有实现上述第三方面提供的任一方法。该通信装置可以通过硬件实现,也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的单元或模块。
在一种可能的实现方式中,该通信装置包括:处理器,该处理器被配置为支持该通信装置执行以上所示方法中SMF网元的相应功能。该通信装置还可以包括存储器,该存储可以与处理器耦合,其保存该通信装置必要的程序指令和数据。可选地,该通信装置还包括通信接口,该通信接口用于支持该通信装置与终端设备等设备之间的通信。
在一种可能的实现方式中,该通信装置包括相应的功能模块,分别用于实现以上方法中的步骤。功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块。
在一种可能的实施方式中,通信装置的结构中包括处理模块和通信模块,这些模块可以执行上述方法示例中相应功能,具体参见第三方面提供的方法中的描述,此处不做赘述。
第五方面,本申请提供一种通信装置,所述通信装置包括处理器,当所述处理器执行存储器中的计算机程序或指令时,如第一方面所述的任一方法被执行。
第六方面,本申请提供一种通信装置,所述通信装置包括处理器,当所述处理器执行存储器中的计算机程序或指令时,如第三方面所述的任一方法被执行。
第七方面,本申请提供一种通信装置,所述通信装置包括处理器和存储器,所述存储器用于存储计算机程序或指令;所述处理器用于执行所述存储器所存储的计算机程序或指令,以使所述通信装置执行如第一方面中所示的任一的方法。
第八方面,本申请提供一种通信装置,所述通信装置包括处理器和存储器,所述存储器用于存储计算机程序或指令;所述处理器用于执行所述存储器所存储的计算机程序或指令,以使所述通信装置执行如第三方面中所示的任一的方法。
第九方面,本申请提供一种通信装置,所述通信装置包括处理器、存储器和通信接口,所述通信接口,用于接收信号或者发送信号;所述存储器,用于存储计算机程序或指令;所述处理器,用于从所述存储器调用所述计算机程序或指令执行如第一方面所述的任一方法。
第十方面,本申请提供一种通信装置,所述通信装置包括处理器、存储器和通信接口,所述通信接口,用于接收信号或者发送信号;所述存储器,用于存储计算机程序或指令;所述处理器,用于从所述存储器调用所述计算机程序或指令执行如第三方面所述的任一方法。
第十一方面,本申请提供一种通信装置,所述通信装置包括处理器和通信接口,所述通信接口,用于接收代码指令并传输至所述处理器;所述处理器运行所述代码指令以执行如第一方面所示的任一的方法。
第十二方面,本申请提供一种通信装置,所述通信装置包括处理器和通信接口,所述通信接口,用于接收代码指令并传输至所述处理器;所述处理器运行所述代码指令以执行如第三方面所示的任一的方法。
第十三方面,本申请提供一种计算机可读存储介质,所述计算机可读存储介质用于存储计算机程序或指令,当计算机读取并执行所述计算机程序或指令时,使得第一方面所述的任一方法被实现。
第十四方面,本申请提供一种计算机可读存储介质,所述计算机可读存储介质用于存储计算机程序或指令,当计算机读取并执行所述计算机程序或指令时,使得第三方面所述的任一方法被实现。
第十五方面,本申请提供一种包括指令的计算机程序产品,当计算机读取并执行所述计算机程序产品时,使得第一方面所述的任一方法被实现。
第十六方面,本申请提供一种包括指令的计算机程序产品,当计算机读取并执行所述计算机程序产品时,使得第三方面所述的任一方法被实现。
第十七方面,本申请提供一种芯片,包括处理器,所述处理器与存储器耦合,用于执行所述存储器中存储的计算机程序或指令,当所述处理器执行所述计算机程序或指令时,使得第一方面所述的任一方法被实现。
第十八方面,本申请提供一种芯片,包括处理器,所述处理器与存储器耦合,用于执行所述存储器中存储的计算机程序或指令,当所述处理器执行所述计算机程序或指令时,使得第三方面所述的任一方法被实现。
附图说明
图1为适用于本申请实施例的一种网络架构示意图;
图2为现有技术中的UPF故障检测流程示意图;
图3为本申请实施例提供的一种故障恢复示意图;
图4为本申请实施例提供的一种故障恢复示意图;
图5为本申请实施例提供的一种通信装置结构示意图;
图6为本申请实施例提供的一种通信装置结构示意图。
具体实施方式
下面结合说明书附图对本申请实施例做详细描述。
本申请实施例可以应用于各种移动通信系统,例如:5G中的新无线(new radio,NR)系统,4G中的长期演进(long term evolution,LTE)系统、先进的长期演进(advancedlong term evolution,LTE-A)系统、演进的长期演进(evolved long term evolution,eLTE)系统,未来通信系统等其它通信系统,具体的,在此不做限制。
为便于理解本申请实施例,首先以图1中示出的通信系统为例详细说明适用于本申请实施例的通信系统。图1示例性示出了适用于本申请实施例的一种系统架构示意图,如图1所示,在5G系统架构中,终端设备可以经接入网设备与核心网进行通信,终端设备可以指用户设备(user equipment,UE)、接入终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置。接入终端可以是蜂窝电话、无绳电话、会话启动协议(session initiation protocol,SIP)电话、无线本地环路(wireless local loop,WLL)站、个人数字处理(personal digital assistant,PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备,未来5G网络中的终端设备等。图1中为方便描述,只示例出1个终端设备,实际网络中,可能存在多个终端设备共存,在此不再赘述。
接入网(access network,AN)设备,接入网设备也可以称之为无线接入网(radioaccess network,RAN)设备,以下统称为接入网设备,主要负责为终端设备提供无线连接,保证终端设备的上下行数据的可靠传输等。接入网设备可以是下一代基站(generationNode B,gNB),可以是演进型节点B(evolved Node B,eNB)等。
会话管理功能(session management function,SMF)网元,该网元可以根据终端设备的位置信息为终端设备选择合适的用户面功能(user Plane function,UPF)网元。
UPF网元,主要功能包括分组路由和转发,用户面数据的服务质量(quality ofservice,QoS)处理等。
接入和移动性管理(access and mobility management function,AMF)网元,主要功能包括无线接入网络控制平面的终结点,非接入信令的终结点,移动性管理,合法监听,接入授权或鉴权等。
策略控制功能(policy control function,PCF)网元,主要负责用户面传输路径的建立、释放和更改等功能。
鉴权服务器功能(authentication server function,AUSF)网元,其主要功能包括用户鉴权等。
用户数据管理(user data management,UDM)网元,主要负责管理用户的签约数据等。
数据网络(data Network,DN)可以是指为终端设备提供服务的网络,比如有些DN可以为终端设备提供上网功能,有些DN可以为终端设备提供彩信功能。
图1只是示例,还可能包括其他网元,例如应用功能(application function,AF)网元等,在此不再逐一举例说明。
图1中还示出了各个网元之间的接口,比如接入网设备和AMF网元之间的N2接口,接入网设备与UPF网元之间的N9接口等,在此不再一一赘述。
现有技术中,P-CSCF网元到UPF网元之间,没有心跳检测,P-CSCF网元不感知UPF网元的状态。SMF网元能检测UPF网元发生故障,从而通知P-CSCF网元,具体流程可以如图2所示。图2所示的流程可以包括以下步骤:
步骤1:SMF网元确定UPF网元发生故障,具体如何确定,可以参考现有技术中的确定方法。
步骤2:SMF网元周期性的向PCF网元发送故障信息,故障信息用于指示SMF网元检测到的发生故障的UPF网元,以及发生故障的原因等信息。
步骤3:PCF网元向Diameter路由代理(diameter route agent,DRA)设备发送所述故障信息。
步骤4:DRA设备向P-CSCF网元发送所述故障信息。
步骤5:P-CSCF网元发起容灾流程,将终端设备重新注册上线,实现容灾恢复。在容灾恢复过程中,SMF网元可以重新为终端设备分配一个UPF网元。
通过上面的流程可知,SMF网元能检测UPF网元发生故障,但无法及时通知给P-CSCF网元。因此,在UPF网元发生故障之后,SMF网元通知P-CSCF网元之前,无法通过该UPF网元呼叫终端设备,从而可能导致通信无法建立。为此,本申请实施例提供一种方法,以解决该问题,下面将详细描述。
另外,在本申请实施例中,“示例的”一词用于表示作例子、例证或说明。本申请中被描述为“示例”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言,使用示例的一词旨在以具体方式呈现概念。
本申请实施例描述的网络架构以及业务场景是为了更加清楚的说明本申请实施例的技术方案,并不构成对于本申请实施例提供的技术方案的限定,本领域普通技术人员可知,随着网络架构的演变和新业务场景的出现,本申请实施例提供的技术方案对于类似的技术问题,同样适用。
本申请实施例中部分场景以NR网络的场景为例进行说明,应当指出的是,本申请实施例中的方案还可以应用于其他无线通信网络中,相应的名称也可以用其他无线通信网络中的对应功能的名称进行替代。
实施例一:
参见图3,为本申请实施例提供的一种故障恢复方法流程示意图。
图3所示的流程中的终端设备为被叫的终端设备,图3以主叫的终端设备(图3中未示出)发起的IMS会话已经到达被叫的终端设备(图3中所示的终端设备)的P-CSCF网元为例进行描述,即主叫的终端设备发起的邀请(INVITE)消息已经到达服务呼叫会话控制功能(serving-call session control function,S-CSCF)网元。
图3所示的流程中,以终端设备与P-CSCF网元包括接入网设备、第一UPF网元、SMF网元、PCF网元以及Diameter路由代理(diameter route agent,DRA)设备为例进行描述。
步骤301:P-CSCF网元接收来自S-CSCF网元的邀请消息,所述邀请消息用于呼叫终端设备。
其中,所述邀请消息的目的网际协议(internet protocol,IP)地址为被叫的终端设备的IP地址。
被叫的终端设备的IP地址由为被叫的终端设备服务的UPF网元来发布、管理,为此P-CSCF网元可以通过该UPF网元(以下称为第一UPF网元)向终端设备发送邀请消息,具体可以包括以下步骤。
步骤302:P-CSCF网元向第一UPF网元发送邀请消息。
该邀请消息可以是步骤301中的邀请消息。
步骤303:P-CSCF网元若确定在预设时间长度内未接收到来自所述终端设备的邀请响应消息,则发送第一请求消息。
具体的,P-CSCF网元可以向Diameter路由代理(diameter route agent,DRA)设备发送第一请求消息。所述第一请求消息用于确认所述P-CSCF网元至所述终端设备之间是否存在发生故障的网元。
举例来说,P-CSCF网元向第一UPF网元发送邀请消息时,可以启动定时器,定时器的定时时长为预设时间长度。在定时器超时的情况下,P-CSCF网元没有接收到邀请响应消息,则可以确定发送第一请求消息。
其中,定时器的定时时长,需避免误发起探测、和避免较长时间才发起探测和容灾恢复(用户体验较差),例如可以设置为3秒。
第一请求消息的具体实现方式,本申请实施例对此并不限定,例如第一请求消息可以为位置请求消息,用于请求所述第一UPF网元的位置信息。假如无法通过第一请求消息请求到第一UPF网元的位置信息,那么可以确定P-CSCF网元至所述终端设备之间存在发生故障的网元。第一请求消息还可以为其他类型的请求消息,本申请不再逐一举例说明。
需要说明的是,P-CSCF网元发送第一请求消息之前,还可以根据SIP协议,对第一请求消息进行超时重传,但如果第一UPF网元发生故障,重传的第一请求消息也无法到达被叫的终端设备。
本申请实施例中的邀请响应消息,可以是指183消息,也可以为其他消息,本申请实施例对此并不限定。
步骤304:DRA设备向PCF网元转发第一请求消息。
具体的,DRA设备通过承载控制功能(bearer service function,BSF)网元查询绑定信息,寻址为被叫的终端设备服务的PCF网元。
一种可能的场景中,DRA设备若没有获取到BSF网元返回的响应消息,则确认BSF网元发生故障,并返回第一响应消息。第一响应消息包括故障指示信息,所述故障指示信息用于指示P-CSCF网元至所述终端设备之间存在发生故障的网元。
本申请中,故障指示信息可以为容灾错误码,不同网元发生故障时对应不同的容灾错误码。若BSF网元发生故障,故障指示信息可以为BSF网元发生故障时对应的容灾错误码。
另一种可能的场景中,DRA设备若通过BSF网元没有查询到PCF网元,则返回第一响应消息。第一响应消息包括故障指示信息,具体的,故障指示信息可以为PCF网元发生故障时对应的容灾错误码。
步骤305:PCF网元接收到第一请求消息之后,若确定存在与第一UPF网元对应的SMF网元,则将第一请求消息转发至SMF网元。
需要说明的是,PCF网元若确定为被叫的终端设备服务的SMF网元已发生故障,则返回第一响应消息。第一响应消息包括故障指示信息,所述故障指示信息用于指示P-CSCF网元至所述终端设备之间存在发生故障的网元。
具体的,若SMF网元发生故障,此时第一响应消息中包括的故障指示信息可以为SMF网元发生故障时对应的容灾错误码。
步骤306:SMF网元根据第一请求消息,确定第一UPF网元是否发生故障;若确定第一UPF网元发生故障,则返回第一响应消息。
第一响应消息包括故障指示信息,此时第一响应消息中包括的故障指示信息可以为第一UPF网元发生故障时对应的容灾错误码。
举例来说,第一请求消息用于请求第一UPF网元的地址信息的位置请求消息时,SMF网元若确定第一UPF网元的状态异常,无法查询到第一UPF网元的地址信息,则可以确定第一UPF网元发生故障。
再举例来说,SMF网元确定SMF网元与所述第一UPF网元之间的心跳包丢失时,则确认所述第一UPF网元发生故障。其中,心跳包是在SMF网元与第一UPF网元间定时通知对方自己状态的一种数据包,心跳包按照一定的周期进行发送,SMF网元如果周期性的接收到第一UPF网元的心跳包,则可以确定第一UPF网元没有发生故障;SMF网元如果在指定时间长度内没有接收到第一UPF网元的心跳包,则认为心跳包丢失,可以确定第一UPF网元发生故障。其中,指定时间长度大于心跳包的发送周期。
需要说明的是,第一响应消息是通过PCF网元、DRA设备转发至P-CSCF网元的,具体过程不再赘述。
需要说明的是,SMF网元若确定第一UPF网元没有发生故障,则可以向P-CSCF网元发送第一响应消息,此时第一响应消息可以用于指示第一UPF网元未发生故障。
步骤307:P-CSCF网元接收第一响应消息,P-CSCF网元发起容灾恢复流程。
如前所述,P-CSCF网元接收到的第一响应消息可以来自SMF网元,也可以来自PCF网元,还可以来自DRA设备等。
P-CSCF网元可以根据第一响应消息中的故障指示信息确定发生故障的网元。结合前面的描述可知,本申请实施例中,发生故障的网元可以为以下一项或多项:
第一UPF网元;PCF网元;SMF网元;BSF网元。
具体的,P-CSCF网元可以向S-CSCF网元发送容灾指示,从而发起容灾恢复流程。S-CSCF网元可以通过UDM网元通知AMF网元或SMF网元,指示终端设备重建IMS默认承载;IMS默认承载建立后,终端设备可以发起IMS注册,网络侧从而可以为终端设备重新分配一个UPF网元,例如可以为第二UPF网元。
需要说明的是,容灾恢复流程的具体过程,本申请实施例对此并不限定,可以参考现有技术中的描述。
S-CSCF网元识别终端设备重新注册上线后,通过第二UPF网元重新呼叫终端设备,具体过程可以参考现有技术专有的呼叫流程,在此不再赘述。
通过上面的流程可知,本申请实施例提供的方法,可以通过在呼叫终端设备的过程中,确定为终端设备服务的UPF网元发生故障,从而实现快速探测、并进行容灾恢复。整个处理的流程,是平滑、离散的,对各网元均无信令冲击。整个过程中,是在确定无法接收到终端设备的响应消息时,对UPF网元进行故障确认,是基于确定的故障原因进行容灾恢复,避免不清楚原因的情况下发起无效的容灾恢复,浪费网络资源。本申请实施例提供的方法能快速容灾恢复,终端设备无感知,可以提高用户体验。
实施例二:
本申请实施例中,SMF网元确定第一UPF网元发生故障时,SMF网元还可以直接发起IMS默认承载重新建立的流程,终端设备重新建立IMS默认承载,并重新发起IMS注册。在终端设备重新注册过程中,可以为终端设备重新分配第二UPF网元。当终端设备IMS注册成功后,S-CSCF网元将被叫请求重新下发,并通过第二UPF网元重新呼叫终端设备,下面将详细描述。
参见图4,为本申请实施例提供的一种故障恢复方法流程示意图。
图4所示的流程中的终端设备为被叫的终端设备,图4以主叫的终端设备(图4中未示出)发起的IMS会话已经到达被叫的终端设备(图4中所示的终端设备)的P-CSCF网元为例进行描述,即主叫的终端设备发起的邀请(INVITE)消息已经到达S-CSCF网元。
图4所示的流程中,以终端设备与P-CSCF网元包括接入网设备、第一UPF网元、SMF网元、PCF网元以及DRA设备为例进行描述。
步骤401:P-CSCF网元接收来自S-CSCF网元的邀请消息,所述邀请消息用于呼叫终端设备。
其中,所述邀请消息的目的IP地址为被叫的终端设备的IP地址。
被叫的终端设备的IP地址由为被叫的终端设备服务的UPF网元来发布、管理,为此P-CSCF网元可以通过该UPF网元(以下称为第一UPF网元)向终端设备发送邀请消息,具体可以包括以下步骤。
步骤402:P-CSCF网元向第一UPF网元发送邀请消息。
该邀请消息可以是步骤401中的邀请消息。
步骤403:P-CSCF网元若确定在预设时间长度内未接收到来自所述终端设备的邀请响应消息,则发送第二请求消息。
具体的,P-CSCF网元可以向DRA设备发送第二请求消息。第二请求消息用于确认第一UPF网元是否发生故障,或者所述第二请求消息用于确认所述P-CSCF网元至所述终端设备之间是否存在发生故障的网元。
举例来说,P-CSCF网元向第一UPF网元发送邀请消息时,可以启动定时器,定时器的定时时长为预设时间长度。在定时器超时的情况下,P-CSCF网元没有接收到邀请响应消息,则可以确定发送第二请求消息。
其中,定时器的定时时长,需避免误发起探测、和避免较长时间才发起探测和容灾恢复(用户体验较差),例如可以设置为3秒。
第二请求消息的具体实现方式,本申请实施例对此并不限定,例如第二请求消息可以为位置请求消息,用于请求所述第一UPF网元的位置信息。假如无法通过第二请求消息请求到第一UPF网元的位置信息,那么可以确定P-CSCF网元至所述终端设备之间存在发生故障的网元。第二请求消息还可以为其他类型的请求消息,本申请不再逐一举例说明。
需要说明的是,P-CSCF网元发送第二请求消息之前,可以根据SIP协议,对第二请求消息进行超时重传,但如果第一UPF网元发生故障,重传的第二请求消息也无法到达被叫的终端设备。
本申请实施例中的邀请响应消息,可以是指183消息,也可以为其他消息,本申请实施例对此并不限定。
步骤404:DRA设备向PCF网元转发第二请求消息。
步骤405:PCF网元接收到第二请求消息之后,若确定存在与第一UPF网元对应的SMF网元,则将第二请求消息转发至SMF网元。
需要说明的是,PCF网元若确定不存在为被叫的终端设备服务的SMF网元,或者若确定为被叫的终端设备服务的SMF网元已发生故障,则返回第二响应消息。第二响应消息包括故障指示信息,所述故障指示信息用于指示P-CSCF网元至所述终端设备之间存在发生故障的网元。
故障指示信息可以为容灾错误码,不同网元发生故障时对应不同的容灾错误码。若SMF网元发生故障,此时第二响应消息中包括的故障指示信息可以为SMF网元发生故障时对应的容灾错误码。
步骤406:SMF网元根据第二请求消息,确定第一UPF网元是否发生故障;若确定第一UPF网元发生故障,则触发重建所述终端设备的IMS默认承载流程。
举例来说,第二请求消息用于请求第一UPF网元的地址信息时,SMF网元若确定第一UPF网元的状态异常,无法查询到第一UPF网元的地址信息,则可以确定第一UPF网元发生故障。
再举例来说,SMF网元确定SMF网元与所述第一UPF网元之间的心跳包丢失时,则确认所述第一UPF网元发生故障。
在重建所述终端设备的IMS默认承载流程中,可以为所述终端设备分配第二UPF网元。重建IMS默认承载流程的具体过程,可以参考现有技术,在此不再赘述。
需要说明的是,SMF网元若确定第一UPF网元没有发生故障,则可以向P-CSCF网元发送第二响应消息,此时第二响应消息可以用于指示第一UPF网元未发生故障。
步骤407:终端设备的IMS默认承载重新建立成功后,发起IMS注册流程。
具体的,终端设备可以向第二UPF网元发生注册(register)消息,第二UPF网元将注册消息发送到P-CSCF网元,具体过程,可以参考现有技术,在此不再赘述。
S-CSCF网元识别终端设备重新注册上线后,通过第二UPF网元重新呼叫终端设备,具体过程可以参考现有技术专有的呼叫流程,在此不再赘述。
通过上面的流程可知,本申请实施例提供的方法,是在呼叫终端设备的过程中,确定无法接收到终端设备的响应消息时,对UPF网元进行故障确认,从而实现通过在呼叫终端设备的过程中,实现UPF故障的快速探测、并进行容灾恢复。整个处理的流程,是平滑、离散的,对各网元均无信令冲击。而且本申请实施例提供的方法能快速容灾恢复,终端设备无感知,可以提高用户体验。
本文中描述的各个实施例可以为独立的方案,也可以根据内在逻辑进行组合,这些方案都落入本申请的保护范围中。
可以理解的是,上述各个方法实施例中,由P-CSCF网元实现的方法和操作,也可以由可用于P-CSCF网元的部件(例如芯片或者电路)实现,由SMF网元实现的方法和操作,也可以由可用于SMF网元的部件(例如芯片或者电路)实现。
上述本申请提供的实施例中,分别从各个设备之间交互的角度对本申请实施例提供的方法进行了介绍。为了实现上述本申请实施例提供的方法中的各功能,P-CSCF网元或SMF网元可以包括硬件结构和/或软件模块,以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能以硬件结构、软件模块、还是硬件结构加软件模块的方式来执行,取决于技术方案的特定应用和设计约束条件。
本申请实施例中对模块的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。另外,在本申请各个实施例中的各功能模块可以集成在一个处理器中,也可以是单独物理存在,也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。
与上述构思相同,如图5所示,本申请实施例还提供一种装置500用于实现上述方法中P-CSCF网元或SMF网元的功能。例如,该装置可以为软件模块或者芯片系统。本申请实施例中,芯片系统可以由芯片构成,也可以包含芯片和其他分立器件。该装置500可以包括:处理模块501和通信模块502。
本申请实施例中,通信模块502也可以称为收发模块,可以包括发送模块和/或接收模块,分别用于实现上文方法实施例中P-CSCF网元或SMF网元执行发送和接收的步骤。
以下,结合图5至图6详细说明本申请实施例提供的通信装置。应理解,装置实施例的描述与方法实施例的描述相互对应,因此,未详细描述的内容可以参见上文方法实施例,为了简洁,这里不再赘述。
示例性地,当该装置500实现本申请提供的流程中P-CSCF网元的功能时:通信模块,用于通过第一用户面功能UPF网元向终端设备发送邀请消息,所述邀请消息用于呼叫终端设备;处理模块,用于若确定在预设时间长度内未接收到来自所述终端设备的邀请响应消息,则通过所述通信模块发送第一请求消息,所述第一请求消息用于确认所述P-CSCF网元至所述终端设备之间是否存在发生故障的网元;所述通信模块,还用于接收第一响应消息,所述处理模块还用于若所述第一响应消息包括故障指示信息,则发起容灾恢复流程,所述容灾恢复流程用于使所述终端设备重新注册上线;所述故障指示信息用于指示所述装置至所述终端设备之间存在发生故障的网元。
一种可能的实现方式中,所述第一请求消息可为位置请求消息,用于请求所述第一UPF网元的位置信息。
一种可能的实现方式中,所述故障指示信息可为容灾错误码,所述容灾错误码用于指示发生故障的网元,不同网元发生故障时对应不同的容灾错误码。
一种可能的实现方式中,所述发生故障的网元包括以下一项或多项:
所述第一UPF网元;策略控制功能PCF网元;会话管理功能SMF网元;承载控制功能BSF网元。
一种可能的实现方式中,所述第一响应消息可为183消息。
示例性地,当该装置500实现本申请提供的流程中SMF网元的功能时:通信模块,用于接收来自代理呼叫会话控制功能P-CSCF网元的第二请求消息,所述第二请求消息用于确认第一用户面功能UPF网元是否发生故障;所述第一UPF网元是为终端设备服务的网元;所述P-CSCF网元为呼叫所述终端设备的网元;处理模块,用于若确认所述第一UPF网元发生故障,则为所述终端设备分配第二UPF网元。
一种可能的实现方式中,所述第二请求消息可为位置请求消息,用于请求所述第一UPF网元的位置信息。
一种可能的实现方式中,所述处理模块可以在确定SMF网元与所述第一UPF网元之间的心跳包丢失,则确认所述第一UPF网元发生故障。
一种可能的实现方式中,所述处理模块可以触发重建所述终端设备的网际协议多媒体子系统IMS默认承载流程,并在重建所述终端设备的IMS默认承载流程中为所述终端设备分配所述第二UPF网元。
如图6所示,为本申请实施例提供的一种通信装置结构示意图,图6所示的装置可以为图5所示的装置的一种硬件电路的实现方式。该通信装置可适用于执行上述方法实施例中终端设备或者网络设备的功能。为了便于说明,图6仅示出了该通信装置的主要部件。
图6所示的装置600包括至少一个处理器620,通信接口610以及存储器630。处理器620用于执行存储器630中存储的指令或程序。存储器630中存储的指令或程序被执行时,该处理器620用于执行上述实施例中处理模块501执行的操作,通信接口610用于执行上述实施例中通信模块502执行的操作。
存储器630,用于存储程序指令和/或数据。存储器630和处理器620耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接,可以是电性,机械或其它的形式,用于装置、单元或模块之间的信息交互。处理器620可能和存储器630协同操作。处理器620可能执行存储器630中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。
在实现过程中,上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。为避免重复,这里不再详细描述。
应注意,本申请实施例中的处理器可以是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理电路(digitalsignal processor,DSP)、专用集成芯片(application specific integrated circuit,ASIC)、现场可编程门阵列(field programmable gate array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
可以理解,本申请实施例中的存储器可以是易失性存储器或非易失性存储器,或可包括易失性和非易失性存储器两者。其中,非易失性存储器可以是只读存储器(read-only memory,ROM)、可编程只读存储器(programmable ROM,PROM)、可擦除可编程只读存储器(erasable PROM,EPROM)、电可擦除可编程只读存储器(electrically EPROM,EEPROM)或闪存。应注意,本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
装置600还可以包括通信接口610,用于通过传输介质和其它设备进行通信,从而用于装置600中的装置可以和其它设备进行通信。在本申请实施例中,通信接口可以是收发器、电路、总线、模块或其它类型的通信接口。在本申请实施例中,通信接口为收发器时,收发器可以包括独立的接收器、独立的发射器;也可以集成收发功能的收发器、或者是接口电路。
装置600还可以包括通信线路640。其中,通信接口610、处理器620以及存储器630可以通过通信线路640相互连接;通信线路640可以是外设部件互连标准(peripheralcomponent interconnect,简称PCI)总线或扩展工业标准结构(extended industrystandard architecture,简称EISA)总线等。所述通信线路640可以分为地址总线、数据总线、控制总线等。为便于表示,图6中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
Claims (10)
1.一种故障恢复方法,其特征在于,包括:
代理呼叫会话控制功能P-CSCF网元通过第一用户面功能UPF网元向终端设备发送邀请消息,所述邀请消息用于呼叫终端设备;
所述P-CSCF网元若确定在预设时间长度内未接收到来自所述终端设备的邀请响应消息,则发送第一请求消息,所述第一请求消息用于确认所述P-CSCF网元至所述终端设备之间是否存在发生故障的网元;
所述P-CSCF网元接收第一响应消息,若所述第一响应消息包括故障指示信息,则发起容灾恢复流程,所述容灾恢复流程用于使所述终端设备重新注册上线;所述故障指示信息用于指示P-CSCF网元至所述终端设备之间存在发生故障的网元。
2.根据权利要求1所述的方法,其特征在于,所述第一请求消息为位置请求消息,用于请求所述第一UPF网元的位置信息。
3.根据权利要求1或2所述的方法,其特征在于,所述故障指示信息为容灾错误码,所述容灾错误码用于指示发生故障的网元,不同网元发生故障时对应不同的容灾错误码。
4.根据权利要求1至3任一所述的方法,其特征在于,所述发生故障的网元包括以下一项或多项:
所述第一UPF网元;策略控制功能PCF网元;会话管理功能SMF网元;承载控制功能BSF网元。
5.一种通信装置,其特征在于,包括:
通信模块,用于通过第一用户面功能UPF网元向终端设备发送邀请消息,所述邀请消息用于呼叫终端设备;
处理模块,用于若确定在预设时间长度内未接收到来自所述终端设备的邀请响应消息,则通过所述通信模块发送第一请求消息,所述第一请求消息用于确认代理呼叫会话控制功能P-CSCF网元至所述终端设备之间是否存在发生故障的网元;
所述通信模块,还用于接收第一响应消息;
所述处理模块,还用于若所述第一响应消息包括故障指示信息,则发起容灾恢复流程,所述容灾恢复流程用于使所述终端设备重新注册上线;所述故障指示信息用于指示所述装置至所述终端设备之间存在发生故障的网元。
6.根据权利要求5所述的装置,其特征在于,所述第一请求消息为位置请求消息,用于请求所述第一UPF网元的位置信息。
7.根据权利要求5或6所述的装置,其特征在于,所述故障指示信息为容灾错误码,所述容灾错误码用于指示发生故障的网元,不同网元发生故障时对应不同的容灾错误码。
8.根据权利要求5至7任一所述的装置,其特征在于,所述发生故障的网元包括以下一项或多项:
所述第一UPF网元;策略控制功能PCF网元;会话管理功能SMF网元;承载控制功能BSF网元。
9.一种通信装置,其特征在于,包括处理器和存储器:
所述处理器,用于执行所述存储器中存储的计算机程序或指令,当所述处理器执行所述计算机程序或指令时,如权利要求1至4中任意一项所述的方法被执行。
10.一种可读存储介质,其特征在于,包括计算机程序或指令,当通信装置执行所述计算机程序或指令时,如权利要求1至4中任意一项所述的方法被执行。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010898370.7A CN114125909B (zh) | 2020-08-31 | 2020-08-31 | 一种故障恢复方法及装置 |
PCT/CN2021/114018 WO2022042466A1 (zh) | 2020-08-31 | 2021-08-23 | 一种故障恢复方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010898370.7A CN114125909B (zh) | 2020-08-31 | 2020-08-31 | 一种故障恢复方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN114125909A CN114125909A (zh) | 2022-03-01 |
CN114125909B true CN114125909B (zh) | 2023-08-22 |
Family
ID=80354603
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010898370.7A Active CN114125909B (zh) | 2020-08-31 | 2020-08-31 | 一种故障恢复方法及装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN114125909B (zh) |
WO (1) | WO2022042466A1 (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115022909B (zh) * | 2022-05-27 | 2024-01-30 | 中国电信股份有限公司 | Upf网元、基于核心网的数据传输方法、设备及介质 |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101170553A (zh) * | 2006-10-24 | 2008-04-30 | 华为技术有限公司 | 实现互联网协议多媒体子系统容灾的方法和装置 |
CN101212814A (zh) * | 2006-12-29 | 2008-07-02 | 中国移动通信集团公司 | 网元数据失效或发生故障后的业务处理方法、系统及网元 |
CN101489245A (zh) * | 2008-12-31 | 2009-07-22 | 华为技术有限公司 | 网络容灾方法、终端和呼叫会话控制功能实体 |
CN102223248A (zh) * | 2011-06-09 | 2011-10-19 | 中国电信股份有限公司 | 呼叫业务处理方法与系统 |
CN102255747A (zh) * | 2011-06-09 | 2011-11-23 | 中国电信股份有限公司 | 呼叫业务处理方法与系统 |
CN102340505A (zh) * | 2011-09-28 | 2012-02-01 | 中兴通讯股份有限公司 | S-cscf容灾恢复倒回的方法及系统 |
CN103138984A (zh) * | 2011-12-02 | 2013-06-05 | 中兴通讯股份有限公司 | 容灾倒回服务呼叫会话控制功能实体的方法及系统 |
CN105813119A (zh) * | 2014-12-31 | 2016-07-27 | 中国电信股份有限公司 | 容灾恢复方法、网元以及通信系统 |
CN106209473A (zh) * | 2016-07-25 | 2016-12-07 | 中国联合网络通信集团有限公司 | 一种容灾倒回的方法及系统 |
US10412625B1 (en) * | 2018-04-24 | 2019-09-10 | Verizon Patent And Licensing Inc. | Systems and methods for tracking and calculating network usage in a network with multiple user plane functions |
CN111294216A (zh) * | 2018-12-10 | 2020-06-16 | 中国电信股份有限公司 | Pcrf容灾方法、系统和pgw |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106470441B (zh) * | 2015-08-20 | 2019-11-29 | 中国电信股份有限公司 | 一种容灾恢复方法和系统 |
CN109391979B (zh) * | 2017-08-03 | 2021-08-17 | 中兴通讯股份有限公司 | P-cscf故障恢复方法、装置及系统 |
EP3827557A1 (en) * | 2018-07-26 | 2021-06-02 | Lenovo (Singapore) Pte. Ltd. | Monitoring qos parameters of a data connection |
US11224093B2 (en) * | 2018-08-13 | 2022-01-11 | Ofinno, Llc | Network initiated UPF sessions transfer |
-
2020
- 2020-08-31 CN CN202010898370.7A patent/CN114125909B/zh active Active
-
2021
- 2021-08-23 WO PCT/CN2021/114018 patent/WO2022042466A1/zh active Application Filing
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101170553A (zh) * | 2006-10-24 | 2008-04-30 | 华为技术有限公司 | 实现互联网协议多媒体子系统容灾的方法和装置 |
CN101212814A (zh) * | 2006-12-29 | 2008-07-02 | 中国移动通信集团公司 | 网元数据失效或发生故障后的业务处理方法、系统及网元 |
CN101489245A (zh) * | 2008-12-31 | 2009-07-22 | 华为技术有限公司 | 网络容灾方法、终端和呼叫会话控制功能实体 |
CN102223248A (zh) * | 2011-06-09 | 2011-10-19 | 中国电信股份有限公司 | 呼叫业务处理方法与系统 |
CN102255747A (zh) * | 2011-06-09 | 2011-11-23 | 中国电信股份有限公司 | 呼叫业务处理方法与系统 |
CN102340505A (zh) * | 2011-09-28 | 2012-02-01 | 中兴通讯股份有限公司 | S-cscf容灾恢复倒回的方法及系统 |
CN103138984A (zh) * | 2011-12-02 | 2013-06-05 | 中兴通讯股份有限公司 | 容灾倒回服务呼叫会话控制功能实体的方法及系统 |
CN105813119A (zh) * | 2014-12-31 | 2016-07-27 | 中国电信股份有限公司 | 容灾恢复方法、网元以及通信系统 |
CN106209473A (zh) * | 2016-07-25 | 2016-12-07 | 中国联合网络通信集团有限公司 | 一种容灾倒回的方法及系统 |
US10412625B1 (en) * | 2018-04-24 | 2019-09-10 | Verizon Patent And Licensing Inc. | Systems and methods for tracking and calculating network usage in a network with multiple user plane functions |
CN111294216A (zh) * | 2018-12-10 | 2020-06-16 | 中国电信股份有限公司 | Pcrf容灾方法、系统和pgw |
Also Published As
Publication number | Publication date |
---|---|
CN114125909A (zh) | 2022-03-01 |
WO2022042466A1 (zh) | 2022-03-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10595250B2 (en) | Quality of service initiated handover | |
EP3664500B1 (en) | Proxy call session control function fault recovering method, apparatus and system | |
KR100975740B1 (ko) | 이종 무선 통신 네트워크에서 핸드오버 방법 및 장치 | |
US9596712B2 (en) | Method and apparatus for handling P-CSCF failure and restoring connectivity | |
CN109863766B (zh) | 用于更新非主动sim的状态信息的系统和方法 | |
WO2016185962A1 (ja) | 移動通信システム、通信制御装置、移動管理エンティティ及び移動通信方法 | |
US20220338152A1 (en) | Support for ims routing with multiple ims pdu sessions over different 5gc slices | |
CN105873241B (zh) | 建立通话连接的方法及装置 | |
KR101812435B1 (ko) | 호출 제어 장치와 사용자 서비스 처리 방법 | |
WO2014048331A1 (zh) | 业务接续处理方法及系统 | |
WO2011137926A1 (en) | Handling a registration timer to provide service continuity in ims | |
US8817778B2 (en) | Session processing method, device, and communication system | |
US9900806B2 (en) | Handling call transfer in a communication network | |
CN114125909B (zh) | 一种故障恢复方法及装置 | |
KR101513451B1 (ko) | 무선 통신 시스템에서 재등록을 유도하기 위한 장치 및 이를 위한 방법 | |
CN111031528B (zh) | 一种专用网络的连接建立方法和装置 | |
JP2013219516A (ja) | 通信制御装置及び通信制御方法 | |
JP2013175885A (ja) | 移動局及び通信方法 | |
EP3742695A1 (en) | Network service system and method | |
WO2016185964A1 (ja) | 移動通信システム、通信制御装置、移動管理エンティティ及び移動通信方法 | |
CN110915291B (zh) | 语音会话建立方法、装置、设备及存储介质 | |
KR20160084516A (ko) | VoLTE(Voice over Long Term Evolution) 시스템 및 그 제어방법과 및 이 시스템에 포함되는 PGW(PDN Gateway) 및 CSCF(Call Session Control Function)과 그 제어방법 | |
WO2020034343A1 (en) | Ultra reliable communication using a single packet data unit session | |
CN116170416A (zh) | 一种确定s-cscf的方法及装置 | |
CN115442793A (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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |