CN117336711A

CN117336711A - 安全决策协商方法及网元

Info

Publication number: CN117336711A
Application number: CN202210728568.XA
Authority: CN
Inventors: 宋雨容; 刘斐; 王东晖
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-06-25
Filing date: 2022-06-25
Publication date: 2024-01-02
Also published as: WO2023246457A1

Abstract

一种安全决策协商方法及网元，可以适用于各类通信系统，如IoT系统、LTE系统、5G系统、MTC系统、M2M系统、D2D系统、V2X系统、WLAN系统(如Wi‑Fi)等。该方法包括：第一网元基于需求方的安全需求和能力方的安全能力确定安全决策；以及该第一网元发送包括安全决策的消息。本申请实施例可以有效保证安全决策协商的灵活性。

Description

安全决策协商方法及网元

技术领域

本申请涉及通信技术领域，尤其涉及一种安全决策协商方法及网元。

背景技术

第五代(5^th-generation，5G)通信系统中的安全决策协商是在非接入层(non-access stratum，NAS)协议的安全模式命令(securitymodecommand)阶段进行。流程如下所示：核心网设备发送安全模式命令消息给终端设备，该安全模式命令消息携带选定的演进分组系统(evolved packet system，EPS)NAS安全算法单元(element，IE)，用于声明网络提供给终端设备的加密和完整性保护算法；最后，终端设备设置加密和完整性保护算法。

然而，未来通信系统中可能会涉及更多类型的终端设备和第三方设备等，由此，导致上述安全决策协商的方法还有待改进。

发明内容

本申请实施例提供一种安全决策协商方法及网元，提高了安全决策协商的灵活性。

第一方面，本申请实施例提供一种安全决策协商方法，所述方法包括：第一网元基于需求方的安全需求和能力方的安全能力确定安全决策；所述第一网元发送包括所述安全决策的消息。

本申请实施例中，第一网元可以有效地结合需求方的安全需求和能力方的安全能力制定安全决策，不仅提高了安全决策协商的灵活性，而且还可以使得需求方和能力方能够通过协商的方式来确定安全决策，提高了需求方的参与度，保证了安全决策的合理性和有效性。

在一种可能的实现方式中，所述第一网元包括所述需求方，所述方法还包括：所述需求方接收包括所述安全能力的消息。

在一种可能的实现方式中，所述需求方接收包括所述安全能力的消息之前，所述方法还包括：所述需求方发送请求消息，所述请求消息用于请求所述能力方的安全能力。

本申请实施例中，需求方通过获取能力方的安全能力，从而可以结合自身的安全需求以及能力方的安全能力确定安全决策，不仅有效保证了需求方可以自主参与到安全决策协商的流程中，而且还使得安全决策的制定更合理有效。

在一种可能的实现方式中，所述第一网元包括所述能力方，所述方法还包括：所述能力方接收包括所述安全需求的消息。

在一种可能的实现方式中，所述能力方接收包括所述安全需求的消息之前，所述方法还包括：所述能力方发送请求消息，所述请求消息用于请求需求方的安全需求。

本申请实施例中，能力方通过获取需求方的安全需求，从而可以结合需求方的安全需求确定安全决策，保证安全决策的制定更合理，使得安全决策协商的流程更灵活。

在一种可能的实现方式中，所述第一网元基于需求方的安全需求和能力方的安全能力确定安全决策之前，所述方法还包括：所述第一网元从分布式账本中获取所述安全需求和所述安全能力。

本申请实施例中，通过将安全需求和安全能力保存至分布式账本，不仅可以有效融合通信网络和分布式账本技术(区块链的一种)，而且还能够提高安全需求和安全能力的安全性。

在一种可能的实现方式中，所述第一网元发送包括所述安全决策的消息，包括：所述第一网元将所述安全决策上传至分布式账本中。

本申请实施例中，通过将安全决策上传至分布式账本中，可以方便后续需要使用该安全决策的网元从分布式账本中下载该安全决策，保证了安全决策的安全性，提高使用该安全决策的网元获取该安全决策的灵活性。

在一种可能的实现方式中，所述第一网元基于需求方的安全需求和能力方的安全能力确定安全决策包括：所述第一网元基于所述安全需求中第一位的取值和所述安全能力中第一位的取值的运算或映射结果确定所述安全决策中第一位的取值；或者，所述第一网元基于所述安全需求中的优先级信息和所述安全能力确定所述安全决策。

第二方面，本申请实施例提供一种安全决策协商方法，所述方法包括：需求方发送包括安全需求的消息；所述需求方接收包括安全决策的消息，所述安全决策对应于所述安全需求。

在一种可能的实现方式中，所述安全决策对应于所述安全需求包括：所述安全决策为基于所述安全需求和能力方的安全能力协商的结果。

第三方面，本申请实施例提供一种安全决策协商方法，所述方法包括：能力方发送包括安全能力的消息；所述能力方接收包括安全决策的消息，所述安全决策为基于所述安全能力和需求方的安全需求协商的结果。

结合第一方面、第二方面和第三方面，在一种可能的实现方式中，所述安全需求包括如下至少一项信息：安全粒度、认证方法、密钥能力、隐私保护、可信证明、跨运营商、分布式账本。

本申请实施例中，安全需求中通过包括上述信息，可使得第一网元结合需求方的安全需求制定安全决策，从而使得不同类型的需求方可以有不同的安全决策，提高安全决策协商的灵活性，满足差异化的安全需求。

结合第一方面、第二方面和第三方面，在一种可能的实现方式中，所述安全需求包括如下至少一项信息的优先级信息：加密算法、完整性保护算法、认证方法、密钥能力、隐私保护、可信证明、跨运营商、分布式账本。

本申请实施例中，安全需求中通过包括不同安全功能的优先级信息，可使得第一网元能够结合不同的优先级信息以及安全能力制定安全决策，进一步提高安全决策的准确性。

结合第一方面、第二方面和第三方面，在一种可能的实现方式中，所述安全决策用于确定可信向量(trustworthiness vector，TV)，所述TV包括如下至少一项信息：隐私保护、可信证明、跨运营商和分布式账本。

本申请实施例中，TV中通过包括更多类型的信息，可使得通信双方能够有效地基于可信向量进行通信。

结合第一方面、第二方面和第三方面，在一种可能的实现方式中，所述第一网元包括如下任一项：终端设备、应用功能(application function，AF)、可信网元、接入与移动性管理功能(access and mobility management function，AMF)、网络开放功能(networkexposure function，NEF)、鉴权服务功能(authentication server function，AUSF)、接入网设备。

需要说明的是，上述能力方和需求方可以为同一类型的网元，也可以为不同类型的网元，本申请实施例对此不作限定。

第四方面，本申请实施例提供一种第一网元，用于执行第一方面或第一方面的任意可能的实现方式中的方法。所述第一网元包括具有执行第一方面或第一方面的任意可能的实现方式的单元。

第五方面，本申请实施例提供一种需求方，用于执行第二方面或第二方面的任意可能的实现方式中的方法。所述需求方包括具有执行第二方面或任意可能的实现方式的单元。

第六方面，本申请实施例提供一种能力方，用于执行第三方面或第三方面的任意可能的实现方式中的方法。所述能力方包括具有执行第三方面或第三方面的任意可能的实现方式的单元。

第七方面，本申请实施例提供一种第一网元，所述第一网元包括处理器，用于执行上述第一方面或第一方面的任意可能的实现方式所示的方法。或者，所述处理器用于执行存储器中存储的程序，当所述程序被执行时，上述第一方面或第一方面的任意可能的实现方式所示的方法被执行。

在一种可能的实现方式中，所述存储器位于所述第一网元之外。

在一种可能的实现方式中，所述存储器位于所述第一网元之内。

本申请实施例中，处理器和存储器还可以集成于一个器件中，即处理器和存储器还可以被集成在一起。

在一种可能的实现方式中，所述第一网元还包括收发器，该收发器，用于接收信号或发送信号。

第八方面，本申请实施例提供一种需求方，所述需求方包括处理器，用于执行上述第二方面或任意可能的实现方式所示的方法。或者，所述处理器用于执行存储器中存储的程序，当所述程序被执行时，上述第二方面或第二方面的任意可能的实现方式所示的方法被执行。

在一种可能的实现方式中，所述存储器位于所述需求方之外。

在一种可能的实现方式中，所述存储器位于所述能力方之内。

在本申请实施例中，处理器和存储器还可以集成于一个器件中，即处理器和存储器还可以被集成在一起。

在一种可能的实现方式中，所述需求方还包括收发器，该收发器，用于接收信号或发送信号。

第九方面，本申请实施例提供一种能力方，所述能力方包括处理器，用于执行上述第三方面或任意可能的实现方式所示的方法。或者，所述处理器用于执行存储器中存储的程序，当所述程序被执行时，上述第三方面或第三方面的任意可能的实现方式所示的方法被执行。

在一种可能的实现方式中，所述存储器位于所述能力方之外。

在一种可能的实现方式中，所述能力方还包括收发器，该收发器，用于接收信号或发送信号。

第十方面，本申请实施例提供一种第一网元，所述第一网元包括逻辑电路和接口，所述逻辑电路和所述接口耦合；所述逻辑电路，用于基于需求方的安全需求和能力方的安全能力确定安全决策；所述接口，用于输出包括所述安全决策的消息。

在一种可能的实现方式中，所述接口，还用于输入包括所述安全能力的消息。

在一种可能的实现方式中，所述接口，还用于输出请求消息，所述请求消息用于请求所述能力方的安全能力。

在一种可能的实现方式中，所述接口，还用于输入包括所述安全需求的消息。

在一种可能的实现方式中，所述接口，还用于输出请求消息，所述请求消息用于请求所述需求方的安全需求。

在一种可能的实现方式中，所述逻辑电路，具体用于从分布式账本中获取所述安全需求和所述安全能力。

在一种可能的实现方式中，所述逻辑电路，具体用于通过所述接口将所述安全决策上传至分布式账本中。

在一种可能的实现方式中，所述逻辑电路，具体用于基于所述安全需求中第一位的取值和所述安全能力中第一位的取值的运算或映射结果确定所述安全决策中第一位的取值；或者，基于所述安全需求中的优先级信息和所述安全能力确定所述安全决策。

第十一方面，本申请实施例提供一种需求方，所述需求方包括逻辑电路和接口，所述逻辑电路和所述接口耦合；所述逻辑电路，用于通过所述接口输出包括安全需求的消息；以及通过所述接口输入包括安全决策的消息，所述安全决策对应于所述安全需求。

第十二方面，本申请实施例提供一种能力方，所述能力方包括逻辑电路和接口，所述逻辑电路和所述接口耦合；所述逻辑电路，用于通过所述接口输出包括安全能力的消息；以及通过所述接口输入包括安全决策的消息，所述安全决策为基于所述安全能力和需求方的安全需求协商的结果。

第十三方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质用于存储计算机程序，当其在计算机上运行时，使得上述第一方面或第一方面的任意可能的实现方式所示的方法被执行。

第十四方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质用于存储计算机程序，当其在计算机上运行时，使得上述第二方面或第二方面的任意可能的实现方式所示的方法被执行。

第十五方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质用于存储计算机程序，当其在计算机上运行时，使得上述第三方面或第三方面的任意可能的实现方式所示的方法被执行。

第十六方面，本申请实施例提供一种计算机程序产品，该计算机程序产品包括计算机程序或计算机代码或指令，当其在计算机上运行时，使得上述第一方面或第一方面的任意可能的实现方式所示的方法被执行。

第十七方面，本申请实施例提供一种计算机程序产品，该计算机程序产品包括计算机程序或计算机代码或指令，当其在计算机上运行时，使得上述第二方面或第二方面的任意可能的实现方式所示的方法被执行。

第十八方面，本申请实施例提供一种计算机程序产品，该计算机程序产品包括计算机程序或计算机代码或指令，当其在计算机上运行时，使得上述第三方面或第三方面的任意可能的实现方式所示的方法被执行。

第十九方面，本申请实施例提供一种计算机程序，该计算机程序在计算机上运行时，上述第一方面或第一方面的任意可能的实现方式所示的方法被执行。

第二十方面，本申请实施例提供一种计算机程序，该计算机程序在计算机上运行时，上述第二方面或第二方面的任意可能的实现方式所示的方法被执行。

第二十一方面，本申请实施例提供一种计算机程序，该计算机程序在计算机上运行时，上述第三方面或第三方面的任意可能的实现方式所示的方法被执行。

第二十二方面，本申请实施例提供一种通信系统，该通信系统包括第一网元和需求方，所述第一网元用于执行上述第一方面所示的方法，所述需求方用于执行上述第二方面所述的方法；或者，所述通信系统包括第一网元和能力方，所述第一网元用于执行上述第一方面所示的方法，所述能力方用于执行上述第三方面所示的方法。

可选地，所述通信系统包括需求方和能力方，关于需求方和能力方的具体说明可以参考下文，这里先不一一详述。上述各个方面中示出的需求方和能力方均可以理解为一种网元。

关于第二方面至第二十二方面的有益效果可以参考第一方面。

附图说明

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

图2是本申请实施例提供的一种安全决策协商方法的流程示意图；

图3是本申请实施例提供的一种安全决策协商方法的流程示意图；

图4a是本申请实施例提供的一种安全需求的结构示意图；

图4b是本申请实施例提供的一种安全能力的结构示意图；

图4c是本申请实施例提供的一种安全决策的结构示意图；

图5a是本申请实施例提供的一种包括优先级信息的结构示意图；

图5b是本申请实施例提供的一种包括优先级信息的结构示意图；

图5c是本申请实施例提供的一种可信向量的结构示意图；

图6a是本申请实施例提供的一种安全决策协商方法的流程示意图；

图6b是本申请实施例提供的一种安全决策协商方法的流程示意图；

图7a是本申请实施例提供的一种安全决策协商方法的流程示意图；

图7b是本申请实施例提供的一种安全决策协商方法的流程示意图；

图8是本申请实施例提供的一种安全决策协商方法的流程示意图；

图9a是本申请实施例提供的一种安全决策协商方法的流程示意图；

图9b是本申请实施例提供的一种安全决策协商方法的流程示意图；

图9c是本申请实施例提供的一种安全决策协商方法的流程示意图；

图9d是本申请实施例提供的一种安全决策协商方法的流程示意图；

图10a是本申请实施例提供的一种安全决策协商方法的流程示意图；

图10b是本申请实施例提供的一种安全决策协商方法的流程示意图；

图11a是本申请实施例提供的一种安全决策协商方法的流程示意图；

图11b是本申请实施例提供的一种安全决策协商方法的流程示意图；

图12a是本申请实施例提供的一种安全决策协商方法的流程示意图；

图12b是本申请实施例提供的一种安全决策协商方法的流程示意图；

图13a是本申请实施例提供的一种上传安全标签的流程示意图；

图13b是本申请实施例提供的一种下载安全标签的流程示意图；

图13c是本申请实施例提供的一种更新安全标签的流程示意图；

图14是本申请实施例提供的一种网元的结构示意图；

图15是本申请实施例提供的一种网元的结构示意图；

图16是本申请实施例提供的一种网元的结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地描述。

本申请的说明书、权利要求书及附图中的术语“第一”和“第二”等仅用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备等，没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元等，或可选地还包括对于这些过程、方法、产品或设备等固有的其它步骤或单元。

在本文中提及的“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员可以显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上，“至少两个(项)”是指两个或三个及三个以上，“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。“或”表示可以存在两种关系，如只存在A、只存在B；在A和B互不排斥时，也可以表示存在三种关系，如只存在A、只存在B、同时存在A和B。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”。

本申请实施例提供的技术方案可以应用于各类通信系统，例如，可以是物联网(internet of things，IoT)系统、窄带物联网(narrow band internet of things，NB-IoT)系统、长期演进(long term evolution，LTE)系统，也可以是第五代(5th-generation，5G)通信系统，以及未来通信发展中出现的新的通信系统，如第六代(6th-generation，6G)通信系统等。

本申请实施例提供的技术方案还可以应用于机器类通信(machine typecommunication，MTC)、机器间通信长期演进技术(long term evolution-machine，LTE-M)、设备到设备(device-todevice，D2D)网络、机器到机器(machine to machine，M2M)网络、物联网(internet of things，IoT)网络、工业互联网或者其他网络。其中，IoT网络例如可以包括车联网。其中，车联网系统中的通信方式统称为车与任何事物(vehicle-to-everything，V2X，X可以代表任何事物)，例如，该V2X可以包括：车辆到车辆(vehicle tovehicle，V2V)通信，车辆与基础设施(vehicle to infrastructure，V2I)通信、车辆与行人之间的通信(vehicle to pedestrian，V2P)或车辆与网络(vehicle to network，V2N)通信等。示例性的，下文示出的图1中，终端设备与终端设备之间便可以通过D2D技术、M2M技术或V2X技术通信等。

本申请实施例提供的技术方案还可以应用于无线局域网(wireless local areanetwork，WLAN)系统，如Wi-Fi等。如本申请实施例提供的方法可以适用于电气及电子工程师学会(institute of electrical and electronics engineers，IEEE)802.11系列协议，例如802.11a/b/g协议、802.11n协议、802.11ac协议、802.11ax协议、802.11be协议或下一代的协议等，这里不再一一列举。

示例性的，以本申请实施例应用于5G通信系统为例，以下对5G系统中的网络功能进行示例性介绍：

请参见图1，图1示出的网络架构是以第三代合作伙伴项目(3rd generationpartnership project，3GPP)标准化过程中定义的基于服务化架构的5G网络架构为例。如图1所示，该网络架构至少可以包括三部分，分别是终端设备部分、运营商网络部分和数据网络(data network，DN)部分等。

其中，终端设备部分可以包括终端设备110，该终端设备110也可以称为用户设备(user equipment，UE)。本申请实施例中的终端设备110是一种具有无线收发功能的设备，可以经无线接入网(radioaccess network，RAN)140中的接入网设备(或者也可以称为接入设备)与一个或多个核心网(core network，CN)设备(或者也可以称为核心设备)进行通信。终端设备110也可称为接入终端、终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、用户代理或用户装置等。在一种可能的实现方式中，终端设备110可以部署在陆地上，包括室内或室外、手持或车载；也可以部署在水面上(如轮船等)；还可以部署在空中(例如飞机、气球和卫星上等)。在一种可能的实现方式中，终端设备110可以是具有无线通信功能的手持设备、车载设备、可穿戴设备或物联网、车联网中的终端、5G网络以及未来网络中的任意形态的终端等，本申请实施例对此并不限定。本申请实施例示出的终端设备还可以包括车联网中的车(如整车)、以及还可以包括车联网中的车载设备或车载终端等，本申请实施例对于该终端设备应用于车联网时的具体形态不作限定。

其中，各种通信系统中由运营者运营的部分可称为运营商网络或公共陆地移动网(public land mobile network，PLMN)网络等。该运营商网络主要是移动网络运营商(mobile network operator，MNO)为用户提供移动宽带接入服务的公共网络。示例性的，本申请实施例中的运营商网络或PLMN网络，还可以为符合3GPP标准要求的网络，简称3GPP网络。通常的，3GPP网络可以由运营商运营，包括但不限于第五代移动通信(5th-generation，5G)网络(简称5G网络)、第四代移动通信(4th-generation，4G)网络(简称4G网络)等。

如图1所示，该运营商网络可以包括：NEF131、网络存储功能(network functionrepository function，NRF)132、策略控制功能(policy control function，PCF)133、统一数据管理(unified data management，UDM)134、AF135、AUSF136、AMF137、会话管理功能(session management function，SMF)138、用户面功能(user plane function，UPF)139以及无线接入网(radioaccess network，RAN)140等。上述运营商网络中，除RAN140部分之外的部分可以称为核心网络(core network，CN)部分或核心网部分。

数据网络DN 120，也可以称为分组数据网络(packet data network，PDN)，通常是位于运营商网络之外的网络。示例性的，运营商网络可以接入多个数据网络DN 120，数据网络DN 120上可部署多种业务，从而为终端设备110提供数据和/或语音等服务。上述的具体表现形式，具体可根据实际应用场景确定，本申请实施例对此不作限定。

示例性的，下面对运营商网络中的网络功能进行简要介绍。

RAN140是运营商网络的子网络，是运营商网络中业务节点与终端设备110之间的实施系统。终端设备110要接入运营商网络，首先是经过RAN140，进而通过RAN140与运营商网络中的网络功能连接。本申请实施例中的接入网设备是一种为终端设备110提供无线通信功能的设备，也可以称为接入设备或RAN设备等，RAN设备包括但不限于：5G系统中的下一代基站(next generation node basestation，gNB)、LTE系统中的演进型基站(evolvednode B，eNB)、无线网络控制器(radio network controller，RNC)、节点B(node B，NB)、基站控制器(base station controller，BSC)、基站收发台(base transceiver station，BTS)、家庭基站(home evolved nodeB，或home node B，HNB)、基带单元(base band unit，BBU)、传输接收点(transmitting and receiving point，TRP)、发射点(transmittingpoint，TP)、小基站设备(pico)、移动交换中心，或者未来网络中的具有基站功能的网络设备等。可理解，本申请实施例对接入网设备的具体类型不作限定。采用不同无线接入技术的系统中，具备接入网设备功能的设备的名称可能会有所不同。

NEF(也可以称为NEF网络功能或NEF网络功能实体)131是由运营商提供控制面功能。NEF131以安全的方式对AF开放运营商网络的对外接口。在SMF138需要与AF的网络功能通信时，NEF131可作为SMF138与AF的网络实体通信的中继。NEF131作为中继时，可作为签约用户的标识信息的翻译，以及AF的网络功能的标识信息的翻译。比如，NEF131将签约用户的用户永久标识符(subscriber permanent identifier，SUPI)从运营商网络发送到AF时，可以将SUPI翻译成其对应的外部身份标识(identity，ID)。反之，NEF131将外部ID(AF的网络实体ID)发送到运营商网络时，可将其翻译成SUPI。

NRF132，可用于维护网络中所有网络功能服务的实时信息。

PCF133是由运营商提供的控制面功能，用于向会话管理功能SMF138提供PDU会话的策略。策略可以包括计费相关策略、QoS相关策略和授权相关策略等。

UDM134是由运营商提供的控制面功能，负责存储运营商网络中签约用户的SUPI、安全上下文(security context)、签约数据等信息。

AF135，用于进行应用影响的数据路由，接入网络开放功能，与策略框架交互进行策略控制等。

AUSF136是由运营商提供的控制面功能，通常用于一级认证，即终端设备110(签约用户)与运营商网络之间的认证。

AMF137是由运营商网络提供的控制面网络功能，负责终端设备110接入运营商网络的接入控制和移动性管理，例如包括移动状态管理，分配用户临时身份标识，认证和授权用户等功能。

SMF138是由运营商网络提供的控制面网络功能，负责管理终端设备110的协议数据单元(protocol data unit，PDU)会话。PDU会话是一个用于传输PDU的通道，终端设备需要通过PDU会话与DN 120互相传输PDU。PDU会话可以由SMF138负责建立、维护和删除等。SMF138包括会话管理(如会话建立、修改和释放，包含UPF 139和RAN140之间的隧道维护等)、UPF139的选择和控制、业务和会话连续性(service and session continuity，SSC)模式选择、漫游等会话相关的功能。

UPF139是由运营商提供的网关，是运营商网络与DN 120通信的网关。UPF139包括数据包路由和传输、包检测、业务用量上报、服务质量(quality of service，QoS)处理、上行包检测、下行数据包存储等用户面相关的功能。

图1所示的运营商网络中的网络功能还可以包括统一数据存储(unified datarepository，UDR)，该UDR的功能可以参考UDM，这里不再详述。

图1中Nnef、Nausf、Nnrf、Npcf、Nudm、Naf、Namf、Nsmf、N1、N2、N3、N4，以及N6为接口序列号。示例性的，上述接口序列号的含义可参见3GPP标准协议中定义的含义，本申请实施例对于上述接口序列号的含义不做限制。需要说明的是，图1中仅以终端设备110为UE作出了示例性说明，图1中的各个网络功能之间的接口名称也仅仅是一个示例，在具体实现中，该系统架构的接口名称还可能为其他名称，本申请实施例对此不作限定。

本申请实施例中的移动性管理网络功能可以是图1所示的AMF137，也可以是未来通信系统中的具有上述接入与移动性管理功能AMF137的其他网络功能。或者，本申请中的移动性管理网络功能还可以是LTE系统中的移动管理实体(mobility management entity，MME)等。为方便说明，本申请实施例中将接入与移动性管理功能AMF137简称为AMF，将终端设备110称为UE，即本申请实施例中后文所描述的AMF均可替换为移动性管理网络功能，UE均可替换为终端设备。可理解，其他未示出的网络功能同样适用该替换方法。

图1中示出的网络架构(例如5G网络架构)采用基于服务的架构和通用接口，传统网元功能基于网络功能虚拟化(network function virtualization，NFV)技术拆分成若干个自包含、自管理、可重用的网络功能服务模块。图1中示出的网络架构示意图可以理解为一种非漫游场景下基于服务的5G网络架构示意图。对于漫游场景，本申请实施例同样适用。

图2是本申请实施例提供的一种安全决策协商方法的流程示意图。如图2所示，该方法包括：

1a.AMF启动完整性保护(startintegrityprotection)。

1b.AMF向UE发送非接入层安全模式命令(NAS securitymodecommand，NAS SMC)，该NAS安全模式命令携带选定的EPSNAS安全算法IE，用于声明网络提供给UE的加密和完整性保护算法。对应的，UE接收该NAS安全模式命令。

1c.AMF启动上行链路解密。

2a.UE验证NAS SMC的完整性，如果验证成功，则启动上行链路加密、下行链路解密和完整性保护。

2b.UE向AMF发送NAS模式完成(NSA modecomplete)，对应的，AMF接收该NAS模式完成。

1d.AMF启动下行链路加密。

从以上所示的安全决策协商方法可以看出，安全决策由核心网制定，如由AMF制定加密算法和完整性保护算法。也就是说，UE不能参与到安全决策协商的过程中，不能主动地向网络侧上报自己的安全需求，从而导致图2所示的安全决策协商方法不够灵活。

鉴于此，本申请实施例提供一种安全决策协商方法及网元，第一网元能够结合需求方的安全需求和能力方的安全能力制定安全决策，提高了安全决策协商的灵活性。示例性的，第一网元结合需求方的安全需求制定安全决策，从而使得不同类型的需求方可以有不同的安全决策，提高安全决策协商的灵活性，满足差异化的安全需求。示例性的，需求方可以主动上报自己的安全需求，从而使得第一网元能够结合需求方的安全需求制定安全决策，从而使得安全决策协商的过程更灵活。示例性的，本申请实施例可以结合更多的安全功能来制定安全决策，从而可以为不同类型的需求方设置不同的安全功能，提高安全功能设置的灵活性。

未来网络中可能会涉及更多类型的终端设备或AF，不同终端设备或AF的安全需求和安全能力不同。例如，轻量级设备可以采用轻量级认证、加密和完整性保护算法，从而通过本申请实施例提供的方法，第一网元可以基于该轻量级设备的需求激活部分安全功能。如轻量级设备可以使用的安全功能包括：小于或等于第一长度的加密密钥长度、小于或等于第二长度的完整性保护密钥长度、加密算法、完整性保护算法、认证方法(如基于证书的身份认证等)、标签属性和安全粒度。又例如，工业互联网第三方可以采用快速、低延迟的安全算法，通过本申请实施例提供的方法，第一网元可以基于该工业互联网的需求激活快速地低延迟的安全功能。如工业互联网可以使用的安全功能包括：使用对称密钥进行鉴权，或者，若使用非对称密钥，则可以使用轻量级的隐式证书进行鉴权。又例如，涉密设备需要增强的数据和隐私保护技术，复杂的安全算法，通过本申请实施例提供的方法，第一网元可以基于该涉密设备的需求激活大部分或全部安全功能。又例如，高计算能力设备可以采用基于人工智能(artificial Intelligence，AI)的安全算法，通过本申请实施例提供的方法，第一网元可以基于该高计算能力设备的需求激活基于AI的安全功能。如高计算能力功能可以使用的安全功能包括：使用密钥长度大于第三长度的加密和完整性保护算法、后量子加密算法、分布式账本。可理解，以上所示的各种类型的网元与其使用的安全功能仅为示例，不应将其理解为对本申请实施例的限定。

不仅不同类型的终端设备可以使用不同的安全功能，而且同一类型的终端设备根据不同场景也可以使用不同的安全功能。未来网络可能涉及更丰富的安全场景，同一个终端设备或AF在不同场景下的安全需求不同。例如，大规模通信场景下可以采用轻量级认证，激活设备和流量的自动检测功能；高可靠和低时延场景下可以采用后量子加密算法，轻量级安全算法；快速移动场景可以实现终端设备和第三方应用跨地域、跨运营商的能力，如用户具有跨运营商的统一信任状(credentials)(可以理解为一种跨运营商的用户身份识别模块(subscriber identification module，SIM)卡)可以被多个运营商鉴权认证。

对于本申请实施例所示的第一网元可以有如下说明：

作为一个示例，本申请实施例所示的第一网元可以是需求方，也可以是能力方。需求方可以理解为任意的具有安全需求的网元，能力方可以理解为任意的能够提供安全能力的网元。对于该需求方和能力方的具体产品形态，本申请实施例不作限定。可理解，能力方和需求方是相对而言的，也就是说，相对于需求方来说，能力方可以提供一些安全功能，因此称为能力方。比如，能力方可以是核心网中的网络功能或接入网中的设备等，需求方可以是终端设备等。又比如，能力方可以是(accesspoint，AP)，需求方可以是站点(station，STA)等。如果通信双方是同类型的网元，如均为核心网中的网元，则也可以根据能力大小区分能力方和需求方，或者，根据网元本身所具备的功能来区分能力方和需求方。如果通信双方都是同类型的网元，且能力大小类似的话，通信双方还可以均称为需求方，如D2D中涉及的两个终端，又如V2X中涉及的两个车载终端等。当然，能力方和需求方的名称仅为示例，本申请实施例对于该能力方和需求方的具体名称不作限定。

作为另一个示例，本申请实施例所示的第一网元可以是除了需求方和能力方之外的网元。

示例性的，第一网元包括如下任一项：终端设备、AF、可信网元、AMF、NEF、AUSF、接入网设备(如基站)。这里所示的第一网元仅为示例，不应将其理解为对本申请实施例的限定。关于可信网元的说明可以如下所示：

可信网元可以理解为一种可信的网络功能、或者，具有可信功能的网元等。该可信网元可以负责管理如下至少一项：生成安全需求、更新安全需求、删除安全需求、生成安全能力、更新安全能力、删除安全能力、确定(或制定)安全决策。作为一个示例，可信网元可以是独立的网元，如存在于核心网中。作为另一个示例，可信网元可以与需求方、能力方、以及除需求方和能力方之外的第三方集成在一起，从而使得需求方、能力方和第三方具有如可信网元所具备的功能。例如，可信网元与终端设备、核心网中的网络功能、接入网设备中的任一项集成于一起，从而使得终端设备、核心网中的网元、接入网设备具有可信网元所具备的功能。作为又一个示例，终端设备、核心网中的网元、接入网设备等本身具有如可信网元所具备的功能。示例性的，核心网中、终端设备中可以包括原子化的安全算法，也可以理解为安全算法的集合，或安全资源池(securityresourcepool)。

示例性的，可信网元的具体功能可以包括如下至少一项，或者参考表1。

(1)可信网元可以生成安全能力。

(2)可信网元可以将安全能力提供给其他功能模块，或者，将安全能力上传到分布式账本。

(3)可信网元可以根据安全决策配置调用接口，使得其他功能模块调用安全决策中规定的安全功能。

(4)如果其他功能模块发起请求，可信网元可以将安全标签发送给该其他功能模块。可理解，本申请实施例所示的安全标签包括安全需求、安全能力和安全决策中的至少一项。

(5)如果通信网引入了分布式账本，可信网元可以将安全标签上传到分布式账本上，也可以从分布式账本下载旧的安全标签。这里所示的旧的安全标签也可以理解为历史安全标签。

(6)可信网元可以生成安全需求。

(7)收到新的安全需求后，可信网元可以确定新的安全决策。

(8)保存的安全标签过期之后，可信网元可以丢弃旧的安全标签，以及生成新的安全标签。

表1

以上所示的第一网元以及可信网元的说明，下文同样适用。

图3是本申请实施例提供的一种安全决策协商方法的流程示意图。示例性的，下文涉及的各个网元均可以具有如表1所示的部分功能或全部功能。如图3所示，该方法包括：

301、第一网元基于需求方的安全需求和能力方的安全能力确定安全决策。

安全需求可以理解为需求方所声明的安全算法，或者，需求方所需要的安全算法，或者，需求方所要求的安全算法或安全功能。安全能力可以理解为能力方声明能提供的安全算法，或者，能力方所能提供给需求方的安全算法或安全功能。安全决策可以理解为最终协商确定的安全算法，或者，基于安全需求和安全能力最终确定的安全算法，或者，最终协商的安全功能。可理解，本申请实施例所示的安全决策还可以理解为安全协商结果，或者安全算法协商的结果，或者安全策略协商结果或安全策略等，本申请实施例对于该安全决策的具体名称不作限定。可理解，由于安全决策中不仅包括一些安全算法，还包括一些非算法类的信息，如属性、安全粒度、可信证明、跨运营商和分布式账本等，因此基于安全决策协商的结果可以称为安全功能，该安全功能中可以包括一些协商好的安全算法。

示例性的，安全需求可以包括如下至少一项信息(或称为需求)：属性(如标签属性)、安全粒度、认证方法、加密算法、加密密钥长度、完整性保护算法、完整性保护密钥长度、密钥能力、隐私保护、可信证明、跨运营商、分布式账本。示例性的，安全能力可以包括如下至少一项信息(或称为能力)：属性(如标签属性)、安全粒度、认证方法、加密算法、加密密钥长度、完整性保护算法、完整性保护密钥长度、密钥能力、隐私保护、可信证明、跨运营商、分布式账本。示例性的，安全决策可以包括如下至少一项信息：属性、安全粒度、认证方法、加密算法、加密密钥长度、完整性保护算法、完整性保护密钥长度、密钥能力、隐私保护、可信证明、跨运营商、分布式账本。

示例性的，图4a是本申请实施例提供的一种安全需求的结构示意图。图4b是本申请实施例提供的一种安全能力的结构示意图。图4c是本申请实施例提供的一种安全决策的结构示意图。可理解，图4a至图4c中的各个信息的顺序仅为示例，不应将其理解为对本申请实施例的限定。在具体实现中，安全需求可能具有比图4a更多的信息，或者，具有比图4a更少的信息，本申请实施例对此不作限定。类似的，上述关于安全需求的说明，同样适用于安全能力和安全决策。安全需求、安全能力和安全决策的结构形式可以是相同的，但是安全需求、安全能力和安全决策在对应字段的取值可能是不同的。如需求方可以基于自身的需求将设置相应字段的取值，能力方可以基于自身的能力设置相应字段的取值，安全决策中相应字段的取值可以由安全需求中该相应字段的取值和安全能力中该字段的取值确定。对于安全决策的确定方法可以参考下文，这里先不一一详述。

安全需求还可以称为安全需求标签，安全能力还可以称为安全能力标签，安全决策还可以称为安全决策标签。安全需求标签、安全能力标签和安全决策标签还可以统称为安全标签或标签等，本申请实施例不作限定。为便于描述，下文将图4a至图4c所示的方框称为字段，如标签属性字段、安全粒度字段等，这里不再一一列举。当然，这里所示的字段的描述仅为示例，如每个方框还可以称为信息位，如标签属性信息位、安全粒度信息位等，本申请实施例对此不作限定。为便于描述，本申请实施例将安全需求、安全能力和安全决策统称为安全标签，但是不应将其理解为对本申请实施例的限定。

安全需求、安全能力和安全决策中可能包括的信息有如下说明：

标签属性可以用于承载与标签相关的一些属性，如包括标签长度、标签类型中的至少一项。标签长度可以用于指示安全需求或安全能力的长度，可以用比特来衡量，也可以用字节来衡量，本申请实施例对此不作限定。标签类型可以用于指示安全需求、安全能力和安全决策中的任一项。安全标签中通过携带标签属性，可以使得接收到安全标签的网元，有效获知安全标签的类型和长度，保证需求方和能力方对安全标签的理解一致，提高通信的效率。

安全粒度可以用于确定安全标签覆盖的范围，如安全标签覆盖的场景；或者，安全粒度可以用于确定安全标签所属的粒度，如属于用户粒度、设备粒度、服务粒度中的至少一项。安全标签所属粒度的不同可以影响该安全标签的范围，或者，影响该安全标签的周期。作为示例，用户粒度可以与用户对应，安全粒度用于声明用户标识(identifier，ID)，如与用户的身份标识相关的账户，如SUPI。又如设备粒度可以与设备对应，安全粒度用于声明设备ID，如永久设备标识符(permanent equipment identifier，PEI)。可选地，当安全粒度为设备粒度时，还可以用于声明用户ID。又如服务粒度可以与服务对应，安全粒度用于声明服务ID，如会话ID(session ID)。可选地，当安全粒度为服务粒度时，还可以用于声明用户ID或设备ID中的至少一项。作为示例，不同的安全粒度可以覆盖不同的场景，如设备粒度可以用于覆盖设备注册阶段的安全决策协商方法；又如服务粒度可以用于覆盖服务请求阶段的安全决策协商方法；又如用户粒度既可以覆盖注册阶段的安全决策协商方法也可以覆盖服务请求阶段的安全决策协商方法。作为示例，不同的安全粒度可以对应不同的周期(或称为有效期)，如果安全粒度为用户粒度，则安全标签可以与用户ID对应，如即使是用户使用不同的设备，如果用户ID未发生变化，则安全标签可以不更新。针对每一个用户生成密钥，对该用户的所有数据用同样的方法进行加密。如果安全粒度为设备粒度，则表示用户更换设备时，安全标签可能需要更新。如果安全粒度为服务粒度，则表示不同的服务可能会对应不同的安全决策。可理解，安全需求标签和安全决策标签的安全粒度可以是相同的，即安全决策可以对应于安全需求。通过携带安全粒度可以灵活地指示标签覆盖的范围。

认证方法可以包括认证和密钥协商(Authentication and Key Agreement，AKA)、基于身份的签名(identity based signature，IBS)，基于公钥证书中的至少一项。加密算法可以包括Show 3G、高级加密标准(advanced encryption standar，AES)、祖冲之算法(ZUC)、后量子加密算法中的至少一项。完整性保护算法可以包括Show3G、AES、ZUC中的至少一项。针对加密密钥长度和完整性保护密钥长度来说，安全需求中的这两个信息可以设置为0。安全能力中的这两个信息可以包括能力方所支持的最短密钥长度和最长密钥长度。安全标签中通过携带加密算法、完整性保护算法、加密密钥长度和完整性保护密钥长度，可使得该安全标签能够兼容通信网络传统的安全能力，保证安全标签的兼容性。同时，还可以有效保证与通信网络传统安全能力对应的设备仍能够使用加密算法和完整性保护算法进行通信，有效保证了安全标签的向后兼容。

密钥能力可以用于指示是否支持用户参与生成密钥。示例性的，UP面密钥可以由用户参与生成，如果该字段的值设置为1，则可以表示支持用户参与生成密钥；如果该字段的值设置为0，则可以表示不支持用户参与生成密钥。安全标签中通过携带密钥能力，可使得用户可以自主参与UP面的密钥生成，可以保护用户的数据。

隐私保护可以用于指示隐私保护算法、隐私保护级别中的至少一项，隐私保护级别可以包括保护ID、保护数据、保护行为中的至少一项，隐私保护算法可以包括差分隐私、匿名化、同态加密中的至少一项。保护ID可以理解为保护用户的ID。保护数据可以理解为ID是明文，但是产生的数据需要进行保护。保护行为可以理解为保护用户在网络中的行为。安全标签中通过携带隐私保护，可以增加对用户的隐私保护。

可信证明可以用于指示系统搭载的可信计算平台，如可信计算平台包括可信平台模块(trusted platform module，TPM)、可信密码模块(trusted cryptography module，TCM)、可信平台控制模块(trusted platform control module，TPCM)、软件防护模块(software guard extensions，SGX)、可信执行环境(trusted execution environment，TEE)、可信域(trustzone)中的至少一项。示例性的，可信证明的功能可以包括至少两个维度：设备自身的能力、除自身可信证明能力之外，还可以提供对其他节点的度量结果进行验证的能力，以及对验证后的结果进行背书的能力。例如，需求方需要可信证明，能力方也可以提供可信证明的能力时，能力方与需求方可以通过这个能力交互，或者，能力方可以对其他节点进行验证等。安全标签通过携带可信证明，可以指示相关网元是否具有可信硬件平台，可以提供远程的可信证明信息。

跨运营商可以用于指示漫游形式或携号转网，如跨运营商可以用于指示跨域、跨网的场景。漫游形式可以理解为在不同运营商网络不同计费，如UE需要重新认证，现有3GPP标准采用的是这种方法。携号转网可以理解为在不同运营商网络采用同一套服务，UE不需要重新认证。安全标签通过携带跨运营商，支持统一信任状(credential)，具有跨运营商鉴权的能力。

分布式账本可以将未来通信网络和分布式账本融合。分布式账本可以用于指示分布式账本的能力，如是否支持分布式账本的能力，以及能力的等级，包括作为客户端进行查询、上传、下载的能力，调用和部署智能合约的能力，对交易进行验证的能力，共识的能力，和存储的能力等。安全标签通过携带分布式账本，可使得通信网络能够与分布式账本融合，充分地将通信网络与区块链结合，提高存储的安全标签的安全性。

可选地，本申请实施例所示的安全标签中还可以包括一些预留字段，该预留字段可以用于保持安全标签的向前兼容性。

作为一个示例，安全需求可以包括加密算法、加密密钥长度、完整性保护算法、完整性保护密钥长度、认证方法、标签属性和安全粒度，如适用于轻量级设备。作为另一个示例，安全需求可以包括加密算法、加密密钥长度、完整性保护算法、完整性保护密钥长度、标签类型、分布式账本。作为又一个示例，安全需求包括密钥长度大于第三长度的加密和完整性保护算法、后量子加密算法和分布式账本，如适用于高计算能力设备。可理解，关于不同类型的需求方所需要的具体安全功能，本申请实施例不再一一列举。

对于安全需求、安全能力和安全决策的长度和取值可以有如下说明：

方法A、每个字段的长度是固定的。

作为一个示例，每个字段的长度相同，如图4a至图4c所示的各个字段的长度可以是n个比特，n为大于或等于1的整数。字段的长度可以根据安全标签中需要承载最多信息的字段的长度而变化。举例来说，安全标签中可信证明字段需要承载的信息最多，如包括至少五种信息，则安全标签中各个字段的长度可以为3个比特。又举例来说，安全标签中加密算法需要承载的信息最多，如包括三种信息，则安全标签中各个字段的长度可以为2个比特。可理解，当某个字段的取值为0时，则可以表示安全标签中不包括与该某个字段对应的信息。例如，当安全需求中的隐私保护字段的取值为0，则可以表示需求方不需要隐私保护。又例如，当安全能力中的可信证明字段的取值为0，则可以表示能力方无法提供可信证明。又例如，当安全决策中的跨运营商字段的取值为0，则表示协商确定的安全功能中不包括跨运营商。

本申请实施例中，由于每个字段的长度相同，因此，第一网元可以快速地解析安全需求和安全能力，从而提高该第一网元确定安全决策的效率。

作为另一个示例，至少两个字段的长度不同。如标签属性字段可以占用3个比特或4个比特等，又如可信证明字段可以占用3个比特，其他字段可以占用2个比特。本申请实施例中，安全标签中可以存在至少两个字段的长度不同，从而可以有效节省安全标签的信令开销。

方法B、每个字段的长度可以是变化的。

作为一个示例，每个字段的长度可以相同，由此第一网元可以基于安全标签的总长度(如通过标签长度指示)以及总字段数获知每个字段的长度。可理解，安全标签中所包括的信息一般是已知的。本申请实施例中，字段的长度可以是变化的，且每个字段的长度相同，从而安全标签的长度设置更灵活，且第一网元可以快速解析安全标签。

作为另一个示例，至少两个字段的长度不同。该情况下，安全标签中可以增加一些字段，或者，在每个字段中增加用于指示长度的信息，或者，在长度发生变化的字段中增加用于指示长度的信息。本申请实施例中，字段的长度是变化的，且至少两个字段的长度可以是不同的，从而安全标签的长度设置更灵活，且还能节省信令开销。

方法C、安全标签的长度由安全标签中所涉及的安全功能的个数确定。

作为一个示例，如图4b所示，每种信息都可以占用一个比特，如用户粒度、设备粒度、服务粒度、AKA、IBS、Show3G、AES、ZUC、后量子加密算法等均可以占用一个比特。示例性的，安全需求可以包括第一比特位图(bitmap)，该第一比特位图中的每个比特可以用于指示是否需要对应的安全功能。举例来说，对应比特的取值为1，则表示需求方需要与该比特对应的安全功能；如果对应比特的取值为0，则表示需求方不需要与该比特对应的安全功能。示例性的，安全能力可以包括第二比特位图，该第二比特位图中的每个比特可以用于指示是否能够提供对应的安全功能。举例来说，对应比特的取值为1，则表示能力方可以提供(或支持)与该比特对应的安全功能；如果对应比特的取值为0，则表示能力方无法提供与该比特对应的安全功能。

可理解，以上所示的各个字段的长度的说明仅为示例，不应将其理解为对本申请实施例的限定。安全需求的长度和安全能力的长度可以相同，也可以不同，本申请实施例对此不作限定。

对于上述方法A至方法C来说，安全标签中的每个字段可以用于承载相应的安全功能，如字段的取值可以用于承载与该字段对应的安全功能的索引。当然，如果需求方不需要某个安全功能，如以下以安全算法A为例，则安全需求中与该安全算法A对应的字段可以不承载该安全算法A的索引。如果能力方无法提供某个安全算法或某些安全算法，如以下以安全算法B为例，则安全能力中与该安全算法B对应的字段可以不承载该安全算法B的索引。示例性的，当安全标签中不包括某个安全算法时，该安全算法对应的字段的取值可以为0。上述方法A至方法C适用于安全需求、安全能力和安全决策。

方法D、安全需求中可以包括如下至少一项信息的优先级信息：加密算法、完整性保护算法、认证方法、密钥能力、隐私保护、可信证明、跨运营商、分布式账本。

作为一个示例，安全需求中可以包括上述至少一项信息的优先级信息，该情况下，安全需求的长度可以适应性地增加。示例性的，每一种安全功能对应的标签位(也可以称为每一种安全功能对应的字段)设置为优先级，不采用某个安全功能，则该安全功能对应的标签位则设置为0，图5a给出了一个示例。示例性的，图5a所示的安全需求中的320可以理解为该320所在字段对应的算法中第一个算法的优先级是3，第二个算法的优先级是2，第三个算法的优先级是0，当然这里所示的320仅为示例，不应将其理解为对本申请实施例的限定。图5a所示的安全需求中的321可以理解为该321所在字段对应的算法中第一个算法的优先级是3，第二个算法的优先级是2，第三个算法的优先级是1。图5a所示的安全能力中的111可以理解为对于该111所在字段对应的算法，能力方均支持；000可以理解为对于该000所在字段对应的算法，能力方均不支持。图5a中，每个字段承载的算法的顺序可以是固定的，由此保证第一网元能够基于该安全需求和安全能力确定出安全决策。如图5a所示，安全决策中的安全算法对应于安全需求中优先级最高的第一个算法。

通过在安全需求中包括优先级信息，可使得第一网元通过一个安全需求就可以获得需求方所需要的安全算法，效率更高。

作为另一个示例，上述至少一项信息的优先级信息可以通过独立的方式发送。即安全需求中需要的安全算法设置为1，不需要的安全算法设置为0，然后通过其他信息指示安全需求中字段的取值不为0的安全算法的优先级，图5b给出了一个示例。图5b所示的安全需求中的110可以理解为该110所在字段对应的算法中第一个算法和第二个算法的优先级相同且均为1，111可以理解为该111所在字段对应的算法不区分优先级。图5b所示的安全能力中的111和000的说明以及图5b所示的安全决策的说明可以参考安全需求的描述和图5a，这里不作详述。通过独立发送优先级信息，可有效节省安全需求的信令开销。

可理解，以上所示的安全需求、安全能力和安全决策的说明仅为示例，在具体实现中，需求方和能力方只要对标签的格式达成一致，使得第一网元可以正确解析安全需求和安全能力即可。

安全决策的确定方法可以有如下说明：

作为一个示例，第一网元基于安全需求中第一位的取值和安全能力中第一位的取值的运算或映射结果确定安全决策中第一位的取值。以每一位的取值为1表示安全标签支持对应位的安全功能，以每一位的取值为0表示安全标签不支持对应位的安全功能，则关于运算或映射结果的说明可以参考表2。从表2可以看出，当需求方需要某个安全功能，且能力方能提供该某个安全功能时，安全决策的对应位为1，即表示需求方和能力方可以采用上述某个安全功能进行通信。类似的，需求方或能力方的至少一方不支持某个安全功能，则安全决策的对应位为0，表示需求方和能力方不可以采用该某个安全功能进行通信。

表2

安全需求第一位的取值	安全能力第一位的取值	安全标签第一位的取值
			1	1	1
1	0	0
			0	1	0
0	0	0

该种实现方式中，第一网元通过对应位的取值就可以确定安全决策，方式简单，节省第一网元的工作量。

需要说明的是，第一网元基于对应位的取值确定安全决策仅为示例，如当安全需求和安全能力的长度相同(如上述方法A和方法C)时，可以通过对应位的取值确定安全决策。当安全需求和安全能力的长度可能不同(如上述方法B)时，第一网元则可以结合每个字段的长度、以及每个字段中承载的内容来确定安全决策。

作为另一个示例，第一网元基于安全需求中的优先级信息和安全能力确定安全决策。

针对不为零的标签位，利用优先级列表确定，优先级列表可以由运营商制定，也可以由UE、AF等网元自行规定。这里所示的优先级列表可以理解为安全标签中包括的优先级列表的格式。优先级列表的格式由运营商制定，格式统一，所有的网元都可以正确解析包括优先级列表的安全标签。优先级列表的格式由通信双方自行协商，可以有效提高优先级列表的灵活性与多样性。

作为又一个示例，第一网元可以基于安全需求、优先级信息和安全能力确定安全决策。该情况下，优先级信息与安全需求可以是独立的内容。关于第一网元确定安全决策的方式可以参考上述方式，这里不作详述。

本申请实施例中，第一网元通过优先级信息确定安全决策，可提高安全决策的准确性。

一般来说，安全决策可以对应于安全需求，如需求方的安全需求中的某种算法唯一，能力方的安全能力中针对该某种算法不唯一的情况下，基于该安全需求和该安全能力确定的安全决策可能是一样的。举例来说，安全需求中所需要的加密算法为AES，安全能力中所能提供的加密算法包括如下至少两项：Show3G、AES、ZUC、后量子加密算法等，则第一网元基于该安全需求中的加密算法需求，以及安全能力中所能提供的加密算法，确定的安全决策中的加密算法可能为AES。又举例来说，安全需求中所需要的隐私保护为差分隐私保护，安全能力中所能提供的隐私保护包括差分隐私保护、匿名化隐私保护、同态加密隐私保护，则安全决策中的隐私保护可能为差分隐私保护。当然，如果需求方所需要的某一类型的安全算法不唯一，且能力方针对该某一类型的安全算法能力有限时，则安全决策对应于安全需求和安全能力。

302、第一网元发送包括安全决策的消息。

本申请实施例中，第一网元可以向其他网元发送包括安全决策的消息。或者，可以将该安全决策上传至分布式账本，以使得其他网元可以从分布式账本下载该安全决策。该其他网元可以是除了第一网元之外的任何网元，本申请实施例对此不作限定。

示例性的，第一网元可以向UDM发送包括安全决策的消息。对应的，UDM接收该包括安全决策的消息，根据该安全决策确定可信向量(trustworthiness vector，TV)。该可信向量可以包括所有安全算法相关的参数，与安全决策对应。当有网元(如网络功能等)向UDM请求安全算法需要的参数，UDM根据TV进一步生成需要的安全向量发送给该网元。图5c给出了可信向量的一个示例。图5c中随机数(randomnumber，RAND)1，认证令牌(Authenticationtoken，AUTN)、期望回复值(expected response，XRES)、XRES*可以理解为鉴权向量，认证方法对应，其中XRES可以对应于EAP-AKA，XRES*可以对应于AKA。加密密钥(crypto key，CK’)、完整性密钥(integrity key，IK’)和K_AUSF可以对应于加密完整性保护算法，CK’和IK’对应EAP-AKA，K_AUSF对应AKA。RAND2可以对应隐私保护，RAND3和参考值(referencevalue，RV)可以对应可信证明，运营商代码可以对应跨运营商，分布式信息对应分布式账本。

可理解，安全决策可以有一定的有效期，当在有效期之内时，如果某个网元需要使用安全决策，则可以向存储该安全决策的网元(如第一网元或UDM等)请求该安全决策，或者从分布式账本下载该安全决策。如果安全决策已过期，则某个网元需要使用安全决策时，就需要按照本申请实施例提供的方法重新确定安全决策。

本申请实施例提供的安全决策协商方法，第一网元可以有效地结合需求方的安全需求和能力方的安全能力制定安全决策，不仅提高了安全决策协商的灵活性，而且还可以使得需求方和能力方能够通过协商的方式来确定安全决策，提高了需求方的参与度，保证了安全决策的有效性。相对于图2所示的安全决策协商方法，图2只能核心网设备安全决策，且只能设置加密算法和完整性保护算法，无法涉及更多的安全算法。然而，本申请实施例提供的方法中，不仅涉及了更多类型的安全功能，而且需求方可以更灵活地参与到安全决策协商的过程，保证了需求方在不同场景中对安全的不同需求。

图6a是本申请实施例提供的一种安全决策协商方法的流程示意图。图6a所示的能力方和需求方可以是网络中任意的设备或网元或网络功能，本申请实施例对此不作限定。如图6a所示，该方法包括：

602、能力方发送包括安全能力的消息，对应的，需求方接收包括安全能力的消息。

作为一种可能的实现方式，能力方可以以广播的形式发送包括安全能力的消息。通过广播的形式发送包括安全能力的消息，可使得更多的需求方同时获取到能力方的安全能力，从而可以使得能力方通过同时与多个需求方协商确定安全决策，有效提高通信的效率。另外，一般来说，能力方的能力可能是固定的，因此不同的能力方通过广播的形式发送安全能力时，可使得需求方能够基于自身的安全需求灵活选择不同的能力方进行通信。当然，该种实现方式中，能力方需要具备广播的能力。

作为另一种可能的实现方式，能力方可以以单播的形式向需求方发送包括安全能力的消息。

作为一个示例，能力方可以以固定的频率或周期向需求方发送包括安全能力的消息；或者，能力方可以在更新安全能力的情况下，向需求方发送包括安全能力的消息；或者，能力方可以在开机上电的情况下，向需求方发送包括安全能力的消息；或者，能力方可以在系统更新的情况下，向需求方发送包括安全能力的消息。能力方通过主动向需求方发送包括安全能力的消息，可使得需求方能够及时获取到能力方的安全能力，从而及时更新安全决策，提高能力方和需求方通信的可靠性。可理解，上述所示的能力方发送包括安全能力的消息的时机也适用于能力方生成安全能力的时机。

作为另一个示例，能力方发送包括安全能力的消息之前，如图6a中的步骤601所示，需求方向能力方发送请求消息，该请求消息用于请求能力方的安全能力。对应的，能力方接收该请求消息，以及向需求方发送包括安全能力的消息。需求方通过发送请求消息，以使得能力方向该需求方发送能力方的安全能力，同时能力方可以向不同的需求方发送该安全能力，提高安全决策协商的效率。

作为又一种可能的实现方式，如图6b所示，能力方可以将安全能力上传至分布式账本。对应的，需求方可以从分布式账本中下载该安全能力。能力方和需求方可以理解为均是分布式账本节点，由此，能力方和需求方均可以通过分布式账本上传相关信息或下载相关信息，这里所示的相关信息包括本申请实施例所示的安全能力、安全需求和安全决策。通过将安全能力上传至分布式账本，从而需求方在用到安全能力时，可以直接从分布式账本下载该安全能力。从而不仅有效融合了通信网络和分布式账本技术，而且提高安全标签的安全性。

可理解，在能力方发送安全能力之前，能力方可以按照图4b所示的结构生成安全能力。当然，图4b所示的安全能力的结构仅为示例，不应将其理解为对本申请实施例的限定。示例性的，能力方可以遍历本身的安全功能，从而生成安全能力，声明其能提供的所有安全功能。作为一种可能的实现方式，能力方在生成安全能力之前，还可以设置生成安全能力的方式。作为一个示例，能力方可以设置自动生成安全能力，例如基于上文所示的发送包括安全能力的消息的时机自动生成安全需求，又例如能力方自动感知应用场景，根据预先设置的规则设置安全能力。作为另一个示例，能力方可以手动生成安全能力，如操作人员通过相关应用软件(application，APP)设置安全能力。

作为一种可能的实现方式，图6a所示的方法还包括步骤603。

603、需求方生成安全需求。

可理解，需求方在确定安全决策之前，可以按照图4a所示的结构生成安全需求，从而使得需求方能够快速方便地确定安全决策。当然，需求方也可以不生成安全需求，而是基于自身的需求以及安全能力确定安全决策。

作为一个示例，需求方可以自动生成安全需求，如需求方自动感知应用场景，根据一定的规则设置安全需求。例如，需求方可以基于如下至少一项规则生成安全需求：第一、需求方所处的网络状态，网络状态可以包括归属地或漫游地；第二、需求方所处的网络，如包括蜂窝网或Wi-Fi网络；第三、需求方自身的设备类型，如包括车、IoT设备、手机等。基于上述不同的规则，需求方可以有不同的需求，从而可以生成不同的安全需求。作为另一个示例，需求方可以手动生成安全需求，如用户通过APP设置安全需求。

可理解，本申请实施例对于步骤603与步骤601或步骤602之间的先后顺序不作限定。图6a所示的步骤603所处的位置仅为示例，不应将其理解为对本申请实施例的限定。

作为一种可能的实现方式，图6a所示的方法还包括步骤604。

604、需求方验证安全能力。

示例性的，需求方可以验证安全能力是否可信，如果安全能力可信，则需求方可以执行步骤605。示例性的，能力方可以利用私钥对安全能力进行签名，或者利用加密方法对安全能力进行加密。对应的，需求方可以使用公钥或解密方法验证该安全能力。如果安全能力不可信，则需求方可以丢弃该安全能力；或者再次向能力方请求安全能力；或者需求方可以返回失败消息，该失败消息用于指示安全能力验证失败，从而使得能力方再次生成安全能力等，本申请实施例对此不作限定。可理解，当需求方多次验证安全能力失败之后，则需求方可以停止安全决策的协商过程。需求方通过验证安全能力，可有效保证安全决策确定的可信度，提高安全决策确定的可信程度。

605、需求方基于安全需求和安全能力确定安全决策。

可理解，关于需求方确定安全决策的具体说明可以参考图3，这里不再赘述。

606、需求方发送包括安全决策的消息。对应的，能力方接收该包括安全决策的消息。

作为一种可能的实现方式，需求方可以通过单播消息发送该安全决策。

作为另一种可能的实现方式，如图6b所示，需求方可以将该安全决策上传至分布式账本，对应的，能力方从分布式账本下载该安全决策。可理解，关于图6b所示的相关步骤的具体说明可以参考图6a，本申请实施例不再详述。

607、需求方和能力方基于安全决策进行通信。

示例性的，需求方和能力方可以基于安全决策设置安全功能，从而在鉴权完成后的加密和完整性保护中使用协商好的安全功能对后续信令和数据进行加密和完保；或者，如果安全决策中包括可信度量的能力，那么在鉴权流程中可以增加对能力方和需求方的可信度量流程。关于需求方和能力方基于安全决策进行通信的例子，本申请实施例不再一一列举。

图7a是本申请实施例提供的一种安全决策协商方法的流程示意图。图7a所示的能力方和需求方可以是网络中任意的设备或网元或网络功能，本申请实施例对此不作限定。如图7a所示，该方法包括：

702、需求方发送包括安全需求的消息，对应的，能力方接收包括安全需求的消息。

作为一种可能的实现方式，需求方可以以广播的形式发送包括安全需求的消息。通过广播的形式发送包括安全需求的消息，可使得更多的能力方同时获取到需求方的安全需求，从而可以使得需求方通过同时与多个能力方协商确定安全决策，同时，多个需求方也可以同时与一个能力方协商安全决策，有效提高通信的效率。当然，该种实现方式中，需求方需要具备广播的能力。可理解，需求方通过以广播的形式发送安全需求时，多个能力方可以会同时接收到该安全需求，从而确定多个安全决策。由此，需求方接收到该多个安全决策之后，可以从该多个安全决策中确定一个安全决策，从而与其确定的安全决策的能力方进行通信，有效保证需求方的安全需求的可实现性。

作为另一种可能的实现方式，需求方可以以单播的形式向能力方发送包括安全需求的消息。

作为一个示例，需求方可以以固定的频率或周期向能力方发送包括安全需求的消息；或者，需求方可以在更新安全需求的情况下，向能力方发送包括安全需求的消息；或者，需求方可以在开机上电的情况下，向能力方发送包括安全需求的消息；或者，需求方可以在系统更新的情况下，向能力方发送包括安全需求的消息。需求方通过主动向能力方发送包括安全需求的消息，可使得能力方能够及时获取到需求方的安全需求，从而及时更新安全决策，提高能力方和需求方通信的可靠性。可理解，上述所示的需求方发送包括安全需求的消息的时机也适用于需求方生成安全需求的时机。

作为另一个示例，需求方发送包括安全需求的消息之前，如图7a中的步骤701所示，能力方向需求方发送请求消息，该请求消息用于请求需求方的安全需求。对应的，需求方接收该请求消息，以及向能力方发送包括安全需求的消息。能力方通过发送请求消息，以使得需求方向该能力方发送需求方的安全需求，同时需求方可以同时向多个能力方发送该安全需求，提高安全决策协商的效率。

作为又一种可能的实现方式，如图7b所示，需求方可以将安全需求上传至分布式账本。对应的，能力方可以从分布式账本中下载该安全需求。通过将安全需求上传至分布式账本，从而能力方在用到安全需求时，可以直接从分布式账本下载该安全需求力。从而不仅有效融合了通信网络和分布式账本技术，而且提高安全标签的安全性。

可理解，在需求方发送安全需求之前，需求方可以按照图4a所示的结构生成安全需求。当然，图4a所示的安全需求的结构仅为示例，不应将其理解为对本申请实施例的限定。作为一种可能的实现方式，需求方在生成安全需求之前，还可以设置生成安全需求的方式。关于设置安全需求方式的具体说明可以参考图6a，这里不再详述。

作为一种可能的实现方式，图7a所示的方法还包括步骤703。

703、能力方生成安全能力。

能力方在确定安全决策之前，可以按照图4b所示的结构生成安全能力，从而使得能力方能够快速方便地确定安全决策。当然，能力方也可以生成安全能力，可以基于自身的能力以及安全需求确定安全决策。作为一个示例，能力方可以自动生成安全能力，如能力方自动感知应用场景，根据一定的规则设置安全能力。作为另一个示例，能力方可以手动生成安全能力，如用户通过APP设置安全能力。关于设置安全能力的方式可以参考图6a，这里不再详述。可理解，本申请实施例对于步骤703与步骤701或步骤702之间的先后顺序不作限定。图7a所示的步骤703所处的位置仅为示例，不应将其理解为对本申请实施例的限定。

704、能力方验证安全需求。

示例性的，能力方可以验证安全需求是否可信，如果安全需求可信，则能力方可以执行步骤705；如果安全能力不可信，则能力方可以丢弃该安全需求；或者再次向需求方请求安全需求；或者能力方可以返回失败消息，该失败消息用于指示安全需求验证失败，从而使得需求方再次生成安全需求等，本申请实施例对此不作限定。可理解，当能力方多次验证安全需求失败之后，则能力方可以停止安全决策的协商过程。能力方通过验证安全能力，可有效保证安全决策确定的可信度，提高安全决策确定的可信程度。关于步骤704的具体说明还可以适应性地参考图6a所示的步骤604。

705、能力方基于安全需求和安全能力确定安全决策。

706、能力方发送包括安全决策的消息。对应的，需求方接收该包括安全决策的消息。

作为一种可能的实现方式，能力方可以通过单播消息发送该安全决策。

作为另一种可能的实现方式，如图7b所示，能力方可以将该安全决策上传至分布式账本，对应的，需求方从分布式账本下载该安全决策。可理解，关于图7b所示的相关步骤的具体说明可以参考图7a，本申请实施例不再详述。

707、需求方和能力方基于安全决策进行通信。

可理解，关于图7a所示的方法中未详细描述的地方可以参考图3或图6a。

图8是本申请实施例提供的一种安全决策协商方法的流程示意图。图8所示的能力方和需求方可以是网络中任意的设备或网元或网络功能，本申请实施例对此不作限定。如图8所示，该方法包括：

801、需求方生成安全需求，能力方生成安全能力。

示例性的，能力方可以按照图4b所示的结构生成安全能力，以及需求方可以按照图4a所示的结构生成安全需求。对于安全能力和安全需求的生成方式或时机，可以参考图3、图6a和图7a，这里不再详述。对于需求方生成安全需求和能力方生成安全能力的先后顺序，本申请实施例不作限定。

802、能力方发送包括安全能力的消息，对应的，需求方接收包括安全能力的消息。

803、需求方发送包括安全需求的消息，对应的，能力方接收包括安全需求的消息。

可理解，本申请实施例对于步骤802和步骤803的先后顺序不作限定。

804、需求方验证安全能力，能力方验证安全需求。

示例性的，需求方接收到安全能力之后，可以验证安全能力是否可信，以及能力方接收到安全需求之后，可以验证安全需求是否可信。对于需求方验证安全能力和能力方验证安全需求的先后顺序，本申请实施例不作限定。

805、需求方基于安全需求和安全能力确定安全决策，能力方基于安全需求和安全能力确定安全决策。

对于需求方确定安全决策和能力方确定安全决策的先后顺序，本申请实施例不作限定。关于确定安全决策的方法可以参考图3，这里不作详述。

806、需求方和能力方基于安全决策进行通信。

本申请实施例中，需求方通过向能力方发送安全需求，以及能力方通过向需求方发送安全能力，使得需求方和能力方可以各自本地确定安全决策，从而不仅节省了信令开销，而且保证安全决策的制定更合理，使得安全决策协商的流程更灵活。

图9a是本申请实施例提供的一种安全决策协商方法的流程示意图。本申请实施例提供了通信双方都提供自己的安全需求时的安全决策协商方法。需求方的安全需求中实际也包含了自身的安全能力，因为通信双方提供自己的安全需求时，本身可以支持这些安全算法。因此如果通信的两方都是需求方，则可以都提供安全需求，安全决策协商流程如图9a所示。即该方法可以涉及两个需求方，比如图9a所示的需求方1和需求方2，该需求方1和需求方2可以是任意的终端设备、IoT设备、网络功能等，本申请实施例对此不作限定。示例性的，需求方1和需求方2都可以是D2D设备，或者需求方1和需求方2都可以是V2X中涉及的车。示例性的，需求方1和需求方2也可以都是网络功能，或基站等。如图9a所示，该方法包括：

901、需求方2发送包括安全需求2的消息，对应的，需求方1接收包括安全需求2的消息。

可理解，在需求方2发送包括安全需求2的消息之前，需求方2还可以按照图4a所示的结构生成安全需求2。当然，图4b所示的安全需求的结构仅为示例，不应将其理解为对本申请实施例的限定。

作为一种可能的实现方式，需求方2可以主动向需求方1发送包括安全需求2的消息。关于需求方2主动发送安全需求2的说明可以参考上文能力方发送安全能力的时机，或者，参考上文需求方发送安全需求的时机，这里不作详述。

作为另一种可能的实现方式，需求方1可以向需求方2发送请求消息，对应的，需求方2接收该请求消息。然后根据该请求消息向需求方1发送包括安全需求2的消息。关于请求消息的具体说明可以参考上文，这里不作详述。

作为一种可能的实现方式，如图9b所示，需求方2可以将安全需求2上传至分布式账本，对应的，需求方1可以从分布式账本下载安全需求2。

作为一种可能的实现方式，图9a所示的方法还包括步骤902。

902、需求方1生成安全需求1。

作为一种可能的实现方式，图9a所示的方法还包括步骤903。

903、需求方1验证安全需求2。

904、需求方1基于安全需求1和安全需求2确定安全决策。

905、需求方1发送包括安全决策的消息。对应的，需求方2接收该包括安全决策的消息。

作为一种可能的实现方式，如图9b所示，需求方1可以将安全决策上传至分布式账本，对应的，需求方2可以从分布式账本下载该安全决策。可理解，关于图9b所示的相关步骤的具体说明可以参考图9a，本申请实施例不再详述。

906、需求方1和需求方2基于安全决策进行通信。

本申请实施例中，两个需求方各自生成安全需求，从而一方结合自身的安全需求以及对方的安全需求确定安全决策，不仅保证了这两个需求方能够基于安全决策通信，而且保证了安全决策的制定更合理，使得安全决策协商的流程更灵活。

图9c是本申请实施例提供的一种安全决策协商方法的流程示意图。如图9c所示，该方法包括：

911、需求方1生成安全需求1，需求方2生成安全需求2。

示例性的，需求方1和需求方2均可以按照图4a所示的结构生成安全需求。对于需求方1生成安全需求1和需求方2生成安全需求2的先后顺序，本申请实施例不作限定。

912、需求方2发送包括安全需求2的消息，对应的，需求方1接收包括安全需求2的消息。

作为一种可能的实现方式，如图9d所示，需求方2可以将安全需求2上传至分布式账本，对应的，需求方1可以从分布式账本下载该安全需求2。

913、需求方1发送包括安全需求1的消息，对应的，需求方2接收包括安全需求1的消息。

作为一种可能的实现方式，如图9d所示，需求方1可以将安全需求1上传至分布式账本，对应的，需求方2可以从分布式账本下载该安全需求1。关于图9d的具体说明可以参考图9c，这里不作详述。

可理解，本申请实施例对于步骤912和步骤913的先后顺序不作限定。

作为一种可能的实现方式，图9c还可以包括步骤914。

914、需求方1验证安全需求2，需求方2验证安全需求1。

915、需求方1基于安全需求1和安全需求2确定安全决策，需求方2基于安全需求1和安全需求2确定安全决策。

916、需求方1和需求方2基于安全决策进行通信。

可理解，关于图9c的具体说明可以参考图3、图8和图9a等，这里不再详述。

本申请实施例中，两个需求方各自生成安全需求，从而各自结合自身的安全需求以及对方的安全需求确定安全决策，不仅保证了这两个需求方能够基于安全决策通信，而且保证了安全决策的制定更合理，使得安全决策协商的流程更灵活。

需要说明的是，图6a、图6b、图7a、图7b、图8、图9a至图9d所示的方法中，能力方和需求方可以为不同的终端设备；或者，能力方和需求方可以为不同的网络功能；或者，需求方为终端设备，能力方为核心网网元等。其中，需求方和能力方之间交互时可以直接通信，或者，需求方和能力方之间的交互可以通过转发网元实现等，本申请实施例对此不作限定。

以下将结合不同的场景及设备说明本申请实施例提供的安全决策协商方法。关于图10a、图10b、图11a、图11b、图12a和图12b的有益效果的说明可以参考上文。

图10a和图10b是本申请实施例提供的一种安全决策协商方法的流程示意图。图10a和图10b中，可信网元可以作为独立的网络功能，存在于核心网中。由此，从图1所示的通信系统可以看出，UE需要与核心网中的网元交互时，需要通过AMF转发相关消息。AMF转发消息时，可以是透传的方式，也可以是再生的方式，本申请实施例对此不作限定。该安全决策协商方法中，安全标签的安全粒度可以为设备粒度，由此可以将安全决策协商流程和UE的注册流程结合起来，提高注册流程和安全决策协商流程的效率。当然，本申请实施例所示的方法也可以应用于用户粒度。

如图10a所示，安全决策协商方法包括：

1001、UE生成安全需求，可信网元生成安全能力。

可理解，UE可以根据设置生成安全需求，可信网元可以遍历查询核心网的安全资源池，生成核心网的安全能力。关于UE根据设置生成安全需求的具体说明可以参考上文，这里不作详述。

1002、UE向AMF发送认证请求(registration request)消息，对应的，AMF接收该认证请求消息。

1003、AMF向可信网元发送请求消息，该请求消息用于请求安全能力，对应的，可信网元接收该请求消息。

该请求消息还可以称为安全标签请求消息，安全标签提供请求(securitytagprovide request)消息或者安全能力请求消息等，本申请实施例对此不作限定。该请求消息还可以理解为用于请求可信网元提供安全能力，或者，用于请求可信网元提供核心网的安全能力。

1004、可信网元向AMF发送响应消息，该响应消息包括安全能力，对应的，AMF接收该响应消息。

响应消息还可以称为安全标签响应消息，安全标签提供响应(securitytagprovide response)消息或安全能力响应消息等，本申请实施例对此不作限定。

1005、AMF向UE发送认证接受(registration accept)消息，该认证接受消息包括安全能力，对应的，UE接收该认证接受消息。

作为一种可能的实现方式，如果UE和可信网元都采用分布式账本，则可信网元可以将安全能力上传到分布式账本，UE可以从分布式账本下载安全能力。对于分布式账本的描述可以参考上文相关的实施例，这里不作详述。

作为一种可能的实现方式，UE获取到安全能力之后，还可以验证该安全能力是否可信，如果可信，则执行步骤1006。关于UE验证安全能力的相关说明可以参考上文，这里不作详述。

1006、UE基于安全需求和安全能力确定安全决策。

1007、UE向AMF发送认证完成(registration complete)消息，该认证完成消息包括安全决策，对应的，AMF接收该认证完成消息。

1008、AMF向可信网元发送包括安全决策的消息，对应的，可信网元接收该包括安全决策的消息。

包括安全决策的消息还可以称为标签提供消息、安全标签提供(securitytagprovide)消息等，本申请实施例对此不作限定。

1009、UE和可信网元基于安全决策进行通信。

图10a是以UE确定安全决策为例示出的，图10b将以可信网元确定安全决策为例进行说明。如图10b所示，该方法包括：

1011、UE生成安全需求，可信网元生成安全能力。

1012、UE向AMF发送认证请求消息，该认证请求消息包括安全需求，对应的，AMF接收该认证请求消息。

示例性的，安全需求可以包含于认证请求消息中的UE安全能力IE中。

1013、AMF向可信网元发送包括安全需求的消息，对应的，可信网元接收该包括安全需求的消息。

作为一种可能的实现方式，如果UE和可信网元都采用分布式账本技术，则UE可以将安全需求上传至分布式账本，对应的，可信网元可以从分布式账本下载UE的安全需求。对于分布式账本的描述可以参考上文相关的实施例，这里不作详述。

作为一种可能的实现方式，可信网元获取到安全需求之后，还可以验证该安全需求是否可信，如果可信，则执行步骤1014。关于可信网元验证安全需求的相关说明可以参考上文，这里不作详述。

1014、可信网元基于安全需求和安全能力确定安全决策。

1015、可信网元向AMF发送包括安全决策的消息，对应的，AMF接收该包括安全决策的消息。

该包括安全决策的消息可以称为安全标签提供响应消息、标签响应消息等，本申请实施例对此不作限定。

1016、AMF向UE发送认证接受消息，该认证接受消息包括安全决策，对应的，UE接收该认证接受消息。

1017、UE向AMF发送认证完成消息，对应的，AMF接收该认证完成消息。

1018、UE和可信网元基于安全决策进行通信。

如果UE有新的安全需求，则UE可以即时向网络发送更新的安全需求，否则网络可以采用旧的安全决策，或上一次该业务场景中该UE的安全决策。

可理解，本申请实施例中，可信网元和UE还可以基于图8所示的方法，均本地生成安全决策，这里不作一一详述。

图11a和图11b是本申请实施例提供的一种安全决策协商方法的流程示意图。图11a和图11b中，可信网元可以作为独立的网络功能，存在于核心网中，即UE可以通过AMF与可信网元交互。该安全决策协商方法中，安全标签的安全粒度可以为服务粒度，由此可以将安全决策协商流程和UE的服务流程结合起来，保证服务流程和安全决策协商流程的效率。

如图11a所示，安全决策协商方法包括：

1101、UE生成安全需求，可信网元生成安全能力。

1102、UE向AMF发送服务请求(servicerequest)消息，对应的，AMF接收该服务请求消息。

1103、AMF向可信网元发送请求消息，该请求消息用于请求安全能力，对应的，可信网元接收该请求消息。

1104、可信网元向AMF发送响应消息，该响应消息包括安全能力，对应的，AMF接收该响应消息。

1105、AMF向UE发送服务响应(serviceresponse)消息，该服务响应消息包括安全能力，对应的，UE接收该服务响应消息。

作为一种可能的实现方式，UE获取到安全能力之后，还可以验证该安全能力是否可信，如果可信，则执行步骤1106。关于UE验证安全能力的相关说明可以参考上文，这里不作详述。

1106、UE基于安全需求和安全能力确定安全决策。

1107、UE向AMF发送服务完成(servicecomplete)消息，该服务完成消息包括安全决策，对应的，AMF接收该服务完成消息。

1108、AMF向可信网元发送包括安全决策的消息，对应的，可信网元接收该包括安全决策的消息。

1109、UE和可信网元基于安全决策进行通信。

图11a是以UE确定安全决策为例示出的，图11b将以可信网元确定安全决策为例进行说明。如图11b所示，该方法包括：

1111、UE生成安全需求，可信网元生成安全能力。

1112、UE向AMF发送服务请求消息，该服务请求消息包括安全需求，对应的，AMF接收该服务请求消息。

1113、AMF向可信网元发送包括安全需求的消息，对应的，可信网元接收该包括安全需求的消息。

作为一种可能的实现方式，可信网元获取到安全需求之后，还可以验证该安全需求是否可信，如果可信，则执行步骤1114。关于可信网元验证安全需求的相关说明可以参考上文，这里不作详述。

1114、可信网元基于安全需求和安全能力确定安全决策。

1115、可信网元向AMF发送包括安全决策的消息，对应的，AMF接收该包括安全决策的消息。

1116、AMF向UE发送服务接受(serviceaccept)消息，该服务接受消息包括安全决策，对应的，UE接收该服务接受消息。

1117、UE和可信网元基于安全决策进行通信。

可理解，本申请实施例中，可信网元和UE还可以基于图8所示的方法，均本地生成安全决策，这里不作一一详述。关于图11a和图11b的具体说明可以参考上文，如图10a、图10b、图6a、图6b、图7a、图7b、图3等，这里不作详述。

图12a和图12b是本申请实施例提供的一种安全决策协商方法的流程示意图。图12a和图12b中，可信网元可以作为独立的网络功能，存在于核心网中。本申请实施例可以结合安全决策协商流程和NEF参数提供服务流程结合起来，从而实现根据安全决策协商流程。一般来说，AF与核心网中的网络功能交互时，需要通过NEF转发相关消息，因此图12a和图12b中均是以NEF转发相关消息为例示出的。NEF转发消息时，可以是透传的方式，也可以是再生的方式，本申请实施例对此不作限定。

如图12a所示，安全决策协商方法包括：

1201、AF生成安全需求，可信网元生成安全能力。

1202、AF向NEF发送参数提供请求(parameterprovisionrequest)消息，对应的，NEF接收该参数提供请求消息。

该参数提供请求消息可以包括Nnef_参数提供请求消息。

1203、NEF向可信网元发送请求消息，该请求消息用于请求安全能力，对应的，可信网元接收该请求消息。

1204、可信网元向NEF发送响应消息，该响应消息包括安全能力，对应的，NEF接收该响应消息。

1205、NEF向AF发送参数提供响应(parameterprovisionreponse)消息，该参数提供响应消息包括安全能力，对应的，AF接收该参数提供响应消息。

1206、AF基于安全需求和安全能力确定安全决策。

1207、AF向NEF发送参数提供结果(parameterprovisionresult)消息，该参数提供结果消息包括安全决策，对应的，NEF接收该参数提供结果消息。

1208、NEF向可信网元发送包括安全决策的消息，对应的，可信网元接收该包括安全决策的消息。

1209、AF和可信网元基于安全决策进行通信。

图12a是以AF确定安全决策为例示出的，图12b将以可信网元确定安全决策为例进行说明。如图12b所示，该方法包括：

1211、AF生成安全需求，可信网元生成安全能力。

1212、AF向NEF发送参数提供请求消息，该参数提供请求消息包括安全需求，对应的，NEF接收该参数提供请求消息。

1213、NEF向可信网元发送包括安全需求的消息，对应的，可信网元接收该包括安全需求的消息。

1214、可信网元基于安全需求和安全能力确定安全决策。

1215、可信网元向NEF发送包括安全决策的消息，对应的，NEF接收该包括安全决策的消息。

1216、NEF向AF发送参数提供响应消息，该参数提供响应消息包括安全决策，对应的，AF接收该参数提供响应消息。

1217、AF和可信网元基于安全决策进行通信。

可理解，图12a和图12b的具体说明可以参考上文，这里不再一一详述。

以下对本申请实施例提供的分布式账本进行说明：

本申请实施例提供了通信网络和分布式账本技术融合场景下安全标签的上传流程、下载流程和更新流程。如果核心网提供分布式账本存储功能，那么可信网元可以向分布式账本上传安全标签。示例性的，安全能力可以是能力方的特征属性，安全决策需要与需求方的标识信息对应进行保存。可选地，安全决策可以与需求方的标识信息和能力方的标识信息对应保存。当重新进行安全决策协商流程时，可信网元可以从分布式账本下载历史的安全需求和安全决策，提高协商效率。

示例性的，核心网设置分布式账本管理节点，负责所有分布式账本中数据的上传、下载和更新管理。图13a是本申请实施例提供的一种上传安全标签的流程示意图。类似的，对于需求方上传安全需求的方法可以参考图13a，不再一一详述。

如图13a，该方法包括：

1301、能力方生成安全能力。

1302、能力方上传安全能力，对应的，分布式账本管理节点接收该安全能力。

能力方发送安全能力的同时可以携带能力方的标识信息。

1303、分布式账本管理节点将安全能力上传至分布式账本。

示例性的，分布式账本管理节点在接收到安全能力之后，可以先验证能力方的身份，确定其是否具有分布式账本的上传数据的权限，如果验证通过，则将安全能力与能力方的标识信息对应保存到分布式账本上。

1304、能力方和需求方通过协商确定安全决策。

1305、能力方上传安全决策，对应的，分布式管理账本节点接收该安全决策。

能力方发送安全决策到分布式账本管理节点时可以同时携带能力方的标识信息和需求方的标识信息。

1306、分布式账本管理节点将安全决策上传至分布式账本。

分布式账本管理节点接收到安全决策之后，可以验证能力方的身份，确定其是否具有分布式账本的上传数据的权限，如果验证通过，则将安全决策与能力方的标识信息身份和需求方的标识信息对应保存到分布式账本上。

图13b是本申请实施例提供的一种下载安全标签的流程示意图。图13b是以能力方为例，对于需求方的方法可以类似参考图13b，不再一一详述。如图13b所示，该方法包括：

1311、需求方发起安全决策协商流程。

示例性的，需求方可以通过向能力方发送请求消息或指示信息的方式发起安全决策协商流程，该请求消息后指示信息中可以不携带安全需求。

可理解，需求方也可以在安全决策协商流程结束后短时间内再次请求安全决策更新。然后按照本申请实施例提供的方法获得分布式账本中的安全决策。

1312、能力方向分布式账本管理节点发送下载请求，对应的，分布式账本管理节点接收该下载请求。其中，下载请求可以用于请求下载需求方的历史安全需求，该下载请求包括能力方的标识信息和需求方的标识信息。

1313、分布式账本管理节点根据需求方的标识信息从分布式账本下载安全需求。

示例性的，分布式账本管理节点可以验证能力方身份，确定其是否具有分布式账本的下载数据的权限，如果验证通过，则根据需求方的标识信息从分布式账本下载安全需求。

1314、分布式账本管理节点将安全需求发送给能力方，对应的，能力方接收该安全需求。

1315、能力方根据安全需求和安全能力确定安全决策。

1316、能力方将将安全决策发送给需求方，对应的，需求方接收该安全决策。

图13c是本申请实施例提供的一种更新安全决策的流程示意图，如图13c所示，该方法包括：

1321、需求方发起安全决策更新流程。

示例性的，需求方可以在安全决策协商流程结束后的一定时间内再次请求安全决策的更新。例如，需求方可以向能力方发送更新请求，对应的，能力方可以接收该更新请求，该更新请求用于请求更新安全决策。需求方在发起安全决策更新流程时，上述更新请求中可以包括新的安全需求。或者，需求方在发起安全决策更新流程之前，就已经向分布式账本管理节点更新了安全需求。

1322、能力方向分布式账本管理节点发送下载请求，对应的，分布式账本管理节点接收该下载请求。其中，下载请求可以用于请求下载需求方的历史安全需求或新的安全需求等保存于分布式账本的需求方的安全需求，该下载请求包括能力方的标识信息和需求方的标识信息。可理解，能力方在获得新的安全需求时，可以基于该新的安全需求以及自身的安全能力确定安全决策，以及将该安全决策上传至分布式账本管理节点。关于上传安全决策的说明可以参考图13a，这里不再详述。当然，能力方在确定安全决策之后，还可以直接将该安全决策发送给需求方，该情况下，图13c所示的步骤1313和步骤1324不是必须的。可选地，步骤1322与步骤1321的先后顺序，本申请实施例不作限定。如在需求方发起安全决策更新流程之前，能力方也可以基于分布式账本中所保存的新的安全需求确定安全决策。

1323、分布式账本管理节点根据需求方的标识信息从分布式账本下载安全决策。

示例性的，分布式账本管理节点可以验证能力方身份，确定其是否具有分布式账本的下载数据的权限，如果验证通过，则根据需求方的标识信息从分布式账本下载安全决策。

1324、分布式账本管理节点将安全决策发送给能力方，对应的，能力方接收该安全决策。

1325、能力方向需求方发送安全决策，对应的，需求方接收安全决策。

可理解，图13a至图13b所示的方法中，可以包括分布式账本管理节点，也可以不包括分布式账本管理节点，如需求方或能力方可以从分布式账本下载安全标签，或上传安全标签至分布式账本。

以下将介绍本申请实施例提供的网元。

本申请根据上述方法实施例对网元进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。下面将结合图14至图16详细描述本申请实施例的网元。

图14是本申请实施例提供的一种网元的结构示意图，如图14所示，该网元包括处理单元1401和收发单元1402。

在本申请的一些实施例中，处理单元1401和收发单元1402可以用于执行上述方法实施例中第一网元执行的步骤或功能。示例性的，处理单元1401，用于基于需求方的安全需求和能力方的安全能力确定安全决策；收发单元1402，用于发送包括安全决策的消息。

在一种可能的实现方式中，处理单元1401，具体用于从分布式账本中获取安全需求和安全能力。

在一种可能的实现方式中，收发单元1402，具体用于将安全决策上传至分布式账本中。

在一种可能的实现方式中，处理单元1401，具体用于基于安全需求中第一位的取值和安全能力中第一位的取值的运算或映射结果确定安全决策中第一位的取值；或者，基于安全需求中的优先级信息和安全能力确定安全决策。

上述第一网元可以为需求方、能力方或除需求方和能力方之外的第三方，本申请实施例对此不作限定。

可选地，上述网元为需求方时，收发单元1402，还用于接收包括安全能力的消息。

收发单元1402，还用于发送请求消息，请求消息用于请求能力方的安全能力。

可选地，上述网元为能力方时，收发单元1402，还用于接收包括安全需求的消息。

收发单元1402，还用于发送请求消息，请求消息用于请求需求方的安全需求。

在本申请的另一些实施例中，处理单元1401和收发单元1402可以用于执行上述方法实施例中需求方执行的步骤或功能。示例性的，收发单元1402，用于发送包括安全需求的消息；收发单元1402，还用于接收包括安全决策的消息，安全决策对应于安全需求。

本申请实施例中，收发单元1402，具体用于通过处理单元1401获取安全需求，然后输出该安全需求。处理单元1401，还可以用于对安全决策进行处理，如通过安全决策与能力方进行通信。

在本申请的又一些实施例中，处理单元1401和收发单元1402可以用于执行上述方法实施例中能力方执行的步骤或功能。示例性的，收发单元1402，用于发送包括安全能力的消息；收发单元1402，还用于接收包括安全决策的消息，安全决策为安全能力和需求方的安全需求协商的结果。

本申请实施例中，收发单元1402，具体用于通过处理单元1401获取安全能力，然后输出该安全能力。处理单元1401，还可以用于对安全决策进行处理，如通过安全决策与能力方进行通信。

可理解，本申请实施例示出的收发单元和处理单元的具体说明仅为示例，对于收发单元和处理单元的具体功能或执行的步骤等，可以参考上述方法实施例，如图3、图6a、图6b、图7a、图7b、图8、图9a至图9d、图10a、图10b、图11a、图11b、图12a、图12b、图13a至图13c，这里不再详述。

以上介绍了本申请实施例的网元，以下介绍所述网元可能的产品形态。应理解，但凡具备上述图14所述的网元的功能的任何形态的产品，都落入本申请实施例的保护范围。还应理解，以下介绍仅为举例，不限制本申请实施例的网元的产品形态仅限于此。

在一种可能的实现方式中，图14所示的网元中，处理单元1401可以是一个或多个处理器，收发单元1402可以是收发器，或者收发单元1402还可以是发送单元和接收单元，发送单元可以是发送器，接收单元可以是接收器，该发送单元和接收单元集成于一个器件，例如收发器。本申请实施例中，处理器和收发器可以被耦合等，对于处理器和收发器的连接方式，本申请实施例不作限定。

如图15所示，该网元150包括一个或多个处理器1520和收发器1510。

在本申请的一些实施例中，处理器1520和收发器1510可以用于执行上述方法实施例中网元第一网元执行的步骤或功能。示例性的，处理器1520，用于基于需求方的安全需求和能力方的安全能力确定安全决策；收发器1510，用于发送包括安全决策的消息。

在一种可能的实现方式中，处理器1520，具体用于从分布式账本中获取安全需求和安全能力。

在一种可能的实现方式中，收发器1510，具体用于将安全决策上传至分布式账本中。

在一种可能的实现方式中，处理器1520，具体用于基于安全需求中第一位的取值和安全能力中第一位的取值的运算或映射结果确定安全决策中第一位的取值；或者，基于安全需求中的优先级信息和安全能力确定安全决策。

可选地，上述网元为需求方时，收发器1510，还用于接收包括安全能力的消息。

收发器1510，还用于发送请求消息，请求消息用于请求能力方的安全能力。

可选地，上述网元为能力方时，收发器1510，还用于接收包括安全需求的消息。

收发器1510，还用于发送请求消息，请求消息用于请求需求方的安全需求。

在本申请的另一些实施例中，处理器1520和收发器1510可以用于执行上述方法实施例中需求方执行的步骤或功能。示例性的，收发器1510，用于发送包括安全需求的消息；收发器1510，还用于接收包括安全决策的消息，安全决策对应于安全需求。

在本申请的又一些实施例中，处理器1520和收发器1510可以用于执行上述方法实施例中能力方执行的步骤或功能。示例性的，收发器1510，用于发送包括安全能力的消息；收发器1510，还用于接收包括安全决策的消息，安全决策为安全能力和需求方的安全需求协商的结果。

可理解，本申请实施例示出的收发器和处理器的具体说明仅为示例，对于收发器和处理器的具体功能或执行的步骤等，可以参考上述方法实施例，如图3、图6a、图6b、图7a、图7b、图8、图9a至图9d、图10a、图10b、图11a、图11b、图12a、图12b、图13a至图13c，这里不再详述。

在图15所示的网元的各个实现方式中，收发器可以包括接收机和发射机，该接收机用于执行接收的功能(或操作)，该发射机用于执行发射的功能(或操作)。以及收发器用于通过传输介质和其他设备/装置进行通信。

可选的，网元150还可以包括一个或多个存储器1530，用于存储程序指令和/或数据(如本申请实施例所示的配置列表等)。存储器1530和处理器1520耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器1520可能和存储器1530协同操作。处理器1520可可以执行存储器1530中存储的程序指令。可选的，上述一个或多个存储器中的至少一个可以集成于处理器中。

本申请实施例中不限定上述收发器1510、处理器1520以及存储器1530之间的具体连接介质。本申请实施例在图15中以存储器1530、处理器1520以及收发器1510之间通过总线1540连接，总线在图15中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图15中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

在本申请实施例中，处理器可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成等。

本申请实施例中，存储器可包括但不限于硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)等非易失性存储器，随机存储记忆体(random accessmemory，RAM)、可擦除可编程只读存储器(erasable programmable ROM，EPROM)、只读存储器(read-only memory，ROM)或便携式只读存储器(compact disc read-only memory，CD-ROM)等等。存储器是能够用于携带或存储具有指令或数据结构形式的程序代码，并能够由计算机(如本申请示出的网元等)读和/或写的任何存储介质，但不限于此。本申请实施例中的存储器还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

示例性的，当网元用于实现终端设备执行的步骤或功能时，处理器1520可以主要用于对通信协议以及通信数据进行处理，以及对整个网元进行控制，执行软件程序，处理软件程序的数据。存储器1530主要用于存储软件程序和数据。收发器1510可以包括控制电路和天线，控制电路主要用于基带信号与射频信号的转换以及对射频信号的处理。天线主要用于收发电磁波形式的射频信号。输入输出装置，例如触摸屏、显示屏，键盘等主要用于接收用户输入的数据以及对用户输出数据。当网元开机后，处理器1520可以读取存储器1530中的软件程序，解释并执行软件程序的指令，处理软件程序的数据。当需要通过无线发送数据时，处理器1520对待发送的数据进行基带处理后，输出基带信号至射频电路，射频电路将基带信号进行射频处理后将射频信号通过天线以电磁波的形式向外发送。当有数据发送到网元时，射频电路通过天线接收到射频信号，将射频信号转换为基带信号，并将基带信号输出至处理器1520，处理器1520将基带信号转换为数据并对该数据进行处理。

在另一种实现中，所述的射频电路和天线可以独立于进行基带处理的处理器而设置，例如在分布式场景中，射频电路和天线可以与独立于网元，呈拉远式的布置。

可理解，本申请实施例示出的网元还可以具有比图15更多的元器件等，本申请实施例对此不作限定。以上所示的处理器和收发器所执行的方法仅为示例，对于该处理器和收发器具体所执行的步骤可参照上文介绍的方法。

在另一种可能的实现方式中，图14所示的网元中，处理单元1401可以是一个或多个逻辑电路，收发单元1402可以是输入输出接口，又或者称为通信接口，或者接口电路，或接口等等。或者收发单元1402还可以是发送单元和接收单元，发送单元可以是输出接口，接收单元可以是输入接口，该发送单元和接收单元集成于一个单元，例如输入输出接口。如图16所示，图16所示的网元包括逻辑电路1601和接口1602。即上述处理单元1401可以用逻辑电路1601实现，收发单元1402可以用接口1602实现。其中，该逻辑电路1601可以为芯片、处理电路、集成电路或片上系统(system on chip，SoC)芯片等，接口1602可以为通信接口、输入输出接口、管脚等。示例性的，图16是以上述网元为芯片为例出的，该芯片包括逻辑电路1601和接口1602。

本申请实施例中，逻辑电路和接口还可以相互耦合。对于逻辑电路和接口的具体连接方式，本申请实施例不作限定。

在本申请的一些实施例中，逻辑电路1601和接口1602可以用于执行上述方法实施例中网元第一网元执行的步骤或功能。示例性的，逻辑电路1601，用于基于需求方的安全需求和能力方的安全能力确定安全决策；接口1602，用于输出包括安全决策的消息。

在一种可能的实现方式中，逻辑电路1601，具体用于从分布式账本中获取安全需求和安全能力。

在一种可能的实现方式中，逻辑电路1601，可以通过接口1602将安全决策上传至分布式账本中。

在一种可能的实现方式中，逻辑电路1601，具体用于基于安全需求中第一位的取值和安全能力中第一位的取值的运算或映射结果确定安全决策中第一位的取值；或者，基于安全需求中的优先级信息和安全能力确定安全决策。

可选地，上述第一网元为需求方时，接口1602，还用于输入包括安全能力的消息。

接口1602，还用于输出请求消息，请求消息用于请求能力方的安全能力。

可选地，上述网元为能力方时，接口1602，还用于输入包括安全需求的消息。

接口1602，还用于输出请求消息，请求消息用于请求需求方的安全需求。

在本申请的另一些实施例中，逻辑电路1601和接口1602可以用于执行上述方法实施例中需求方执行的步骤或功能。示例性的，接口1602，用于输出包括安全需求的消息；接口1602，还用于输入包括安全决策的消息，安全决策对应于安全需求。

本申请实施例中，接口1602，具体用于通过逻辑电路1601获取安全需求，然后输出该安全需求。逻辑电路1601，还可以用于对安全决策进行处理，如通过安全决策与能力方进行通信。

在本申请的又一些实施例中，逻辑电路1601和接口1602可以用于执行上述方法实施例中能力方执行的步骤或功能。示例性的，接口1602，用于输出包括安全能力的消息；接口1602，还用于输入包括安全决策的消息，安全决策为安全能力和需求方的安全需求协商的结果。

本申请实施例中，接口1602，具体用于通过逻辑电路1601获取安全能力，然后输出该安全能力。逻辑电路1601，还可以用于对安全决策进行处理，如通过安全决策与能力方进行通信。

可理解，本申请实施例示出的逻辑电路和接口的具体说明仅为示例，对于逻辑电路和接口的具体功能或执行的步骤等，可以参考上述方法实施例，如图3、图6a、图6b、图7a、图7b、图8、图9a至图9d、图10a、图10b、图11a、图11b、图12a、图12b、图13a至图13c，这里不再详述。

可理解，本申请实施例示出的网元可以采用硬件的形式实现本申请实施例提供的方法，也可以采用软件的形式实现本申请实施例提供的方法等，本申请实施例对此不作限定。

本申请实施例还提供了一种通信系统，该通信系统包括需求方和能力方，该需求方和该能力方可以用于执行前述任一实施例中的方法，如图3、图6a、图6b、图7a、图7b、图8、图9a至图9d、图10a、图10b、图11a、图11b、图12a、图12b、图13a至图13c。可选地，该通信系统可以包括需求方、能力方和第三方，该第三方可以理解为除需求方和能力方之外的网元，关于需求方、能力方和第三方的说明可以参考上述方法实施例。

此外，本申请还提供一种计算机程序，该计算机程序用于实现本申请提供的方法中由第一网元执行的操作和/或处理。

本申请还提供一种计算机程序，该计算机程序用于实现本申请提供的方法中由需求方或能力方执行的操作和/或处理。

本申请还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机代码，当计算机代码在计算机上运行时，使得计算机执行本申请提供的方法中由第一网元执行的操作和/或处理。

本申请还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机代码，当计算机代码在计算机上运行时，使得计算机执行本申请提供的方法中由需求方或能力方执行的操作和/或处理。

本申请还提供一种计算机程序产品，该计算机程序产品包括计算机代码或计算机程序，当该计算机代码或计算机程序在计算机上运行时，使得本申请提供的方法中由第一网元执行的操作和/或处理被执行。

本申请还提供一种计算机程序产品，该计算机程序产品包括计算机代码或计算机程序，当该计算机代码或计算机程序在计算机上运行时，使得本申请提供的方法中由需求方或能力方执行的操作和/或处理被执行。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

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

Claims

1.一种安全决策协商方法，其特征在于，所述方法包括：

第一网元基于需求方的安全需求和能力方的安全能力确定安全决策；

所述第一网元发送包括所述安全决策的消息。

2.根据权利要求1所述的方法，其特征在于，所述第一网元包括所述需求方，所述方法还包括：

所述需求方接收包括所述安全能力的消息。

3.根据权利要求2所述的方法，其特征在于，所述需求方接收包括所述安全能力的消息之前，所述方法还包括：

所述需求方发送请求消息，所述请求消息用于请求所述能力方的安全能力。

4.根据权利要求1所述的方法，其特征在于，所述第一网元包括所述能力方，所述方法还包括：

所述能力方接收包括所述安全需求的消息。

5.根据权利要求4所述的方法，其特征在于，所述能力方接收包括所述安全需求的消息之前，所述方法还包括：

所述能力方发送请求消息，所述请求消息用于请求需求方的安全需求。

6.根据权利要求1所述的方法，其特征在于，所述第一网元基于需求方的安全需求和能力方的安全能力确定安全决策之前，所述方法还包括：

所述第一网元从分布式账本中获取所述安全需求和所述安全能力。

7.根据权利要求1-6任一项所述的方法，其特征在于，所述第一网元发送包括所述安全决策的消息，包括：

所述第一网元将所述安全决策上传至分布式账本中。

8.根据权利要求1-7任一项所述的方法，其特征在于，所述第一网元基于需求方的安全需求和能力方的安全能力确定安全决策包括：

所述第一网元基于所述安全需求中第一位的取值和所述安全能力中第一位的取值的运算或映射结果确定所述安全决策中第一位的取值；或者，

所述第一网元基于所述安全需求中的优先级信息和所述安全能力确定所述安全决策。

9.一种安全决策协商方法，其特征在于，所述方法包括：

需求方发送包括安全需求的消息；

所述需求方接收包括安全决策的消息，所述安全决策对应于所述安全需求。

10.根据权利要求9所述的方法，其特征在于，所述安全决策对应于所述安全需求包括：所述安全决策为基于所述安全需求和能力方的安全能力协商的结果。

11.一种安全决策协商方法，其特征在于，所述方法包括：

能力方发送包括安全能力的消息；

所述能力方接收包括安全决策的消息，所述安全决策为基于所述安全能力和需求方的安全需求协商的结果。

12.根据权利要求1-11任一项所述的方法，其特征在于，所述安全需求包括如下至少一项信息：安全粒度、认证方法、密钥能力、隐私保护、可信证明、跨运营商、分布式账本。

13.根据权利要求1-12任一项所述的方法，其特征在于，所述安全需求包括如下至少一项信息的优先级信息：加密算法、完整性保护算法、认证方法、密钥能力、隐私保护、可信证明、跨运营商、分布式账本。

14.根据权利要求1-13任一项所述的方法，其特征在于，所述安全决策用于确定可信向量TV，所述TV包括如下至少一项信息：隐私保护、可信证明、跨运营商、和分布式账本。

15.根据权利要求1-14任一项所述的方法，其特征在于，所述第一网元包括如下任一项：终端设备、应用功能AF、可信网元、接入和移动性管理功能AMF、网络开放功能NEF、鉴权服务功能AUSF、接入网设备。

16.一种第一网元，其特征在于，所述网元包括：

处理单元，用于基于需求方的安全需求和能力方的安全能力确定安全决策；

收发单元，用于发送包括所述安全决策的消息。

17.根据权利要求16所述的网元，其特征在于，所述收发单元，还用于接收包括所述安全能力的消息。

18.根据权利要求17所述的网元，其特征在于，所述收发单元，还用于发送请求消息，所述请求消息用于请求所述能力方的安全能力。

19.根据权利要求16所述的网元，其特征在于，所述收发单元，还用于接收包括所述安全需求的消息。

20.根据权利要求19所述的网元，其特征在于，所述收发单元，还用于发送请求消息，所述请求消息用于请求所述需求方的安全需求。

21.根据权利要求16所述的网元，其特征在于，所述处理单元，具体用于从分布式账本中获取所述安全需求和所述安全能力。

22.根据权利要求16-21任一项所述的网元，其特征在于，所述收发单元，具体用于将所述安全决策上传至分布式账本中。

23.根据权利要求16-22任一项所述的网元，其特征在于，所述处理单元，具体用于基于所述安全需求中第一位的取值和所述安全能力中第一位的取值的运算或映射结果确定所述安全决策中第一位的取值；或者，基于所述安全需求中的优先级信息和所述安全能力确定所述安全决策。

24.一种需求方，其特征在于，所述需求方包括：

收发单元，用于发送包括安全需求的消息；

所述收发单元，还用于接收包括安全决策的消息，所述安全决策对应于所述安全需求。

25.一种能力方，其特征在于，所述能力方包括：

收发单元，用于发送包括安全能力的消息；

所述收发单元，还用于接收包括安全决策的消息，所述安全决策为基于所述安全能力和需求方的安全需求协商的结果。

26.一种网元，其特征在于，包括处理器和存储器；

所述存储器用于存储指令；

所述处理器用于执行所述指令，以使权利要求1-14任一项所述的方法被执行。

27.一种网元，其特征在于，包括逻辑电路和接口，所述逻辑电路和所述接口耦合；

所述接口用于输入待处理的数据，所述逻辑电路按照如权利要求1-14任一项所述的方法对所述待处理的数据进行处理，获得处理后的数据，所述接口用于输出所述处理后的数据。

28.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储计算机程序，当所述计算机程序被执行时，权利要求1-14任一项所述的方法被执行。

29.一种通信系统，其特征在于，所述通信系统包括第一网元和需求方，所述第一网元用于执行如权利要求1、4-8、12-14任一项所示的方法，所述需求方用于执行如权利要求9、10、12-14所述的方法；或者，所述通信系统包括第一网元和能力方，所述第一网元用于执行如权利要求1-3、6-8、12-14任一项所示的方法，所述能力方用于执行如权利要求11-14任一项所示的方法。