具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义,“多种”一般包含至少两种,但是不排除包含至少一种的情况。
应当理解,本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
取决于语境,如在此所使用的词语“如果”、“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于识别”。类似地,取决于语境,短语“如果确定”或“如果识别(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当识别(陈述的条件或事件)时”或“响应于识别(陈述的条件或事件)”。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的商品或者系统不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。
下面结合附图对本发明的一些实施方式作详细说明。在各实施例之间不冲突的情况下,下述的实施例及实施例中的特征可以相互组合。另外,下述各方法实施例中的步骤时序仅为一种举例,而非严格限定。
为了便于方案理解,可以先从整个通信系统的角度进行描述。则图1为本发明实施例提供的一种通信系统的结构示意图。如图1所示,该通信系统可以包括:容器编排工具、内存数据库以及核心网中不同功能网元各自对应的网元实例。
可选地,容器编排工具可以是Kubernetes,简称K8s或者Docker Swarm等。
可选地,内存数据库可以是位于内存中的数据库,比如可以是Redis数据库、Memcached数据库等等。使用内存数据库能够保证网元实例从数据库中读取和写入数据的速度。
可选地,核心网的网络架构可以如图2所示。核心网具体可以包括:网络切片选择功能(Network Slice Selection Function ,简称NSSF)网元、网络暴露功能(NetworkExposure Function,简称NEF)网元、网络存储库功能(Network Repository Function,简称NRF)网元、策略控制功能(Policy Control Function ,简称PCF)网元、统一数据管理(Unified Data Management,简称UDM)网元、鉴权服务功能(Authentication ServerFunction,简称AUSF)网元、接入和移动性管理功能(Access and Mobility ManagementFunction,简称AMF)网元、会话管理功能(Session Management Function,简称SMF)网元以及移动性管理功能(Mobility Management Function,简称MMF)网元。上述各网元可以称为控制面功能网元。核心网还可以包括用户面功能(User Plane Function,简称UPF)网元。
其中,核心网中的每个功能网元可以包括多个网元实例,也就是说每个功能网元都可以认为是由多个网元实例构成的网元实例集群,可以由集群中的某一网元实例响应终端设备发送的信令。
基于上述描述,通信系统的具体工作过程可以描述为:
终端设备发送的第一信令可以借助基站和交换机传输至核心网,容器编排工具可以确定核心网中的第一功能网元,并进一步在第一功能网元对应的网元实例集群中确定第一网元实例,以由此第一网元实例响应第一信令,从而得到第一信令的响应状态。并且第一网元实例还可以将第一信令的响应状态写入通信系统的内存数据库中。可选地,第一网元实例可以是第一功能网元对应的所有网元实例中任一网元实例。第一信令的响应状态可以包括正常响应和异常响应。异常响应可以是信令未被响应,被丢弃。
在第一信令发送后,终端设备还可以产生第二信令并将其发送至核心网。容器编排工具同样可以在第二功能网元对应的网元实例中确定用于响应第二信令的第二网元实例。可选地,第二网元实例也可以是第二功能网元对应的所有网元实例中任一网元实例。
第二信令的具体响应过程可以为:第二网元实例可以先从内存数据库中读取第一信令的响应状态,再根据读取到的响应状态对第二信令进行响应,以得到第二信令的响应状态。可见,第一信令的响应状态直接影响到第二信令的响应状态,这种影响可以具体体现为:若第一信令的响应状态为正常响应,则第二网元实例可以正常对第二信令进行响应,即第二信令的响应状态为正常响应。若第一信令的响应状态为异常响应,则第二网元实例可以直接丢弃第二信令,不对其进行响应,则第二信令的响应状态为异常响应。并且第二网元实例也可以将第二信令的响应状态写入内存数据库中。
根据上述描述可知,第二信令需要在正常响应第一信令后才能被正常响应,则可以认两信令之间具有先后响应关系。并且可选地,用于分别响应第一信令和第二信令的第一网元实例和第二网元实例可以属于相同或不同的网元实例集群,即对应于相同或不同的功能网元。
举例来说,第一信令可以是终端设备向核心网发送的接入信令,该接入信令可以被容器编排工具选中的、AMF网元中的网元实例1正常响应,并由网元实例1向终端设备返回待认证信令。终端设备可以再向核心网发送认证信令(即第二信令),由于网元实例1已经正常响应上述的接入信令,则该认证信令同样可以被容器编排工具选中的、AMF网元中的网元实例2正常响应,并由网元实例2向终端设备返回认证通过信令。上述过程中,用于响应接入信令和认证信令的网元实例1和网元实例2来源于同一网元实例集群,并且网元实例1和网元实例2可以是AMF网元对应的相同或不同的网元实例。
又举例来说,第一信令可以是认证信令,该认证信令可以由AMF网元中的网元实例1正常响应。第二信令可以是终端设备发送的会话建立信令,由于认证信令已经被正常响应,则该会话建立信令可以由SMF网元中的网元实例2进行响应。上述过程中,响应认证信令和会话建立信令的网元实例属于不同网元实例集群。
除了上述举例外,终端设备发送的信令可以是需要控制面功能网元进行响应的各种信令。
本实施例中,当第一信令传输至通信系统中的核心网后,通信系统中的容器编排工具会在核心网中包含的第一功能网元对应的各网元实例中,确定第一网元实例。此第一网元实例响应第一信令,并将第一信令的响应状态写入通信系统的内存数据库中。在第二信令又传输至核心网后,容器编排工具可以进一步确定第二功能网元的第二网元实例。以由此第二网元实例根据从内存数据库中读取第一信令的响应状态来响应第二信令。
本实施例中,可以利用独立的容器编排工具确定用于响应信令的网元实例,即利用独立的工具实现网元实例的调度。相比于由核心网中的目标网元实例进行网元实例调度,本实施例能够改善当目标网元实例故障时,由于网元实例无法调度而导致信令无法响应的情况,从而提高核心网的可用性。同时,省去了目标网元实例的选择过程,也减轻了目标网元实例的工作压力。另外,第一信令的响应状态会被写入内存数据库,则第二功能网元的各个网元实例都能够通过主动读取内存数据库了解第一信令的响应状态,使得第二功能网元中的每个网元实例都能够根据第一信令的响应状态来响应第二信令,即任一网元实例出现故障都不会影响第二信令的正常响应,从而提高核心网的可用性。
另外,相比于图1所示实施例的通信系统,一种更常见的方式,假设第一网元实例响应第一信令后,并由此第一网元实例将第一信令的响应状态通知给第二功能网元中的部分网元实例,则只有此部分网元实例才能响应第二信令。此时,若部分网元实例发生故障,则第二信令便无法进行响应,从而降低核心网的可用性。同时,响应状态的通知需要第一网元实例主动进行,增大了第一网元实例的工作压力,当第一网元实例出现故障时,第二功能网元中的各网元实例便会由于无法知晓第一消息的响应状态而无法响应第二信令,从而降低核心网的可用性。
而使用图1所示实施例的通信系统,借助内存数据库便可以避免上述方式产生的问题,从而提高核心网的可用性。
可选地,为了保证信令的处理速度,容器编排工具可以按照负载均衡原则选择第一网元实例和第二网元实例,即容器编排工具可以根据核心网中第一功能网元和第二功能网元各自对应的网元实例的负载情况,选择负载最小的网元实例来响应信令。其中,网元实例对应的待响应信令的数量越少,此网元实例的负载越小,则容器编排工具可以将第一功能网元对应的网元实例中待响应信令数量最少的网元实例确定为用于响应第一信令的第一网元实例。类似的,也可以按照上述方式选择第二网元实例。
可选地,容器编排工具可以从本地维护的可用网元实例列表中,依据负载均衡原则从第一功能网元中选择第一网元实例,从第二功能网元中选择第二网元实例。可选地,可用网元实例列表与功能网元一一对应,即不同功能网元对应的可用网元实例可以分别写入不同的可用网元实例列表中。
可选地,容器编排工具还可以实时监测核心网中不同功能网元对应的各网元实例的运行状态,以将正常运行的网元实例写入该网元实例所属功能网元对应的可用网元实例列表中,也即是生成不同功能网元对应的可用网元实例列表。可选地,若核心网中发生故障的某一网元实例,则容器编排工具还可以将此故障的网元实例从相应的可用网元实例列表中删除。容器编排工具还可以控制此发生故障的网元实例重启,若当此故障网元实例重启成功后,还可以将其重新添加到可用网元实例列表中。
基于上述描述,可以以第二网元实例响应第二信令为例进行说明:
容器编排工具可以实时监测核心网中第二功能网元对应的各网元实例的运行状态,以得到第二功能网元对应的可用网元实例列表。当终端设备发送的第二信令传输至核心网时,容器编排工具还可以从第二功能网元对应的可用实例列表中选中第二网元实例来响应此第二信令。并且在第二信令响应的过程中,若第二网元实例发生故障,则容器编排工具可以将其从可用网元实例列表中删除,再以网元实例的负载状态为依据,从列表中剩余的网元实例中确定第三网元实例,并由此第三网元实例继续响应第二信令。
在由第三网元实例响应第二信令的过程中,容器编排工具还可以控制发生故障的第二网元实例重启。若第二网元实例重启成功,则可以将其重新添加至可用网元实例列表中。此第二网元实例可以响应终端设备后续发送的信令。
上述实施例中,通过对网元实例的运行状态的监测,容器编排工具能够及时将终端设备发送的信令交由其他可用的网元实例进行响应,即核心网中某一网元实例的故障不会影响信令的正常响应,从而提高核心网的可用性。
图3为本发明实施例提供的另一种通信系统的结构示意图。如图3所示,在图1所示通信系统的基础上,该通信系统还可以包括:负载均衡组件和解析组件集群。二者结合使用可以保证终端设备发送的各种信令能够传输至核心网包含的功能网元对应的某一网元实例,以由该网元实例响应信令。可选地,负载均衡组件可以是核心网内部署的Metallb软件,解析组件可以是核心网内部署的frontend软件。
可选地,以第二信令为例,其的具体传输过程为:通信系统中的负载均衡组件可以根据核心网中各网络接口的负载状态,确定目标网络接口,并将此目标网络接口的接口地址发送至通信系统中的交换机。则终端设备发送的第二信令可以通过基站传输至交换机,在由交换机按照目标网络接口的接口地址发送第二信令至核心网。
可选地,通信系统中的负载均衡组件还可以确定解析组件集群中的任一解析组件确定为目标解析组件,也可以根据解析组件集群中各解析组件的负载状态,将最小负载的解析组件确定为目标解析组件。第二信令还可以,按照核心网中解析组件集群的外部网络地址发送第二信令至解析组件集群,按照目标解析组件的内部网络地址发送至解析组件集群中的目标解析组件,以由目标解析组件对此信令进行解析,得到第二信令的解析结果,该解析结果中包含网元响应此第二信令所需的全部信息。第二信令的解析结果还可以按照第二功能网元的外部网络地址发送至第二功能网元,再按照第二网元实例的内部网络地址发送第二信令的解析结果至第二网元实例。
第一信令的传输过程与上述过程类似,在此不再赘述。可选地,终端设备发送的各种信令可以是基于流控制传输协议(Stream Control Transmission Protocol,简称SCTP)的SCTP信令。可选地,负载均衡组件还用于监测网络接口和各解析组件的运行状态,同时结合运行状态和负载状态实现网络接口和解析组件的选择。
在第一信令和第二信令被分别传输至第一网元实例和第二网元实例后,便可以按照图1所示实施例中的相关描述实现对第一信令和第二信令的响应,则具体响应过程在此不再赘述。
需要说明的有,解析组件集群中的每个解析组件对集群外部都有统一的外部网络地址,对集群内部则有各不相同的内部网络地址。终端设备发送的信令可以按照解析组件集群的外部网络地址发送至此解析组件集群,再利用内部网络地址将信令发送至目标解析组件,以由该目标解析组件解析信令。类似的,网元实例集群中的每个网元实例对集群外部也有一个统一的外部网络地址,对集群内部则有各不相同的内部网络地址。目标解析组件可以将信令的解析结果通过网元实例集群的外部网络地址发送至网元实例集群,在利用内部网络地址发送解析结果至第一网元实例或者第二网元实例,以由网元实例响应信令。
本实施例中,通信系统中的负载均衡组件能够根据为信令的传输选择目标网络端口和目标解析组件,因此,当核心网的某一网络接口或者某一解析组件发生故障时并不会造成信令传输失败,从而保证核心网的可用性。
可选地,为了节约网络资源,容器编排工具还可以动态调整核心网中各功能网元对应的网元实例的数量。具体地,容器编排工具可以定时确定核心网中各功能网元对应的网元实例的待响应信令数量,并根据此信令数量调整网元实例的数量。在实际中,可以由核心网中每个功能网元对应的一个网元实例构成一组网元实例即一个pod,则容器编排工具可以根据待响应信令数量,以组为单位调整网元实例数量。比如增删至少一组网元实例。可选地,容器编排工具还可以对核心网的网络端口以及解析组件的数量进行动态调整。
在实际中,终端设备可以通过发送各种信令,以实现终端设备的入网或者其他处理。可选地,终端设备入网后,还可以向核心网发送数据包,数据包可以借助核心网中的UPF网元转发至服务器,以实现终端设备与服务器之间的数据交互,使终端设备能够提供网页浏览、点播视频观看、直播视频观看等服务。
为了后续描述简洁,可以将UPF网元对应的各网元实例称为UPF网元实例。此时,对于终端设备先后发送的第一数据包和第二数据包,可以由UPF网元对应的网元实例集群中相同或不同的UPF网元实例来转发。比如可以由第一UPF网元实例转发第一数据包,由第二UPF网元实例转发第二数据包。
为了实现数据包的正常转发,还可以借助预设通信协议,比如双向转发检测(Bidirectional Forwarding Detection,简称BFD)协议,监测各UPF网元实例的运行状态,并将UPF网元实例的运行状态通知至交换机,以使交换机将数据包传输至任一正常工作的UPF网元实例,再由该UPF网元实例进行数据包的转发。
在实际中,为了提高数据包的转发速度,可选地,还可以在交换机和UPF网元实例之间建立LAG(Link Aggregation)链路,以使交换机按照负载均衡的原则,选择负载最小的UPF网元实例发送数据包。
可选地,每个UPF网元实例都有与交换机进行通信时使用的第一外部网络地址,以及与基站行通信时使用的第二外部网络地址。其中,所有UPF网元实例具有相同的第二外部网络地址。此第一外部网络地址和第二外部地址都由交换机维护。
基于上述描述,可选地,为了提高数据包的转发的成功率,提高核心网的可用性,UPF网元对应的各UPF网元实例还需要订阅内存数据库。在订阅后,对于终端设备发送的第一数据包,其可以按照UPF网元实例的第二外部网络地址传输至基站,基站再将第一数据包传输至交换机。未发生故障的第一UPF网元实例可以接收到按照第一UPF网元实例的第一外部网络地址发送的第一数据包。其中,第一UPF网元实例的工作状态可以通过BFD协议进行监测得到。
当第一UPF网元实例正常响应第一数据包后,该第一数据包的响应状态可以作为新增响应状态更新到内存数据库中。之后,内存数据库会向所有订阅内存数据库的各UPF网元实例发送状态新增信令,以使各UPF网元实例从内存数据库中读取新增响应状态。
对于终端设备发送的第二数据包,其同样可以借助第二UPF网元实例的第一外部网络地址和第二外部网络地址传输至正常运行的第二UPF网元实例。并且第二UPF网元实例可以通过读取内存数据库中的响应状态可以知晓第一数据包已经被正常响应,则第二UPF网元可以对第二数据包进行正常响应,即按照预设处理规则对第二数据包进行处理,并将第二数据包的处理结果发送至相应的接收设备。可选地,预设处理规则可以与第二数据包的接收设备存在对应关系。可选地,预设处理规则可也是对数据包进行封装、去除数据包中的包头等。
可选地,订阅过程可以为:UPF网元实例向内存数据库发送订阅信令,内存数据库接收到此信令后对此UPF网元实例反馈订阅成功信令,即UPF网元实例成功订阅内存数据库。
可选地,由于使用UPF网元实例进行数据包的转发十分频繁,因此,为了提高转发速度,内存数据库中的响应状态可以在UPF网元实例启动时就被主动读取到UPF网元实例本地,以便根据内存数据库中的响应状态对数据包进行处理。相比于需要转发的数据包,需要控制面功能网元对应的网元实例进行响应的信令的数量就会大大减少,因此,当控制面功能网元对应的网元实例在响应某一信令时才会读取内存数据库中的响应状态,而无需在网元实例启动时就读取内存数据库中的响应状态。
本实施例中,借助BFD协议监测各UPF网元实例的运行状态,并将运行状态及时通知到交换机,以使交换机不会将数据包发送至故障的UPF网元实例上,从而保证了数据包转发的成功率,提高了核心网的可用性。
图4为本发明实施例提供的一种消息处理方法的流程示意图,本发明实施例提供的该消息处理方法可以由通信系统中的容器编排工具执行。如图4所示,该方法包括如下步骤:
S101,在核心网包含的第一功能网元对应的各网元实例中,确定第一网元实例,以由第一网元实例响应第一信令并将第一信令的响应状态写入内存数据库。
S102,在核心网包含的第二功能网元对应的各网元实例中,确定第二网元实例,以由第二网元实例根据从内存数据库中读取的响应状态,响应在第一信令之后发送的第二信令。
核心网接收到终端设备发送的第一信令后,可以由容器编排工具在核心网中确定第一功能网元,再从此第一功能网元对应的网元实例集群中确定第一网元实例,并由此第一网元实例响应第一信令。并且第一网元实例对第一信令的响应状态可以写入通信系统中的内存数据库中。
在第一信令之后,终端设备还可以发送第二信令,此时,容器编排工具可以再次在核心网中确定第二功能网元中的第二网元实例,并由此第二网元实例响应第二信令。第二网元实例具体的信令响应过程为:先从内存数据库中读取第一信令的响应状态,若响应状态为正常响应,则第二网元实例会正常响应第二信令;若第一信令的响应状态为异常响应,则第二网元实例也会异常响应第二信令。无论是何种响应状态,第二网元实例也都会将其写入内存数据库中。
根据上述描述可知,第一信令的响应状态会直接影响第二信令的响应状态,这种影响可以认为是第一信令和第二信令之间具有一定的执行先后顺序。
可选地,终端设备发送的信令由基站依次传输至交换机、核心网中的某一网元实例的过程可以参见上述各实施例中的相关描述,在此不再赘述。
另外,本实施例中未详细描述的内容以及所能实现的技术效果可以参见如图1~图3所示实施例中的相关描述,在此不再赘述。
本实施例中,可以利用独立的容器编排工具确定用于响应信令的网元实例,即利用独立的工具实现网元实例的调度。相比于由核心网中的目标网元实例进行网元实例调度,本实施例能够避免产生目标网元实例故障时,网元实例无法调度导致信令无法响应的情况,从而提高核心网的可用性。同时,也省去了目标网元实例的选择过程,同时也减轻了目标网元实例的工作压力。另外,第一信令的响应状态会被写入内存数据库,则第二功能网元的各个网元实例都能够通过主动读取内存数据库了解第一信令的响应状态,使得第二功能网元中的每个网元实例都能够响应第二信令,即任一网元实例出现故障都不会影响第二信令的正常响应,从而提高核心网的可用性。
根据图4所示实施例可知,容器编排工具的主要作用就是在网元实例集群中进行网元实例的选择,以由选中的网元实例来执行终端设备发送的信令。
可选地,对于网元实例的选择原则可以是负载均衡原则,即容器编排工具可以根据核心网中第一功能网元和第二功能网元各自对应的网元实例的负载情况,选择负载最小的网元实例来响应信令。其中,网元实例对应的待响应信令的数量越少,此网元实例的负载越小,则容器编排工具可以将第一功能网元对应的网元实例中待响应信令数量最少的网元实例确定为用于响应第一信令的第一网元实例。对第二网元实例的选择也可以按照上述方式进行,在此不再赘述。
可选地,容器编排工具可以从本地维护的可用网元实例列表中,依据负载均衡原则从第一功能网元中选择第一网元实例,从第二功能网元中选择第二网元实例。可选地,可用网元实例列表与功能网元一一对应,即不同功能网元对应的可用网元实例可以分别写入不同的可用网元实例列表中。
可选地,对于各功能网元对应的可用网元实例列表,
容器编排工具还可以实时监测核心网中不同功能网元对应的各网元实例的运行状态,以将正常运行的网元实例写入该网元实例所属功能网元对应的可用网元实例列表中。可选地,若核心网中发生故障的某一网元实例,则容器编排工具还可以将此故障的网元实例从相应的可用网元实例列表中删除。容器编排工具还可以控制此发生故障的网元实例重启,若当此故障网元实例重启成功后,将其重新添加到可用网元实例列表中。
基于上述描述,以第二网元实例响应第二信令为例进行说明:
容器编排工具可以实时监测核心网中第二功能网元对应的各网元实例的运行状态,以得到第二功能网元对应的可用网元实例列表。当终端设备发送的第二信令传输至核心网时,容器编排工具还可以从第二功能网元对应的可用实例列表中选中第二网元实例来响应此第二信令。并且在第二信令响应的过程中,若第二网元实例发生故障,则容器编排工具可以将其从可用网元实例列表中删除,再以网元实例的负载状态为依据,从列表中剩余的网元实例中确定第三网元实例,并由此第三网元实例继续响应第二信令。
在由第三网元实例响应第二信令的过程中,容器编排工具还可以控制发生故障的第二网元实例重启。若第二网元实例重启成功,则可以将其重新添加至可用网元实例列表中。此第二网元实例可以响应终端设备后续发送的信令。
上述实施例中,通过对网元实例的运行状态的监测,容器编排工具能够及时将终端设备发送的信令交由其他可用的网元实例进行响应,即核心网中某一网元实例的故障不会影响信令的正常响应,从而提高核心网的可用性。
可选地,为了节约网络资源,容器编排工具还可以动态调整核心网中各功能网元对应的网元实例的数量。具体地,容器编排工具可以定时确定核心网中各功能网元对应的网元实例的待响应信令数量,并根据此信令数量调整网元实例的数量。
为了便于理解,以直播场景为例对以上各实施例提供的消息处理方法、通信系统的具体实现过程进行示例性说明。
当终端设备首次接入5G通信系统时,终端设备可以发送接入信令,此接入信令可以被基站和交换机接收到,交换机再利用目标网络接口将接入信令传输至核心网中。接入信令可以按照frontend集群的外部网络地址发送接入信令至frontend集群,再按照frontend集群中目标frontend的内部网络地址发送至目标frontend。目标frontend可以对接入信令进行解析,解析结果可以按照AMF网元的外部网络地址发送至AMF网元对应的网元实例集群中,再按照AMF网元对应的第一AMF网元实例的内部网络地址发送解析结果至第一AMF网元实例,以由此网元实例正常响应此接入信令,以得到待认证信令,此待认证信令会反馈至终端设备。其中,接入信令对应的响应状态即正常响应可以由第一AMF网元实例写入通信系统中的内存数据库中。
其中,上述的目标网络接口可以是核心网中部署的Metallb选中的、具有最小负载的网络接口。目标frontend也可以是由Metallb选中的。第一AMF网元实例可以由核心网中部署的Kubernetes选中。
接着,终端设备响应于第一AMF网元实例反馈的待认证信令,还可以发送认证信令至核心网。此认证信令同样需要经过基站、交换机最终传输至核心网,并由核心网中的第二AMF网元实例进行响应。认证信令的传输与接入信令的传输过程相似,在此不再赘述。可选地,由Kubernetes选中的第二AMF网元实例可以是具有负载最小的网元实例。
第二AMF网元实例响应认证信令的过程为:第二AMF网元实例从内存数据库中读取接入信令的响应状态为正常响应,则第二AMF网元实例可以进一步正常响应认证信令。由于每个正常运行的AMF网元实例都能够从内存数据库中读取接入信令的响应状态,因此,任一AMF网元实例发生故障都不会影响接入信令的响应。
进一步地,终端设备还可以发送会话建立信令,该信令可以由Kubernetes选中的SMF网元实例响应。由于第二AMF网元实例正常响应认证信令,因此,SMF网元实例也可以正常响应此会话建立信令,从而使终端设备完成入网过程。
可选地,Kubernetes可以实时监测网元实例的运行状态和负载状态,从而选择出正常运行的、负载最小的网元实例。
进一步地,当终端设备成功入网后,用户便可以使用安装的直播APP观看视频直播。对于直播APP提供直播服务的过程,终端设备可以向核心网中的UPF网元发送由多个数据包构成的直播数据获取请求,以由UPF网元对直播数据获取请求中包含的多个数据包进行处理后依次转发至服务器,服务器在接收到终端设备发送的多个数据包后,可以将对应的视频流同样以数据包的形式通过UPF网元反馈给终端设备。
根据上述描述可知,终端设备和服务器之间可以借助UPF网元实现数据包的传输,具体过程可以为:终端设备发送第一数据包,其可以按照UPF网元实例的第二外部网络地址传输至基站,基站再将第一数据包传输至交换机,交换机再按照第一UPF网元实例的第一外部网络地址发送数据包至未发生故障的第一UPF网元实例。当第一UPF网元实例正常响应第一数据包后,该第一数据包的响应状态可以作为新增响应状态更新到内存数据库中。
之后终端设备还可以发送第二数据包,其同样可以借助第二UPF网元实例的第一外部网络地址和第二外部网络地址传输至正常运行的第二UPF网元实例。并且第二UPF网元实例可以通过读取内存数据库中的响应状态可以知晓第一数据包已经被正常响应,则第二UPF网元可以对第二数据包进行正常响应,即按照预设处理规则对第二数据包进行处理,并将第二数据包的处理结果发送至服务器。当服务器接收到包含多个数据包的直播数据请求后,可以将直播视频以多个数据包的形式通过URF网元实例反馈给终端设备,以使用户能够看到直播视频。上述过程也可以结合图5理解。
上述各实施例提供的消息处理方法、通信系统还可以应用到自动驾驶场景中。对于由车辆、通信系统、路测设备和服务器构成的车联网,当车辆接入车联网并且启动自动驾驶模式后,可以通过向服务器依次发送共同构成驾驶数据获取请求的多个数据包,再由服务器在接收到此多个数据包后,将驾驶数据以多个数据包的形式反馈给车辆,从而实现自动驾驶。
其中,车辆入网的过程与上述终端设备入网的过程基本相同,数据包的传输、处理过程也与上述直播场景中数据包的传输、处理过程相同,在此不再赘述。上述内容也可以结合图6理解。
在一个可能的设计中,上述的消息处理方法具体可以借助一种电子设备实现。如图7所示,该电子设备可以包括:处理器21和存储器22。其中,所述存储器22用于存储支持该电子设备执行上述图4所示实施例中提供的消息处理方法的程序,所述处理器21被配置为用于执行所述存储器22中存储的程序。
所述程序包括一条或多条计算机指令,其中,所述一条或多条计算机指令被所述处理器21执行时能够实现如下步骤:
在核心网包含的第一功能网元对应的各网元实例中,确定第一网元实例,以由所述第一网元实例响应所述第一信令并将所述第一信令的响应状态写入内存数据库;
在所述核心网包含的第二功能网元对应的各网元实例中,确定第二网元实例,以由所述第二网元实例根据从所述内存数据库中读取的所述响应状态,响应在所述第一信令之后发送的第二信令。
可选地,所述处理器21还用于执行前述图4所示实施例中的全部或部分步骤。
其中,所述电子设备的结构中还可以包括通信接口23,用于该电子设备与其他设备或通信网络通信。
另外,本发明实施例提供了一种计算机存储介质,用于储存上述电子设备所用的计算机软件指令,其包含用于执行上述图4所示方法实施例中消息处理方法所涉及的程序。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。