CN112087770B - 一种通知服务状态的方法、通信系统和通信装置 - Google Patents

Abstract

本申请提供了一种通知服务状态的方法、通信系统和通信装置，第一网元通过向网元发现设备发送包括通知策略的服务去注册请求消息或者服务更新请求消息，使得网元发现设备可以根据该通知策略，以较合理的方式向订阅了第一网元服务状态的多个订阅网元发送服务状态通知消息(即，去注册状态或是更新状态)，从而有利于解决核心网信令负荷过重和网络性能波动的问题。

Description

一种通知服务状态的方法、通信系统和通信装置

技术领域

本申请涉及通信领域，并且更具体地，涉及一种通知服务状态的方法、通信系统和通信装置。

背景技术

目前第三代合作伙伴项目(the 3rd generation partner project，3GPP)所定义的第五代(5th generation，5G)架构中，控制面网元之间的接口采用了服务化架构。基于服务化架构，各控制面网元通过向网络仓库功能(network repository function，NRF)注册自身地址及支持的服务信息以便第三方网元查询。当某个网元判断需要执行网元割接时，将向NRF发送服务去注册请求消息或服务更新请求消息，并由NRF将去注册状态或更新状态通知到所有订阅了该网元服务状态的订阅网元，以触发这些订阅网元向新侧网元发起建立或更新上下文请求。

由于NRF并不感知各订阅网元上受影响的用户数量或者发起网元割接的原因，从而可能由于NRF通知各订阅网元去注册状态或是更新状态的方式不合理，导致核心网信令负荷过重或是网络性能波动的问题。

发明内容

本申请提供一种通知服务状态的方法、通信系统和通信装置，有利于解决核心网信令负荷过重和网络性能波动的问题。

第一方面，提供了一种通知服务状态的方法，包括：网元发现设备接收来自第一网元的请求消息，该请求消息为服务去注册请求消息或者服务更新请求消息，该请求消息包括通知策略；网元发现设备根据通知策略，向订阅了第一网元服务状态的多个订阅网元发送服务状态通知消息。

根据本申请提供的方法，由于第一网元能够感知因第一网元割接受影响的用户数量和/或第一网元发起割接的原因，所以可以由第一网元确定网元发现设备通知各订阅网元服务状态通知消息时所采用的通知策略，并且第一网元将该通知策略发送给网元发现设备，从而网元发现设备可以根据第一网元提供的通知策略，以较合理的方式向各订阅网元发送服务状态通知消息(即，去注册状态或是更新状态)，有利于解决核心网信令负荷过重和网络性能波动的问题。比如，第一网元可以遵循该通知策略，向各订阅网元发送服务状态通知消息，或者，第一网元可以结合本地配置，确定向各订阅网元发送服务状态通知消息的策略，并以该策略，向各订阅网元发送服务状态通知消息。

可选地，该服务状态通知消息用于触发订阅网元发起建立上下文流程或更新上下文流程。

结合第一方面，在第一方面的某些实现方式中，该服务状态通知消息还包括一个或多个第二网元的信息，所述第二网元为支持提供与所述第一网元相同服务的网元，或者所述第二网元为与所述第一网元具有相同功能的网元。

基于该方案，订阅网元不需要先从网元发现设备查询第二网元的信息，再向第二网元发起建立上下文流程或更新上下文流程，从而能够减少由于订阅网元向网元发现设备查询第二网元的信息所带来的信令开销。

结合第一方面，在第一方面的某些实现方式中，网元发现设备根据该通知策略，向该多个订阅网元120发送服务状态通知消息，包括：网元发现设备根据该通知策略确定多个发送时机，并分别在该多个发送时机，向对应的订阅网元发送服务状态通知消息。其中，该多个发送时机与该多个订阅网元对应，一个发送时机对应至少一个订阅网元。

基于该方案，网元发现设备可以根据通知策略，针对各订阅网元确定合适的发送时机，能够避免同时向该多个订阅网元发送服务状态通知消息，进而能够避免该多个订阅网元同时发起建立上下文流程或更新上下文流程而导致的核心网信令负荷过重的问题。

结合第一方面，在第一方面的某些实现方式中，所述通知策略包括结束时间，其中所述网元发现设备需要在所述结束时间前向所述多个订阅网元发送所述服务状态通知消息。

基于此方案，网元发现设备可以在该结束时间前完成向该多个订阅网元发送服务状态通知消息，从而使得订阅网元可以及时向第二网元发起建立上下文流程或更新上下文流程，以及时建立或更新上下文，能够避免由于没有及时建立或更新上下文导致的网络性能波动。

结合第一方面，在第一方面的某些实现方式中，所述通知策略包括所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元对应的目标用户的数量，所述目标用户为需要执行建立上下文流程或者更新上下文流程的用户。

基于该方案，网元发现设备可以根据该部分或全部订阅网元中各订阅网元对应的目标用户的数量，确定该部分或全部订阅网元中各订阅网元所需的处理时间，即各订阅网元执行建立(或重建)上下文流程或者更新上下文流程所需的时间，进而可以根据所确定的处理时间，向对应的订阅网元发送服务状态通知消息。这样，网元发送设备可以在一个订阅网元执行完建立上下文流程或者更新上下文流程后再向另一订阅网元发送服务状态通知消息，从而能够避免多个订阅网元同时发起建立或更新上下文流程而导致的核心网信令负荷过重的问题。

结合第一方面，在第一方面的某些实现方式中，所述通知策略包括所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元对应的目标用户的比率，

其中，所述目标用户为需要执行建立上下文流程或者更新上下文流程的用户，一个订阅网元对应的目标用户的比率为该订阅网元对应的目标用户占所述部分或全部订阅网元对应的所有目标用户的比率，或者，一个订阅网元对应的目标用户的比率为该订阅网元对应的目标用户占所述第一网元对应的所有目标用户的比率。

基于该方案，网元发现设备可以根据该部分或全部订阅网元中各订阅网元对应的目标用户的比率，确定该部分或全部订阅网元中各订阅网元所需的处理时间，即各订阅网元执行建立(或重建)上下文流程或者更新上下文流程所需的时间，进而可以根据所确定的处理时间，向对应的订阅网元发送服务状态通知消息。这样，网元发送设备可以在一个订阅网元执行完建立上下文流程或者更新上下文流程后再向另一订阅网元发送服务状态通知消息，从而能够避免多个订阅网元同时发起建立或更新上下文流程而导致的核心网信令负荷过重的问题。

结合第一方面，在第一方面的某些实现方式中，所述通知策略包括所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元的处理时间，一个订阅网元的处理时间为该订阅网元执行建立上下文流程或者更新上下文流程所需的时间。

基于该方案，网元发送设备可以在一个订阅网元执行完建立上下文流程或者更新上下文流程后再向另一订阅网元发送服务状态通知消息，从而能够避免多个订阅网元同时发起建立或更新上下文流程而导致的核心网信令负荷过重的问题。

结合第一方面，在第一方面的某些实现方式中，所述通知策略包括所述多个订阅网元中的部分或全部网元分别对应的通知时间间隔，所述通知时间间隔为发送所述服务状态通知消息的时间间隔。

基于该方案，网元发送设备可以根据通知时间间隔，向订阅网元发送服务状态通知消息，从而能够避免多个订阅网元同时发起建立或更新上下文流程而导致的核心网信令负荷过重的问题。

结合第一方面，在第一方面的某些实现方式中，所述通知策略包括通知顺序，所述通知顺序为所述网元发现设备向所述多个订阅网元发送所述服务状态通知消息的顺序。

比如，网元发现设备可以根据该多个订阅网元中各订阅网元对应的通知时间间隔和通知顺序，向对应的订阅网元服务状态通知消息。其中，通知顺序为网元发现设备向该多个订阅网元发送服务状态通知消息的顺序。

第二方面，提供了一种通知服务状态的方法，包括：第一网元生成请求消息，该请求消息为服务去注册请求消息或者服务更新请求消息，该请求消息包括通知策略；第一网元向网元发现设备发送该请求消息。其中，该通知策略用于该网元发现设备向订阅了第一网元的多个订阅网元发送服务状态通知消息。

可选地，第一网元可以根据因第一网元割接受影响的用户数量和/或第一网元发起割接的原因，确定该通知策略。

根据本申请提供的方法，由于第一网元能够感知因第一网元割接受影响的用户数量和/或第一网元发起割接的原因，所以可以由第一网元确定网元发现设备通知各订阅网元服务状态通知消息时所采用的通知策略，并且第一网元将该通知策略发送给网元发现设备，从而网元发现设备可以根据第一网元提供的通知策略，以较合理的方式向各订阅网元发送服务状态通知消息(即，去注册状态或是更新状态)，有利于解决核心网信令负荷过重和网络性能波动的问题。比如，第一网元可以遵循该通知策略，向各订阅网元发送服务状态通知消息，或者，第一网元可以结合本地配置，确定向各订阅网元发送服务状态通知消息的策略，并以该策略，向各订阅网元发送服务状态通知消息。

可选地，第一网元可以在确定其不可用或者需要进行服务更新时，向所述网元发现设备发送所述请求消息。

第三方面，提供了一种通知服务状态的方法，包括：订阅网元接收网元发现设备发送的服务状态通知消息，该服务状态通知消息包括一个或多个第二网元的信息，所述第二网元为支持提供与第一网元相同服务的网元，或者所述第二网元为与所述第一网元具有相同功能的网元，该订阅网元订阅了所述第一网元服务状态；订阅网元根据该一个或多个第二网元中部分或全部第二网元的信息，发起建立上下文流程或更新上下文流程。

应理解，该订阅网元可能只需要与该一个或多个第二网元中的部分第二网元之间建立上下文或者更新上下文，也可能需要与该一个或多个第二网元中的全部第二网元之间建立上下文或者更新上下文，具体可以由网络部署情况决定。

基于该方案，订阅网元不需要先从网元发现设备查询第二网元的信息，再向第二网元发起建立上下文流程或更新上下文流程，从而能够减少由于订阅网元向网元发现设备查询第二网元的信息所带来的信令开销。

第四方面，提供了一种通信系统，包括网元发现设备和多个订阅网元。网元发现设备，用于接收来自第一网元的请求消息，所述请求消息为服务去注册请求消息或者服务更新请求消息，所述请求消息包括通知策略；根据所述通知策略，向订阅了所述第一网元服务状态的所述多个订阅网元发送服务状态通知消息；所述订阅网元，用于接收所述服务状态通知消息。

根据本申请提供的通信系统，由于第一网元能够感知因第一网元割接受影响的用户数量和/或第一网元发起割接的原因，所以可以由第一网元确定网元发现设备通知各订阅网元服务状态通知消息时所采用的通知策略，并且第一网元将该通知策略发送给网元发现设备，从而网元发现设备可以根据第一网元提供的通知策略，以较合理的方式向各订阅网元发送服务状态通知消息(即，去注册状态或是更新状态)，有利于解决核心网信令负荷过重和网络性能波动的问题。比如，第一网元可以遵循该通知策略，向各订阅网元发送服务状态通知消息，或者，第一网元可以结合本地配置，确定向各订阅网元发送服务状态通知消息的策略，并以该策略，向各订阅网元发送服务状态通知消息。

结合第四方面，在第四方面的某些实现方式中，所述订阅网元还用于：根据所述服务状态通知消息，发起建立上下文流程或更新上下文流程。

结合第四方面，在第四方面的某些实现方式中，所述服务状态通知消息还包括一个或多个第二网元的信息，所述第二网元为支持提供与所述第一网元相同服务的网元，或者所述第二网元为与所述第一网元具有相同功能的网元；以及，所述订阅网元，用于根据所述服务状态通知消息，发起建立上下文流程或更新上下文流程，包括：所述订阅网元，用于根据所述一个或多个第二网元的信息，向所述一个或多个第二网元中的部分或全部第二网元，发起建立上下文流程或更新上下文流程。

基于该方案，订阅网元不需要先从网元发现设备查询第二网元的信息，再向第二网元发起建立上下文流程或更新上下文流程，从而能够减少由于订阅网元向网元发现设备查询第二网元的信息所带来的信令开销。

结合第四方面，在第四方面的某些实现方式中，所述系统还包括第一网元。所述第一网元，用于在确定所述第一网元不可用或者需要进行服务更新时，向所述网元发现设备发送所述请求消息。

第五方面，提供了一种装置，包括用于执行第一方面至第三方面以及第一方面至第三方面中任一种可能实现方式中的方法的各个模块或单元。

第六方面，提供了一种装置，包括处理器。该处理器与存储器耦合，可用于执行存储器中的指令，以使得该装置执行上述第一方面至第三方面以及第一方面至第三方面中任一种可能实现方式中的方法。可选地，该装置还包括存储器。可选地，该装置还包括接口电路，处理器与接口电路耦合。

在一种实现方式中，该装置为网元发现设备或者配置于网元发现设备中的芯片。当该装置为网元发现设备时，该接口电路可以是收发器，或，输入/输出接口。当该装置为配置于网元发现设备中的芯片时，该接口电路可以是输入/输出接口。

在另一种实现方式中，该装置为第一网元或者配置于第一网元中的芯片。当该装置为第一网元时，该接口电路可以是收发器，或，输入/输出接口。当该装置为配置于第一网元中的芯片时，该接口电路可以是输入/输出接口。

在又一种实现方式中，该装置为订阅网元或者配置于订阅网元中的芯片。当该装置为订阅网元时，该接口电路可以是收发器，或，输入/输出接口。当该装置为配置于订阅网元中的芯片时，该接口电路可以是输入/输出接口。

可选地，该收发器可以为收发电路。可选地，该输入/输出接口可以为输入/输出电路。

第七方面，提供了一种处理器，包括：输入电路、输出电路和处理电路。该处理电路用于通过该输入电路接收信号，并通过该输出电路发射信号，使得该处理器执行第一方面至第三方面以及第一方面至第三方面任一种可能实现方式中的方法。

在具体实现过程中，上述处理器可以为芯片，输入电路可以为输入管脚，输出电路可以为输出管脚，处理电路可以为晶体管、门电路、触发器和各种逻辑电路等。输入电路所接收的输入的信号可以是由例如但不限于接收器接收并输入的，输出电路所输出的信号可以是例如但不限于输出给发射器并由发射器发射的，且输入电路和输出电路可以是同一电路，该电路在不同的时刻分别用作输入电路和输出电路。本申请实施例对处理器及各种电路的具体实现方式不做限定。

第八方面，提供了一种处理装置，包括处理器和存储器。该处理器用于读取存储器中存储的指令，并可通过接收器接收信号，通过发射器发射信号，以执行第一方面至第三方面以及第一方面至第三方面任一种可能实现方式中的方法。

可选地，该处理器为一个或多个，该存储器为一个或多个。

可选地，该存储器可以与该处理器集成在一起，或者该存储器与处理器分离设置。

在具体实现过程中，存储器可以为非瞬时性(non-transitory)存储器，例如只读存储器(read only memory，ROM)，其可以与处理器集成在同一块芯片上，也可以分别设置在不同的芯片上，本申请实施例对存储器的类型以及存储器与处理器的设置方式不做限定。

上述第八方面中的处理装置可以是一个芯片，该处理器可以通过硬件来实现也可以通过软件来实现，当通过硬件实现时，该处理器可以是逻辑电路、集成电路等；当通过软件来实现时，该处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现，该存储器可以集成在处理器中，可以位于该处理器之外，独立存在。

第九方面，提供了一种计算机程序产品，该计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当该计算机程序被运行时，使得计算机执行上述第一方面至第三方面以及第一方面至第三方面中任一种可能实现方式中的方法。

第十方面，提供了一种计算机可读介质，该计算机可读介质存储有计算机程序(也可以称为代码，或指令)当其在计算机上运行时，使得计算机执行上述第一方面至第三方面以及第一方面至第三方面中任一种可能实现方式中的方法。

附图说明

图1是本申请实施例提供的一种通信系统的示意图；

图2是应用于本申请的一个5G系统的架构示意图；

图3是应用于本申请另一5G系统的架构示意图；

图4是应用于本申请实施例的一种通信装置的示意性框图；

图5是本申请提供的通知服务状态的方法的示意性流程图；

图6是本申请提供的通知服务状态的方法的示意性流程图；

图7是本申请提供的通信装置的示意性框图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行描述。

基于3GPP所定义的服务化架构，例如5G系统，当某一网元判断需执行网元割接时，将向NRF发送服务去注册请求或是服务更新请求，并由NRF将去注册状态或是更新状态通知到所有订阅了该网元服务状态的其他网元(即，订阅网元)，以触发订阅网元向新侧网元发起建立或更新上下文请求。

由于NRF并不感知各订阅网元上受影响的用户数量或者发起网元割接的原因，从而可能由于NRF通知各订阅网元去注册状态或是更新状态的方式不合理，导致核心网信令负荷过重或是网络性能波动的问题。

比如，实际场景中，网元割接可能会影响数百万用户量，由于NRF并不感知各订阅网元下受影响用户数量，NRF可能会同时向这些订阅网元通知去注册状态或是更新状态，从而可能导致这些订阅网元同时发起建立或更新上下文请求。由于建立或更新上下文请求是以用户设备(user equipment，UE)或协议数据单元(protocol data unit，PDU)会话(Session)为粒度的，因此会有数百万的建立或更新上下文请求发送至该新侧网元，从而导致核心网信令负荷过重。

又如，如果NRF按照预设的时间间隔向这些订阅网元通知去注册状态或是更新状态，而预设的时间间隔可能与各订阅网元上受影响的用户数量并不匹配，则也可能导致网络性能波动。

再如，若统一数据管理(unified data management，UDM)需要进行割接，并且UDM割接是由于语音数据迁移所导致的，那么若用户设备(user equipment，UE)无法及时正确注册到对应新侧UDM，则新侧UDM在收到下行语音呼叫请求时，将无法查找到正确的接入与移动性管理功能(access and mobility management function，AMF)，从而将导致UE语音被叫失败，进而导致网络性能波动。

应理解，上文中仅以5G系统中的网元割接为例，描述了网元割接时可能存在的问题，在其他系统，比如未来的6G等系统中，可能也存在类似的问题。

有鉴于此，本申请提供了一种通知服务状态的方法、通信系统和通信装置，通过由需要进行网元割接的网元(即，第一网元)确定通知策略，并将该通知策略提供给网元发现设备(如，NRF)，使得网元发现设备可以根据该通知策略，以较合理的方式向各订阅网元通知去注册状态或是更新状态，有利于解决核心网信令负荷过重和网络性能波动的问题。

图1是本申请提供的一种通信系统的示意图。系统100可以用于执行本申请提供的通知服务状态的方法。应理解，系统100的各网元可以分别可以是一个单独的网元，或者这些网元分别可以是一个功能模块，或者这些网元中的任意多个网元所实现的功能可以集成在一个功能模块或者一个网元上，本申请对此不作限定。

如图1所示，该系统100包括：网元发现设备110和多个(即，两个或两个以上)订阅网元120。可选地，系统100还可以包括第一网元130和一个或多个第二网元140。其中，每个订阅网元120都订阅了第一网元130服务状态，该一个或多个第二网元140为支持提供与第一网元130相同服务的网元，或者该一个或多个第二网元140为与该第一网元130具有相同功能的网元。当第一网元需要进行割接时，第一网元上的用户将被迁移至该一个或多个第二网元140。

应理解，所述多个订阅网元可以包括一种或多种类型的网元，具体与第一网元的类型相关。比如，以系统100为5G系统为例，第一网元为UDM时，该多个订阅网元可以包括AMF和会话管理功能(session management function，SMF)。进一步地，该多个订阅网元还有可能包括短消息业务功能(short message service function，SMSF)。再如，第一网元为AMF时，该多个订阅网元可以包括AMF、策略控制功能(policy control function，PCF)和鉴权服务器功能(authentication server function，AUSF)。

在系统100中，网元发现设备110，用于：接收来自第一网元130的请求消息，该请求消息为服务去注册请求消息或者服务更新请求消息，该请求消息包括通知策略(或者称，通知策略信息)，该通知策略用于网元发现设备110向该多个订阅网元120发送服务状态通知消息；根据该通知策略，向订阅了第一网元130服务状态的该多个订阅网元120发送服务状态通知消息。相应地，订阅网元120，用于接收该服务状态通知消息。

比如，当第一网元130不可用，如第一网元发生故障时，第一网元130可以向网元发现设备110发送服务去注册请求消息，该服务去注册请求消息将触发网元发现设备110去注册第一网元130的服务内容(NF profile)或者说去注册第一网元130注册到网元发现设备110上的服务列表或者用户号段。该服务去注册请求消息还包括该通知策略，网元发现设备110可以根据通知策略，向该多个订阅网元120发送服务状态通知消息，以通知该多个订阅网元120该第一网元130不可用。

又如，当第一网元130支持的用户列表发生部分变更时，可以向网元发现设备110发送服务更新请求消息，该服务更新请求消息可以触发网元发现设备110更新第一网元130的服务内容(例如，包含网元类型、网元地址、服务列表和支持号段等中的一种或多种信息)。该服务更新请求消息还包括该通知策略。网元发现设备110可以根据通知策略，向该多个订阅网元120发送服务状态通知消息，以通知该多个订阅网元120该第一网元130需要进行服务状态更新。应理解，服务更新请求消息可以包括更新后第一网元130支持的用户列表。

根据本申请提供的系统，由于第一网元能够感知因第一网元割接受影响的用户数量和/或第一网元发起割接的原因，所以可以由第一网元确定网元发现设备通知各订阅网元服务状态通知消息时所采用的通知策略，并且第一网元将该通知策略发送给网元发现设备，从而网元发现设备可以根据第一网元提供的通知策略，以较合理的方式向各订阅网元发送服务状态通知消息(即，去注册状态或是更新状态)，有利于解决核心网信令负荷过重和网络性能波动的问题。比如，第一网元可以遵循该通知策略，向各订阅网元发送服务状态通知消息，或者，第一网元可以结合本地配置，确定向各订阅网元发送服务状态通知消息的策略，并以该策略，向各订阅网元发送服务状态通知消息。

本领域技术人员可以理解，订阅网元120接收的服务状态通知消息可以触发该订阅网元120发起建立上下文流程或更新上下文流程。从而，订阅网元120可以在接收到服务状态通知消息后，发起建立上下文流程或者更新上下文流程，以建立或更新订阅网元120与该一个或多个第二网元140之间的上下文。

需要说明的是，本文中所描述的建立上下文也可以是重建上下文。订阅网元120例如可以通过发送注册请求消息或者初始上下文消息发起建立上下文或者更新上下文流程。另外，建立上下文流程和更新上下文流程都是UE粒度的。在建立上下文流程或更新上下文流程由服务更新请求消息触发的情况下，订阅网元120可以只对之前注册到第一网元的用户列表中除更新后第一网元130支持的用户列表外的其他用户，发起建立上下文流程和更新上下文流程。比如，之前注册到订阅网元120的用户为用户1至用户20，更新后第一网元130支持的用户为用户1至用户10，那么订阅网元120可以只对用户11至用户20发起建立上下文流程和更新上下文流程。

可选地，该服务状态通知消息可以包括该一个或多个第二网元140的信息。比如，服务状态通知消息可以包括该一个或多个第二网元140的标识。

订阅网元120可以根据该一个或多个第二网元140的信息，向该一个或多个第二网元140中的部分或全部第二网元140，发起建立上下文流程或更新上下文流程。

基于该方案，订阅网元不需要先从网元发现设备查询第二网元的信息，再向第二网元发起建立上下文流程或更新上下文流程，从而能够减少由于订阅网元向网元发现设备查询第二网元的信息所带来的信令开销。

另外，该一个或多个第二网元140的信息也可以由管理面，例如运维管理系统(Operation&Management，OAM)，配置给网元发现设备110。从而，订阅网元可以从网元发现设备110获取该一个或多个第二网元140的信息。

在一种可能的实现方式中，网元发现设备110用于根据该通知策略，向该多个订阅网元120发送服务状态通知消息，包括：

网元发现设备110，用于根据该通知策略确定多个发送时机，并分别在该多个发送时机，向对应的订阅网元120发送服务状态通知消息。其中，该多个发送时机与该多个订阅网元120对应，一个发送时机对应至少一个订阅网元120。

也就是说，网元发现设备110可以根据通知策略确定每个订阅网元120对应的发送时机，并且针对每个订阅网元120，网元发现设备110可以在对应的发送时机，向该订阅网元120发送服务状态通知消息。应理解，网元发现设备110可以在一个发送时机，同时向多个订阅网元发送服务状态通知消息。

基于该方案，网元发现设备110可以根据通知策略，针对各订阅网元确定合适的发送时机，能够避免同时向该多个订阅网元发送服务状态通知消息，进而能够避免该多个订阅网元同时发起建立上下文流程或更新上下文流程而导致的核心网信令负荷过重的问题。

以下对该通知策略可能包括的内容进行说明。

可选地，该通知策略可以包括下述五种信息中的其中一种，或者可以同时包括下述五种信息中的若干种。

(1)结束时间。其中，网元发现设备110需要在该结束时间前向该多个订阅网元120发送服务状态通知消息。

在该通知策略包括第一种信息的情况下，网元发现设备110可以在该结束时间前完成向该多个订阅网元120发送服务状态通知消息，从而使得订阅网元120可以及时向第二网元140发起建立上下文流程或更新上下文流程，以及时建立或更新上下文。

比如，第一网元是UDM，并且该UDM的割接是由于语音数据迁移所引起的，根据本申请的方案，网元发现设备110能够在结束时间前完成向该多个订阅网元120发送服务状态通知消息，从而该多个订阅网元可以及时将UE注册到对应新侧UDM(即，第二网元)，那么第二网元在收到下行语音呼叫请求时，可以查找到正确的AMF，保证UE语音被叫成功，避免网络性能波动。

可选地，在该通知策略包括第一种信息的情况下，网元发现设备110还可以结合本地配置，确定所有订阅网元中每个订阅网元所对应的通知时间间隔，并根据该通知时间间隔向对应的订阅网元发送服务状态通知消息。

基于此方案，网元发现设备110可以在结束时间之前，分时向各订阅网元发送服务状态通知消息，从而能够避免多个订阅网元同时发起建立或更新上下文流程而导致的核心网信令负荷过重的问题。

(2)该多个订阅网元120中部分或全部订阅网元的信息，以及该部分或全部订阅网元中每个订阅网元对应的目标用户的数量。

其中，目标用户为需要执行建立(或重建)上下文流程或者更新上下文流程的用户，或者说，一个订阅网元对应的目标用户为该订阅网元上因第一网元去注册或者服务更新而受影响的用户。订阅网元的信息例如可以是订阅网元的标识。

应理解，通知策略可以包括与第一网元存在交互的所有订阅网元(即，上文中描述的该多个订阅网元)的信息，也可以仅包括与第一网元存在交互的所有订阅网元中部分订阅网元的信息，该部分订阅网元例如可以是该多个订阅网元中订阅网元上受影响用户的数量较多(比如，大于预设阈值)的订阅网元。

在该通知策略包括第二种信息的情况下，网元发现设备110可以根据该部分或全部订阅网元中各订阅网元对应的目标用户的数量，确定该部分或全部订阅网元中各订阅网元所需的处理时间，即各订阅网元执行建立(或重建)上下文流程或者更新上下文流程所需的时间。

进一步地，网元发现设备110可以基于其所确定的该部分或全部订阅网元中各订阅网元所需的处理时间，确定所有订阅网元中每个订阅网元所对应的通知时间间隔，并根据该通知时间间隔向对应的订阅网元发送服务状态通知消息。

基于该方案，网元发送设备可以在一个订阅网元执行完建立上下文流程或者更新上下文流程后再向另一订阅网元发送服务状态通知消息，从而能够避免多个订阅网元同时发起建立或更新上下文流程而导致的核心网信令负荷过重的问题。

(3)该多个订阅网元120中部分或全部订阅网元的信息，以及该部分或全部订阅网元中每个订阅网元对应的目标用户的比率。

其中，一个订阅网元对应的目标用户的比率为该订阅网元对应的目标用户占该部分或全部订阅网元对应的所有目标用户的比率。或者，一个订阅网元对应的目标用户的比率为该订阅网元对应的目标用户占所述第一网元对应的所有目标用户的比率。目标用户的含义可以参见上文描述。应理解，第一网元对应的所有目标用户等于所有订阅网元对应的目标用户的总和。

以第一网元为UDM，该多个订阅网元为AMF#1至AMF#10以及SMF#1至SMF#10为例进行说明。该部分或全部订阅网元为AMF#1至AMF#5，那么对于AMF#1至AMF#5中任一AMF，其对应的目标用户的比率可以是该AMF上受影响的用户量与AMF#1至AMF#5这五个AMF上受影响的用户量之和的比率，也可以是该AMF上受影响的用户量与该UDM上所有受影响的用户量(即，AMF#1至AMF#10以及SMF#1至SMF#10这20个网元上受影响的用户量之和)的比率。

应理解，通知策略可以包括与第一网元存在交互的所有订阅网元(即，上文中描述的该多个订阅网元)的信息，也可以仅包括与第一网元存在交互的所有订阅网元中部分订阅网元的信息，该部分订阅网元例如可以是该多个订阅网元中对应的目标用户的比率较大(比如，大于预设阈值)的订阅网元。

在该通知策略包括第三种信息的情况下，网元发现设备110可以根据该部分或全部订阅网元中各订阅网元对应的目标用户的比率，确定该部分或全部订阅网元中各订阅网元所需的处理时间，即各订阅网元执行建立(或重建)上下文流程或者更新上下文流程所需的时间。

进一步地，网元发现设备110可以基于其所确定的该部分或全部订阅网元中各订阅网元所需的处理时间，确定所有订阅网元中每个订阅网元所对应的通知时间间隔，并根据该通知时间间隔向对应的订阅网元发送服务状态通知消息。

示例性的，网元发现设备110可以将一个订阅网元所需的处理时间作为该订阅网元对应的通知时间间隔。

示例性的，在确定了部分订阅网元中各订阅网元所需的处理时间的情况下，网元发现设备110可以基于任何机制确定所有订阅网元中其他订阅网元所需的处理时间，比如网元发现设备110可以认为该其他订阅网元所需的处理时间为0或者小于某一阈值。

基于该方案，网元发送设备可以在一个订阅网元执行完建立上下文流程或者更新上下文流程后再向另一订阅网元发送服务状态通知消息，从而能够避免多个订阅网元同时发起建立或更新上下文流程而导致的核心网信令负荷过重的问题。

(4)该多个订阅网元120中部分或全部订阅网元的信息，以及该部分或全部订阅网元中每个订阅网元的处理时间。其中，一个订阅网元的处理时间为该订阅网元执行建立上下文流程或者更新上下文流程所需的时间。

在该通知策略包括第四种信息的情况下，网元发现设备110可以基于该部分或全部订阅网元中各订阅网元所需的处理时间，确定所有订阅网元中每个订阅网元所对应的通知时间间隔，并根据该通知时间间隔向对应的订阅网元服务状态通知消息。

基于该方案，网元发送设备可以在一个订阅网元执行完建立上下文流程或者更新上下文流程后再向另一订阅网元发送服务状态通知消息，从而能够避免多个订阅网元同时发起建立或更新上下文流程而导致的核心网信令负荷过重的问题。

(5)该多个订阅网元中的部分或全部网元分别对应的通知时间间隔，通知时间间隔为发送服务状态通知消息的时间间隔。

在该通知策略包括第五种信息的情况下，网元发现设备110可以基于部分或全部网元分别对应的通知时间间隔，确定所有订阅网元中每个订阅网元对应的通知时间间隔，并可以根据所确定的通知时间间隔，向对应的订阅网元服务状态通知消息。

基于该方案，网元发送设备可以根据通知时间间隔，向订阅网元发送服务状态通知消息，从而能够避免多个订阅网元同时发起建立或更新上下文流程而导致的核心网信令负荷过重的问题。

需要说明的是，上述第二种信息、第三种信息和第四种信息可以相结合，但本申请对此不作限定。上述的第一种信息可以和其他几种信息中的任意一项或多项结合，从而网元发送设备可以结合该结束时间，确定所有订阅网元中各订阅网元所对应的通知时间间隔。

在一种可能的实现方式中，网元发现设备110根据所有订阅网元中各订阅网元对应的通知时间间隔，向对应的订阅网元服务状态通知消息，包括：

网元发现设备110根据所有订阅网元中各订阅网元对应的通知时间间隔和通知顺序，向对应的订阅网元服务状态通知消息。

其中，通知顺序为网元发现设备110向该多个订阅网元发送服务状态通知消息的顺序。

比如，所有订阅网元包括AMF和SMF，通知顺序为先AMF后SMF，SMF对应的通知时间间隔为30ms，则网元发现设备110可以在向AMF发送服务状态通知消息后30ms，向SMF发送服务状态通知消息。

可选地，通知顺序可以由网元发现设备110自主确定，也可以通过通知策略携带，本申请对此不作限定。

示例性的，第一网元是UDM，并且该UDM的割接是由于语音数据迁移所引起的，那么第一网元可以指示网元发现设备110先向AMF发送服务状态通知消息，从而AMF可以及时将UE注册到对应新侧UDM(即，第二网元)，那么第二网元在收到下行语音呼叫请求时，可以查找到正确的AMF，保证UE语音被叫成功，避免网络性能波动。

应理解，网元发现设备110确定了各订阅网元所对应的通知时间间隔和通知顺序，也就相当于确定了各订阅网元所对应的发送时机。

上述系统100可以是基于服务化架构的通信系统，例如第五代(5th generation，5G)系统、新无线(new radio，NR)或未来可能出现的其他的通信系统等。

比如，系统100中的网元发现设备可以是5G系统中的NRF。

图2示出了一个采用服务化架构的5G系统架构示意图。如图2所示，该系统200包括：短消息业务功能(short message service function，SMSF)、网络开放功能(networkexposure function，NEF)、鉴权服务器功能(authentication server function，AUSF)、PCF、统一数据管理(unified data management，UDM)、应用功能(application function，AF)、NRF、AMF、SMF、无线接入网(radio access network，RAN)、数据网络(data network，DN)、用户面功能(user plane function，UPF)和UE。图2中所示除N1、N2、N3、N4和N6以外的各接口，还包括如Nnef、Nnrf和Npcf等为相应网元对应的服务化接口。关于接口N1、N2、N3、N4和N6可以参见下文对图3所示的系统所作的说明。

其中，各网元主要功能描述如下：

SMSF：短消息业务功能。主要负责在短消息业务相关的控制功能，包括在AMF及短消息中心之间进行短消息数据包的转发，及根据运营商配置、用户签约信息执行短消息的计费控制。

NEF：网络开放功能。主要负责将网络侧的部分能力开放至第三方应用功能，从而支持第三方应用功能向核心网定制业务参数、订阅用户状态事件等。

AUSF：鉴权服务器功能。主要负责在归属地网络对用户进行鉴权，以及在AMF与UDM间转发鉴权向量等。

PCF：策略控制功能。主要负责针对会话、业务流级别进行计费、QoS带宽保障及移动性管理、UE策略决策等策略控制功能。该系统中，AMF与SMF所连接的PCF分别是接入和移动控制PCF(PCF for access and mobility control，AM PCF)和会话管理PCF(PCF forsession management，SM PCF)，在实际部署中AM PCF和SM PCF可能不是同一个PCF实体。

UDM：统一数据管理。主要负责管理签约数据、用户接入授权等功能。

AF：应用功能。主要传递应用侧对网络侧的需求，例如，服务质量(quality ofservice，QoS)需求等。AF可以是第三方功能实体，也可以是运营商部署的应用服务，如IP多媒体子系统(IP Multimedia Subsystem，IMS)语音呼叫业务。

NRF：网络仓库功能，用于实现网元服务的注册和发现功能。

AMF：接入和移动性管理功能。主要进行移动性管理、接入鉴权/授权等功能。此外，还负责在UE与PCF间传递用户策略。

SMF：会话管理功能。主要进行会话管理、PCF下发控制策略的执行、UPF的选择、UEIP地址分配等功能。

UPF：用户面功能实体。作为和数据网络的接口UPF，完成用户面数据转发、基于会话/流级的计费统计，带宽限制等功能。

(R)AN：(无线)接入网，对应5G中的不同接入网，如有线接入、无线基站接入等多种方式。

DN：数据网络，对应了相应的网络接入技术。

图3示出了非漫游场景下基于参考点的5G系统架构示意图。如图3所示，系统300包括：SMSF、AMF、SMF、PCF、AF、RAN、UDM、DN、UPF、UE和统一数据仓库(unified datarepository，UDR)。

其中，主要负责签约数据、策略数据、应用数据等类型数据的存取功能。其他各网元主要功能可以参见对图2所示的相应网元所作的说明。

其中，各接口功能描述如下：

N7：PCF与SMF之间的接口，用于下发PDU会话粒度以及业务数据流粒度控制策略。

N15：PCF与AMF之间的接口，用于下发UE策略及接入控制相关策略。

N5：AF与PCF之间的接口，用于应用业务请求下发以及网络事件上报。

N4：SMF与UPF之间的接口，用于控制面与用户面之间传递信息，包括控制面向用户面的转发规则、QoS控制规则、流量统计规则等的下发以及用户面的信息上报。

N11：SMF与AMF之间的接口，用于传递RAN和UPF之间的PDU会话隧道信息、传递发送给UE的控制消息、传递发送给RAN的无线资源控制信息等。

N1：AMF与UE之间的接口，接入无关，用于向UE传递QoS控制规则等。

N2：AMF与RAN之间的接口，用于传递核心网侧至RAN的无线承载控制信息等。

N8：AMF与UDM间的接口，用于AMF向UDM获取接入与移动性管理相关签约数据与鉴权数据，以及AMF向UDM注册UE当前移动性管理相关信息等。

N10：SMF与UDM间的接口，用于SMF向UDM获取会话管理相关签约数据，以及SMF向UDM注册UE当前会话相关信息等。

N35：UDM与UDR间的接口，用于UDM从UDR中获取用户签约数据信息。

N36：PCF与UDR间的接口，用于PCF从UDR中获取策略相关签约数据以及应用数据相关信息。

N3：RAN与UPF间的接口，用于在RAN与UPF间传递用户面数据。。

N6：UPF与DN连接间的接口，用于在UPF与DN间传递用户面数据。

N9：UPF与UPF间的接口，或是与DN相连的UPF与RAN相连的UPF间的接口，用于在UPF间传递用户面数据。

N20：AMF与SMSF间的接口，用于AMF触发SMSF向UDM发起短消息业务注册/去注册流程。

N21：SMSF与UDM间的接口，用于SMSF向UDM获取短消息业务相关签约数据，以及SMSF向UDM注册UE当前的短消息业务相关信息等。

应理解，本申请还可以应用于漫游场景下基于服务化架构的系统中。关于漫游场景下基于服务化接口和参考点的5G系统架构图可以参见现有技术，本申请不再赘述。

需要说明的是，图2和图3中包括的各个网元的命名仅是一个名字，名字对网元本身的功能不构成限定。在5G网络以及未来其它的网络中，上述各个网元也可以是其他的名字，本申请实施例对此不作具体限定。例如，在6G网络中，上述各个网元中的部分或全部可以沿用5G中的术语，也可能是其他命名，等等，在此进行统一说明，以下不再赘述。类似地图2和图3所示的网元之间的接口仅是一个示例，在5G网络以及未来其它的网络中，网元之间的接口也可以不是图中所示的接口，本申请对此不作限定。

本申请中，UE和用户均指终端设备，其可以为接入终端、V2X通信中的终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、无线通信设备、用户代理或用户装置。终端设备还可以是蜂窝电话、无绳电话、会话启动协议(sessioninitiation protocol，SIP)电话、无线本地环路(wireless local loop，WLL)站、个人数字处理(personal digital assistant，PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备，未来5G网络中的终端设备或者未来演进的公用陆地移动通信网络(public land mobile network，PLMN)中的终端设备等，本申请实施例对此并不限定。终端设备还可以包括V2X设备，例如为车辆或车辆中的车载单元(on board unit，OBU)。

其中，(R)AN节点可以是演进型节点B(evolved Node B，eNB)、无线网络控制器(Radio Network Controller，RNC)、节点B(Node B，NB)、基站控制器(Base StationController，BSC)、基站收发台(Base Transceiver Station，BTS)、家庭基站(例如，Homeevolved NodeB，或Home Node B，HNB)、基带单元(BaseBand Unit，BBU)，无线保真(Wireless Fidelity，WIFI)系统中的接入点(Access Point，AP)、无线中继节点、无线回传节点、传输点(transmission point，TP)或者发送接收点(transmission and receptionpoint，TRP)等，还可以为gNB，或，传输点(TRP或TP)，5G系统中的基站的一个或一组(包括多个天线面板)天线面板，或者，还可以为构成gNB或传输点的网络节点，如基带单元(BBU)，或，分布式单元(distributed unit，DU)等。(R)AN还可以是云无线接入网络(cloud radioaccess network，CRAN)场景下的无线控制器。网络设备还可以是可穿戴设备或车载设备等。

在一些部署中，gNB可以包括集中式单元(centralized unit，CU)和DU。gNB还可以包括射频单元(radio unit，RU)。CU实现gNB的部分功能，DU实现gNB的部分功能，比如，CU实现无线资源控制(radio resource control，RRC)，分组数据汇聚层协议(packet dataconvergence protocol，PDCP)层的功能，DU实现无线链路控制(radio link control，RLC)层、媒体接入控制(media access control，MAC)层和物理(physical，PHY)层的功能。由于RRC层的信息最终会变成PHY层的信息，或者，由PHY层的信息转变而来，因而，在这种架构下，高层信令，如RRC层信令，也可以认为是由DU发送的，或者，由DU+CU发送的。

图4是本申请实施例提供的通信装置400的示意图。所述通信装置400可以是本申请所涉及的任一网元，如第一网元、网元发现设备、第二网元或订阅网元等，并且可以实现本文中描述的该网元所能实现的功能。

应理解，通信装置400可以是实体设备，也可以是实体设备的部件(例如，集成电路，芯片等等)，还可以是实体设备中的功能模块。

比如，通信装置400可以用于实现本文中所描述的第一网元的功能。如通信装置400可以是第一网元，也可以是第一网元中的部件(例如，集成电路，芯片等等)，还可以是功能模块。

又如，通信装置400可以用于实现本文中所描述的网元发现设备的功能。如通信装置400可以是网元发现设备，也可以是网元发现设备中的部件(例如，集成电路，芯片等等)，还可以是网元发现设备中的功能模块。

该装置400可用于实现本申请提供的方法，装置400可以包括一个或多个处理器401。

所述处理器401也可以称为处理单元，可以实现一定的控制功能。所述处理器401可以是通用处理器或者专用处理器等。例如可以是基带处理器或中央处理器。基带处理器可以用于对通信协议以及通信数据进行处理，中央处理器可以用于对通信装置(如，第一网元、网元发现设备、第二网元或订阅网元等)进行控制，执行软件程序，处理软件程序的数据。

在一种可选的设计中，处理器401也可以存有指令403，所述指令403可以被所述处理器运行，使得所述装置400执行本申请方法实施例中描述的方法。

在另一种可选的设计中，处理器401中可以包括用于实现接收和发送功能的收发单元。例如该收发单元可以是收发电路，或者是接口，或者是接口电路。用于实现接收和发送功能的收发电路、接口或接口电路可以是分开的，也可以集成在一起。上述收发电路、接口或接口电路可以用于代码/数据的读写，或者，上述收发电路、接口或接口电路可以用于信号的传输或传递。

在又一种可能的设计中，装置400可以包括电路，所述电路可以实现本申请方法实施例中发送或接收或者通信的功能。

可选的，所述装置400还可以包括一个或多个存储器402，其上可以存有指令404，所述指令可在所述处理器401上被运行，使得所述装置400执行本申请方法实施例中描述的方法。可选的，所述存储器402中还可以存储有数据。所述处理器401和存储器402可以单独设置，也可以集成在一起。

可选的，所述装置400还可以包括收发器405和/或天线406。所述处理器401可以称为处理单元，对所述装置400进行控制。所述收发器405可以称为收发单元、收发机、收发电路或者收发器等，用于实现收发功能。

示例性的，装置400可以是一个通用计算机设备或者是一个专用计算机设备。在具体实现中，装置400可以是台式机、便携式电脑、网络服务器、掌上电脑(Personal DigitalAssistant，PDA)、移动手机、平板电脑、无线终端设备、通信设备、嵌入式设备或有图4中类似结构的设备。本发明实施例不限定，装置400的类型。

为使本领域技术人员更好的理解本申请，下面结合本文所描述的5G系统，分别以UDM和AMF需要进行割接为例，结合图5和图6，对本申请提供的通知服务状态的方法进行举例说明。

图5是本申请提供的通知服务状态的方法的示意性流程图。应理解，图5所示的NRF对应于网元发现设备，旧侧UDM对应于第一网元，新侧UDM对应于第二网元，AMF、SMF和SMSF均为订阅网元。以下对图5所示的各步骤进行详细说明。

S501，OAM更新NRF中的UDM组标识(Group ID)与用户永久标识(subscriptionpermanent identifier，SUPI)范围(range)、通用公开用户标识(generic publicsubscription identifier，GPSI)range和路由指示(routing indicator，RI)间的映射关系。

比如，旧侧UDM发生故障、退网、或者需要对旧侧UDM进行负载均衡(部分签约数据迁移至新的设备)时，在NRF向各订阅网元发送服务状态通知消息前，NRF中所保存的UDMGroup ID与SUPI range、GPSI range和RI间的映射关系可以提前进行更新。

应理解，SUPI range即前文所述的用户号段。

S502，旧侧UDM向NRF发送请求消息。其中，该请求消息包括通知策略。

比如，旧侧UDM向NRF发送服务去注册请求消息，以触发NRF通知所有相关订阅网元当前UDM不可用。再如，旧侧UDM向NRF发送服务更新请求消息，该服务更新请求消息可以携带更新后的服务信息，如更新UDM所支持的用户号段列表(SUPI range,GPSI range,SUCI)，或UDM所提供的服务列表等。

S503，NRF根据通知策略，向各订阅网元发送服务状态通知消息，以触发AMF/SMF/SMSF向新侧UDM发送注册请求消息。

应理解，该注册请求消息可以是Nudm_UECM_Registration request。关于通知策略有可能包括的内容，以及NRF如何根据通知策略，向各订阅网元发送服务状态通知消息，可以参见上文描述，这里不再赘述。

S504，AMF/SMF/SMSF向新侧UDM发送注册请求消息。

AMF/SMF/SMSF在接收到服务状态通知消息后，可以确定受影响的用户，并获取新侧UDM信息。在获取到新侧UDM的信息后，AMF/SMF/SMSF为受影响的用户向新侧UDM重新发送注册请求消息，以建立或更新受影响的用户的上下文。

如前文所述，该通知策略可以包括新侧UDM的信息，或者可以由OAM向NRF提供新侧UDM的信息。

S505，AMF/SMF/SMSF与新侧UDM进行后续的注册流程。

应理解，AMF/SMF/SMSF的注册流程可以参照现有技术，本文不再赘述。

基于该方案，NRF可以基于旧侧UDM提供的通知策略，基于合理的方式向AMF/SMF/SMSF发送服务状态通知消息。

图6是本申请提供的通知服务状态的方法的示意性流程图。应理解，图6所示的NRF对应于网元发现设备，旧侧AMF对应于第一网元，新侧AMF对应于第二网元，SMF、PCF和AUSF均为订阅网元。以下对图6所示的各步骤进行详细说明。

S601，旧侧AMF向NRF发送请求消息。其中，该请求消息包括通知策略。

旧侧AMF确定需要进行割接时，比如旧侧AMF自主确定需要进行割接或者由OAM触发旧侧AMF进行割接时，旧侧AMF向NRF发送请求消息。比如，旧侧AMF不可用时，旧侧AMF向NRF发送服务去注册请求消息，以触发NRF通知所有相关订阅网元当前AMF不可用。再如，旧侧AMF需要进行更新时，旧侧AMF向NRF发送服务更新请求消息。

S602，NRF根据通知策略，向各订阅网元发送服务状态通知消息，以触发SMF/PCF/AUSF向新侧AMF发送建立上下文请求消息(或，上下文建立请求消息)或更新上下文请求消息(或，上下文更新请求消息)。

关于通知策略有可能包括的内容，以及NRF如何根据通知策略，向各订阅网元发送服务状态通知消息，可以参见上文描述，这里不再赘述。

S603，SMF/PCF/AUSF向新侧AMF发送建立上下文请求消息或更新上下文请求消息。

SMF/PCF/AUSF在接收到服务状态通知消息后，确定受影响的用户，并获取新侧AMF信息。在获取到新侧AMF的信息后，SMF/PCF/AUSF为受影响的用户向新侧AMF发送建立上下文请求消息或更新上下文请求消息，以建立或更新受影响的用户的上下文。

如前文所述，该通知策略可以包括新侧AMF的信息，或者可以由OAM向NRF提供新侧AMF的信息。

S604，SMF/PCF/AUSF与新侧AMF进行后续的建立或更新上下文流程。

应理解，SMF/PCF/AUSF的建立或更新上下文流程可以参照现有技术，本文不再赘述。

基于该方案，NRF可以基于旧侧AMF提供的通知策略，基于合理的方式向SMF/PCF/AUSF发送服务状态通知消息。

上面描述了根据本申请实施例的方法，下面将描述根据本申请实施例的装置。

图7示出了根据本申请实施例的通信装置700的示意性框图。该通信装置700可以包括接收单元710和发送单元720。可选地，该通信装置700还可以包括处理单元730。

通信装置700可以是本申请涉及的任一网元，并且可以实现该网元所能实现的功能。应理解，通信装置700可以是实体设备，也可以是实体设备的部件(例如，集成电路，芯片等等)，还可以是实体设备中的功能模块。

在一种实现方式中，通信装置700可以用于实现本文中所描述的网元发现设备的功能。如通信装置700可以是网元发现设备，也可以是网元发现设备中的部件(例如，集成电路，芯片等等)，还可以是网元发现设备中的功能模块。

具体地，接收单元710，用于接收来自第一网元的请求消息，所述请求消息为服务去注册请求消息或者服务更新请求消息，所述请求消息包括通知策略；发送单元720，用于根据所述通知策略，向订阅了所述第一网元服务状态的多个订阅网元发送服务状态通知消息。

可选地，处理单元730用于根据该通知策略确定多个发送时机；以及，发送单元720，用于根据该通知策略，向该多个订阅网元120发送服务状态通知消息，包括：

发送单元720，用于在该多个发送时机，向对应的订阅网元120发送服务状态通知消息。其中，该多个发送时机与该多个订阅网元120对应，一个发送时机对应至少一个订阅网元120。

可选地，所述服务状态通知消息用于触发所述订阅网元发起建立上下文流程或更新上下文流程。

可选地，所述服务状态通知消息还包括一个或多个第二网元的信息，所述第二网元为支持提供与所述第一网元相同服务的网元，或者所述第二网元为与所述第一网元具有相同功能的网元。

可选地，所述通知策略包括结束时间，其中所述网元发现设备需要在所述结束时间前向所述多个订阅网元发送所述服务状态通知消息。

可选地，所述通知策略包括所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元对应的目标用户的数量，所述目标用户为需要执行建立上下文流程或者更新上下文流程的用户。

可选地，所述通知策略包括所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元对应的目标用户的比率，

其中，所述目标用户为需要执行建立上下文流程或者更新上下文流程的用户，一个订阅网元对应的目标用户的比率为该订阅网元对应的目标用户占所述部分或全部订阅网元对应的所有目标用户的比率，或者，一个订阅网元对应的目标用户的比率为该订阅网元对应的目标用户占所述第一网元对应的所有目标用户的比率。

可选地，所述通知策略包括所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元的处理时间，一个订阅网元的处理时间为该订阅网元执行建立上下文流程或者更新上下文流程所需的时间。

可选地，所述通知策略包括所述多个订阅网元中的部分或全部网元分别对应的通知时间间隔，所述通知时间间隔为发送所述服务状态通知消息的时间间隔。

可选地，所述通知策略包括通知顺序，所述通知顺序为所述网元发现设备向所述多个订阅网元发送所述服务状态通知消息的顺序。

在另一种实现方式中，通信装置700可以用于实现本文中所描述的第一网元的功能。如通信装置700可以是第一网元，也可以是第一网元中的部件(例如，集成电路，芯片等等)，还可以是第一网元中的功能模块。

具体地，处理单元730，用于生成请求消息，所述请求消息为服务去注册请求消息或者服务更新请求消息，所述请求消息包括通知策略；发送单元720，用于向网元发现设备发送该请求消息。其中，该通知策略用于该网元发现设备向订阅了所述通信装置700的多个订阅网元发送服务状态通知消息。

在又一种实现方式中，通信装置700可以用于实现本文中所描述的第二网元的功能。如通信装置700可以是订阅网元，也可以是订阅网元中的部件(例如，集成电路，芯片等等)，还可以是订阅网元中的功能模块。

具体地，接收单元710，用于接收网元发现设备发送的服务状态通知消息，该服务状态通知消息包括一个或多个第二网元的信息，所述第二网元为支持提供与第一网元相同服务的网元，或者所述第二网元为与所述第一网元具有相同功能的网元，通信装置700订阅了所述第一网元服务状态；处理单元730，用于根据所述服务状态通知消息，发起建立上下文流程或更新上下文流程。

应理解，在本实施例中，通信装置700是以功能模块的形式来呈现。这里的“单元”可以指特定应用集成电路ASIC、电路、执行一个或多个软件或固件程序的处理器和存储器、集成逻辑电路，和/或其他可以提供上述功能的器件。在一个简单的实施例中，本领域的技术人员可以想到装置700可以采用图4所示的形式。处理单元730可以通过图4所示的处理器401来实现。可选地，如果图4所示的装置包括存储器402，处理单元730可以通过处理器401和存储器402来实现。接收单元710和发送单元720可以通过图4所示的收发器405来实现。具体的，处理器通过执行存储器中存储的计算机程序来实现。可选地，当所述装置700是芯片时，那么接收单元710和发送单元720的功能和/或实现过程还可以通过管脚或电路等来实现。可选地，所述存储器可以为所述芯片内的存储单元，比如寄存器、缓存等，所述存储单元还可以是所述计算机设备内的位于所述芯片外部的存储单元，如图4所的存储器402，或者，也可以是部署在其他系统或设备中的存储单元，不在所述计算机设备内。

应理解，本申请实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(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)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rateSDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(directrambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

本申请还提供了一种计算机可读介质，其上存储有计算机程序，该计算机程序被计算机执行时实现上述任一方法实施例的功能。

本申请还提供了一种计算机程序产品，该计算机程序产品被计算机执行时实现上述任一方法实施例的功能。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc，DVD))、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。

应理解，说明书通篇中提到的“实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各个实施例未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

还应理解，在本申请中，“当…时”、“若”以及“如果”均指在某种客观情况下UE或者基站会做出相应的处理，并非是限定时间，且也不要求UE或基站实现时一定要有判断的动作，也不意味着存在其它限定。

另外，本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。本文中描述“A/B”，除SAC/AS以外，均表示A或B。本文中术语“……中的至少一个”或“……中的至少一种”，表示所列出的各项的全部或任意组合，例如，“A、B和C中的至少一种”，可以表示：单独存在A，单独存在B，单独存在C，同时存在A和B，同时存在B和C，同时存在A、B和C这六种情况。

应理解，在本申请各实施例中，“与A相应的B”表示B与A相关联，根据A可以确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种通知服务状态的方法，其特征在于，包括：

网元发现设备接收来自第一网元的请求消息，所述请求消息为服务去注册请求消息或者服务更新请求消息，所述请求消息包括通知策略，所述通知策略包括以下一项或多项：

结束时间，其中，所述网元发现设备需要在所述结束时间前向所述第一网元服务状态的多个订阅网元发送服务状态通知消息，

所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元对应的目标用户的数量，其中，所述目标用户为需要执行建立上下文流程或者更新上下文流程的用户，

所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元对应的目标用户的比率，其中，所述目标用户为需要执行建立上下文流程或者更新上下文流程的用户，一个订阅网元对应的目标用户的比率为该订阅网元对应的目标用户占所述部分或全部订阅网元对应的所有目标用户的比率，或者，一个订阅网元对应的目标用户的比率为该订阅网元对应的目标用户占所述第一网元对应的所有目标用户的比率，

所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元的处理时间，其中，一个订阅网元的处理时间为该订阅网元执行建立上下文流程或者更新上下文流程所需的时间，

多个订阅网元中的部分或全部网元分别对应的通知时间间隔，所述通知时间间隔为发送所述服务状态通知消息的时间间隔，或

通知顺序，所述通知顺序为所述网元发现设备向所述多个订阅网元发送所述服务状态通知消息的顺序；

所述网元发现设备根据所述通知策略，向订阅了所述第一网元服务状态的所述多个订阅网元发送所述服务状态通知消息。

2.如权利要求1所述的方法，其特征在于，所述服务状态通知消息用于触发所述订阅网元发起建立上下文流程或更新上下文流程。

3.如权利要求1所述的方法，其特征在于，所述服务状态通知消息还包括一个或多个第二网元的信息，所述第二网元为支持提供与所述第一网元相同服务的网元，或者所述第二网元为与所述第一网元具有相同功能的网元。

4.一种通信系统，其特征在于，包括网元发现设备和多个订阅网元；

所述网元发现设备，用于接收来自第一网元的请求消息，所述请求消息为服务去注册请求消息或者服务更新请求消息，所述请求消息包括通知策略，所述通知策略包括以下一项或多项：

结束时间，其中，所述网元发现设备需要在所述结束时间前向所述第一网元服务状态的所述多个订阅网元发送服务状态通知消息，

所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元对应的目标用户的数量，其中，所述目标用户为需要执行建立上下文流程或者更新上下文流程的用户，

所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元对应的目标用户的比率，其中，所述目标用户为需要执行建立上下文流程或者更新上下文流程的用户，一个订阅网元对应的目标用户的比率为该订阅网元对应的目标用户占所述部分或全部订阅网元对应的所有目标用户的比率，或者，一个订阅网元对应的目标用户的比率为该订阅网元对应的目标用户占所述第一网元对应的所有目标用户的比率，

所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元的处理时间，其中，一个订阅网元的处理时间为该订阅网元执行建立上下文流程或者更新上下文流程所需的时间，

多个订阅网元中的部分或全部网元分别对应的通知时间间隔，所述通知时间间隔为发送所述服务状态通知消息的时间间隔，或

通知顺序，所述通知顺序为所述网元发现设备向所述多个订阅网元发送所述服务状态通知消息的顺序；

根据所述通知策略，向订阅了所述第一网元服务状态的所述多个订阅网元发送所述服务状态通知消息；

所述订阅网元，用于接收所述服务状态通知消息。

5.如权利要求4所述的系统，其特征在于，所述订阅网元还用于：

根据所述服务状态通知消息，发起建立上下文流程或更新上下文流程。

6.如权利要求5所述的系统，其特征在于，所述服务状态通知消息还包括一个或多个第二网元的信息，所述第二网元为支持提供与所述第一网元相同服务的网元，或者所述第二网元为与所述第一网元具有相同功能的网元；

以及，所述订阅网元，用于根据所述服务状态通知消息，发起建立上下文流程或更新上下文流程，包括：

所述订阅网元，用于根据所述一个或多个第二网元的信息，向所述一个或多个第二网元中的部分或全部第二网元，发起建立上下文流程或更新上下文流程。

7.如权利要求4至6中任一项所述的系统，其特征在于，所述系统还包括第一网元；

所述第一网元，用于在确定所述第一网元不可用或者需要进行服务更新时，向所述网元发现设备发送所述请求消息。

8.一种通信装置，其特征在于，包括：

接收单元，用于接收来自第一网元的请求消息，所述请求消息为服务去注册请求消息或者服务更新请求消息，所述请求消息包括通知策略，所述通知策略包括以下一项或多项：

结束时间，其中，网元发现设备需要在所述结束时间前向所述第一网元服务状态的多个订阅网元发送服务状态通知消息，

所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元对应的目标用户的数量，其中，所述目标用户为需要执行建立上下文流程或者更新上下文流程的用户，

所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元对应的目标用户的比率，其中，所述目标用户为需要执行建立上下文流程或者更新上下文流程的用户，一个订阅网元对应的目标用户的比率为该订阅网元对应的目标用户占所述部分或全部订阅网元对应的所有目标用户的比率，或者，一个订阅网元对应的目标用户的比率为该订阅网元对应的目标用户占所述第一网元对应的所有目标用户的比率，

所述多个订阅网元中部分或全部订阅网元的信息，以及所述部分或全部订阅网元中每个订阅网元的处理时间，其中，一个订阅网元的处理时间为该订阅网元执行建立上下文流程或者更新上下文流程所需的时间，

多个订阅网元中的部分或全部网元分别对应的通知时间间隔，所述通知时间间隔为发送所述服务状态通知消息的时间间隔，或

通知顺序，所述通知顺序为所述网元发现设备向所述多个订阅网元发送所述服务状态通知消息的顺序；

发送单元，用于根据所述通知策略，向订阅了所述第一网元服务状态的所述多个订阅网元发送所述服务状态通知消息。

9.如权利要求8所述的装置，其特征在于，所述服务状态通知消息用于触发所述订阅网元发起建立上下文流程或更新上下文流程。

10.如权利要求8所述的装置，其特征在于，所述服务状态通知消息还包括一个或多个第二网元的信息，所述第二网元为支持提供与所述第一网元相同服务的网元，或者所述第二网元为与所述第一网元具有相同功能的网元。

Images