CN115022909B - Upf网元、基于核心网的数据传输方法、设备及介质 - Google Patents

Upf网元、基于核心网的数据传输方法、设备及介质 Download PDF

Info

Publication number
CN115022909B
CN115022909B CN202210593645.5A CN202210593645A CN115022909B CN 115022909 B CN115022909 B CN 115022909B CN 202210593645 A CN202210593645 A CN 202210593645A CN 115022909 B CN115022909 B CN 115022909B
Authority
CN
China
Prior art keywords
network element
upf network
transmission data
main
upf
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
Application number
CN202210593645.5A
Other languages
English (en)
Other versions
CN115022909A (zh
Inventor
黄鸿儒
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Telecom Corp Ltd
Original Assignee
China Telecom Corp Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by China Telecom Corp Ltd filed Critical China Telecom Corp Ltd
Priority to CN202210593645.5A priority Critical patent/CN115022909B/zh
Publication of CN115022909A publication Critical patent/CN115022909A/zh
Application granted granted Critical
Publication of CN115022909B publication Critical patent/CN115022909B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements
    • H04W24/04Arrangements for maintaining operational condition
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/12Setup of transport tunnels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/15Setup of multiple wireless link connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/19Connection re-establishment

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请提供了一种UPF网元、基于核心网的数据传输方法、设备及介质,涉及通信技术领域。该方法包括:在主UPF网元故障恢复的情况下,接收第一数据网络DN发送的第一传输数据;在主UPF网元上未创建有第一传输数据的会话的情况下,通过通信隧道将第一传输数据转发至容灾UPF网元,以使容灾UPF网元将第一传输数据发送至会话对应的第一终端设备。根据本申请实施例,能够提高终端设备的使用用户的业务体验。

Description

UPF网元、基于核心网的数据传输方法、设备及介质
技术领域
本申请涉及通信技术领域,尤其涉及一种UPF网元、基于核心网的数据传输方法、设备及介质。
背景技术
用户面功能(User Plane Function,UPF网元),其是第五代移动通信技术(5thGeneration Mobile Communication Technology,5G)核心网***架构的重要组成部分,负责用户数据报文的路由转发、业务识别和策略执行等功能。
现阶段,UPF网元故障往往会影响终端设备用户的业务使用体验。
因此,如果提高终端设备用户的业务体验成为了亟待解决的问题。
需要说明的是,在上述背景技术部分公开的信息仅用于加强对本申请的背景的理解,因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。
发明内容
本申请提供一种UPF网元、基于核心网的数据传输方法、设备及介质,至少在一定程度上克服UPF网元故障导致终端设备的使用用户业务体验变差的问题。
本申请的其他特性和优点将通过下面的详细描述变得显然,或部分地通过本申请的实践而习得。
根据本申请的一个方面,提供了一种基于核心网的数据传输方法,核心网包括主用户面功能UPF网元和容灾UPF网元,主UPF网元与容灾UPF网元之间设置有通信隧道,方法应用于主UPF网元,包括:
在主UPF网元故障恢复的情况下,接收第一数据网络DN发送的第一传输数据;
在主UPF网元上未创建有第一传输数据的会话的情况下,通过通信隧道将第一传输数据转发至容灾UPF网元,以使容灾UPF网元将第一传输数据发送至会话对应的第一终端设备。
在一个实施例中,在接收第一数据网络DN发送的第一传输数据之后,方法还包括:
在主UPF网元上创建有第一传输数据的会话的情况下,将第一传输数据发送至第一终端设备。
在一个实施例中,方法还包括:
在主UPF网元与第二DN之间的通信链路发生故障的情况下,接收第二终端设备发送的、待传输至第二DN的第二传输数据;
通过通信隧道,将第二传输数据转发至容灾UPF网元,以使容灾UPF网元将第二传输数据发送至第二DN。
在一个实施例中,方法还包括:
在主UPF网元与第二DN之间的通信链路发生故障的情况下,通过通信隧道接收容灾UPF网元转发的、待传输至第二终端设备的第三传输数据,第三传输数据由第二DN发送至容灾UPF网元;
将第三传输数据发送至第二终端设备。
在一个实施例中,方法还包括:
在主UPF网元与SMF网元之间的通信链路发生故障的情况下,接收第三DN发送的第四传输数据;
在第四传输数据所属会话未创建于主UPF网元的情况下,通过通信隧道将第四传输数据转发至容灾UPF网元,以使容灾UPF网元将第四传输数据发送至第四传输数据所属会话对应的第三终端设备。
在一个实施例中,在判断第四传输数据所属会话是否创建于主UPF网元上之后,方法还包括:
在第四传输数据所属会话创建于主UPF网元的情况下,将第四传输数据发送至第三终端设备。
根据本申请的另一个方面,提供了一种基于核心网的数据传输方法,核心网包括主用户面功能UPF网元和容灾UPF网元,主UPF网元与容灾UPF网元之间设置有通信隧道,方法应用于容灾UPF网元,包括:
在主UPF网元故障恢复的情况下,通过通信隧道接收主UPF网元发送的第一传输数据,其中,第一传输数据由第一DN发送至主UPF网元、且经主UPF网元确定其上未创建有第一传输数据所属会话;
将第一传输数据发送至会话对应的第一终端设备。
在一个实施例中,方法还包括:
在主UPF网元与第二DN之间的通信链路发生故障的情况下,通过通信隧道接收主UPF网元转发的、待传输至第二DN的第二传输数据,其中,第二传输数据由第二终端设备发送;
将第二传输数据发送至第二DN。
在一个实施例中,方法还包括:
在主UPF网元与第二DN之间的通信链路发生故障的情况下,接收第二DN发送的第三传输数据;
将第三传输数据转发至主UPF网元,以使主UPF网元将第三传输数据发送至第二终端设备。
在一个实施例中,方法还包括:
在主UPF网元与SMF网元之间的通信链路发生故障的情况下,接收主UPF网元发送的第四传输数据,其中,第四传输数据由第三DN发送至主UPF网元、且经主UPF网元确定其上未创建有第四传输数据所属会话;
将第四传输数据发送至会话对应的第三终端设备。
根据本申请的又一个方面,提供了一种主UPF网元,主UPF网元所属核心网还包括容灾UPF网元,主UPF网元与容灾UPF网元之间设置有通信隧道,主UPF网元包括:
数据接收模块,用于在主UPF网元故障恢复的情况下,接收第一数据网络DN发送的第一传输数据;
数据转发模块,用于在主UPF网元上未创建有第一传输数据的会话的情况下,通过通信隧道将第一传输数据转发至容灾UPF网元,以使容灾UPF网元将第一传输数据发送至会话对应的第一终端设备。
根据本申请的再一个方面,提供了一种容灾UPF网元,容灾UPF网元所属核心网还包括容灾UPF网元,主UPF网元与容灾UPF网元之间设置有通信隧道,容灾UPF网元包括:
数据接收模块,用于在主UPF网元故障恢复的情况下,通过通信隧道接收主UPF网元发送的第一传输数据,其中,第一传输数据由第一DN发送至主UPF网元、且经主UPF网元确定其上未创建有第一传输数据所属会话;
数据发送模块,用于将第一传输数据发送至会话对应的第一终端设备。
根据本申请的再一个方面,提供一种电子设备,包括:处理器;以及存储器,用于存储处理器的可执行指令;其中,处理器配置为经由执行可执行指令来执行上述的基于核心网的数据传输方法。
根据本申请的再一个方面,提供一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现上述的基于核心网的数据传输方法。
本申请实施例所提供的UPF网元、基于核心网的数据传输方法、设备及介质,可以在主UPF网元故障恢复之后,对于将会话创建于容灾UPF网元的第一终端设备,主UPF网元可以在接收第一DN发送的第一传输数据,可以通过主UPF网元和容灾UPF网元之间的通信隧道将其转发至容灾UPF网元,然后由容灾UPF网元将其发送至对应的第一终端设备。由于在UPF网元故障恢复之后,第一DN会将传输数据的下一跳路由默认为主UPF网元,相较于需要将故障期间在容灾UPF网元上创建的会话从容灾UPF网元下线并于主UPF网元重新上线的方案相比,本申请实施例通过主UPF网元向容灾UPF网元转发数据的方式,无需对故障期间在容灾UPF网元上创建的会话重新上下线,从而保证了会话所对应的终端设备的使用用户的业务体验。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本申请。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理。显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1示出了一种相关技术中的网络架构图;
图2示出了本申请实施例提供的一种网络架构图;
图3示出本申请实施例中一种基于核心网的数据传输方法流程图;
图4示出了在主UPF网元故障恢复之后的数据传输路径的示意图;
图5示出了本申请实施例提供的另一种基于核心网的数据传输方法的流程示意图;
图6示出了本申请实施例提供的一种示例性的基于核心网的数据传输方法的流程示意图;
图7示出了示出本申请实施例中又一种基于核心网的数据传输方法流程图;
图8示出了在主UPF网元与第二DN之间的通信链路发生故障时的数据传输路径的示意图;
图9示出了示出本申请实施例中再一种基于核心网的数据传输方法流程图;
图10示出了本申请实施例提供的另一种示例性的基于核心网的数据传输方法的流程示意图;
图11示出了示出本申请实施例中又一种基于核心网的数据传输方法流程图;
图12示出了在主UPF网元与SMF网元之间的通信链路发生故障时的数据传输路径的示意图;
图13示出了本申请实施例提供的再一种基于核心网的数据传输方法的流程示意图;
图14示出了本申请实施例提供的又一种示例性的基于核心网的数据传输方法的流程示意图;
图15示出本申请实施例中一种主UPF网元的结构示意图;
图16示出本申请实施例中一种容灾UPF网元的结构示意图;和
图17示出本申请实施例中一种电子设备的结构框图。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而,示例实施方式能够以多种形式实施,且不应被理解为限于在此阐述的范例;相反,提供这些实施方式使得本申请将更加全面和完整,并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。
此外,附图仅为本申请的示意性图解,并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分,因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体,不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体,或在一个或多个硬件模块或集成电路中实现这些功能实体,或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
应当理解,本申请的方法实施方式中记载的各个步骤可以按照不同的顺序执行,和/或并行执行。此外,方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本申请的范围在此方面不受限制。
需要注意,本申请中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分,并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。
需要注意,本申请中提及的“一个”、“多个”的修饰是示意性而非限制性的,本领域技术人员应当理解,除非在上下文另有明确指出,否则应该理解为“一个或多个”。
UPF网元,其是核心网的重要组成部分之一。由于UPF网元可以作为终端设备和DN之间的数据传输桥梁,因此,UPF网元往往对终端设备用户的业务体验起到了关键作用。
图1示出了一种相关技术中的网络架构图。如图1所示,核心网10可以至少包括UPF网元11和会话管理功能(Session Management Function,SMF)网元12。其中,UPF网元11可以通过N4接口与SMF网元12交互,被SMF网元12直接控制和管理,并根据SMF网元12发布的各种策略执行业务流处理。
以及,终端设备20可以通过基站30以及UPF网元11,与访问数据网络(DataNetwork,DN)40进行数据交互。
为了提高UPF网元的容灾能力,图2示出了本申请实施例提供的一种网络架构图。图2与图1的不同之处在于,核心网10可以至少包括主UPF网元111、容灾UPF网元112和SMF网元12。
其中,主UPF网元111可以通过一个N4链路与SMF网元12通信连接,以及通过一个N6链路与DN 40进行通信连接。以及,容灾UPF网元112可以通过一个N4链路与SMF网元12通信连接,以及通过一个N6链路与DN40进行通信连接。
在主UPF网元111发生故障的场景中,可以将主UPF网元111上的会话迁移至容灾UPF网元112,从而使得与主UPF网元111连接的终端设备在容灾UPF网元112重新上线。此时,DN 40在监测到主UPF网元111发生故障之后,将下行数据的下一跳路由修改为容灾UPF网元112。此时,终端设备20与DN 40之间可以通过容灾UPF网元112进行上行数据、下行数据等的传输。从而可以在主UPF网元111故障时,能够使得终端设备20可以继续访问DN 40,提高了UPF网元***的容灾能力。示例性地,在终端设备配置有固定互联网协议(InternetProtocol,IP)地址(即静态IP地址)的具体场景下,终端设备仅能选择在一个UPF网元上线,相应地,当主UPF网元111发生故障时,终端设备需要整体从主UPF网元111下线,并在容灾UPF网元112重新上线。
在一种相关技术中,在诸如下行数据指向固定互联网协议(Internet Protocol,IP)等情况下,下行数据的下一跳路由只能选择其中一个UPF网元。因此,当主UPF网元故障恢复之后,新上线的终端设备(即在故障恢复之后在主UPF网元111上线的终端设备)与之前上线的终端设备(即在故障恢复之前在容灾UPF网元112上线的终端设备)若分属不同的UPF网元,无论DN在主UPF网元111和容灾UPF网元112中选择哪一个UPF网元作为下行数据的下一跳路由,另外一个UPF网元上的下行业务均会中断。
因此,在主UPF网元111故障恢复之后,DN 40会重新选择主UPF网元111作为下行数据(即由DN发往终端的传输数据)的下一跳路由。以及在SMF 12的控制下,在容灾UPF网元112上面的静态IP地址的终端需要中断业务之后,于主UPF网元111上重新上线之后才可以恢复服务。
该种技术将会终端设备的业务连续性,严重影响用户的业务使用体验。
基于此,继续参见图2,发明人提出了可以通过在第一UPF网元111和第二UPF网元112之间设置通信隧道13的方式,可以在主UPF网元111故障恢复之后,主UPF网元111可以在接收DN发送的传输数据之后,向容灾UPF网元112转发传输数据的方式,无需对故障期间在容灾UPF网元112上创建的会话重新上下线,从而保证了会话所对应的终端设备的使用用户的业务体验。
接下来对本申请实施例提供的技术方案进行说明。其中,在开始介绍本申请实施例涉及的技术方案之前,先对本申请实施例涉及的技术术语进行说明。
(1)SMF网元,负责用户会话管理功能。示例性地,其可以负责5G用户的会话的生命管理周期、IP地址分配、数据路由选择、业务连续性管理、策略规则匹配以及流量计费处理等功能。
在本申请实施例中,SMF网元可以选择终端设备对应的会话建立于哪一个UPF网元上。在一个示例中,在主UPF网元故障时,终端设备可以在SMF网元的控制下将会话建立于容灾UPF网元。在另一个示例中,在主UPF网元故障恢复之后,将已经创建的会话保持于容灾UPF网元,将新产生的会话建立于主UPF网元。在又一个示例中,在主UPF网元与SMF网元之间的N4链路中断时,可以将已经创建的会话保持于主UPF网元,将新产生的会话建立于容灾UPF网元。
(2)DN,5GC(5G核心网)的外部数据网络,比如运营商业务,互联网或者第三方业务等。
(3)N4,SMF和UPF网元之间的接口,用于传输SMF和UPF网元间的控制面信息。示例性地,可以将SMF与UPF网元之间的通信链路称为N4链路。
(4)N6,DN和UPF网元之间的接口,用于传递UPF网元与DN之间的上下行数据。比如,可以基于IP、路由协议等与DN网络通信。示例性地,可以将DN与UPF网元之间的通信链路称为N6链路。
(5)N9,UPF网元之间的接口,用于在UPF网元之间传递数据。
(6)对于主UPF网元和容灾UPF网元中的任意UPF网元,可以是一个网络设备,或者是网络设备中用于实现UPF网元功能的模块,对此不作具体限定。
在一些实施例中,主UPF网元和容灾UPF网元可以是相对而言的。主UPF网元和容灾UPF网元可以分别为不同的终端设备提供UPF网元服务。
对于终端设备而言,为其主要提供UPF网元服务的UPF网元为主UPF网元,另一UPF网元为容灾UPF网元。比如,对于一个UPF网元所服务的区域内的终端用户而言,该UPF网元为主UPF网元。比如,以广州的UPF网元和深圳的UPF网元为例,对于深圳的终端设备,深圳的UPF网元为主UPF网元,广州的UPF网元为容灾UPF网元。对于广州的终端设备,广州的UPF网元为主UPF网元,深圳的UPF网元为容灾UPF网元。
示例性地,主UPF网元和容灾UPF网元可以位于不同的局域网内。
在另一些实施例中,可以为主UPF网元单独设置一个容灾UPF网元,对此不作具体限定。
在介绍完上述技术术语之后,下面结合附图及实施例对本示例实施方式进行详细说明。
本申请实施例中提供了一种基于核心网的数据传输方法,该方法可以由上述主UPF网元执行。
图3示出本申请实施例中一种基于核心网的数据传输方法流程图,如图3所示,本申请实施例中提供的基于核心网的数据传输方法包括如下步骤S310和S320。
S310,在主UPF网元故障恢复的情况下,接收第一DN发送的第一传输数据。
对于主UPF网元故障恢复,其可以是指主UPF网元从故障状态转换为正常状态。
对于第一DN,其可以是在主UPF网元故障恢复之后,需要进行数据下行传输的数据网络。在一个实施例中,第一DN上可以设置第一传输数据(即下行数据)的下一跳路由。示例性地,第一DN可以在主UPF网元故障期间,将下一跳路由修改为容灾UPF网元,以及在故障恢复之后,将下一跳路由修改为主UPF网元。
可选地,第一DN的交换机与主UPF网元的N6接口之间,可以建立有通信隧道。第一DN可以通过通信隧道迅速感知主UPF网元的状态变化,在主UPF网元故障时,将路由表中的传输数据的下一跳路由修改为容灾UPR。以及在主UPF网元故障恢复之后,将路由表中的传输数据的下一跳路由修改为主UPR。
示例性地,该通信隧道可以是通用路由封装(Generic Routing Encapsulation,GRE)隧道。从而使得第一DN可以通过GRE隧道的keepalive机制,迅速感知主UPF网元的状态变化,从而可以根据该状态变化对路由表进行实时更新。
可选地,第一DN的交换机还可以与容灾UPF网元的N6之间建立通信隧道。该隧道的具体内容和功能可以参见主UPF网元的隧道的相关内容,在此不再赘述。
对于第一传输数据,其可以是第一DN需要向终端设备传输的数据。
对于步骤S310,在一个示例中,图4示出了在主UPF网元故障恢复之后的数据传输路径的示意图。如图4所示,虚线L41和实线L42示出了第一传输数据的两种可行传输路径。
如虚线L41和实线L42所示,第一DN41在主UPF网元111故障恢复之后,默认第一传输数据的下一跳路由为主UPF网元111,从而将第一传输数据沿着虚线L41或实线L42所示的路径传输至主UPF网元111。
S320,在主UPF网元上未创建有第一传输数据的会话的情况下,通过通信隧道将第一传输数据发送至容灾UPF网元,以使容灾UPF网元将第一传输数据转发至会话对应的第一终端设备。
在S320中,主UPF网元可以判断第一传输数据的会话是否创建于主UPF网元上。在该第一传输数据的会话未创建于主UPF网元的情况下,通过通信隧道将第一传输数据发送至容灾UPF网元。
对于第一终端设备,其可以是指会话创建于容灾UPF网元或者主UPF网元上的设备。示例性地,第一终端设备可以包括但不限于智能手机、平板电脑、膝上型便携计算机、台式计算机、可穿戴设备、增强现实设备、虚拟现实设备等,对此不作具体限定。
在一个实施例中,第一终端设备可以是配置有固定IP地址的终端设备,相应地,第一终端设备的会话均创建于容灾UPF网元和主UPF网元中的一者。示例性地,第一终端设备可以在容灾UPF网元和主UPF网元中选择一者上线。
对于第一传输数据的会话,其可以是指第一传输数据所归属的会话。在一些实施例中,可以根据第一传输数据的IP五元组确定其所属的会话。
对于会话是否创建于主UPF网元的方式,在一些实施例中,主UPF网元在接收到第一传输数据之后,判断第一传输数据的会话的会话上下文是否创建于主UPF网元上,来判断第一传输数据的会话是否创建于主UPF网元。需要说明的是,由于在UPF网元上创建会话时,均会记录该会话的上下文信息,因此通过查询会话上下文的方式能够准确判断会话是否创建于主UPF网元。
对于通信隧道,其可以是指主UPF网元和容灾UPF网元之间用于传输数据的隧道。可选地,可以在主UPF网元的N9接口与容灾UPF网元的N9接口之间建立该通信隧道。示例性地,通信隧道可以是GRE隧道、虚拟扩展局域网(Virtual Extensible Local AreaNetwork,VxLAN)隧道等,对此不作限定。
在一个示例中,为了提高方案的通用性,通信隧道可以是GRE隧道。
在该示例中,由于GRE隧道具有封装方便、网络设备支持广泛的优点,从而提高了本申请实施例的数据传输方案的通用性。
相较于N9接口连接公网的UPF网元的技术方案,本申请实施例可以通过N9接口实现传输数据在主UPF网元与容灾UPF网元之间的灵活中转。
对于S320,在一个示例中,继续参见图4,如虚线L41所示,第一主UPF网元111可以通过通信隧道将第一传输数据传输至容灾UPF网元112,然后由容灾UPF网元112将第一传输数据发送至基站31,然后由基站31发送至第一终端设备21。
本申请实施例所提供基于核心网的数据传输方法,可以在主UPF网元故障恢复之后,对于将会话创建于容灾UPF网元的第一终端设备,主UPF网元可以在接收第一DN发送的第一传输数据,可以通过主UPF网元和容灾UPF网元之间的通信隧道将其转发至容灾UPF网元,然后由容灾UPF网元将其发送至对应的第一终端设备。由于在UPF网元故障恢复之后,第一DN会将传输数据的下一跳路由默认为主UPF网元,相较于需要将故障期间在容灾UPF网元上创建的会话从容灾UPF网元下线并于主UPF网元重新上线的方案相比,本申请实施例通过主UPF网元向容灾UPF网元转发数据的方式,无需对故障期间在容灾UPF网元上创建的会话重新上下线,使得原有业务不受影响,从而保证了会话所对应的终端设备的使用用户的业务体验。
以及,还需要说明的是,在主UPF网元故障恢复之后,若SMF网元选择将新的会话建立于主UPF网元,则随着会话在使用过程中正常的不断下线与重新上线,最终所有业务回切到主UPF网元,从而业务可以自动无缝回迁,整个回迁过程无需人工介入。
在一些实施例中,在S310之后,方法还包括下述步骤A1。
步骤A1,在主UPF网元上创建有第一传输数据的会话的情况下,将第一传输数据发送至第一终端设备。
在一个实施例中,主UPF网元可以基于会话上下文中的基站标识,将第一传输数据发送至第一终端设备所连接的基站,然后由该基站将第一传输数据继续发送至第一终端设备。
在一个示例中,继续参见图4,该步骤A1中第一传输数据的传输路径如实线L42所示,第一传输数据在到达主UPF网元111之后,由主UPF网元111将第一传输数据发送至基站31,然后由基站31发送至第一终端设备21。
通过上述步骤A1,可以在主UPF网元故障恢复之后,可以使得容灾UPF网元上的原有业务以及主UPF网元上的新业务可以同时不间断运行,提高了用户的业务使用体验。
在一些实施例中,方法还包括下述步骤A2。
步骤A2,在主UPF网元故障恢复的情况下,接收第一终端设备发送的传输数据,以及根据路由信息将其发送至第一DN。
示例性地,继续参见图4,当第一终端设备上线于主UPF网元111上时,其上行数据的传输路径如实线L42所示。
可选地,在主UPF网元故障恢复的情况下,当第一终端设备上线于容灾UPF网元112上时,其上行数据的传输路径如点划线L43所示。
基于同一发明构思,图5示出了本申请实施例提供的另一种基于核心网的数据传输方法的流程示意图。该方法可以由上述容灾UPF网元执行。本申请实施例在上述实施例的基础上进行优化,本申请实施例可以与上述一个或者多个实施例中各个可选方案结合。
如图5所示,本申请实施例中提供的基于核心网的数据传输方法包括如下步骤S510和S520。
S510,在主UPF网元故障恢复的情况下,通过通信隧道接收主UPF网元发送的第一传输数据。其中,第一传输数据由第一DN发送至主UPF网元、且经主UPF网元确定其上未创建有第一传输数据所属会话。
其中,S510与S310类似,可以参见S310的具体内容,在此不再赘述。
S520,将第一传输数据发送至会话对应的第一终端设备。
在一些实施例中,可以根据会话的会话上下文信息确定基站标记,然后发送至第一终端设备所连接的基站,进而发送至第一终端设备。
其中,S520的其他内容与S320类似,可以参见S320的具体内容,在此不再赘述。
本申请实施例所提供的基于核心网的数据传输方法,可以在主UPF网元故障恢复之后,对于将会话创建于容灾UPF网元的第一终端设备,主UPF网元可以在接收第一DN发送的第一传输数据,可以通过主UPF网元和容灾UPF网元之间的通信隧道将其转发至容灾UPF网元,然后由容灾UPF网元将其发送至对应的第一终端设备。由于在UPF网元故障恢复之后,第一DN会将传输数据的下一跳路由默认为主UPF网元,相较于需要将故障期间在容灾UPF网元上创建的会话从容灾UPF网元下线并于主UPF网元重新上线的方案相比,本申请实施例通过主UPF网元向容灾UPF网元转发数据的方式,无需对故障期间在容灾UPF网元上创建的会话重新上下线,从而保证了会话所对应的终端设备的使用用户的业务体验。
在一个示例中,在第一终端设备上线于容灾UPF网元的情况下,方法还包括下述步骤B1。
步骤B1,在主UPF网元故障恢复的情况下,接收第一终端设备发送的传输数据,以及根据路由信息将其发送至第一DN。
需要说明的是,步骤B1可以参见上述步骤A2的相关说明,在此不再赘述。
为了整体上理解主UPF网元故障恢复之后的数据传输方案,接下来通过图6进行说明。
图6示出了本申请实施例提供的一种示例性的基于核心网的数据传输方法的流程示意图。
如图6所示,本申请实施例中提供的基于核心网的数据传输方法包括如下步骤S601至S605。
S601,第一DN向主UPF网元发送第一传输数据。
S602,主UPF网元判断第一传输数据的会话是否创建于本地(即主UPF网元)。
S603,若上述判断结果为是,则由主UPF网元向第一终端设备发送第一传输数据。
S604,若上述判断结果为否,主UPF网元通过通信隧道将第一传输数据转发至容灾UPF网元。
S605,容灾UPF网元将第一传输数据发送至第一终端设备。
在通过图3-图6说明了在主UPF网元故障恢复的情况下的数据传输方法之后,基于同一发明构思,本申请实施例还提供了一种在主UPF网元与第二DN之间的通信链路发生故障时的数据传输方案,接下来将通过图7-图10进行说明。
发明人通过研究发现,在相关技术中,若主UPF网元与DN之间的通信链路发生故障时,终端设备将会不停上下线,影响终端设备用户的业务体验。
基于此,发明人提出了一种终端设备-主UPF网元-容灾UPF网元-DN的传输路径,从而可以在主UPF网元与DN之间的通信链路故障,即主UPF网元的N6链路故障时,传输数据可以绕行容灾UPF网元的N6链路,使得终端设备用户的业务可以不受影响,进而提高用户业务体验的技术方案。
图7示出了示出本申请实施例中又一种基于核心网的数据传输方法流程图,该方法可以由上述主PUF网元执行。如图7所示,本申请实施例中提供的基于核心网的数据传输方法包括如下S710和S720。
S710,在主UPF网元与第二DN之间的通信链路发生故障的情况下,接收第二终端设备发送的、待传输至第二DN的第二传输数据。
对于主UPF网元与第二DN之间的通信链路的故障,即主UPF网元的N6链路故障,其可以是诸如N6接口故障、通信链路中断或者传输延迟过高等对数据传输产生影响的故障,对此不作具体限定。
对于第二DN,其可以和第一DN是同一网络,或者是不同网络。第二DN的具体内容可以参见本申请实施例上述部分对第一DN的相关说明,对此不作限定。
在一些实施例中,主UPF网元与第二DN之间的通信链路发生故障时,第二DN可以通过与主UPF网元之间的通信隧道快速感知到该故障,并自动切换至容灾UPF网元进行通信。
在一个实施例中,主UPF网元可以将路由表中下一跳路由从主UPF网元修改为容灾UPF网元的方式来实现快速切换至容灾UPF网元进行通信。
对于第二终端设备,其可以与第一终端设备为同一设备或者不同设备,对此不作具体限定。
第二终端设备的具体内容可以参见本申请实施例上述部分对第一终端设备的相关说明,对此不再赘述。
S720,通过通信隧道,将第二传输数据转发至容灾UPF网元,以使容灾UPF网元将第二传输数据发送至第二DN。
示例性地,容灾UPF网元可以查找第二传输数据的路由信息的方式,将第二传输数据发送至第二DN。
本申请实施例提供的基于核心网的数据传输方法,可以在主UPF网元与第二DN之间的通信链路发生故障的情况下,主UPF网元通过将第二传输数据转发至容灾UPF网元来传输至第二DN的方式,第二传输数据可以绕行容灾UPF网元的N6链路,进而对该故障进行容灾,从而使得终端设备用户的业务在主UPF网元与第二DN之间的通信链路发生故障时可以不受影响,进而提高用户业务体验。
在一个示例中,图8示出了在主UPF网元与第二DN之间的通信链路发生故障时的数据传输路径的示意图。如图8所示,实线L81示出了主UPF网元未发生N6链路故障时的传输路径,虚线L82示出了主UPF网元发生N6链路故障时的传输路径。
通过L81和L82对比可知,在N6故障时,SMF网元12仍然选择主UPF网元111进行终端设备的上线,第二DN 42将第二传输数据发送至容灾UPF网元112,然后经容灾UPF网元112将第二传输数据转发至主UPF网元111。主UPF网元111经过基站31将第二传输数据发送至第二终端设备22。
在一些实施例中,方法还可以包括下述N6链路故障下行时的数据传输步骤,即下述步骤C1和步骤C2。
步骤C1,在主UPF网元与第二DN之间的通信链路发生故障的情况下,通过通信隧道接收容灾UPF网元转发的、待传输至第二终端设备的第三传输数据。第三传输数据由第二DN发送至容灾UPF网元。
对于第三传输数据,其可以是第二终端设备需要向第二DN上传的数据。
步骤C2,将第三传输数据发送至第二终端设备。
其中,向第二终端设备发送第三传输数据的具体内容可以参见本申请实施例上述部分对UPF网元向终端设备发送传输数据的相关说明,在此不再赘述。
需要说明的是,步骤C1和步骤C2可以独立于上述S710和S720独立实施,可以与S710和S720协同实施,对此不作具体限定。
通过本实施例,在数据上行时,若主UPF网元的N6链路故障,则主UPF网元可以将第三传输数据发送至容灾UPF网元,然后由容灾UPF网元发送至第二DN,从而可以绕行故障的N6链路成功实现数据的传输,提高了用户业务体验。
基于同一发明构思,图9示出了本申请实施例提供的再一种基于核心网的数据传输方法的流程示意图。该方法可以由上述容灾UPF网元执行。本申请实施例在上述实施例的基础上进行优化,本申请实施例可以与上述一个或者多个实施例中各个可选方案结合。
如图9所示,本申请实施例中提供的基于核心网的数据传输方法包括如下步骤S910和S920。
S910,在主UPF网元与第二DN之间的通信链路发生故障的情况下,通过通信隧道接收主UPF网元转发的、待传输至第二DN的第二传输数据。其中,第二传输数据由第二终端设备发送。
其中,S910与S710类似,可以参见S710的具体内容,在此不再赘述。
S920,将第二传输数据发送至第二DN。
其中,S920与S720类似,可以参见S720的具体内容,在此不再赘述。
本申请实施例提供的基于核心网的数据传输方法,可以在主UPF网元与第二DN之间的通信链路发生故障的情况下,主UPF网元通过将第二传输数据转发至容灾UPF网元来传输至第二DN的方式,第二传输数据可以绕行容灾UPF网元的N6链路,进而对该故障进行容灾,从而使得终端设备用户的业务在主UPF网元与第二DN之间的通信链路发生故障时可以不受影响,进而提高用户业务体验。
在一些实施例中,方法还包括步骤D1和步骤D2。
步骤D1,在主UPF网元与第二DN之间的通信链路发生故障的情况下,接收第二DN发送的第三传输数据。
其中,步骤D1与步骤C1类似,可以参见步骤C1的具体内容,在此不再赘述。
步骤D2,将第三传输数据转发至主UPF网元,以使主UPF网元将第三传输数据发送至第二终端设备。
其中,步骤D2与步骤C2类似,可以参见步骤C2的具体内容,在此不再赘述。
需要说明的是,步骤D1和步骤D2可以独立于上述S910和S920独立实施,可以与S910和S920协同实施,对此不作具体限定。
示例性地,为了整体上理解主UPF网元发生N6故障时的数据传输方案,接下来通过图10进行说明。
图10示出了本申请实施例提供的另一种示例性的基于核心网的数据传输方法的流程示意图。
如图10所示,本申请实施例中提供的基于核心网的数据传输方法包括如下步骤S1001至S1006。
S1001,主UPF网元接收第二终端设备发送的第二传输数据。
S1002,主UPF网元通过通信隧道将第二传输数据转发至容灾UPF网元。
S1003,容灾UPF网元将第二传输数据发送至第二DN。
S1004,第二DN向主UPF网元发送第三传输数据。
S1005,主UPF网元通过通信隧道将第三传输数据转发至容灾UPF网元。
S1006,容灾UPF网元将第三传输数据发送至第二终端设备。
需要说明的是,本示例对S1001-S1003、S1004-S1006彼此之间的先后次序不作具体限定。
在通过图7-图10说明了在主UPF网元的N6故障时的情况下的数据传输方法之后,基于同一发明构思,本申请实施例还提供了一种在主UPF网元与SMF网元之间的通信链路发生故障时的数据传输方案,接下来将通过图11-图14进行说明。
在相关技术中,若主UPF网元与SMF网元之间的通信链路发生故障,即发生主UPF网元的N4链路故障时,将无法继续为新上线的终端设备提供服务。
发明人通过研究发现,N4链路故障发生之后新上线的终端设备可以于容灾UPF网元上线。基于此,发明人提出了一种在N4链路故障发生之后,主UPF网元可以在接收到DN发送的传输数据之后,向容灾UPF网元转发传输数据以进一步传输至上线于容灾UPF网元的终端设备上。从而可以对N4链路故障进行容灾的技术方案。
图11示出了示出本申请实施例中又一种基于核心网的数据传输方法流程图,该方法可以由上述主PUF网元执行。如图11所示,本申请实施例中提供的基于核心网的数据传输方法包括如下S1110和S1120。
S1110,在主UPF网元与SMF网元之间的通信链路发生故障的情况下,接收第三DN发送的第四传输数据。
对于主UPF网元与SMF网元之间的通信链路的故障,即主UPF网元的N4链路故障,其可以是诸如N4接口故障、通信链路中断或者传输延迟过高等对数据传输产生影响的故障,对此不作具体限定。
对于第四传输数据,其可以是第三DN需要下行传输至第四终端设备的数据。
对于第三DN,其可以和第一DN、第二DN是同一网络,或者是不同网络。第三DN的具体内容可以参见本申请实施例上述部分对第一DN、第二DN的相关说明,对此不作限定。
在一些实施例中,在主UPF网元发送N4故障时,第三DN可以确定第四传输数据的下一跳路由为主UPF。
需要说明的是,S1110与上述S310类似,可以参见S310的相关内容,对此不再赘述。
S1120,在第四传输数据所属会话未创建于主UPF网元的情况下,通过通信隧道将第四传输数据转发至容灾UPF网元,以使容灾UPF网元将第四传输数据发送至第四传输数据所属会话对应的第三终端设备。
对于第三终端设备,其可以是需要向第二DN上传数据的终端设备。需要说明的是,第二终端设备可以与上述设备为同一设备,或者不同设备,对此不再赘述。
第三终端设备的其他内容可以参见本申请实施例上述部分对第一终端设备和第二终端设备的相关说明,在此不再赘述。
需要说明的是,S1120与上述S320类似,可以参见S320的相关内容,对此不再赘述。
本申请实施例提供的基于核心网的数据传输方法,可以在主UPF网元与SMF网元之间的通信链路发生故障的情况下,即主UPF网元发生N4链路故障的情况下,主UPF网元可以在接收到DN发送的传输数据之后,向容灾UPF网元转发传输数据以进一步传输至需要上线于容灾UPF网元的终端设备上,从而可以对N4链路故障进行容灾。
以及,在一些实施例中,在N4故障恢复之后,可以随着会话在使用过程中正常的不断下线与重新上线,最终所有业务回迁到主UPF网元,从而业务可以自动无缝回迁,整个回迁过程无需人工介入。
在一些实施例中,在S1110之后,方法还包括下述步骤E1。
步骤E1,在第四传输数据所属会话创建于主UPF网元的情况下,将第四传输数据发送至第三终端设备。
需要说明的是,步骤E1与步骤A1类似,可以参见本申请实施例上述部分对步骤A1的相关描述,对此不再赘述。
在一个示例中,图12示出了在主UPF网元与SMF网元之间的通信链路发生故障时的数据传输路径的示意图。
如图12所示,在第三终端设备23上线于容灾UPF网元112的情况下,第四传输数据的传输路径可以如虚线L121所示。
在第三终端设备23上线于主UPF网元111的情况下,第四传输数据的传输路径可以如实现L122所示。
具体地,第三DN 43将第四传输数据发送至主UPF网元111之后,若第四传输数据所属会话创建于主UPF网元111,则继续沿着实线L122传输至基站32,继而传输至第三终端设备23。同理地,若第四传输数据所属会话创建于容灾UPF网元112,则沿着通信隧道传输至容灾UPF网元112,然后由容灾UPF网元112继续沿着虚线L121传输至基站32,继而传输至第三终端设备23。
通过上述步骤E1,在N4链路故障期间,可以使得主UPF网元上的原有业务以及容灾UPF网元上的新业务可以同时不间断运行,提高了用户的业务使用体验。
在一些实施例中,方法还包括下述步骤E2。
步骤E2,在主UPF网元与SMF网元之间的通信链路发生故障的情况下,接收第三终端设备发送的第五传输数据,以及根据路由信息将其发送至第一DN。
示例性地,继续参见图12,当第三终端设备上线于主UPF网元111上时,其上行数据的传输路径如实线L122所示。
可选地,当第一终端设备上线于容灾UPF网元112上时,其上行数据的传输路径如点划线L123所示。
基于同一发明构思,图13示出了本申请实施例提供的再一种基于核心网的数据传输方法的流程示意图。该方法可以由上述容灾UPF网元执行。本申请实施例在上述实施例的基础上进行优化,本申请实施例可以与上述一个或者多个实施例中各个可选方案结合。
如图13所示,本申请实施例中提供的基于核心网的数据传输方法包括如下步骤S1310和S1320。
S1310,在主UPF网元与SMF网元之间的通信链路发生故障的情况下,接收主UPF网元发送的第四传输数据,其中,第四传输数据由第三DN发送至主UPF网元、且经主UPF网元确定其上未创建有第四传输数据所属会话。
其中,S1310与S1110类似,可以参见S1110的具体内容,在此不再赘述。
S1320,将第四传输数据发送至会话对应的第三终端设备。
其中,S1320与S1120类似,可以参见S1120的具体内容,在此不再赘述。
本申请实施例提供的基于核心网的数据传输方法,可以在主UPF网元与SMF网元之间的通信链路发生故障的情况下,即主UPF网元发生N4链路故障的情况下,主UPF网元可以在接收到DN发送的传输数据之后,向容灾UPF网元转发传输数据以进一步传输至需要上线于容灾UPF网元的终端设备上,从而可以对N4链路故障进行容灾。
在一个示例中,在第一终端设备上线于容灾UPF网元的情况下,方法还包括下述步骤F1。
步骤F1,在主UPF网元与SMF网元之间的通信链路发生故障的情况下接收第三终端设备发送的传输数据,以及根据路由信息将其发送至第三DN。
需要说明的是,步骤F1可以参见上述步骤E2的相关说明,在此不再赘述。
为了整体上理解主UPF网元与SMF网元之间的通信链路发生故障时的数据传输方案,接下来通过图14进行说明。
图14示出了本申请实施例提供的又一种示例性的基于核心网的数据传输方法的流程示意图。
如图14所示,本申请实施例中提供的基于核心网的数据传输方法包括如下步骤S1401至S1405。
S1401,第三DN向主UPF网元发送第四传输数据。
S1402,主UPF网元判断第四传输数据的会话是否创建于本地(即主UPF网元)。
S1403,若上述判断结果为是,则由主UPF网元向第三终端设备发送第四传输数据。
S1404,若上述判断结果为否,主UPF网元通过通信隧道将第四传输数据转发至容灾UPF网元。
S1405,容灾UPF网元将第四传输数据发送至第三终端设备。
在通过上述图3-图14说明了本申请实施例提供的基于核心网的数据传输方法之后,接下来对主UPF网元和容灾UPF网元的具体结构进行说明。
基于同一发明构思,本申请实施例中还提供了一种主UPF网元,如下面的实施例。图15示出本申请实施例中一种主UPF网元的结构示意图,如图15所示,该主UPF网元1500包括:数据接收模块1510和数据转发模块1520。
数据接收模块1510,用于在主UPF网元故障恢复的情况下,接收第一数据网络DN发送的第一传输数据;
数据转发模块1520,用于在主UPF网元上未创建有第一传输数据的会话的情况下,通过通信隧道将第一传输数据转发至容灾UPF网元,以使容灾UPF网元将第一传输数据发送至会话对应的第一终端设备。
在一些实施例中,主UPF网元1500还包括数据发送模块。
数据发送模块,用于在主UPF网元上创建有第一传输数据的会话的情况下,将第一传输数据发送至第一终端设备。
在一些实施例中,数据接收模块1510还用于在主UPF网元与第二DN之间的通信链路发生故障的情况下,接收第二终端设备发送的、待传输至第二DN的第二传输数据;
数据转发模块1520还用于通过通信隧道,将第二传输数据转发至容灾UPF网元,以使容灾UPF网元将第二传输数据发送至第二DN。
在一些实施例中,数据接收模块1510还用于在主UPF网元与第二DN之间的通信链路发生故障的情况下,通过通信隧道接收容灾UPF网元转发的、待传输至第二终端设备的第三传输数据,第三传输数据由第二DN发送至容灾UPF网元;
主UPF网元1500还包括数据发送模块。数据发送模块,用于将第三传输数据发送至第二终端设备。
在一些实施例中,数据接收模块1510还用于在主UPF网元与SMF网元之间的通信链路发生故障的情况下,接收第三DN发送的第四传输数据;
数据转发模块1520还用于在第四传输数据所属会话未创建于主UPF网元的情况下,通过通信隧道将第四传输数据转发至容灾UPF网元,以使容灾UPF网元将第四传输数据发送至第四传输数据所属会话对应的第三终端设备。
在一些实施例中,主UPF网元1500还包括数据发送模块。
数据发送模块,用于在第四传输数据所属会话创建于主UPF网元的情况下,将第四传输数据发送至第三终端设备。
本申请实施例所提供的主UPF网元,可以在主UPF网元故障恢复之后,对于将会话创建于容灾UPF网元的第一终端设备,主UPF网元可以在接收第一DN发送的第一传输数据,可以通过主UPF网元和容灾UPF网元之间的通信隧道将其转发至容灾UPF网元,然后由容灾UPF网元将其发送至对应的第一终端设备。由于在UPF网元故障恢复之后,第一DN会将传输数据的下一跳路由默认为主UPF网元,相较于需要将故障期间在容灾UPF网元上创建的会话从容灾UPF网元下线并于主UPF网元重新上线的方案相比,本申请实施例通过主UPF网元向容灾UPF网元转发数据的方式,无需对故障期间在容灾UPF网元上创建的会话重新上下线,从而保证了会话所对应的终端设备的使用用户的业务体验。
需要说明的是,图15所示的主UPF网元1500可以执行图3、图7、图11所示的方法实施例中的各个步骤,并且实现图3、图7、图11所示的方法实施例中的各个过程和效果,在此不做赘述。
基于同一发明构思,本申请实施例中还提供了一种容灾UPF网元,如下面的实施例。图16示出本申请实施例中一种容灾UPF网元的结构示意图,如图16所示,该容灾UPF网元1600包括:数据接收模块1610和数据发送模块1620。
数据接收模块1610,用于在主UPF网元故障恢复的情况下,通过通信隧道接收主UPF网元发送的第一传输数据,其中,第一传输数据由第一DN发送至主UPF网元、且经主UPF网元确定其上未创建有第一传输数据所属会话;
数据发送模块1620,用于将第一传输数据发送至会话对应的第一终端设备。
在一些实施例中,数据接收模块1610还用于在主UPF网元与第二DN之间的通信链路发生故障的情况下,通过通信隧道接收主UPF网元转发的、待传输至第二DN的第二传输数据,其中,第二传输数据由第二终端设备发送;
数据发送模块1620还用于将第二传输数据发送至第二DN。
在一些实施例中,数据接收模块1610还用于在主UPF网元与第二DN之间的通信链路发生故障的情况下,接收第二DN发送的第三传输数据;
以及,该容灾UPF网元1600还包括数据转发模块。数据转发模块用于将第三传输数据转发至主UPF网元,以使主UPF网元将第三传输数据发送至第二终端设备。
在一些实施例中,数据接收模块1610还用于在主UPF网元与SMF网元之间的通信链路发生故障的情况下,接收主UPF网元发送的第四传输数据,其中,第四传输数据由第三DN发送至主UPF网元、且经主UPF网元确定其上未创建有第四传输数据所属会话;
数据发送模块1620还用于将第四传输数据发送至会话对应的第三终端设备。
本申请实施例所提供的容灾UPF网元,可以在主UPF网元故障恢复之后,对于将会话创建于容灾UPF网元的第一终端设备,主UPF网元可以在接收第一DN发送的第一传输数据,可以通过主UPF网元和容灾UPF网元之间的通信隧道将其转发至容灾UPF网元,然后由容灾UPF网元将其发送至对应的第一终端设备。由于在UPF网元故障恢复之后,第一DN会将传输数据的下一跳路由默认为主UPF网元,相较于需要将故障期间在容灾UPF网元上创建的会话从容灾UPF网元下线并于主UPF网元重新上线的方案相比,本申请实施例通过主UPF网元向容灾UPF网元转发数据的方式,无需对故障期间在容灾UPF网元上创建的会话重新上下线,从而保证了会话所对应的终端设备的使用用户的业务体验。
需要说明的是,图16所示的容灾UPF网元1600可以执行图5、图9、图13所示的方法实施例中的各个步骤,并且实现图5、图9、图13所示的方法实施例中的各个过程和效果,在此不做赘述。
以及还需要说明的是,在同一UPF网元可以实现主UPF网元和容灾UPF网元的功能时,其可以包括主UPF网元和容灾UPF网元功能模块,对此不再赘述。
所属技术领域的技术人员能够理解,本申请的各个方面可以实现为***、方法或程序产品。因此,本申请的各个方面可以具体实现为以下形式,即:完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等),或硬件和软件方面结合的实施方式,这里可以统称为“电路”、“模块”或“***”。
下面参照图17来描述根据本申请的这种实施方式的电子设备1700。图17显示的电子设备1700仅仅是一个示例,不应对本申请实施例的功能和使用范围带来任何限制。
如图17所示,电子设备1700以通用计算设备的形式表现。电子设备1700的组件可以包括但不限于:上述至少一个处理单元1710、上述至少一个存储单元1720、连接不同***组件(包括存储单元1720和处理单元1710)的总线1730。
其中,存储单元存储有程序代码,程序代码可以被处理单元1710执行,使得处理单元1710执行本说明书上述“示例性方法”部分中描述的根据本申请各种示例性实施方式的步骤。
存储单元1720可以包括易失性存储单元形式的可读介质,例如随机存取存储单元(RAM)17201和/或高速缓存存储单元17202,还可以进一步包括只读存储单元(ROM)17203。
存储单元1720还可以包括具有一组(至少一个)程序模块17205的程序/实用工具17204,这样的程序模块17205包括但不限于:操作***、一个或者多个应用程序、其它程序模块以及程序数据,这些示例中的每一个或某种组合中可能包括网络环境的实现。
总线1730可以为表示几类总线结构中的一种或多种,包括存储单元总线或者存储单元控制器、***总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。
电子设备1700也可以与一个或多个外部设备1740(例如键盘、指向设备、蓝牙设备等)通信,还可与一个或者多个使得用户能与该电子设备1700交互的设备通信,和/或与使得该电子设备1700能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1750进行。
并且,电子设备1700还可以通过网络适配器1760与一个或者多个网络(例如局域网(LAN),广域网(WAN)和/或公共网络,例如因特网)通信。
如图17所示,网络适配器1760通过总线1730与电子设备1700的其它模块通信。
应当明白,尽管图中未示出,可以结合电子设备1700使用其它硬件和/或软件模块,包括但不限于:微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID***、磁带驱动器以及数据备份存储***等。
通过以上的实施方式的描述,本领域的技术人员易于理解,这里描述的示例实施方式可以通过软件实现,也可以通过软件结合必要的硬件的方式来实现。因此,根据本申请实施方式的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中或网络上,包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本申请实施方式的方法。
在本申请的示例性实施例中,还提供了一种计算机可读存储介质,该计算机可读存储介质可以是可读信号介质或者可读存储介质。其上存储有能够实现本申请上述方法的程序产品。
在一些可能的实施方式中,本申请的各个方面还可以实现为一种程序产品的形式,其包括程序代码,当程序产品在终端设备上运行时,程序代码用于使终端设备执行本说明书上述“示例性方法”部分中描述的根据本申请各种示例性实施方式的步骤。
本申请中的计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
在本申请中,计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了可读程序代码。
这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。
可读信号介质还可以是可读存储介质以外的任何可读介质,该可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。
在一些示例中,计算机可读存储介质上包含的程序代码可以用任何适当的介质传输,包括但不限于无线、有线、光缆、RF等等,或者上述的任意合适的组合。
在具体实施时,可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码,程序设计语言包括面向对象的程序设计语言—诸如Java、C++等,还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。
程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。
在涉及远程计算设备的情形中,远程计算设备可以通过任意种类的网络,包括局域网(LAN)或广域网(WAN),连接到用户计算设备,或者,可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
应当注意,尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元,但是这种划分并非强制性的。
实际上,根据本申请的实施方式,上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之,上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
此外,尽管在附图中以特定顺序描述了本申请中方法的各个步骤,但是,这并非要求或者暗示必须按照该特定顺序来执行这些步骤,或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的,可以省略某些步骤,将多个步骤合并为一个步骤执行,以及/或者将一个步骤分解为多个步骤执行等。
通过以上实施方式的描述,本领域的技术人员易于理解,这里描述的示例实施方式可以通过软件实现,也可以通过软件结合必要的硬件的方式来实现。
因此,根据本申请实施方式的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中或网络上,包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本申请实施方式的方法。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。
本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由所附的权利要求指出。

Claims (14)

1.一种基于核心网的数据传输方法,其特征在于,所述核心网包括主用户面功能UPF网元和容灾UPF网元,所述主UPF网元与所述容灾UPF网元之间设置有通信隧道,所述方法应用于所述主UPF网元,包括:
在所述主UPF网元故障恢复的情况下,接收第一数据网络DN发送的第一传输数据;
在所述主UPF网元上未创建有所述第一传输数据的会话的情况下,通过所述通信隧道将所述第一传输数据转发至所述容灾UPF网元,以使所述容灾UPF网元将所述第一传输数据发送至所述会话对应的第一终端设备。
2.根据权利要求1所述的方法,其特征在于,在所述接收第一数据网络DN发送的第一传输数据之后,所述方法还包括:
在所述主UPF网元上创建有所述第一传输数据的会话的情况下,将所述第一传输数据发送至所述第一终端设备。
3.根据权利要求1所述的方法,其特征在于,所述方法还包括:
在所述主UPF网元与第二DN之间的通信链路发生故障的情况下,接收第二终端设备发送的、待传输至所述第二DN的第二传输数据;
通过所述通信隧道,将所述第二传输数据转发至所述容灾UPF网元,以使所述容灾UPF网元将所述第二传输数据发送至所述第二DN。
4.根据权利要求1或3所述的方法,其特征在于,所述方法还包括:
在所述主UPF网元与第二DN之间的通信链路发生故障的情况下,通过所述通信隧道接收所述容灾UPF网元转发的、待传输至第二终端设备的第三传输数据,所述第三传输数据由所述第二DN发送至所述容灾UPF网元;
将所述第三传输数据发送至所述第二终端设备。
5.根据权利要求1或3所述的方法,其特征在于,所述方法还包括:
在所述主UPF网元与SMF网元之间的通信链路发生故障的情况下,接收第三DN发送的第四传输数据;
在所述第四传输数据所属会话未创建于所述主UPF网元的情况下,通过所述通信隧道将所述第四传输数据转发至所述容灾UPF网元,以使所述容灾UPF网元将所述第四传输数据发送至所述第四传输数据所属会话对应的第三终端设备。
6.根据权利要求5所述的方法,其特征在于,在所述接收第三DN发送的第四传输数据之后,所述方法还包括:
在所述第四传输数据所属会话创建于所述主UPF网元的情况下,将所述第四传输数据发送至所述第三终端设备。
7.一种基于核心网的数据传输方法,其特征在于,所述核心网包括主用户面功能UPF网元和容灾UPF网元,所述主UPF网元与所述容灾UPF网元之间设置有通信隧道,所述方法应用于所述容灾UPF网元,包括:
在所述主UPF网元故障恢复的情况下,通过所述通信隧道接收所述主UPF网元发送的第一传输数据,其中,所述第一传输数据由第一DN发送至所述主UPF网元、且经所述主UPF网元确定其上未创建有所述第一传输数据所属会话;
将所述第一传输数据发送至所述会话对应的第一终端设备。
8.根据权利要求7所述的方法,其特征在于,所述方法还包括:
在所述主UPF网元与第二DN之间的通信链路发生故障的情况下,通过所述通信隧道接收所述主UPF网元转发的、待传输至第二DN的第二传输数据,其中,所述第二传输数据由第二终端设备发送;
将所述第二传输数据发送至所述第二DN。
9.根据权利要求8所述的方法,其特征在于,所述方法还包括:
在所述主UPF网元与第二DN之间的通信链路发生故障的情况下,接收第二DN发送的第三传输数据;
将所述第三传输数据转发至所述主UPF网元,以使所述主UPF网元将所述第三传输数据发送至所述第二终端设备。
10.根据权利要求7或8所述的方法,其特征在于,所述方法还包括:
在所述主UPF网元与SMF网元之间的通信链路发生故障的情况下,接收主UPF网元发送的第四传输数据,其中,所述第四传输数据由第三DN发送至所述主UPF网元、且经所述主UPF网元确定其上未创建有所述第四传输数据所属会话;
将所述第四传输数据发送至所述会话对应的第三终端设备。
11.一种主UPF网元,其特征在于,所述主UPF网元所属核心网还包括容灾UPF网元,所述主UPF网元与所述容灾UPF网元之间设置有通信隧道,所述主UPF网元包括:
数据接收模块,用于在所述主UPF网元故障恢复的情况下,接收第一数据网络DN发送的第一传输数据;
数据转发模块,用于在所述主UPF网元上未创建有所述第一传输数据的会话的情况下,通过所述通信隧道将所述第一传输数据转发至所述容灾UPF网元,以使所述容灾UPF网元将所述第一传输数据发送至所述会话对应的第一终端设备。
12.一种容灾UPF网元,其特征在于,所述容灾UPF网元所属核心网还包括主UPF网元,所述主UPF网元与所述容灾UPF网元之间设置有通信隧道,所述容灾UPF网元包括:
数据接收模块,用于在所述主UPF网元故障恢复的情况下,通过所述通信隧道接收所述主UPF网元发送的第一传输数据,其中,所述第一传输数据由第一DN发送至所述主UPF网元、且经所述主UPF网元确定其上未创建有所述第一传输数据所属会话;
数据发送模块,用于将所述第一传输数据发送至所述会话对应的第一终端设备。
13.一种电子设备,其特征在于,包括:
处理器;以及
存储器,用于存储所述处理器的可执行指令;
其中,所述处理器配置为经由执行所述可执行指令来执行权利要求1-10中任意一项所述的基于核心网的数据传输方法。
14.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1-10中任意一项所述的基于核心网的数据传输方法。
CN202210593645.5A 2022-05-27 2022-05-27 Upf网元、基于核心网的数据传输方法、设备及介质 Active CN115022909B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210593645.5A CN115022909B (zh) 2022-05-27 2022-05-27 Upf网元、基于核心网的数据传输方法、设备及介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210593645.5A CN115022909B (zh) 2022-05-27 2022-05-27 Upf网元、基于核心网的数据传输方法、设备及介质

Publications (2)

Publication Number Publication Date
CN115022909A CN115022909A (zh) 2022-09-06
CN115022909B true CN115022909B (zh) 2024-01-30

Family

ID=83071515

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210593645.5A Active CN115022909B (zh) 2022-05-27 2022-05-27 Upf网元、基于核心网的数据传输方法、设备及介质

Country Status (1)

Country Link
CN (1) CN115022909B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116390272B (zh) * 2023-04-11 2024-04-19 广州爱浦路网络技术有限公司 5g核心网pfcp-gw实现upf控制的方法、装置以及电子设备
CN116367204B (zh) * 2023-05-31 2023-09-12 阿里巴巴(中国)有限公司 用户设备业务处理方法、电子设备、存储介质及***

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020253627A1 (zh) * 2019-06-18 2020-12-24 ***通信有限公司研究院 局域网隧道建立、释放的方法及设备
CN113573344A (zh) * 2021-06-21 2021-10-29 深圳震有科技股份有限公司 一种基于5g的smf会话检测方法及终端
WO2022042466A1 (zh) * 2020-08-31 2022-03-03 华为技术有限公司 一种故障恢复方法及装置
CN114465948A (zh) * 2022-02-16 2022-05-10 中国电信股份有限公司 主备容灾方法、装置、设备及介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020253627A1 (zh) * 2019-06-18 2020-12-24 ***通信有限公司研究院 局域网隧道建立、释放的方法及设备
WO2022042466A1 (zh) * 2020-08-31 2022-03-03 华为技术有限公司 一种故障恢复方法及装置
CN113573344A (zh) * 2021-06-21 2021-10-29 深圳震有科技股份有限公司 一种基于5g的smf会话检测方法及终端
CN114465948A (zh) * 2022-02-16 2022-05-10 中国电信股份有限公司 主备容灾方法、装置、设备及介质

Also Published As

Publication number Publication date
CN115022909A (zh) 2022-09-06

Similar Documents

Publication Publication Date Title
CN115022909B (zh) Upf网元、基于核心网的数据传输方法、设备及介质
WO2017036288A1 (zh) 一种网元升级方法及设备
US20230132861A1 (en) Switching method and apparatus, device, and storage medium
CN102970160B (zh) 一种辅助监控终端和备用服务器快速通信的方法和装置
CN113315665B (zh) 一种双网卡终端设备的报文发送方法、装置、设备及介质
CN111988222A (zh) 数据传输方法及装置、电子设备和计算机可读存储介质
CN114465948B (zh) 主备容灾方法、装置、设备及介质
CN110895469A (zh) 双机热备***的升级方法、装置及电子设备和存储介质
CN111741508B (zh) 建立通信连接的方法、控制器、转发设备、设备及介质
EP3695569B1 (en) A system and method for providing a layer 2 fast re-switch for a wireless controller
CN108900441B (zh) 网络切换方法、第一电子设备及可读存储介质
CN110391987B (zh) 从运营商边缘设备集合中选择指定转发器的方法、设备及计算机可读介质
CN101217293B (zh) 媒体业务托管切换***及方法
CN109379292A (zh) 一种组播方法、虚拟交换机、sdn控制器及存储介质
CN115396489A (zh) Upf容灾方法、装置、电子设备及计算机可读存储介质
CN112492634B (zh) 一种基于移动网络的传输ptn逃生电路实现方法及装置
CN114302463A (zh) 网络切换方法、***、设备及存储介质
CN114302453A (zh) 网元切换方法及装置、存储介质及电子设备
CN114157606A (zh) 虚拟网元设备切换方法、设备和存储介质
CN114727324B (zh) 网络容灾处理方法、装置、存储介质及电子设备
JP2013527648A (ja) 緊急時用切り替え方法及びそのシステム
WO2024147385A1 (ko) 릴레이 서버를 통한 파일의 전송
WO2023233666A1 (ja) 無瞬断冗長切替装置、無瞬断冗長切替方法、無瞬断冗長切替システム、及びプログラム
KR102157538B1 (ko) 가상화 네트워크 장치 또는 시스템의 소프트웨어 갱신을 위한 시스템 및 그 방법
CN114980232B (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