通信方法和网络设备与流程

阅读：评论：0

1.本技术涉及通信领域，并且更具体地，涉及一种通信方法和网络设备。

背景技术：

2.当前第五代(the 5th generation，5g)网络中，针对基于服务化架构(service based architecture，sba)，不同网络功能(network function，nf)网元之间的业务访问是基于授权机制进行的，比如：包括静态授权方式和oauth授权方式。
3.其中，网络功能网元在进行业务访问时需要确定执行的授权方式。特别是在漫游场景下，如果服务消费功能网元和服务提供功能网元属于不同的运营商，那么两个网元之间的授权机制不同，就会出现授权冲突的问题，从而发生业务的中断。
4.因此，不同网络功能网元之间如何完成授权方式的协商是亟待解决的问题。

技术实现要素：

5.第一方面，提供了一种通信方法，该方法可以由网络存储功能(network repository function，nrf)网元或安全边缘保护代理(security edge protection proxy，sepp)网元执行，该方法包括：确定第一授权方式和第二授权方式，该第一授权方式是服务消费功能网元所属网络对应的授权方式，该第二授权方式是服务提供功能网元所属网络对应的授权方式；根据该第一授权方式和该第二授权方式确定第三授权方式，该第三授权方式是访问服务提供功能网元的授权方式；发送该第三授权方式。
6.根据本技术提供的方案，通过确定第一授权方式和第二授权方式，根据第一授权方式和第二授权方式确定第三授权方式，并向服务消费功能网元发送该第三授权方式。采用协商的方式进行确定访问服务提供功能网元的授权方式，进而解决授权冲突的问题，保证不同网络功能网元之间的业务访问正常进行。
7.结合第一方面，在第一方面的某些实现方式中，确定第二授权方式，包括：接收第一请求消息，该第一请求消息包括该服务提供功能网元所属网络的标识信息；根据该服务提供功能网元所属网络的标识信息确定该第二授权方式。
8.示例性的，确定第二授权方式可以是网络存储功能nrf网元或安全边缘保护代理sepp网元配置该第二授权方式。通过配置对端授权方式，例如服务提供功能(nf service producer，nfp)网元所属网络公共陆地移动网标识(public land mobile network identity，plmn id2)对应的授权方式，使得nrf或sepp在接收到nfc请求访问对端nfp网元的授权方式时，本端nrf或sepp可以直接根据nfc网元所属网络plmn id1对应的授权方式和对端nfp所属网络plmn id2对应的授权方式确定最终访问nfp的授权方式，减少nfc和nfp之间的授权冲突。
9.应理解，本技术实施例中，第一请求消息包括发现请求消息和/或授权请求消息。
10.结合第一方面，在第一方面的某些实现方式中，确定第一授权方式，包括：获取该服务消费功能网元所属网络的标识信息；根据该服务消费功能网元所属网络的标识信息确
定该第一授权方式。
11.结合第一方面，在第一方面的某些实现方式中，获取服务消费功能网元所属网络的标识信息，包括：接收服务消费功能网元所属网络的标识信息，或者根据第一网络存储功能网元和第一安全边缘保护代理网元之间的连接确定所述服务消费功能网元所属网络的标识信息。
12.示例性的，从服务消费功能网元nfc接收服务消费功能网元所属网络的标识信息。
13.作为示例而非限定，nrf或者sepp可以直接配置访问服务提供功能nfp网元对应的授权方式，即第一授权方式，nrf或者sepp直接保存有该第一授权方式。此时，当nfc请求访问nfp的授权方式时，nrf或者sepp不需要再根据plmn id1和plmn id2支持的授权方式确定最终授权方式。该实现方式既可以避免不同网元互相访问服务时发生授权冲突，又能够较少信令开销。
14.结合第一方面，在第一方面的某些实现方式中，该第三授权方式为开放授权方式，该方法还包括：接收第二请求消息，该第二请求消息用于请求获取第一令牌，该第一令牌用于授权该服务消费功能网元访问该第一服务；确定该第一令牌；发送该第一令牌。
15.示例性的，nrf网元负责服务授权的判断，例如服务消费功能nfc网元在访问服务提供功能nfp网元之前，会先向nrf发送请求消息，nrf判断允许nfc访问nfp之后，会生成一个授权令牌token，并发送token给nfc。使得nfc在访问nfp服务携带token。待nfp在校验token成功后，会为nfc提供对应的服务。
16.示例性的，第一请求信息和第二请求消息均还包括以下信息中的一个或多个：服务消费功能网元所属网络的标识信息、服务提供功能网元的业务类型、服务消费功能网元的业务类型。
17.结合第一方面，在第一方面的某些实现方式中，根据该第一授权方式和该第二授权方式确定第三授权方式，包括：根据该第一授权方式和该第二授权方式的共有授权方式确定该第三授权方式。
18.示例性的，当该共有授权方式为该静态授权方式或该开放授权方式，确定该静态授权方式或该开放授权方式为该第三授权方式；当该共有授权方式为该静态授权方式和该开放授权方式，根据本地策略确定该第三授权方式，或者确定该开放授权方式为该第三授权方式。
19.通过选取第一授权方式和第二授权方式的交集进一步确定最终nfc访问nfp服务使用的授权方式，避免由于授权冲突的问题，导致发生业务的中断。
20.示例性的，当第一授权方式和第二授权方式的共有授权方式同时支持静态授权方式和开放授权方式时，可以确定开放授权方式为最终nfc访问nfp服务所使用的授权方式；也可以根据本地策略进一步确定该第三授权方式，例如，根据nfc网元的能力，或者nfc所在网络的授权策略的机制等，本技术对此不作限定。
21.作为示例而非限定，nrf或sepp根据nfp所属网络(例如，plmn id2)直接确定第三授权，无需根据第一授权方式和第二授权方式的共有方式，进一步确定访问nfp服务的授权方式，并向nfc发送该第三授权方式。
22.第二方面，提供了一种通信方法，该方法可以由服务消费功能(nf service consumer，nfc)网元执行，该方法包括：接收第三授权方式，该第三授权方式是访问服务提
供功能网元的授权方式，该第三授权方式是根据第一授权方式和第二授权方式确定的，该第一授权方式是服务消费功能网元所属网络对应的授权方式，该第二授权方式是该服务提供功能网元所属网络对应的授权方式；根据该第三授权方式向该服务提供功能网元请求第一服务。
23.根据本技术提供的方案，通过接收第三授权方式，即访问服务提供功能网元的授权方式，并根据该第三授权方式向nfp发送服务请求。该第三授权方式是采用协商的方式进行确定的，进而解决nfc和nfp网元之间授权冲突的问题，保证不同网络功能网元之间的业务访问正常进行。
24.结合第二方面，在第二方面的某些实现方式中，在接收该第三授权方式之前，该方法还包括：发送第一请求消息，该第一请求消息用于请求获取该第三授权方式，该第一请求消息包括该服务提供功能网元所属网络的标识信息。
25.应理解，本技术实施例中，第一请求消息包括发现请求消息和/或授权请求消息。
26.示例性的，发送第一请求消息包括：向网络存储功能nrf网元或安全边缘保护代理sepp网元或服务通信代理(service communication proxy，scp)网元发送第一请求消息。
27.应理解，当前5g架构包括scp网元。scp是nf网元的代理，也可以理解scp为一个scp域的出入口，或者代理节点。因此不同域之间的协商，也可以通过scp来完成，例如nfc-scp1-scp2-nfp。所以上述通过sepp直接协商的方式，也可以使用scp的方式。对应的，可以将scp替换为上述sepp，plmn id替换为scp域标识。
28.本技术适用不同域之间的协商，通过域标识确定此域授权方式的机制。例如nrf域、nf set域、scp域，安全域等。域标识也可以不同，例如scp域id，nf set域id，安全域id，nrf域id等。以下以漫游场景，域标识为plmn id为例进行描述。
29.结合第二方面，在第二方面的某些实现方式中，根据该第三授权方式向该服务提供功能网元请求第一服务，包括：当该第三授权方式为开发授权方式，向nrf发送第二请求消息，该第二请求消息用于请求获取第一令牌，该第一令牌用于授权该服务消费功能网元访问该第一服务；接收该第一令牌；向该服务提供功能网元发送用于请求该第一服务的消息，该用于请求该第一服务的消息中包括该第一令牌。
30.示例性的，nrf网元负责服务授权的判断，例如服务消费功能nfc网元在访问服务提供功能nfp网元之前，会先向nrf发送请求消息，nrf判断允许nfc访问nfp之后，会生成一个授权令牌token，并发送token给nfc。使得nfc在访问nfp服务携带token。待nfp在校验token成功后，会为nfc提供对应的服务。
31.结合第二方面，在第二方面的某些实现方式中，根据该第三授权方式向该服务提供功能网元请求第一服务，包括：当第三授权方式为静态授权方式，nfc直接使用该静态授权方式向nfp请求服务。例如发送业务请求至nfp，nfp根据静态授权方式(例如本地策略)判断是否授权nfc使用其请求的服务。
32.示例性的，第一请求信息和第二请求消息均还包括以下信息中的一个或多个：服务消费功能网元所属网络的标识信息、服务提供功能网元的业务类型、服务消费功能网元的业务类型。
33.结合第二方面，在第二方面的某些实现方式中，该接收第三授权方式包括：从网络存储功能网元或安全边缘保护代理网元接收该第三授权方式。
34.第三方面，提供了一种通信方法，该方法可以由第二网络存储功能nrf2网元或第二安全边缘保护代理sepp2网元执行，该方法包括：接收请求消息，该请求消息用于请求获取访问第二功能网元的授权方式，该请求消息包括第一功能网元所属网络对应的授权方式；确定该第二功能网元所属网络对应的授权方式；根据该第一功能网元所属网络对应的授权方式和该第二功能网元所属网络对应的授权方式确定访问该第二功能网元的授权方式；发送访问该第二功能网元的授权方式。
35.可选地，该请求信息包括用于指示nrf2或sepp2返回第二功能网元的授权方式的指示信息。
36.示例性的，sepp2可以同时为多个nfc所属多个网络提供服务，或者仅为nfc所属网络plmn id1提供服务。如果sepp2为多个plmn id对应的网络提供服务，那么sepp2需要从sepp1接收具体的某一plmn id，并根据接收到的plmn id确定对应的授权方式。
37.根据本技术提供的方案，通过两端nrf之间的协商，或者sepp之间的协商，进而确定访问第二功能网元的授权方式，有效解决不同网元间授权冲突的问题，保证不同网络功能网元之间的业务访问正常进行。
38.结合第三方面，在第三方面的某些实现方式中，该第一功能网元包括第一网络存储功能网元或第一安全边缘保护代理网元，该第二功能网元包括第二网络存储功能网元或第二安全边缘保护代理网元。
39.结合第三方面，在第三方面的某些实现方式中，确定该第二功能网元所属网络对应的授权方式，包括：获取该第二功能网元所属网络的标识信息；根据该第二功能网元所属网络的标识信息确定该第二功能网元所属网络对应的授权方式。
40.结合第三方面，在第三方面的某些实现方式中，根据该第一功能网元所属网络对应的授权方式和该第二功能网元所属网络对应的授权方式确定访问该第二功能网元的授权方式，包括：根据该第一功能网元所属网络对应的授权方式和该第二功能网元所属网络对应的授权方式的共有授权方式确定访问该第二功能网元的授权方式；
41.示例性的，当该共有授权方式为该静态授权方式或该开放授权方式，确定该静态授权方式或该开放授权方式为访问该第二功能网元的授权方式；当该共有授权方式为该静态授权方式和该开放授权方式，根据本地策略确定访问该第二功能网元的授权方式，或者确定该开放授权方式为访问该第二功能网元的授权方式。应理解，本技术实施例中根据本地策略确定访问该第二功能网元的授权方式，可以是基于nfc网元的能力，或者nfc所在网络的授权策略的机制等确定，本技术对此不作限定。
42.第四方面，提供了一种通信方法，该方法可以由第一网络存储功能nrf1网元或第一安全边缘保护代理sepp1网元执行，该方法包括：确定第一功能网元所属网络对应的授权方式；发送请求消息，该请求消息用于请求获取访问第二功能网元的授权方式，该请求消息包括该第一功能网元所属网络对应的授权方式；接收访问第二功能网元的授权方式，访问第二功能网元的授权方式是根据该第一功能网元所属网络对应的授权方式和该第二功能网元所属网络对应的授权方式确定的；发送访问第二功能网元的授权方式。
43.可选地，该请求信息包括用于指示nrf2或sepp2返回第二功能网元的授权方式的指示信息。
44.示例性的，sepp2可以同时为多个nfc所属多个网络提供服务，或者仅为nfc所属网
络plmn id1提供服务。如果sepp2为多个plmn id对应的网络提供服务，那么sepp2需要从sepp1接收具体的某一plmn id，并根据接收到的plmn id确定对应的授权方式。
45.根据本技术提供的方案，通过向对端nrf2或sepp2请求获取访问第二功能网元的授权方式，并接收访问第二功能网元的授权方式。再向nfc发送访问第二功能网元的授权方式，使得nfc可以基于该授权方式向第二功能网元发送服务请求，避免网元间授权冲突，保证业务访问的正常进行。
46.结合第四方面，在第四方面的某些实现方式中，该第一功能网元包括第一网络存储功能网元或第一安全边缘保护代理网元，该第二功能网元包括第二网络存储功能网元或第二安全边缘保护代理网元。
47.结合第四方面，在第四方面的某些实现方式中，确定该第一功能网元所属网络对应的授权方式，包括：获取该第一功能网元所属网络的标识信息；根据该第一功能网元所属网络的标识信息确定该第一功能网元所属网络对应的授权方式。
48.第五方面，提供了一种通信方法，该方法可以由第一网络存储功能nrf1网元或第一安全边缘保护代理sepp1网元执行，该方法包括：发送请求消息，该请求消息包括获取第二功能网元所属网络对应的授权方式的指示信息；接收该第二功能网元所属网络对应的授权方式；根据该第二功能网元所属网络对应的授权方式和第一功能网元所属网络对应的授权方式确定访问该第二功能网元的授权方式；发送访问该第二功能网元的授权方式。
49.示例性的，nrf1网元或sepp1网元向nfc发送访问第二功能网元的授权方式，使得nfc可以基于该授权方式向第二功能网元发送服务请求，避免网元间授权冲突，保证业务访问正常进行。
50.根据本技术提供的方案，通过发送请求获取第二功能网元所述网络对应的授权方式的指示信息，来获取第二功能网元所属网络对应的授权方式，再根据第一功能网元和第二功能网元分别对应的授权方式进一步确定最终的授权方式，即nfc访问第二功能网元的授权方式。通过两端nrf之间的协商或sepp之间的协商来确定访问第二功能网元的授权方式。该实现方式时效性较好，因为如果对端网络的授权方式发生变化，通过两端网元之间的协商可以获得最新的授权机制。
51.结合第五方面，在第五方面的某些实现方式中，该第一功能网元包括第一网络存储功能网元或第一安全边缘保护代理网元，该第二功能网元包括第二网络存储功能网元或第二安全边缘保护代理网元。
52.结合第五方面，在第五方面的某些实现方式中，发送通知消息，该通知消息用于指示访问该第一功能网元对应的授权方式，该通知消息包括该第一功能网元所属网络对应的授权方式。
53.示例性的，nrf1网元或sepp1网元向nrf2网元或sepp2网元发送该通知消息，方便后续nfp所在网络内nf网元请求访问第一功能网元所在网络内nf网元对应的授权方式时，nrf2网元或sepp2网元可以直接将第一功能网元对应的授权方式发送给nfp，避免协商流程，既能解决网元间授权冲突问题，还能够减少信令开销。
54.结合第五方面，在第五方面的某些实现方式中，获取该第一功能网元所属网络的标识信息；根据该第一功能网元所属网络的标识信息确定该第一功能网元所属网络对应的授权方式。
55.示例性的，第三请求信息包括第三指示，第三指示用于指示需要返回第二功能网元的授权方式。
56.第六方面，提供了一种通信方法，该方法可以由第二网络存储功能nrf2网元或第二安全边缘保护代理sepp2网元执行，该方法包括：接收请求消息，该请求消息包括获取第二功能网元所属网络对应的授权方式的指示信息；确定该第二功能网元所属网络对应的授权方式；发送该第二功能网元所属网络对应的授权方式。
57.根据本技术提供的方案，通过接收请求获取第二功能网元所述网络对应的授权方式的指示信息，并向nrf1或sepp1发送第二功能网元所属网络对应的授权方式。通过两端nrf之间的协商或sepp之间的协商来确定访问第二功能网元的授权方式。该实现方式时效性较好，因为如果对端网络的授权方式发生变化，通过两端网元之间的协商可以获得最新的授权机制。
58.结合第六方面，在第六方面的某些实现方式中，该第一功能网元包括第一网络存储功能网元或第一安全边缘保护代理网元，该第二功能网元包括第二网络存储功能网元或第二安全边缘保护代理网元。
59.结合第六方面，在第六方面的某些实现方式中，接收通知消息，该通知消息用于指示访问该第一功能网元对应的授权方式，该通知消息包括该第一功能网元所属网络对应的授权方式。
60.示例性的，nrf2网元或sepp2网元接收来自nrf1网元或sepp1网元的通知消息，方便后续nfp请求访问第一功能网元对应的授权方式时，nrf2网元或sepp2网元可以直接将第一功能网元对应的授权方式发送给nfp，避免协商流程，既能解决网元间授权冲突问题，还能够减少信令开销。
61.结合第六方面，在第六方面的某些实现方式中，确定该第二功能网元所属网络对应的授权方式，包括：获取该第二功能网元所属网络的标识信息；根据该第二功能网元所属网络的标识信息确定该第二功能网元所属网络对应的授权方式。
62.第七方面，提供了一种通信方法，该方法可以由服务消费功能nfc网元执行，该方法包括：接收授权指示信息，该授权指示信息用于确定访问服务提供功能网元的授权方式，该授权指示信息为多个指示信息中的一个，该多个指示信息包括第一指示信息和第二指示信息，该第一指示信息用于指示静态授权方式，该第二指示信息用于指示在静态授权方式和开放授权方式中优先使用开放授权方式；根据该授权指示信息确定访问服务提供功能网元的授权方式；根据访问服务提供功能网元的授权方式向该服务提供功能网元请求第二服务。
63.应理解，在静态授权方式和开放授权方式中优先使用开放授权方式，是因为开放授权方式相对来说适用性更好。
64.根据本技术提供的方案，通过接收授权指示信息，进一步确定访问服务提供功能网元的授权方式；根据访问服务提供功能网元的授权方式向该服务提供功能网元请求。通过新定义授权指示信息oauth2required，使得nfc完成授权策略的确定，减少了不必要的协商流程。
65.结合第七方面，在第七方面的某些实现方式中，根据该授权指示信息确定访问服务提供功能网元的授权方式，包括：
66.当该服务消费功能网元所属网络对应的授权方式包括该开放授权方式，或该静态授权方式和该开放授权方式，该授权指示信息为该第二指示信息时，确定访问该服务提供功能网元的授权方式是该开放授权方式，或者根据本地策略确定访问服务提供功能网元的授权方式是否为该开放授权方式；或者
67.当该服务消费功能网元所属网络对应的授权方式包括该静态授权方式，该授权指示信息为该第一指示信息或该第二指示信息时，确定访问该服务提供功能网元的授权方式是该静态授权方式。
68.应理解，本技术实施例中根据本地策略确定访问该第二功能网元的授权方式，可以是基于nfc网元的能力，或者nfc所在网络的授权策略的机制等确定，本技术对此不作限定。
69.在该实现方式中，nfc通过授权指示进一步确定访问服务提供功能网元的授权方式是静态授权方式和/或开放授权方式。并根据确定的授权方式向nfp请求服务。其中，如果最终的授权方式是静态方式，则nfc直接采用静态授权方式向nfp发送服务请求；如最终的授权方式是开放授权方式，nfc则需要先向nrf发送请求获取授权令牌token，再携带该授权令牌token向nfp请求服务，待nfp校验token成功后，为nfc提供相应的服务。
70.结合第七方面，在第七方面的某些实现方式中，该多个指示信息还包括第三指示信息，该第三指示信息用于指示该开放授权方式，根据该授权指示信息确定访问服务提供功能网元的授权方式，包括：
71.当该服务消费功能网元所属网络对应的授权方式包括该开放授权方式，或该静态授权方式和该开放授权方式，该授权指示信息为第三指示信息时，根据该第三指示信息确定访问该服务提供功能网元的授权方式是该开放授权方式；或者
72.当该服务消费功能网元所属网络对应的授权方式为该静态授权方式，并且访问该服务提供功能网元的授权方式为该开放授权方式，发送拒绝消息，或者根据本地策略确定访问服务提供功能网元的授权方式为该静态授权方式。
73.结合第七方面，在第七方面的某些实现方式中，发送通知消息，该通知消息用于指示访问该服务消费功能网元对应的授权方式，该通知消息包括该服务消费功能网元所属网络的标识信息和该服务消费功能网元所属网络对应的授权方式。
74.示例性的，nfc网元向nfp网元发送通知消息，方便后续nfp所在网络内nf网元请求访问服务消费功能nfc所在网络内nf网元时，可以直接将nfc网元对应的授权方式发送给nfp，避免协商流程，既能解决网元间授权冲突问题，还能够减少信令开销。
75.第八方面，提供了一种通信方法，该方法可以由第二服务提供功能(nf service producer，nfp)网元执行，该方法包括：确定访问服务提供功能网元的授权方式的授权指示信息，该授权指示信息为多个指示信息中的一个，该多个指示信息包括第一指示信息和第二指示信息，该第一指示信息用于指示静态授权方式，该第二指示信息用于指示在静态授权方式和开放授权方式中优先使用开放授权方式；发送该授权指示信息。
76.应理解，在静态授权方式和开放授权方式中优先使用开放授权方式，是因为开放授权方式相对来说适用性更好。
77.根据本技术提供的方案，通过新定义的授权指示信息oauth2required，nfp确定并向nfc发送授权指示信息，使得nfc完成访问服务提供功能网元的授权方式的确定，减少了
不必要的协商流程。
78.结合第八方面，在第八方面的某些实现方式中，接收通知消息，该通知消息用于指示访问该服务消费功能网元对应的授权方式，该通知消息包括该服务消费功能网元所属网络的标识信息和该服务消费功能网元所属网络对应的授权方式。
79.示例性的，nfp网元接收来自nfc网元的通知消息，方便后续nfp请求访问服务消费功能nfc网元时，可以直接将nfc网元对应的授权方式发送给nfp，避免协商流程，既能解决网元间授权冲突问题，还能够减少信令开销。
80.结合第一方面至第八方面，在某些实现方式中，该第一授权方式和第二授权方式包括静态授权方式和/或开放授权方式。对应地，该第三授权方式是静态授权方式和/或开放授权方式。这里静态授权方式(static)是基于本地授权策略的机制，开放授权方式(open authorization，oauth)是一种基于令牌等授权参数的开放授权机制，其包括授权中心，业务的使用者，业务的提供者或者资源的拥有者等实体。授权中心会授权是否允许业务使用者使用业务提供者的服务。如果允许的话，则为业务使用者分发令牌。业务使用者发送令牌至业务提供者，当令牌校验成功后，业务提供者则为业务使用者提供服务。在5g网络则定义一个网络存储功能nrf网元进行服务授权的判断，该网络存储功能网元与该服务消费功能网元对应。
81.第九方面，提供了一种网络设备，该方法可以由网络存储功能nrf网元或安全边缘保护代理sepp网元执行，该方法包括：处理单元，用于确定第一授权方式和第二授权方式，该第一授权方式是服务消费功能网元所属网络对应的授权方式，该第二授权方式是服务提供功能网元所属网络对应的授权方式；该处理单元，还用于根据该第一授权方式和该第二授权方式确定第三授权方式，该第三授权方式是访问服务提供功能网元的授权方式；收发单元，用于发送该第三授权方式。
82.具体地，该收发单元可以执行上述第一方面中涉及接收/发送的处理；该处理单元可以执行上述第一方面中除了接收/发送之外的其他处理。
83.第十方面，提供了一种网络设备，该方法可以由服务消费功能nfc网元执行，该方法包括：收发单元，用于接收第三授权方式，该第三授权方式是访问服务提供功能网元的授权方式，该第三授权方式是根据第一授权方式和第二授权方式确定的，该第一授权方式是服务消费功能网元所属网络对应的授权方式，该第二授权方式是该服务提供功能网元所属网络对应的授权方式；处理单元，用于根据该第三授权方式向该服务提供功能网元请求第一服务。
84.具体地，该收发单元可以执行上述第二方面中涉及接收/发送的处理；该处理单元可以执行上述第二方面中除了接收/发送之外的其他处理。
85.第十一方面，提供了一种网络设备，该方法可以由第二网络存储功能nrf2网元或第二安全边缘保护代理sepp2网元执行，该方法包括：收发单元，用于接收请求消息，该请求消息用于请求获取访问第二功能网元的授权方式，该请求消息包括第一功能网元所属网络对应的授权方式；处理单元，用于确定该第二功能网元所属网络对应的授权方式；该处理单元，还用于根据该第一功能网元所属网络对应的授权方式和该第二功能网元所属网络对应的授权方式确定访问该第二功能网元的授权方式；该收发单元，还用于发送访问该第二功能网元的授权方式。
86.具体地，该收发单元可以执行上述第三方面中涉及接收/发送的处理；该处理单元可以执行上述第三方面中除了接收/发送之外的其他处理。
87.第十二方面，提供了一种网络设备，该方法可以由第一网络存储功能nrf1网元或第一安全边缘保护代理sepp1网元执行，该方法包括：处理单元，用于确定第一功能网元所属网络对应的授权方式；收发单元，用于发送请求消息，该请求消息用于请求获取访问第二功能网元的授权方式，该请求消息包括该第一功能网元所属网络对应的授权方式；该收发单元，还用于接收访问第二功能网元的授权方式，访问第二功能网元的授权方式是根据该第一功能网元所属网络对应的授权方式和该第二功能网元所属网络对应的授权方式确定的；该收发单元，还用于发送访问第二功能网元的授权方式。
88.具体地，该收发单元可以执行上述第四方面中涉及接收/发送的处理；该处理单元可以执行上述第四方面中除了接收/发送之外的其他处理。
89.第十三方面，提供了一种网络设备，该方法可以由第一网络存储功能nrf1网元或第一安全边缘保护代理sepp1网元执行，该方法包括：收发单元，用于发送请求消息，该请求消息包括获取第二功能网元所属网络对应的授权方式的指示信息；该收发单元，还用于接收该第二功能网元所属网络对应的授权方式；处理单元，用于根据该第二功能网元所属网络对应的授权方式和第一功能网元所属网络对应的授权方式确定访问该第二功能网元的授权方式；该收发单元，还用于发送访问该第二功能网元的授权方式。
90.具体地，该收发单元可以执行上述第五方面中涉及接收/发送的处理；该处理单元可以执行上述第五方面中除了接收/发送之外的其他处理。
91.第十四方面，提供了一种网络设备，该方法可以由第二网络存储功能nrf2网元或第二安全边缘保护代理sepp2网元执行，该方法包括：接收请求消息，该请求消息包括获取第二功能网元所属网络对应的授权方式的指示信息；确定该第二功能网元所属网络对应的授权方式；发送该第二功能网元所属网络对应的授权方式。
92.具体地，该收发单元可以执行上述第六方面中涉及接收/发送的处理；该处理单元可以执行上述第六方面中除了接收/发送之外的其他处理。
93.第十五方面，提供了一种网络设备，该方法可以由服务消费功能nfc网元执行，该方法包括：收发单元，用于接收授权指示信息，该授权指示信息用于确定访问服务提供功能网元的授权方式，该授权指示信息为多个指示信息中的一个，该多个指示信息包括第一指示信息和第二指示信息，该第一指示信息用于指示静态授权方式，该第二指示信息用于指示在静态授权方式和开放授权方式中优先使用开放授权方式；处理单元，用于根据该授权指示信息确定访问服务提供功能网元的授权方式；该处理单元，还用于根据访问服务提供功能网元的授权方式向该服务提供功能网元请求第二服务。
94.具体地，该收发单元可以执行上述第七方面中涉及接收/发送的处理；该处理单元可以执行上述第七方面中除了接收/发送之外的其他处理。
95.第十六方面，提供了一种网络设备，该方法可以由第二服务提供功能(nf service producer，nfp)网元执行，该方法包括：处理单元，用于确定访问服务提供功能网元的授权方式的授权指示信息，该授权指示信息为多个指示信息中的一个，该多个指示信息包括第一指示信息和第二指示信息，该第一指示信息用于指示静态授权方式，该第二指示信息用于指示在静态授权方式和开放授权方式中优先使用开放授权方式；收发单元，用于发送该
授权指示信息。
96.具体地，该收发单元可以执行上述第八方面中涉及接收/发送的处理；该处理单元可以执行上述第八方面中除了接收/发送之外的其他处理。
97.第十七方面，提供了一种网络设备，包括：处理器，可选地，还包括存储器，该处理器用于控制收发器收发信号，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得该网络设备执行上述第一方面或第一方面中任一种可能实现方式中的方法，或者第二方面或第二方面中任一种可能实现方式中的方法，或者第三方面或第三方面中任一种可能实现方式中的方法，或者第四方面或第四方面中任一种可能实现方式中的方法，或者第五方面或第五方面中任一种可能实现方式中的方法，或者第六方面或第六方面中任一种可能实现方式中的方法，或者第七方面或第七方面中任一种可能实现方式中的方法，或者第八方面或第八方面中任一种可能实现方式中的方法。
98.可选地，该处理器为一个或多个，该存储器为一个或多个。
99.可选地，该存储器可以与该处理器集成在一起，或者该存储器与处理器分离设置。
100.可选地，该终端设备还包括收发器，收发器具体可以为发射机(发射器)和接收机(接收器)。
101.第十八方面，提供了一种通信装置，包括：用于实现第一方面或第一方面任一种可能实现方式中的方法的单元；或者用于实现第二方面或第二方面任一种可能实现方式中的方法；或者用于实现第三方面或第三方面任一种可能实现方式中的方法，或者第四方面或第四方面中任一种可能实现方式中的方法，或者第五方面或第五方面中任一种可能实现方式中的方法，或者第六方面或第六方面中任一种可能实现方式中的方法，或者第七方面或第七方面中任一种可能实现方式中的方法，或者第八方面或第八方面中任一种可能实现方式中的方法。
102.第十九方面，提供了一种通信系统，包括：网络设备，用于执行如上述第一方面或第一方面任一种可能实现方式中的方法；或者第二方面或第二方面任一种可能实现方式中的方法；或者第三方面或第三方面任一种可能实现方式中的方法，或者第四方面或第四方面中任一种可能实现方式中的方法，或者第五方面或第五方面中任一种可能实现方式中的方法，或者第六方面或第六方面中任一种可能实现方式中的方法，或者第七方面或第七方面中任一种可能实现方式中的方法，或者第八方面或第八方面中任一种可能实现方式中的方法。
103.第二十方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序或代码，所述计算机程序或代码在计算机上运行时，使得所述计算机执行上述第一方面或第一方面任一种可能实现方式中的方法，第二方面或第二方面任一种可能实现方式中的方法，第三方面或第三方面任一种可能实现方式中的方法，第四方面或第四方面中任一种可能实现方式中的方法，第五方面或第五方面中任一种可能实现方式中的方法，第六方面或第六方面中任一种可能实现方式中的方法，第七方面或第七方面中任一种可能实现方式中的方法，以及第八方面或第八方面中任一种可能实现方式中的方法。
104.第二十一方面，提供了一种芯片，包括至少一个处理器，所述至少一个处理器与存储器耦合，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得安装有该芯片系统的网络设备执行上述第一方面或第一方面任一种可能实现方
式中的方法，第二方面或第二方面任一种可能实现方式中的方法，以及第三方面或第三方面任一种可能实现方式中的方法。
105.其中，该芯片可以包括用于发送信息或数据的输入电路或者接口，以及用于接收信息或数据的输出电路或者接口。
106.第二十二方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码被网络设备运行时，使得所述网络设备执行上述第一方面或第一方面任一种可能实现方式中的方法，第二方面或第二方面任一种可能实现方式中的方法，第三方面或第三方面任一种可能实现方式中的方法，第四方面或第四方面中任一种可能实现方式中的方法，第五方面或第五方面中任一种可能实现方式中的方法，第六方面或第六方面中任一种可能实现方式中的方法，第七方面或第七方面中任一种可能实现方式中的方法，以及第八方面或第八方面中任一种可能实现方式中的方法。
107.根据本技术实施例的方案，通过配置对端授权方式，或者增加nfc和nfp之间的网络存储功能网元的协商或安全边缘保护代理网元的协商，或者扩展nfp中的指示信息来减少不必要的协商流程，进而确定nfc访问nfp最终的授权方式。该方法能够完成不同网络功能网元之间授权机制的协商，使得服务消费功能网元获得业务访问的授权方式，进而解决授权冲突的问题，保证业务访问的正常进行。
附图说明
108.图1是本技术的通信系统的一例的示意图。
109.图2是本技术的获取授权令牌的方法的一例示意图。
110.图3是本技术的授权协商场景的一例示意图。
111.图4是本技术的请求获取服务提供功能网元的信息的一例示意图。
112.图5是本技术的通信方法的一例示意图。
113.图6是本技术的网元间授权机制协商方法的一例示意图。
114.图7是本技术的网元间授权机制协商方法的另一例示意图。
115.图8是本技术的网元间授权机制协商方法的又一例示意图。
116.图9是本技术的网元间授权机制协商方法的又一例示意图。
117.图10是本技术的网元间授权机制协商方法的又一例示意图。
118.图11是本技术的通信装置的一例示意图。
119.图12是本技术的通信装置的另一例示意图。
120.图13是本技术的通信装置的又一例示意图。
121.图14是本技术的网络设备的一例示意图。
122.图15是本技术的网络设备的另一例示意图。
123.图16是本技术的网络设备的又一例示意图。
具体实施方式
124.下面将结合附图，对本技术中的技术方案进行描述。
125.本技术实施例的技术方案可以应用于各种通信系统，例如：通用分组无线业务(general packet radio service，gprs)、长期演进(long term evolution，lte)系统、lte
频分双工(frequency division duplex，fdd)系统、lte时分双工(time division duplex，tdd)、通用移动通信系统(universal mobile telecommunication system，umts)、全球互联微波接入(worldwide interoperability for microwave access，wimax)通信系统、第五代(5th generation，5g)系统或新无线(new radio，nr)，也可以扩展到类似的无线通信系统中，如无线保真(wireless-fidelity，wifi)，以及第三代合作伙伴计划(3rd generation partnership project，3gpp)相关的蜂窝系统等。
126.通常来说，传统的通信系统支持的连接数有限，也易于实现。然而，随着通信技术的发展，移动通信系统将不仅支持传统的通信，还将支持例如，设备到设备(device to device，d2d)通信，机器到机器(machine to machine，m2m)通信，机器类型通信(machine type communication，mtc)，车联网(vehicle to everything，v2x)通信，例如，车到车(vehicle to vehicle，v2v)通信、车到基础设施(vehicle to infrastructure，v2i)通信、车到行人(vehicle to pedestrian，v2p)通信、车到网络(vehicle to network，v2n)通信等，车间通信长期演进技术(long term evolution-vehicle，lte-v)、车联网、物联网(internet of things，iot)、机器间通信长期演进技术(long term evolution-machine，lte-m)等。
127.本技术提供的技术方案还可以应用于未来的通信系统，如第六代移动通信系统等。本技术对此不作限定。
128.在本技术实施例中，网络设备可以是一种部署在无线接入网中为终端设备提供无线通信功能的装置，可以是用于与终端设备通信的设备或者该设备的芯片。该网络设备包括但不限于：无线网络控制器(radio network controller，rnc)、控制器(base station controller，bsc)、家庭(例如，home evolved nodeb，或home node b，hnb)、基带单元(baseband unit，bbu)，无线保真系统中的接入点(access point，ap)、无线中继节点、无线回传节点、传输点(transmission point，tp)或者发送接收点(transmission and reception point，trp)等，还可以为5g(如nr)系统中的gnb或传输点(trp或tp)，或者5g系统中的的一个或一组(包括多个天线面板)天线面板，或者还可以为构成gnb或传输点的网络节点，如基带单元bbu，或分布式单元(distributed unit，du)等。
129.本技术实施例中的网络设备可以包括各种形式的宏，微(也称为小站)，中继站，接入点等，还可以是lte系统中的演进型(evolutional nodeb，enb或enodeb)，还可以是云无线接入网络(cloud radio access network，cran)场景下的无线控制器，或者该网络设备可以为中继站、接入点、可穿戴设备或车载设备、可穿戴设备以及5g或未来网络中的网络设备或者未来演进的公用陆地移动通信网络plmn网络中的网络设备等。
130.在一些网络部署中，网络设备可以包括集中式单元(centralized unit，cu)和分布式单元(distributed unit，du)。网络设备还可以包括射频单元(radio unit，ru)、有源天线单元(active antenna unit，aau)。cu实现网络设备的部分功能，比如负责处理非实时协议和服务，实现无线资源控制(radio resource control，rrc)，分组数据汇聚层协议(packet data convergence protocol，pdcp)层的功能。du实现网络设备的部分功能，比如负责处理物理层协议和实时服务，实现无线链路控制(radio link control，rlc)层、媒体接入控制(media access control，mac)层和物理(physical，phy)层的功能。aau实现部分物理层处理功能、射频处理及有源天线的相关功能。由于rrc层的信息最终会变成phy层的
信息，或者，由phy层的信息转变而来。因而在这种架构下，高层信令(例如，rrc层信令)也可以认为是由du发送的，或者由du+aau发送的。可以理解的是，网络设备可以为cu节点、或du节点、或包括cu节点和du节点的设备。此外，cu可以划分为接入网ran中的网络设备，也可以将cu划分为核心网(core network，cn)中的网络设备，在此不做限制。
131.网络设备为小区提供服务，终端设备通过网络设备分配的传输资源(例如，频域资源，或者频谱资源)与小区进行通信，该小区可以属于宏(例如，宏enb或宏gnb等)，也可以属于小小区(small cell)对应的，这里的小小区可以包括：城市小区(metro cell)、微小区(micro cell)、微微小区(pico cell)、毫微微小区(femto cell)等，这些小小区具有覆盖范围小、发射功率低的特点，适用于提供高速率的数据传输服务。
132.图1是应用于本技术实施例的网络架构100的一例示意图，如图1所示，虚线右侧表示本地共用陆地网络(home public land mobile network，hplmn)，虚线左侧表示拜访公用陆地移动网(visited public land mobile network，vplmn)。下面对该网络架构中可能涉及的部分网元分别进行说明。
133.(无线)接入网络(radio access network，(r)an)网元120：包含ran设备和an设备，主要用于为特定区域的授权终端设备提供入网功能，并能够根据终端设备的级别，业务的需求等使用不同质量的传输隧道。ran设备主要是3gpp网络无线网络设备，an可以是non-3gpp定义的接入网设备。
134.用户面网元130：主要提供用户平面的业务处理功能，用于终端设备中用户数据的转发和接收，即数据包分组路由和转发，锚定功能、服务质量qos映射和执行、上行链路的标识识别并路由到数据网络、下行包缓存和下行链路数据到达的通知触发、与外部数据网络连接等，可以从数据网络接收用户数据，通过接入网设备传输给终端设备，还可以通过接入网设备从终端设备接收用户数据，转发到数据网络。
135.用户面功能(user plane function，upf)网元中为终端设备提供服务的传输资源和调度功能可以由会话管理功能(session management function，smf)网元管理控制。在5g通信系统中，该用户面网元可以是用户面功能upf网元。在未来通信系统中，用户面网元仍可以是upf网元，或者，还可以有其它的名称，本技术不做限定。
136.网络存储网元180：用于维护网络中所有网络功能服务的实时信息，负责网元的控制，以及执行网络功能(network function，nf)网元的注册，发现和授权功能。
137.在5g通信系统中，该网络存储网元可以是网络存储功能(network repository function，nrf)网元。在未来通信系统中，网络存储网元仍可以是nrf网元，或者，还可以有其它的名称，本技术不做限定。
138.在本技术中，功能网元可以分为服务消费功能网元(nf service consumer，nfc)和服务提供功能网元(nf service producer，nfp)。nfc是业务消费者nf，nfp是业务提供者nf。nfc从nfp获得nfp提供的服务。在其他场景中，该功能网元也可以为终端、、网元、控制器或服务器等实体，本技术不做限定。为描述方便，后续以nf为例进行描述。
139.需要说明的是，上述“网元”也可以称为实体、设备、装置或模块等，本技术并未特别限定。并且，在本技术中，为了便于理解和说明，在对部分描述中省略“网元”这一描述，例如，将smf网元简称smf，此情况下，该“smf”应理解为smf网元或smf实体，以下，省略对相同或相似情况的说明。
140.可以理解的是，上述网元或者功能既可以是硬件设备中的网络元件，也可以是在专用硬件上运行软件功能，或者是平台(例如，云平台)上实例化的虚拟化功能。
141.应理解，以上列举的通信系统包括的网元仅仅为示例性说明，本技术并未限定于此，例如，还可以包括但不限于：
142.网络切片选择功能网元：用于为用户设备选择一组网络切片实例、确定允许的网络切片选择辅助信息(network slice selection assistance information，nssai)和确定可以服务用户设备的amf集，可以是切片选择功能网元(network slice selection function，nssf)；
143.绑定支持功能网元：用于查会话所关联的策略控制功能网元pcf；
144.安全边缘保护代理(security edge protection proxy，sepp)网元：两个运营商之间漫游的安全功能网元，分为csepp和psepp。其中，消费安全边缘保护代理(consumer of sepp，csepp)网元为nfc侧对应的sepp，服务安全边缘保护代理(producer of sepp，psepp)网元为nfp侧对应的sepp。主要执行漫游数据的封装，保护，校验等操作。
145.网络数据分析功能(network data analytics funtion，nwda)网元：用于收集与存储来自于终端设备，r元，以及其他网络实体(例如，amf网元)的信息，并对这些信息进行分析，以及生成关于用户的上下文信息(可以认为是应用层的信息)，并对此应用层的信息进行分发等。
146.在图1所示的网络架构中，n2接口为r元20和amf网元160的参考点，用于非接入层(non-access stratum，nas)消息的发送等；n3接口为r元120和upf网元130之间的参考点，用于传输用户面的数据等；n4接口为smf网元170和upf网元130之间的参考点，用于传输例如n3连接的隧道标识信息，数据缓存指示信息，以及下行数据通知消息等信息；n6接口为upf网元130和dn网元140之间的参考点，用于传输用户面的数据；n9接口为upf网元130和另一个upf网元之间的参考点；n32接口为v-安全边缘保护代理(v-security edge protection proxy，vsepp)网元和h-安全边缘保护代理(h-security edge protection proxy，hsepp)网元之间的参考点，用于vsepp和hsepp通信等。
147.需要说明的是，基于服务化架构(service based architecture，sba)的范围限于核心网的控制面网元，不包括用户面功能upf网元。而且，upf支持的接口n3，n9，n6，n4都不是服务化接口。从上述架构图中可见，与upf可以连接的网元设备有smf，ran，dn和另一个upf。
148.应理解，上述应用于本技术实施例的网络架构仅是举例说明的从服务化架构的角度描述的网络架构，适用本技术实施例的网络架构并不局限于此，任何能够实现上述各个网元的功能的网络架构都适用于本技术实施例。
149.例如，在某些网络架构中，amf、smf、pcf、gmf以及udm等网络功能实体都称为网络功能nf网元；或者，在另一些网络架构中，amf、smf、pcf、gmf及udm等网元的集合都可以称为控制面功能(control plane function，cpf)网元。
150.为方便说明，本技术以装置nf、nrf、sepp为例，对用于建立会话的方法进行说明。本技术后续所描述的nf均可替换为网络功能网元网，nrf均可替换为网络存储网元、sepp均可替换为漫游安全网元。对于装置为nf体内的芯片、nrf内的芯片或为sepp实体内的芯片的实现方法，可参考装置分别为nf实体、nrf实体、sepp实体的具体说明，不再重复介绍。本申
请对nf适用的网元不做限制，例如ran，upf，amf等所有功能网元设备都适用。
151.本技术实施例并未对本技术实施例提供的方法的执行主体的具体结构特别限定，只要能够通过运行记录有本技术实施例的提供的方法的代码的程序，以根据本技术实施例提供的方法进行通信即可。例如，本技术实施例提供的方法的执行主体可以是网络设备，或者是网络设备中能够调用程序并执行程序的功能模块；或者是可用于网络设备的部件(例如芯片或者电路)。
152.另外，本技术的各个方面或特征可以实现成方法、装置或使用标准编程和/或工程技术的制品。本技术中使用的术语“制品”涵盖可从任何计算机可读器件、载体或介质访问的计算机程序。例如，计算机可读介质可以包括，但不限于：磁存储器件(例如，硬盘、软盘或磁带等)，光盘(例如，压缩盘(compact disc，cd)、数字通用盘(digital versatile disc，dvd)等)，智能卡和闪存器件(例如，可擦写可编程只读存储器(erasable programmable read-only memory，eprom)、卡、棒或钥匙驱动器等)。另外，本文描述的各种存储介质可代表用于存储信息的一个或多个设备和/或其它机器可读介质。术语“机器可读介质”可包括但不限于，无线信道和能够存储、包含和/或承载指令和/或数据的各种其它介质。
153.当前5g网络中，服务化架构借鉴it系统服务化/微服务化架构的成功经验，通过模块化实现网络功能间的解耦和整合，每个5g的功能网元都是一个独立的功能。控制面所有nf之间的交互采用服务化接口，同一种服务可以被多种nf调用。针对服务化架构，标准定义了两种nf之间相互访问的授权方式，一种为静态授权方式，一种为oauth授权方式。
154.具体地，静态授权方式(static)是一种基于本地授权策略的机制。例如，amf访问smf场景，smf根据amf发送的业务请求内的参数和本地策略，判断是否允许amf访问自己的服务。若根据本地授权策略判断允许amf访问自己的服务，则为amf提供服务。这里本地策略可以为是否允许amf类型网络访问自己的服务，本技术对本地策略的举例不做限定。
155.oauth授权方式是指，一种基于令牌等授权参数的开放授权机制，其包括授权中心，业务的使用者，业务的提供者或者资源的拥有者等实体。授权中心会授权是否允许业务使用者使用业务提供者的服务。如果允许的话，则为业务使用者分发令牌。业务使用者发送令牌至业务提供者，当令牌校验成功后，业务提供者则为业务使用者提供服务。在5g网络则定义一个nrf网元，其负责服务授权的判断。例如，服务消费功能网元(nf service consumer，nfc)在访问服务提供功能网元(nf service producer，nfp)之前，会先向nrf发送请求消息，nrf判断允许nfc访问nfp之后，会生成一个授权令牌token，并向nfc发送token。然后，nfc在访问nfp服务时，发送服务请求，其中携带token。nfp在校验token成功后，会为nfc提供对应的服务。图2示出了实用本技术的nfc获取token的方法200，如图2所示，具体实现步骤包括：
156.s210，可选地，服务消费功能网元nfc(用nf1描述)在网络存储功能网元nrf完成注册；
157.s220，该nfc向nrf(用nf2描述)发送请求消息；对应的，nrf接收来自nfc的请求消息。
158.其中，该请求消息用于请求获取循序访问nfp的授权令牌token。该请求消息包括：nf1实例id(例如，nf instance id(s)of the nf service consumer)、nf2的nf类型、nf1期望的业务(例如，expected nf service name(s))、以及该nfc期望的nfp的nf类型。
159.s230，nrf根据本地策略，确定是否授权nf1获取token的请求。
160.示例性的，nrf计算token，并基于数字签名或者消息验证码的方式完整性保护该token。其中，token包括声明(claim)，该claim包括：nrf的nf实例id，nf1实例id，nf2的nf类型，期望的业务名称和有效期等。
161.s240，nrf向nfc发送授权响应消息；对应的，nfc接收来自nrf的授权响应消息。
162.其中，该响应消息用于指示同意授权该nfc访问nfp，该响应消息包括授权令牌token。
163.应理解，基于该授权令牌token，nfc可以向nfp请求访问服务，发送服务请求。相应的，nfp在成功校验token后为nfc提供服务。
164.应理解，以上列举的获取授权令牌token的过程仅为示例性说明，本技术并未限定于此，其他能够实现获取授权令牌的方法及过程均落入本技术的保护范围内。
165.需要说明的是，当oauth授权方式没有被采纳的时候，两个网元之间就使用静态授权方式进行交互。特别是在漫游场景下，若nfc和nfp属于不同的运营商，由于授权机制的不同，也会使得nfp拒绝nfc的业务请求，从而发生业务的中断。例如nfc支持静态授权，而nfp支持oauth授权，那么就会出现授权冲突问题。
166.图3示出了nfc和nfp基于不同授权方式进行协商的4种场景，如图3所示，场景1中nfc和nfp均只支持静态授权方式(static)，二者可以直接通过静态授权方式进行访问与服务；场景2中nfc仅支持静态授权方式(static)，nfp同时支持静态授权方式(static)和oauth授权方式，当nfc向nfp提出访问请求时，nfp可以基于静态授权方式为nfc提供相应的服务；场景3中nfc同时支持静态授权方式(static)和oauth授权方式，nfp仅支持静态授权方式(static)，那么二者之间只能基于静态授权方式(static)进行访问与服务，nfc需要进一步确定是否采用oauth授权方式，如果该nfc直接发起token授权请求，nfp会拒绝nfc对应的访问请求；场景4中nfc和nfp均同时支持静态授权方式(static)和oauth授权方式，但是nfc需要进一步确定是否采用oauth授权方式，如果该nfc直接使用静态授权方式(static)发起访问请求，那么作为更强授权控制能力的token或者oauth授权方式将可能永远不会被采纳。因此，上述场景3和场景4中都存在nfc和nfp授权机制不一致的问题，容易发生nf间的授权冲突。另外，若nfp仅支持oauth授权方式，而nfc支持静态授权和oauth授权方式，当nfc直接发起静态授权，也将会被nfp拒绝。nfc和nfp之间发生冲突的场景较多，此处就不再赘述。
167.另外，图4示出了适用于本技术的nfc发现流程400的一例示意图，如图4所示，具体实现步骤包括：
168.s410，服务消费功能网元nfc向网络存储功能nrf网元发送发现服务请求消息；对应的，nrf接收来自nfc的发现服务请求消息。
169.其中，该服务请求可以为nnrf_nfdiscovery_request。该发现请求消息用来请求获得能够为nfc提供服务的nfp的信息。
170.示例性的，nfc可以向nrf发送与smf相关的发现请求消息，用于nfc向smf访问业务。
171.s420，nrf授权同意该发现服务请求消息。
172.可选地，nrf根据本地网络策略确定同意授权nfc向smf访问业务。
173.s430，nrf向nfc发送发现请求响应消息；对应的，nfc接收来自nrf的发现请求响应消息。
174.需要说明的是，当前协议定义，在nf发现流程中，nrf会将nfp(例如，smf)的nfprofile中的信息发送给nfc。可选地，如果该nfprofile的nf service中包括oauth2required，那么接入nf produce的nfc需要执行oauth机制。而如果nfc仅支持static，则出现业务中断。因此标准的定义在具体实现中也存在不合理，容易出现漫游时，或者不同域间nf不能互通的问题，例如域1内nfp要求oauth机制，域2内nfc仅支持static授权。这里域可以为scp域，nrf域，nf set域，安全域等不同的概念。综上所述，两个nf之间如何进行授权方式的协商是亟待解决的问题，即两个nf之间的业务访问与服务是使用oauth授权方式还是静态授权方式。另外，当前协议也存在不合理，容易出现漫游时或者域间nf不能互通的问题。基于此，本技术提供了一种通信方法，根据是否考虑oauth2required指示信息入手，利用nrf或sepp配置对端授权方式，进而确定最终授权方式，使得nfc确定采用静态授权方式或oauth授权方式进行访问。该方法能够解决网元(例如，nfc和nfp)之间授权机制不一致的问题，避免nf间授权冲突。
175.下面结合附图对本技术实施例中通信方法进行详细说明。
176.图5是适用本技术实施例的授权机制协商方法的一例示意图，具体实现步骤500包括：
177.s510，网络存储功能nrf网元或安全边缘保护代理sepp网元确定第一授权方式和第二授权方式。
178.其中，第一授权方式是服务消费功能网元所属网络对应的授权方式，第二授权方式是服务提供功能网元所属网络对应的授权方式。
179.根据本技术提供的方案，通过确定第一授权方式和第二授权方式，根据第一授权方式和第二授权方式确定第三授权方式，并向服务消费功能网元发送该第三授权方式。采用协商的方式进行确定访问服务提供功能网元的授权方式，进而解决授权冲突的问题，保证不同网络功能网元之间的业务访问正常进行。
180.一种可能的实现方式，确定第二授权方式包括：nrf或sepp接收来自nfc的第一请求消息，该第一请求消息包括该服务提供功能网元所属网络的标识信息；根据该服务提供功能网元所属网络的标识信息确定该第二授权方式。
181.可选地，nfc向服务通信代理(service communication proxy，scp)网元发送第一请求消息。
182.应理解，当前5g架构包括scp网元。scp是nf网元的代理，也可以理解scp为一个scp域的出入口，或者代理节点。因此不同域之间的协商，也可以通过scp来完成，例如nfc-scp1-scp2-nfp。所以上述通过sepp直接协商的方式，也可以使用scp的方式。对应的，可以将scp替换为上述sepp，plmn id替换为scp域标识。
183.示例性的，确定第二授权方式可以是网络存储功能nrf网元或安全边缘保护代理sepp网元配置该第二授权方式。通过配置对端授权方式，例如服务提供功能(nf service producer，nfp)网元所属网络公共陆地移动网标识(public land mobile network identity，plmn id2)对应的授权方式，使得nrf或sepp在接收到nfc请求访问对端nfp网元的授权方式时，本端nrf或sepp可以直接根据nfc网元所属网络plmn id1对应的授权方式和
对端nfp所属网络plmn id2对应的授权方式确定最终访问nfp的授权方式，减少nfc和nfp之间授权冲突。
184.应理解，本技术实施例中，第一请求消息包括发现请求消息和/或授权请求消息。
185.另一种可能的实现方式，确定第一授权方式包括：获取该服务消费功能网元所属网络的标识信息；根据该服务消费功能网元所属网络的标识信息确定该第一授权方式。
186.进一步地，获取服务消费功能网元所属网络的标识信息，包括：接收服务消费功能网元所属网络的标识信息，或者根据第一网络存储功能网元和第一安全边缘保护代理网元之间的连接确定所述服务消费功能网元所属网络的标识信息。
187.示例性的，从服务消费功能网元nfc接收服务消费功能网元所属网络的标识信息。
188.s520，nrf或sepp根据第一授权方式和第二授权方式确定第三授权方式。
189.其中，第三授权方式是访问服务提供功能网元的授权方式。
190.需要说明的是，本技术实施例中，第一授权方式和第二授权方式包括静态授权方式(static)和/或开放授权方式(oauth)。对应地，该第三授权方式是静态授权方式和/或开放授权方式。这里静态授权方式(static)是基于本地授权策略的机制，开放授权方式(oauth)是需要网络存储功能nrf网元进行服务授权的判断，该网络存储功能网元与该服务消费功能网元对应。
191.示例性的，静态授权方式(static)是一种基于本地授权策略的机制。oauth授权方式是指，一种基于令牌等授权参数的开放授权机制，其包括授权中心，业务的使用者，业务的提供者或者资源的拥有者等实体。授权中心会授权是否允许业务使用者使用业务提供者的服务。如果允许的话，则为业务使用者分发令牌。业务使用者发送令牌至业务提供者，当令牌校验成功后，业务提供者则为业务使用者提供服务。在5g网络则定义一个nrf网元，其负责服务授权的判断。
192.示例性的，该第三授权方式为开放授权方式，该方法还包括：接收第二请求消息，该第二请求消息用于请求获取第一令牌，该第一令牌用于授权该服务消费功能网元访问该第一服务；确定该第一令牌；发送该第一令牌。
193.示例性的，nrf网元负责服务授权的判断，例如服务消费功能nfc网元在访问服务提供功能nfp网元之前，会先向nrf发送请求消息，nrf判断允许nfc访问nfp之后，会生成一个授权令牌token，并发送token给nfc。使得nfc在访问nfp服务携带token。待nfp在校验token成功后，会为nfc提供对应的服务。
194.示例性的，第一请求信息和第二请求消息均还包括以下信息中的一个或多个：服务消费功能网元所属网络的标识信息、服务提供功能网元的业务类型、服务消费功能网元的业务类型。
195.示例性的，根据该第一授权方式和该第二授权方式确定第三授权方式，包括：根据该第一授权方式和该第二授权方式的共有授权方式确定该第三授权方式；当该共有授权方式为该静态授权方式或该开放授权方式，确定该静态授权方式或该开放授权方式为该第三授权方式；当该共有授权方式为该静态授权方式和该开放授权方式，根据本地策略确定该第三授权方式，或者确定该开放授权方式为该第三授权方式。
196.通过选取第一授权方式和第二授权方式的交集进一步确定最终nfc访问nfp服务使用的授权方式，避免由于授权冲突的问题，导致发生业务的中断。
197.示例性的，当第一授权方式和第二授权方式的共有授权方式同时支持静态授权方式和开放授权方式时，可以确定开放授权方式为最终nfc访问nfp服务所使用的授权方式；也可以根据本地策略进一步确定该第三授权方式，例如，根据nfc网元的能力，或者nfc所在网络的授权策略的机制等，本技术对此不作限定。
198.一种可能的实现方式，nrf或sepp根据nfp所属网络(例如，plmn id2)直接确定第三授权，无需根据第一授权方式和第二授权方式的共有方式，进一步确定访问nfp服务的授权方式，并向nfc发送该第三授权方式。
199.s530，nrf或sepp向服务消费功能nfc网元发送第三授权方式；对应的，nfc接收来自nrf或sepp的第三授权方式。
200.作为示例而非限定，nrf或sepp向对端网络存储功能网元nrf2或安全边缘保护代理网元sepp2发送通知消息，该通知消息用于指示访问该nfc网元对应的授权方式，该通知消息包括该nfc网元所属网络plmn id1对应的授权方式。该实现方式为了方便后续nfp所在网络内nf网元请求访问nfc所在网络内nf网元时，nrf2网元或sepp2网元可以直接将nfc网元对应的授权方式发送给nfp，避免协商流程，既能解决网元间授权冲突问题，还能够减少信令开销。
201.s540，nfc根据第三授权方式向服务提供功能网元请求第一服务。
202.一种可能的实现方式，根据该第三授权方式向该服务提供功能网元请求第一服务，包括：当第三授权方式为开放授权方式，向nrf发送第二请求消息，该第二请求消息用于请求获取第一令牌，该第一令牌用于授权该服务消费功能网元访问该第一服务；接收该第一令牌；向该服务提供功能网元发送用于请求该第一服务的消息，该用于请求该第一服务的消息中包括该第一令牌。
203.示例性的，nrf网元负责服务授权的判断，例如服务消费功能nfc网元在访问服务提供功能nfp网元之前，会先向nrf发送请求消息，nrf判断允许nfc访问nfp之后，会生成一个授权令牌token，并发送token给nfc。使得nfc在访问nfp服务携带token。待nfp在校验token成功后，会为nfc提供对应的服务。
204.另一种可能的实现方式，当第三授权方式为静态授权方式，nfc直接使用该静态授权方式向nfp请求服务。例如发送业务请求至nfp，nfp根据静态授权方式(例如本地策略)判断是否授权nfc使用其请求的服务。
205.图6是适用本技术实施例的授权机制协商方法的一例示意图，通过网络存储功能网元配置对端网络授权方式，并确定最终的授权方式，使得服务消费功能网元获得业务访问的授权方式。如图6所示，包括服务消费功能网元nfc、网络存储功能网元nrf#1和网络存储功能网元nrf#2，具体实现步骤600包括：
206.s610，网络存储功能网元(例如，nrf#1)配置对端(例如，plmn id2)对应的授权方式。
207.示例性的，nrf#1属于域1，nrf#2属于域2，域1和域2有不同的标识，可以为plmn id、scp域标识、nrf域标识等。不同域之间的协商可以通过plmn id、scp域、nrf域、nf set域、安全域等来完成。可选地，nrf#1属于运营商1，nrf#2属于运营商2。一般地，不同运营商的网络功能网元之间的授权方式不同，同一运营商中网络功能网元之间的授权机制相同。可选地，nrf#1和nrf#2可以属于同一个运营商，此时nrf#1对应的业务类型的授权方式与
nrf#2对应的业务类型的授权方式不同。
208.需要说明的是，本技术中nrf#1和nrf#2均配置各自plmn id对应的授权方式。即nrf#1配置plmn id1对应的授权方式，nrf#2配置plmn id2对应的授权方式。
209.示例性的，nrf#1配置有对端plmnd id2对应的的授权方式，或者nrf#1向其他网元(例如，控制网元和/或管理网元)发送请求消息，该请求消息包括对端plmn id2，用于请求该plmn id2对应的授权方式，其他网元根据plmn id2确定plmn id2对应的授权方式，并发送给nrf#1。
210.其中，具体的plmn id对应的授权方式包括：静态授权方式(static)，和/或oauth授权方式。
211.一种可能的实现方式：
212.s620，服务消费功能网元(例如，nfc)向nrf#1发送发现请求消息；对应的，nrf#1接收来自nfc的发现请求消息。
213.其中，该发现请求消息包括plmn id2，该发现请求消息用于请求确定访问plmn id2对应网络的nfp的信息。
214.可选地，该发现请求消息还包括plmn id1、nfc对应的其他参数和期望访问的nfp对应的其他参数。
215.需要说明的是，plmn id1为nfc所在网络的标识信息，plmn id2为nfc希望进行业务访问的服务提供功能nfp网元对应网络的标识信息。示例性的，该nfp可以为会话管理功能smf网元，或者策略控制功能pcf网元等。
216.s630，nrf#1向nrf#2发送该发现请求消息；对应的，nrf#2接收来自nrf#1的发现请求消息。
217.其中，该发现请求消息用于请求确定访问plmn id2对应网络的nfp的信息。
218.示例性地，该发现请求消息可以包括以下参数中的一个或多个：plmn id1、plmn id2、nfc对应的其他参数和期望访问的nfp对应的其他参数。
219.可选地，该发现请求消息可以不包括plmn id1、nfc对应的其他参数和期望访问的nfp对应的其他参数。在这种情况下，nrf#1在向nrf#2发送发现请求消息时，可以先经过sepp#1转发至sepp#2，再发送至nrf#2。此时，sepp#2可以根据与sepp#1之间协商的n32-f context中远端plmn id信息确定plmn id1，或者根据其与sepp#1之间的连接确定plmn id1，并将plmn id1发送至nrf#2。
220.其中，上述步骤s620和s630中，nfc对应的其他参数和期望访问的nfp对应的其他参数可以为nfc和nfp的网络业务类型，发现请求消息的名称可以为已有的服务名称，例如nnrf_nfdiscovery_request，也可以为新定义的服务名称，本技术对此不作限定。
221.s640，nrf#2向nrf#1发送发现响应消息；对应的，nrf#1接收来自nrf#2的发现响应消息。
222.示例性地，该发现响应消息可以包括以下参数中的一个或多个：plmn id1、plmn id2、期望访问的nfp对应的其他参数。
223.需要说明的是，步骤s630和s640可以参考目前发现请求消息和发现响应消息的内容，本技术对此不做限制。
224.s650，nrf#1根据配置的对端plmn id2对应的授权方式，以及plmn id1对应的授权
方式，确定最终的授权方式。
225.应理解，最终的授权方式既可以指示静态授权方式(static)或者oauth授权方式，还可以同时指示静态授权方式(static)和oauth授权方式。
226.示例性的，这里plmn id1可以是从步骤s620中nfc发送的发现请求消息中获取的，或者nrf#1自己所在网络的标识信息，即plmn id1。
227.特别地，nrf#1可以在步骤s640之后，根据plmn id1和plmn id2确定自己是否保存有或配置有该对应的最终授权方式，若有则跳过确定最终授权方式的步骤s650，即无需nrf#1与nrf#2之间进行授权机制的协商，继续下面步骤s660；否则，需要继续执行步骤s650进行最终授权方式的判定。
228.本技术实施例中，nrf#1中保存有的最终授权方式，可以是nrf#1根据plmn id1对应的授权方式和plmn id2对应的授权方式确定最终的授权方式，或者可以是一开始就保存在nrf#1内部。那么，nfc在访问plmn id2对应的nfp时，nrf#1中根据plmn id2可以直接确定和提供该最终授权方式给nfc，促进nfc和nfp之间业务的访问和服务。
229.需要说明的是，最终授权方式的确定采用取交集的方式，即根据plmn id1对应的授权方式和plmn id2对应的授权方式的交集确定最终的授权方式，具体包括：
230.(1)如果交集为支持静态授权方式(static)，nfc和nfp之间的业务访问使用static授权方式。
231.(2)如果交集为支持oauth授权方式，nfc和nfp之间的业务访问使用oauth授权方式。
232.(3)如果交集为同时支持oauth授权方式和static授权方式，可以根据本地网络策略来决定nfc和nfp之间的业务访问是使用oauth授权方式，还是static授权方式。可选地，如果两个交集都支持oauth授权方式和static授权方式，可以直接选择oauth授权方式进行nfc和nfp之间的业务访问。因为oauth授权方式相对于static授权方式来说，授权的控制更好，安全性更高。
233.可选地，上述步骤s650可以在步骤s610之后的任一步执行，具体执行位置不作限定。例如，步骤s650可以在步骤s620之后执行，即nrf#1在收到nfc的发现请求消息后，就可以根据plmn id1对应的授权方式和plmn id2对应的授权方式确定最终的授权方式。又或者，步骤s650可以在步骤s620之前执行，即nrf#1可以提前告知nfc进行业务访问nfp时，采用的最终授权方式，该实现方式可以进一步减少nfc的信令开销。
234.s660，nrf#1向nfc发送发现响应消息；对应的，nfc接收来自nrf#1的发现响应消息。
235.其中，该发现响应消息包括最终的授权方式。最终的授权方式可以携带在发现响应消息的有效载荷(payload)或头(header)中，例如http header中。
236.示例性的，发现响应消息中已有header可以有1个或多个，可以在已有的一个或多个header中新增指示信息，用于指示最终的授权的方式；或者在发现响应消息中新增一个header，用于携带最终的授权方式信息。
237.需要说明的是，该最终授权方式可以为静态授权方式或oauth授权方式，对应的，nfc可以根据静态授权方式或oauth授权方式向nfp请求业务访问；可选地，该最终授权还可以同时支持静态授权方式和oauth授权方式，此时nfc需要本地策略进一步确定使用哪种授
权方式向nfp请求业务访问。即nfc在接收到静态和oauth两种授权方式时，自己决定使用哪种授权方式。
238.可选地，该发现响应消息可以包括以下参数：期望访问的nfp对应的其他参数。
239.其中，上述步骤s640和s660中，期望访问的nfp对应的其他参数可以为nfp的nfprofile等信息，该发现响应消息的名称可以为新的服务名称，或者已有的服务名称，例如nnrf_nfdiscovery_response，本技术对此不作限定。
240.作为示例而非限定，通过nrf#2确定最终授权方式。示例性的，nrf#2配置对端plmn id1对应的授权方式，此时nrf#2从nrf#1接收发现请求消息，该请求消息包括plmn id1。然后，nrf#2根据plmn id1对应的授权方式和plmn id2对应的授权方式，确定最终的授权方式，并将最终的授权方式通过nrf#1发送给nfc。其中，具体的实现步骤与上述方法600中步骤s620至步骤s660类似。为了简洁，此处不再赘述。
241.另一种可能的实现方式：
242.s670，nfc向nrf#1发送授权请求消息；对应的，nrf#1接收来自nfc的授权请求消息。
243.其中，该授权请求消息包括plmn id2，该授权请求消息用于请求确定访问plmn id2对应网络的授权方式。
244.可选地，该授权请求消息还包括plmn id1、nfc对应的其他参数和期望访问的nfp对应的其他参数。
245.需要说明的是，plmn id1为nfc所在网络的标识信息，plmn id2为nfc希望进行业务访问的服务提供功能nfp网元对应网络的标识信息。示例性的，该nfp可以为会话管理功能smf网元，或者策略控制功能pcf网元等。
246.其中，nfc对应的其他参数和期望访问的nfp对应的其他参数可以为nfc和nfp的网络业务类型，授权请求消息的名称可以为新的服务名称，例如nnrf_authorization_request，本技术对此不作限定；或者可以为已有的服务名称，那么需要新增指示信息，用于指示请求确定访问plmn id2对应网络的授权方式。可选地，该指示信息包括plmn id1。
247.s680，nrf#1根据配置的对端plmn id2对应的授权方式，以及plmn id1对应的授权方式，确定最终的授权方式。
248.应理解，最终的授权方式既可以指示静态授权方式(static)或者oauth授权方式，还可以同时指示静态授权方式(static)和oauth授权方式。
249.示例性的，这里plmn id1可以是从步骤s670中nfc发送的授权请求消息中获取的，或者nrf#1自己所在网络的标识信息，即plmn id1。
250.特别地，nrf#1可以在步骤s670之后，根据plmn id1和plmn id2确定自己是否保存有该对应的最终授权方式，若有则跳过确定最终授权方式的步骤s680，继续下面步骤s690；否则，需要继续执行步骤s680进行最终授权方式的判定。
251.本技术实施例中，nrf#1中保存有的最终授权方式，可以是nrf#1根据plmn id1对应的授权方式和plmn id2对应的授权方式确定最终的授权方式，或者可以是一开始就保存在nrf#1内部。那么，nfc在访问plmn id2对应的nfp时，nrf#1中根据plmn id2可以直接确定和提供该最终授权方式给nfc，促进nfc和nfp之间业务的访问和服务。
252.示例性的，最终授权方式的确定采用取交集的方式，即根据plmn id1对应的授权
方式和plmn id2对应的授权方式的交集确定最终的授权方式，具体实现与步骤s650中一致。为了简洁，此处不再赘述。
253.s690，nrf#1向nfc发送授权响应消息；对应的，nfc接收来自nrf#1授权响应消息。
254.其中，该授权响应消息包括最终的授权方式。最终的授权方式可以携带在发现响应消息的有效载荷(payload)或头(header)中，例如http header中。
255.示例性的，授权响应消息中已有header可以有1个或多个，可以在已有的一个或多个header中新增指示信息，用于指示最终的授权的方式；或者在发现响应消息中新增一个header，用于携带最终的授权方式信息。
256.需要说明的是，该最终授权方式可以为静态授权方式或oauth授权方式，对应的，nfc可以根据静态授权方式或oauth授权方式向nfp请求业务访问；可选地，该最终授权还可以同时支持静态授权方式和oauth授权方式，此时nfc需要本地策略进一步确定使用哪种授权方式向nfp请求业务访问。即nfc在接收到静态和oauth两种授权方式时，自己决定使用哪种授权方式。
257.可选地，该授权响应消息可以包括以下参数：nfp对应的其他参数。
258.其中，授权响应消息的名称可以为新的服务名称，例如nnrf_authorization_response，本技术对此不作限定。
259.s691，基于上述两种可能的实现方式，nfc根据最终的授权方式确定是否发起获取授权令牌token的流程。
260.示例性的，当最终的授权方式为static时，nfc采用静态授权方式直接向nfp发送业务请求；当最终的授权方式为oauth时，nfc需要先向nrf发起请求获取授权令牌token的流程，再携带token向nfp发送业务请求，nfp在校验token成功后，为nfc提供相应的业务服务。其中，获取token的具体实现步骤在方法200中已经阐述，为了简洁，这里不再赘述。
261.作为示例而非限定，通过nrf#2确定最终授权方式。示例性的，nrf#2配置对端plmn id1对应的授权方式，此时nrf#2从nrf#1接收授权请求消息，该请求消息包括plmn id1。然后，nrf#2根据plmn id1对应的授权方式和plmn id2对应的授权方式，确定最终的授权方式，并将最终的授权方式通过nrf#1发送给nfc。其中，具体的实现步骤与上述方法600中步骤s670至步骤s690类似。为了简洁，此处不再赘述。
262.图7是适用本技术实施例的授权机制协商方法的一例示意图，通过安全边缘保护代理网元配置对端网络授权方式，并确定最终的授权方式，使得服务消费功能网元获得业务访问的授权方式。该具体实现方式和上述方法600的区别在于，基于sepp完成授权方式的配置和协商，避免了对于nrf的影响，将授权内容控制在漫游安全网元之间。如图7所示，包括服务消费功能网元nfc、网络存储功能网元nrf#a、网络存储功能网元nrf#b、安全边缘保护代理网元sepp#a和安全边缘保护代理网元sepp#b，具体实现步骤700包括：
263.s710，安全边缘保护代理网元(例如，sepp#a)配置对端(例如，plmn id2)对应的授权方式。
264.示例性的，nrf#a属于域1，nrf#b属于域2，域1和域2有不同的标识，可以为plmn id、scp域标识、nrf域标识等。不同域之间的协商可以通过plmn id、scp域id、nrf域id、nf set域id、安全域id等来完成。可选地，nrf#a属于运营商1，nrf#b属于运营商2。一般地，不同运营商的网络功能网元之间的授权方式不同，同一运营商中网络功能网元之间的授权机制
相同。可选地，nrf#a和nrf#b可以属于同一个运营商，此时nrf#a对应的业务类型的授权方式与nrf#b对应的业务类型的授权方式不同。
265.需要说明的是，本技术中nrf#a和nrf#b均配置各自plmn id对应的授权方式，sepp#a和sepp#b均配置各自plmn id对应的授权方式。即nrf#a和sepp#a配置plmn id1对应的授权方式，nrf#b和sepp#b配置plmn id2对应的授权方式。这里sepp#a和sepp#b是通过n32接口连接，nrf#a与nrf#b之间的信息交互需要先后通过sepp#和sepp#b传输。
266.示例性的，sepp#a配置有对端plmnd id2对应的的授权方式，或者sepp#a向其他网元(例如，控制网元和/或管理网元)发送请求消息，该请求消息包括对端plmn id2，用于请求该plmn id2对应的授权方式，其他网元根据plmn id2确定plmn id2对应的授权方式，并发送给sepp#a。
267.其中，具体的plmn id对应的授权方式包括：静态授权方式(static)，和/或oauth授权方式。
268.一种可能的实现方式：
269.s720，服务消费功能网元(例如，nfc)向nrf#a发送发现请求消息；对应的，nrf#a接收来自nfc的发现请求消息。
270.s731-s733，nrf#a确定sepp#a，并通过sepp#a和sepp#b向nrf#b发送发现请求消息；对应的，nrf#b接收来自nrf#a的发现请求消息。
271.其中，在上述步骤s720和步骤s731中，该发现请求消息包括plmn id2，该发现请求消息用于请求确定访问plmn id2对应网络的nfp的信息。
272.可选地，该发现请求消息还包括plmn id1、nfc对应的其他参数和期望访问的nfp对应的其他参数。
273.需要说明的是，plmn id1为nfc所在网络的标识信息，plmn id2为nfc希望进行业务访问的服务提供功能nfp网元对应网络的标识信息。示例性的，该nfp可以为会话管理功能smf网元，或者策略控制功能pcf网元等。
274.可选地，步骤s732中该发现请求消息可以不包括plmn id1、plmn id2、nfc对应的其他参数和期望访问的nfp对应的其他参数。
275.在这种情况下，nrf#a在向nrf#b发送发现请求消息时，示例性的，sepp#b可以根据与sepp#a之间协商的n32-f context中远端plmn id信息确定plmn id1，或者根据其与sepp#a之间的连接确定plmn id1，并将plmn id1发送至nrf#b。
276.其中，步骤s733中该发现请求消息包括plmn id1，用于请求确定访问plmn id2对应网络的信息。可选地，该发现请求消息还包括plmn id2、nfc对应的其他参数和期望访问的nfp对应的其他参数。
277.其中，上述步骤s720至步骤s733中，nfp对应的其他参数和期望访问的nfp对应的其他参数可以为nfc和nfp的网络业务类型，发现响应消息的名称可以为已有的服务名称，例如nnrf_nfdiscovery_request，也可以为新定义的服务名称，本技术对此不作限定。
278.s741-s742，nrf#b通过sepp#b向sepp#a发送发现响应消息；对应的，sepp#a接收来自nrf#b的发现响应消息。
279.示例性地，该发现响应消息可以包括以下参数：nfp对应的nfpofile等其他参数。
280.需要说明的是，步骤s732和s742可以参考目前发现请求消息和发现响应消息的内
容，本技术对此不做限制。
281.应理解，上述步骤s732至步骤s742的发现流程的具体实现方式可以参照上述方法400，本技术对此不作限定。
282.s750，sepp#a根据配置的对端plmn id2对应的授权方式，以及plmn id1对应的授权方式，确定最终的授权方式。
283.应理解，最终的授权方式既可以指示静态授权方式(static)或者oauth授权方式，还可以同时指示静态授权方式(static)和oauth授权方式。
284.示例性的，这里plmn id1可以是从步骤s731中nfc发送的发现请求消息中获取的，或者sepp#a自己所在网络的标识信息，即plmn id1。
285.特别地，sepp#a可以在步骤s742之后，根据plmn id1和plmn id2，或者plmnid2确定自己是否保存有或配置有该对应的最终授权方式，若有则跳过确定最终授权方式的步骤s750，继续下面步骤s760；否则，需要继续执行步骤s750进行最终授权方式的判定。
286.本技术实施例中，sepp#a中保存有的最终授权方式，可以是sepp#a根据plmn id1对应的授权方式和plmn id2对应的授权方式确定最终的授权方式，或者可以是一开始就保存在sepp#a内部。那么，nfc在访问plmn id2对应的nfp时，sepp#a中根据plmn id2可以直接确定和提供该最终授权方式给nfc，促进nfc和nfp之间业务的访问和服务。
287.示例性的，最终授权方式的确定采用取交集的方式，即根据plmn id1对应的授权方式和plmn id2对应的授权方式的交集确定最终的授权方式，具体实现与步骤s650中一致。为了简洁，此处不再赘述。
288.需要说明的是，sepp#a在确定最终的授权方式之前需要确定plmn id1和plmn id2。其中，plmn id2是从nrf#a接收的。plmn id1可以是从步骤s731中nfc发送的发现请求消息中获取的；或者sepp#a自己所在网络的标识信息，即plmn id1；或者根据sepp#a与nrf#a之间连接确定的nrf#a所在的网络标识，即plmn id1。例如，sepp#a根据从nrf#a接收的nrf#a的全限定域名(fully qualified domain name，fqdn)，和/或nrf#ad地址，和/或nrf#a证书内plmn id信息等确定的plmn id。
289.可选地，上述步骤s750可以在步骤s731之后的任一步执行，具体执行位置不作限定。例如，步骤s750可以在步骤s731之后执行，即sepp#a在收到nrf#a的发现请求消息后，就可以根据plmn id1对应的授权方式和plmn id2对应的授权方式确定最终的授权方式。
290.s760-s770，sepp#a通过nrf#a向nfc发送发现响应消息；对应的，nfc接收来自sepp#a的发现响应消息。
291.其中，在上述步骤s760和步骤s770中，该发现响应消息包括最终的授权方式。最终的授权方式可以携带在发现响应消息的有效载荷(payload)或头(header)中，例如http header中。
292.示例性的，发现响应消息中已有header可以有1个或多个，可以在已有的一个或多个header中新增指示信息，用于指示最终的授权的方式；或者在发现响应消息中新增一个header，用于携带最终的授权方式信息。
293.需要说明的是，该最终授权方式可以为静态授权方式或oauth授权方式，对应的，nfc可以根据静态授权方式或oauth授权方式向nfp请求业务访问；可选地，该最终授权还可以同时支持静态授权方式和oauth授权方式，此时nfc需要本地策略进一步确定使用哪种授
权方式向nfp请求业务访问。即nfc在接收到静态和oauth两种授权方式时，自己决定使用哪种授权方式。
294.可选地，该发现响应消息可以包括以下参数：期望访问的nfp对应的其他参数。
295.其中，在上述步骤s741、s742、s760和s770中，期望访问的nfp对应的其他参数可以为nfp的nfprofile等信息，该发现响应消息的名称可以为新的服务名称，例如nnrf_nfdiscovery_response，本技术对此不作限定。
296.作为示例而非限定，通过sepp#b确定最终授权方式。示例性的，sepp#b配置对端plmn id1对应的授权方式，此时sepp#b从sepp#a接收发现请求消息，该请求消息包括plmn id1，并接收来自nrf#b的发现响应消息。然后，sepp#b根据plmn id1对应的授权方式和plmn id2对应的授权方式，确定最终的授权方式，并将最终的授权方式通过sepp#a和nrf#a发送给nfc。其中，具体的实现步骤与上述方法700中步骤s720至步骤s770类似。为了简洁，此处不再赘述。
297.另一种可能的实现方式：
298.s780，nfc向sepp#a发送授权请求消息；对应的，sepp#a接收来自nfc的授权请求消息。
299.其中，该授权请求消息包括plmn id2，该授权请求消息用于请求确定访问plmn id2对应网络的授权方式。
300.可选地，该授权请求消息还包括plmn id1。
301.应理解，plmn id1为nfc所在网络的标识信息，plmn id2为nfc希望进行业务访问的服务提供功能nfp网元对应网络的标识信息。
302.其中，授权请求消息的名称可以为新的服务名称，例如nnrf_authorization_request，本技术对此不作限定；或者可以为已有的服务名称，那么需要新增指示信息，用于指示请求确定访问plmn id2对应网络的授权方式。可选地，该指示信息包括plmn id1。
303.作为示例而非限定，nfc访问sepp#a，也可以通过其他网元进行访问。例如nrf，服务通信代理(service communication proxy，scp)等，本技术对此不作限定。当前5g架构包括scp网元，scp是nf网元的代理，也可以理解scp为一个scp域的出入口，或者代理节点。因此不同域之间的协商，也可以通过scp来完成。例如，nfc与nfp之间的业务访问可以先后经过scp1和scp2，即nfc-scp1-scp2-nfp。所以上述通过sepp直接协商的方式，也使用scp的方式。即可以将scp替换为上述sepp，plmn id替换为scp域标识。
304.示例性的，sepp#a的地址可以是nf发现流程中，nfc从nrf#a接收到的地址信息，或者nfc预先配置sepp#a的地址信息，本技术对此不作限定。
305.s790，sepp#a根据配置的对端plmn id2对应的授权方式，以及plmn id1对应的授权方式，确定最终的授权方式。
306.应理解，最终的授权方式既可以指示静态授权方式(static)或者oauth授权方式，还可以同时指示静态授权方式(static)和oauth授权方式。
307.示例性的，这里plmn id1可以是从步骤s780中nfc发送的授权请求消息中获取的，或者sepp#a自己所在网络的标识信息，即plmn id1。
308.特别地，sepp#a可以在步骤s780之后，根据plmn id1和plmn id2确定自己是否保存有该对应的最终授权方式，若有则跳过确定最终授权方式的步骤s790，继续下面步骤
s791；否则，需要继续执行步骤s790进行最终授权方式的判定。
309.本技术实施例中，sepp#a中保存有的最终授权方式，可以是sepp#a根据plmn id1对应的授权方式和plmn id2对应的授权方式确定最终的授权方式，或者可以是一开始就保存在sepp#a内部。那么，nfc在访问plmn id2对应的nfp时，sepp#a中根据plmn id2可以直接确定和提供该最终授权方式给nfc，促进nfc和nfp之间业务的访问和服务。
310.示例性的，最终授权方式的确定采用取交集的方式，即根据plmn id1对应的授权方式和plmn id2对应的授权方式的交集确定最终的授权方式，具体实现与步骤s650中一致。为了简洁，此处不再赘述。
311.s791，sepp#a向nfc发送授权响应消息；对应的，nfc接收来自sepp#a授权响应消息。
312.其中，该授权响应消息包括最终的授权方式。最终的授权方式可以携带在授权响应消息的有效载荷(payload)或头(header)中，例如http header中。
313.示例性的，授权响应消息中已有header可以有1个或多个，可以在已有的一个或多个header中新增指示信息，用于指示最终的授权的方式；或者在授权响应消息中新增一个header，用于携带最终的授权方式信息。
314.需要说明的是，该最终授权方式可以为静态授权方式或oauth授权方式，对应的，nfc可以根据静态授权方式或oauth授权方式向nfp请求业务访问；可选地，该最终授权还可以同时支持静态授权方式和oauth授权方式，此时nfc需要本地策略进一步确定使用哪种授权方式向nfp请求业务访问。即nfc在接收到静态和oauth两种授权方式时，自己决定使用哪种授权方式。
315.其中，授权响应消息的名称可以为新的服务名称，例如nnrf_authorization_response，本技术对此不作限定。
316.s792，基于上述两种可能的实现方式，nfc根据最终的授权方式确定是否发起获取授权令牌token的流程。具体实现方式参见上述步骤s691，为了简洁，此处不再赘述。
317.作为示例而非限定，通过sepp#b确定最终授权方式。示例性的，sepp#b配置对端plmn id1对应的授权方式，此时sepp#b从sepp#a接收授权请求消息，该请求消息包括plmn id1。然后，sepp#b根据plmn id1对应的授权方式和plmn id2对应的授权方式，确定最终的授权方式，并将最终的授权方式通过sepp#a发送给nfc。其中，具体的实现步骤与上述方法700中步骤s780至步骤s791类似。为了简洁，此处不再赘述。
318.图8是适用本技术实施例的授权机制协商方法的一例示意图，通过网络存储功能网元配置本端网络授权方式，并与对端网络存储功能网元协商确定最终的授权方式，使得服务消费功能网元获得业务访问的授权方式。该具体实现方式和上述方法600的区别在于，新增了网络存储功能网元之间交互协商的流程。支持动态的授权协商，若对端网络授权方式发生变化，协商方式可以获得最新的授权机制。而配置方式需要配置之后，才能获得最新的授权机制，因此时效性没有协商机制好。如图8所示，包括服务消费功能网元nfc、网络存储功能网元nrf#1和网络存储功能网元nrf#2，具体实现步骤800包括：
319.一种可能的实现方式：
320.s810，服务消费功能网元(例如，nfc)向nrf#1发送发现请求消息；对应的，nrf#1接收来自nfc的发现请求消息。
321.其中，该发现请求消息包括plmn id2，该发现请求消息用于请求确定访问plmn id2对应网络的授权方式。
322.可选地，该发现请求消息还包括plmn id1、nfc对应的其他参数和期望访问的nfp对应的其他参数。
323.需要说明的是，plmn id1为nfc所在网络的标识信息，plmn id2为nfc希望进行业务访问的服务提供功能nfp网元对应网络的标识信息。示例性的，该nfp可以为会话管理功能smf网元，或者策略控制功能pcf网元等。
324.s820，nrf#1向nrf#2发送发现请求消息；对应的，nrf#2接收来自nrf#1的发现请求消息。
325.其中，该发现请求消息包括plmn id1对应的授权方式，用于请求确定访问plmn id2对应网络的授权方式。plmn id1对应的授权方式可以携带在发现请求消息的有效载荷(payload)或头(header)中，例如http header中。
326.示例性的，发现请求消息中已有header可以有1个或多个，可以在已有的一个或多个header中新增指示信息，用于指示最终的授权的方式；或者在发现请求消息中新增一个header，用于携带最终的授权方式信息。
327.可选地，该发现请求消息可以包括以下参数中的一个或多个：plmn id1、plmn id2、nfc对应的其他参数和期望访问的nfp对应的其他参数。
328.可选地，该发现请求消息可以不包括plmn id1、plmn id2、nfc对应的其他参数和期望访问的nfp对应的其他参数。在这种情况下，nrf#1在向nrf#2发送发现请求消息时，可以先经过sepp#1转发至sepp#2，再发送至nrf#2。此时，sepp#2可以根据与sepp#1之间协商的n32-f context中远端plmn id信息确定plmn id1，或者根据其与sepp#1之间的连接确定，并将plmn id1发送至nrf#2。
329.其中，上述步骤s810和s820中，plmn id1对应的其他参数和plmn id2对应的其他参数可以为nfc和nfp的网络业务类型，发现请求消息的名称可以为已有服务名称，例如nnrf_nfdiscovery_request，也可以为新定义的服务名称，本技术对此不作限定。可选地，该发现请求消息可以携带指示信息，用于指示获取访问nfp的最终授权方式，nrf#2根据此指示信息确定最终授权方式。
330.s830，nrf#2根据本端plmn id2对应的授权方式，以及接收的plmn id1对应的授权方式，确定最终的授权方式。
331.应理解，最终的授权方式既可以指示静态授权方式(static)或者oauth授权方式，还可以同时指示静态授权方式(static)和oauth授权方式。
332.示例性的，plmn id1可以是从步骤s820中nrf#1发送的发现请求消息中获取的。
333.需要说明的是，最终授权方式的确定采用取交集的方式，即根据plmn id1对应的授权方式和plmn id2对应的授权方式的交集确定最终的授权方式，具体实现与步骤s650中一致。为了简洁，此处不再赘述。
334.s840-s850，nrf#2通过nrf#1向nfc发送发现响应消息；对应的，nfc接收来自nrf#2的发现响应消息。
335.其中，该发现响应消息包括最终的授权方式。最终的授权方式可以携带在发现响应消息的有效载荷(payload)或头(header)中，例如http header中。
336.示例性的，发现响应消息中已有header可以有1个或多个，可以在已有的一个或多个header中新增指示信息，用于指示最终的授权的方式；或者在发现响应消息中新增一个header，用于携带最终的授权方式信息。
337.需要说明的是，该最终授权方式可以为静态授权方式或oauth授权方式，对应的，nfc可以根据静态授权方式或oauth授权方式向nfp请求业务访问；可选地，该最终授权还可以同时支持静态授权方式和oauth授权方式，此时nfc需要本地策略进一步确定使用哪种授权方式向nfp请求业务访问。即nfc在接收到静态和oauth两种授权方式时，自己决定使用哪种授权方式。
338.可选地，该发现响应消息可以包括以下参数中的一个或多个：plmn id1、plmn id2、期望访问的nfp对应的其他参数，例如nfprofile。发现响应消息的名称可以为已有的服务名称，例如nnrf_nfdiscovery_response，也可以为新定义的服务名称，本技术对此不作限定。
339.作为示例而非限定，通过nrf#1确定最终授权方式。示例性的，nrf#1向nrf#2发送发现请求消息，该请求消息用于请求plmn id2对应的授权方式，并从nrf#2接收plmn id2对应的授权方式。然后nrf#1根据plmn id1对应的授权方式和plmn id2对应的授权方式确定最终的授权方式，并将最终的授权方式发送给nfc。其中，具体的实现步骤与上述方法800中步骤s810至步骤s850类似。为了简洁，此处不再赘述。
340.另一种可能的实现方式：
341.s860，可选地，服务消费功能网元(例如，nfc)向nrf#1发送发现请求消息；对应的，nrf#1接收来自nfc的发现请求消息。其中，该发现请求消息包括plmn id2。
342.s870，nrf#1向nrf#2发送能力请求消息；对应的，nrf#2接收来自nrf#1的能力请求消息。
343.其中，该能力请求消息包括指示信息#1，用于指示nrf#2发送plmn id2对应网络的授权方式。
344.可选地，该能力请求消息可以包括以下参数：plmn id1。
345.其中，授权响应消息的名称可以为新的服务名称，例如nnrf_bootstrapping_get_request，本技术对此不作限定；或者可以为已有的服务名称，那么需要新增指示信息#2，用于指示请求确定访问plmn id2对应网络的授权方式。可选地，该指示信息#2包括plmn id1。
346.s880，nrf#2根据能力请求消息和指示信息#1确定plmn id2对应的授权方式；或者根据新的服务名称，确定plmn id2对应的授权方式。
347.s890，nrf#2向nrf#1发送能力响应消息；对应的，nrf#1接收来自nrf#2的能力响应消息。
348.其中，能力响应消息包括plmn id2对应的授权方式。能力响应消息的名称可以为已有的服务名称，例如nnrf_bootstrapping_get_response，本技术对此不作限定。
349.s891，nrf#1根据接收的plmn id2对应的授权方式，以及本地plmn id1对应的授权方式，确定最终的授权方式。
350.应理解，最终的授权方式既可以指示静态授权方式(static)或者oauth授权方式，还可以同时指示静态授权方式(static)和oauth授权方式。
351.示例性的，这里plmn id1可以是从步骤s860中nfc发送的发现请求消息中获取的，
或者nrf#1自己所在网络的标识信息，即plmn id1。
352.本技术实施例中，nrf#1中保存有的最终授权方式，可以是nrf#1根据plmn id1对应的授权方式和plmn id2对应的授权方式确定最终的授权方式，或者可以是一开始就保存在nrf#1内部。那么，nfc在访问plmn id2对应的nfp时，nrf#1根据plmn id2可以直接确定和提供该最终授权方式给nfc，促进nfc和nfp之间业务的访问和服务。
353.示例性的，最终授权方式的确定采用取交集的方式，即根据plmn id1对应的授权方式和plmn id2对应的授权方式的交集确定最终的授权方式，具体实现与步骤s650中一致。为了简洁，此处不再赘述。
354.s892，可选地，nrf#1向nrf#2发送通知消息；对应的，nrf#2接收来自nrf#1的通知消息。
355.其中，该通知消息包括最终授权方式，用于后续plmn id2对应的网络功能nf网元向plmn id1对应的网络功能nf网元发送业务访问请求消息时，nrf#2网元可以根据上述最终授权方式执行对应的授权操作。
356.s893，nrf#1向nfc发送授权响应消息；对应的，nfc接收来自nrf#1授权响应消息。
357.其中，该授权响应消息包括最终的授权方式。最终的授权方式可以携带在发现响应消息的有效载荷(payload)或头(header)中，例如http header中。
358.示例性的，发现响应消息中已有header可以有1个或多个，可以在已有的一个或多个header中新增指示信息，用于指示最终的授权的方式；或者在发现响应消息中新增一个header，用于携带最终的授权方式信息。
359.需要说明的是，该最终授权方式可以为静态授权方式或oauth授权方式，对应的，nfc可以根据静态授权方式或oauth授权方式向nfp请求业务访问；可选地，该最终授权还可以同时支持静态授权方式和oauth授权方式，此时nfc需要本地策略进一步确定使用哪种授权方式向nfp请求业务访问。即nfc在接收到静态和oauth两种授权方式时，自己决定使用哪种授权方式。
360.s894，基于上述两种可能的实现方式，nfc根据最终的授权方式确定是否发起获取授权令牌token的流程。具体实现方式参见上述步骤s691，为了简洁，此处不再赘述。
361.作为示例而非限定，通过nrf#2确定最终授权方式。示例性的，nrf#2从nrf#1接收请求消息，该请求消息包括plmn id1对应的授权方式。可选地，该请求消息包括plmn id2。然后，nrf#2根据plmn id1对应的授权方式和plmn id2对应的授权方式，确定最终的授权方式，并将最终的授权方式通过nrf#1发送给nfc。其中，具体的实现步骤与上述方法800中步骤s860至步骤s893类似。为了简洁，此处不再赘述。
362.图9是适用本技术实施例的授权机制协商方法的一例示意图，通过安全边缘保护代理网元配置本端网络授权方式，并与对端网络存储功能网元协商确定最终的授权方式，使得服务消费功能网元获得业务访问的授权方式。该具体实现方式和上述方法600的区别在于，新增了sepp间交互协商的流程，避免了对于nrf的影响，将授权内容控制在漫游安全网元之间。支持动态的授权协商，若对端网络授权方式发生变化，协商方式可以获得最新的授权机制。而配置方式需要配置之后，才能获得最新的授权机制，因此时效性没有协商机制好。如图9所示，包括服务消费功能网元nfc、网络存储功能网元nrf#a、网络存储功能网元nrf#b、安全边缘保护代理网元sepp#a和安全边缘保护代理网元sepp#b，具体实现步骤900
包括：
363.一种可能的实现方式：
364.s911，服务消费功能网元(例如，nfc)向nrf#a发送发现请求消息；对应的，nrf#a接收来自nfc的发现请求消息。
365.s912，nrf#a确定sepp#a，并向sepp#a发送发现请求消息；对应的，sepp#a接收来自nrf#a的发现请求消息。
366.其中，在上述步骤s9110和步骤s912中，该发现请求消息包括plmn id2，该发现请求消息用于请求确定访问plmn id2对应网络的授权方式。
367.可选地，该发现请求消息还包括plmn id1、nfc对应的其他参数和期望访问的nfp对应的其他参数中的至少一项。
368.需要说明的是，plmn id1为nfc所在网络的标识信息，plmn id2为nfc希望进行业务访问的服务提供功能nfp网元对应网络的标识信息。示例性的，该nfp可以为会话管理功能smf网元，或者策略控制功能pcf网元等。
369.s920，sepp#a根据plmn id1确定plmn id1对应的授权方式。
370.其中，plmn id1可以是从步骤s912中接收的发现请求消息中获取的；或者sepp#a自己所在网络的标识信息，即plmn id1；或者根据sepp#a与nrf#a之间连接确定的nrf#a所在的网络标识，即plmn id1。例如，sepp#a根据从nrf#a接收的nrf#a的fqdn，和/或nrf#a的地址，和/或nrf#a证书内plmn id信息等确定的plmn id。
371.s930-s940，sepp#a通过sepp#b向nrf#b发送发现请求消息；对应的，nrf#b接收来自sepp#a的发现请求消息。
372.其中，步骤s930中该发现请求消息包括：plmn id1对应的授权方式。
373.可选地，该发现请求消息可以不包括plmn id1、plmn id2、nfc对应的其他参数和期望访问的nfp对应的其他参数。
374.在这种情况下，sepp#a在向sepp#b发送发现请求消息时，示例性的，sepp#b可以根据与sepp#a之间协商的n32-f context中远端plmn id信息确定plmn id1，或者根据其与sepp#a之间的连接确定plmn id1，并将plmn id1发送至nrf#b。
375.其中，步骤s940中该发现请求消息包括plmn id1，用于请求确定访问plmn id2对应网络的授权方式。
376.需要说明的是，上述步骤s911、s912、s930和步骤s940中，plmn id1对应的其他参数和plmn id2对应的其他参数可以为nfc和nfp的网络业务类型，发现响应消息的名称可以为已有的服务名称，例如nnrf_nfdiscovery_request，也可以为新定义的服务名称，本技术对此不作限定。
377.可选地，该发现请求消息可以携带指示信息，用于指示获取访问nfp的最终授权方式，nrf#b根据此指示信息确定最终授权方式。
378.s950，nrf#b向sepp#b发送发现响应消息；对应的，sepp#b接收来自nrf#b的发现响应消息。
379.示例性地，该发现响应消息可以包括以下参数：期望访问的nfp对应的其他参数。
380.s960，sepp#b根据plmn id2对应授权方式和plmn id1对应的授权方式，确定最终的授权方式。
381.应理解，最终的授权方式既可以指示静态授权方式(static)或者oauth授权方式，还可以同时指示静态授权方式(static)和oauth授权方式。
382.示例性的，这里plmn id1可以是从步骤s930中接收的发现请求消息中获取的，或者sepp#a自己所在网络的标识信息，即plmn id1。
383.示例性的，最终授权方式的确定采用取交集的方式，即根据plmn id1对应的授权方式和plmn id2对应的授权方式的交集确定最终的授权方式，具体实现与步骤s650中一致。为了简洁，此处不再赘述。
384.s971-s973，sepp#通过sepp#a和nrf#a向nfc发送发现响应消息；对应的，nfc接收来自sepp#b的发现响应消息。
385.其中，该发现响应消息包括最终的授权方式。最终的授权方式可以携带在发现响应消息的有效载荷(payload)或头(header)中，例如http header中。
386.示例性的，发现响应消息中已有header可以有1个或多个，可以在已有的一个或多个header中新增指示信息，用于指示最终的授权的方式；或者在发现响应消息中新增一个header，用于携带最终的授权方式信息。
387.需要说明的是，该最终授权方式可以为静态授权方式或oauth授权方式，对应的，nfc可以根据静态授权方式或oauth授权方式向nfp请求业务访问；可选地，该最终授权还可以同时支持静态授权方式和oauth授权方式，此时nfc需要本地策略进一步确定使用哪种授权方式向nfp请求业务访问。即nfc在接收到静态和oauth两种授权方式时，自己决定使用哪种授权方式。
388.可选地，该发现响应消息可以包括以下参数：期望访问的nfp对应的其他参数。
389.其中，在上述步骤s741、s742、s760和s770中，plmn id1对应的其他参数和plmn id2对应的其他参数可以为nfc和nfp的网络业务类型，发现响应消息的名称可以为已有服务名称，例如nnrf_nfdiscovery_response，也可以为新定义的服务名称，本技术对此不作限定。
390.作为示例而非限定，通过nrf#b确定最终授权方式。示例性的，基于上述方法900的基础上，在步骤s930之后，sepp#b将plmn id1对应的授权方式发送给nrf#b。然后，nrf#b根据plmn id1对应的授权方式和plmn id2对应的授权方式，确定最终的授权方式，并将最终的授权方式通过sepp#b、sepp#a和nrf#a发送给nfc。其中，具体的实现步骤与上述方法900中步骤s911至步骤s973类似。为了简洁，此处不再赘述。
391.另一种可能的实现方式：
392.s981-s982，可选地，服务消费功能网元(例如，nfc)通过nrf#a向sepp#a发送发现请求消息；对应的，sepp#a接收来自nfc的发现请求消息。
393.其中，该发现请求消息包括plmn id2，用于请求确定访问plmn id2对应网络的授权方式。
394.s983，sepp#a向sepp#b发送n32连接建立请求消息；对应的，sepp#b接收来自sepp#a的n32连接建立请求消息。
395.其中，该n32接口是用于sepp#a和sepp#b之间的通信。可选地，该n32连接建立请求消息包括指示信息#a，用于指示sepp#b发送sepp#b所在网络支持的授权方式。例如，plmn id2对应网络的授权方式，或者其他plmn id对应的授权方式。
396.应理解，如果执行上述步骤s981-s982，那么该sepp#b需要确定并向sepp#a发送plmn id2对应的授权方式。如果不执行上述步骤s981-s982，那么该sepp#b可以确定多个为nfc提供服务的plmn id，以及对应的授权方式。因为sepp#b可能支持多个plmn id，本技术对此不作限定。
397.可选地，该n32连接建立请求消息可以包括以下参数中的一个或多个：plmn id1、plmn id2。
398.其中，授权响应消息的名称可以为新的服务名称，例如n32connection establishment request(indicator)，本技术对此不作限定；或者可以为已有的服务名称，那么需要新增指示信息#b，用于指示请求确定访问sepp2对应网络的授权方式。可选地，该指示信息#b包括plmn id1。
399.s990，sepp#b根据连接建立请求消息和指示信息#a确定sepp#b支持的网络对应的授权方式(可能支持多个plmn id，以及对应的授权方式)，或者plmn id2对应的授权方式，即sepp#b确定sepp#b支持的网络对应的授权方式，或者从sepp#a接收到的plmn id2对应的授权方式。sepp#b支持的网络plmn id及其对应的授权方式取决于是否执行上述步骤s981-s982。
400.可选地，sepp#b根据新的服务名称，确定向sepp#a发送sepp#b支持的网络对应的授权方式，或者plmn id2对应的授权方式。
401.需要说明的是，这里plmn id2为接收的plmn id2，或者sepp#b根据两个sepp之间协商的n32-f context中远端plmn id信息确定plmn id1，或者根据其与sepp#a之间的连接来确定。
402.s991，sepp#b向sepp#a发送n32连接建立响应消息；对应的，sepp#a接收来自sepp#a的n32连接建立响应消息。
403.其中，该连接建立响应消息包括plmn id2对应的授权方式。
404.其中，该连接建立响应消息的名称可以为新的服务名称，例如n32connection establishment response，本技术对此不作限定。
405.s992，sepp#a根据接收的plmn id2对应的授权方式，以及本地plmn id1对应的授权方式，确定最终的授权方式。
406.应理解，最终的授权方式既可以指示静态授权方式(static)或者oauth授权方式，还可以同时指示静态授权方式(static)和oauth授权方式。
407.示例性的，这里plmn id1可以是从步骤s982中接收的发现请求消息中获取的，或者sepp#a自己所在网络的标识信息，即plmn id1。
408.本技术实施例中，sepp#a中保存有的最终授权方式，可以是sepp#a根据plmn id1对应的授权方式和plmn id2对应的授权方式确定最终的授权方式，或者可以是一开始就保存在sepp#a内部访问plmn id2，或者plmn id1访问plmn id2对应网络的最终授权方式。那么，nfc在访问plmn id2对应的nfp时，sepp#a根据plmn id2可以直接确定和提供该最终授权方式给nfc，促进nfc和nfp之间业务的访问和服务。
409.示例性的，最终授权方式的确定采用取交集的方式，即根据plmn id1对应的授权方式和plmn id2对应的授权方式的交集确定最终的授权方式，具体实现与步骤s650中一致。为了简洁，此处不再赘述。
410.s993，可选地，sepp#a向sepp#b发送通知消息；对应的，sepp#b接收来自sepp#a的通知消息。
411.其中，该通知消息包括最终授权方式，用于后续plmn id2对应的网络功能nf网元向plmn id1对应的网络功能nf网元发送业务访问请求消息时，sepp#b可以根据上述最终授权方式执行对应的授权操作。
412.s994-s995，sepp#a通过nrf#a向nfc发送授权响应消息；对应的，nfc接收来自sepp#a授权响应消息。
413.其中，该授权响应消息包括最终的授权方式。最终的授权方式可以携带在发现响应消息的有效载荷(payload)或头(header)中，例如http header中。
414.示例性的，授权响应消息中已有header可以有1个或多个，可以在已有的一个或多个header中新增指示信息，用于指示最终的授权的方式；或者在授权响应消息中新增一个header，用于携带最终的授权方式信息。
415.需要说明的是，该最终授权方式可以为静态授权方式或oauth授权方式，对应的，nfc可以根据静态授权方式或oauth授权方式向nfp请求业务访问；可选地，该最终授权还可以同时支持静态授权方式和oauth授权方式，此时nfc需要本地策略进一步确定使用哪种授权方式向nfp请求业务访问。即nfc在接收到静态和oauth两种授权方式时，自己决定使用哪种授权方式。
416.s996，基于上述两种可能的实现方式，nfc根据最终的授权方式确定是否发起获取授权令牌token的流程。具体实现方式参见上述步骤s691，为了简洁，此处不再赘述。
417.作为示例而非限定，通过sepp#b确定最终授权方式。示例性的，基于上述方法900中，在步骤s983之后，sepp#a向sepp#b发送plmn id1及其对应的plmn id1支持的授权方式。然后，sepp#b根据接收到的plmn id1对应授权方式和plmn id2对应授权方式，确定最终授权方式。并将最终的授权方式通过sepp#a和nrf#a发送给nfc。其中，具体的实现步骤与上述方法900中步骤s981至步骤s995类似。为了简洁，此处不再赘述。
418.特别地，上述提供的几种实现方式，nf发现流程中，nrf会将nfp的nfprofile中的信息发送给nfc。其中，nfprofile的nf service消息中可能会携带oauth2required指示信息，该指示信息表示nfc需要执行oauth授权方式。上述图6中方法600至图9中方法900均不考虑该oauth2required指示的方式，即忽略此指示信息。主要通过配置对端授权方式或者配置本端授权方式，完成服务消费功能网元和服务提供功能网元之间的授权机制的协商，进而保证不同nf之间的业务访问正常进行。
419.图10是适用本技术实施例的授权机制协商方法的一例示意图，考虑oauth2required指示的方式，并对oauth2required做扩展。当前oauth2required指示信息需要oauth的认证方式。减少了不必要的协商流程，完成授权策略的确定。如图10所示，包括服务消费功能网元nfc、网络存储功能网元nrf#1、网络存储功能网元nrf#2和服务提供功能网元nfp，具体实现步骤1000包括：
420.s1010，服务消费功能网元(例如，nfc)向nrf#1发送发现请求消息；对应的，nrf#1接收来自nfc的发现请求消息。
421.其中，该发现请求消息包括plmn id2，该发现请求消息用于请求确定访问plmn id2对应网络的授权方式。
422.可选地，该发现请求消息还包括plmn id1、nfc对应的其他参数和期望访问的nfp对应的其他参数。
423.需要说明的是，plmn id1为nfc所在网络的标识信息，plmn id2为nfc希望进行业务访问的服务提供功能nfp网元对应网络的标识信息。示例性的，该nfp可以为会话管理功能smf网元，或者策略控制功能pcf网元等。
424.s1020，nrf#1向nrf#2转发该发现请求消息；对应的，nrf#2接收来自nrf#1的发现请求消息。
425.示例性地，该发现请求消息可以包括以下参数中的一个或多个：plmn id1、plmn id2、nfc对应的其他参数和期望访问的nfp对应的其他参数。
426.可选地，该发现请求消息可以不包括plmn id1、plmn id2、nfc对应的其他参数和期望访问的nfp对应的其他参数。在这种情况下，nrf#1在向nrf#2发送发现请求消息时，可以先经过sepp#1转发至sepp#2，再发送至nrf#2。此时，sepp#2可以根据与sepp#1之间协商的n32-f context中远端plmn id信息确定plmn id1，或者根据sepp#1与sepp#2之间的连接确定plmn id1，并将plmn id1发送至nrf#2。
427.其中，上述步骤s1010和s1020中，plmn id1对应的其他参数和plmn id2对应的其他参数可以为nfc和nfp的网络业务类型，发现请求消息的名称可以为已有的服务名称，例如nnrf_nfdiscovery_request，也可以为新定义的服务名称，本技术对此不作限定。
428.s1030，nrf#2根据发现请求消息确定nfp的nfprofile信息。
429.其中，nfprofile信息中包括oauth2required。
430.s1040-s1050，nrf#2通过nrf#1向nfc发送发现响应消息；对应的，nfc接收来自nrf#2的发现响应消息。
431.其中，该发现响应消息包括指示信息#a，例如oauth2required。该指示信息#a可以携带在发现响应消息的有效载荷(payload)或头(header)中，例如http header中。
432.示例性的，发现响应消息中已有header可以有1个或多个，可以在已有的一个或多个header中新增指示信息，用于指示最终的授权的方式；或者在发现响应消息中新增一个header，用于携带最终的授权方式信息。
433.可选地，该发现响应消息可以包括以下参数中的一个或多个：期望访问的nfp对应的其他参数。
434.其中，发现响应消息的名称可以为已有的服务名称，例如nnrf_nfdiscovery_response；也可以为新定义的服务名称，本技术对此不作限定。
435.s1060，nfc根据接收的oauth2required指示信息，确定是否发起获取token的流程。
436.一种可能的实现方式：
437.将oauth2required其扩充为3种值，preferred，required，not needed。
438.nfc接收到oauth2required之后，分为以下三种处理方式：
439.(1)若required，则执行oauth授权；
440.(2)若preferred，倾向于执行oauth授权；
441.(3)若not needed，则执行静态授权。
442.另一种可能的实现方式：
443.将oauth2required其扩充为2种值，preferred，not needed。
444.nfc接收到oauth2required之后，分为以下三种处理方式：
445.(1)nfc所在网络支持oauth授权和静态授权方式
446.若required，确定执行oauth授权请求；
447.若preferred，根据本地策略确定是否执行oauth授权请求；
448.若not needed，则执行静态授权方式。
449.(2)nfc所在网络仅支持静态授权
450.若preferred或not needed，则执行静态授权方式；
451.若required，发生冲突，采用如下的处理方式。
452.(3)nfc所在网络仅支持oauth授权
453.若required，确定执行oauth授权请求；
454.若preferred，确定执行oauth授权请求；
455.若not needed，则执行静态授权方式。发生冲突，采用如下的处理方式。
456.综上所述，当nfc所在网络支持oauth授权方式，若oauth2required指示为required，则nfc执行oauth授权请求，向nrf发送获取授权令牌token的流程；若oauth2required指示preferred，nfc根据本地策略确定是否执行oauth授权请求；若oauth2required指示not needed，则执行静态授权方式。当nfc所在网络不支持oauth授权方式，若oauth2required指示为required，则nfc向nrf#1发送拒绝消息。可选地，这里拒绝消息可以携带拒绝原因值，用于指示nfc不支持oauth2required指示的授权方式。
457.作为示例而非限定，如果nrf#2或者nrf#1确定的最终授权方式与上述步骤s1030中确定的nfprofile中oauth2required指示发生冲突，那么以最终授权的方式结果为准；同时发送通知消息至nfp。
458.在本技术实施例中，上述方法500/600/700/800/900中，授权策略的确定均未考虑nfp的nfprofile中携带的oauth2required指示信息。如果考虑该oauth2required指示信息的同时，nrf或sepp确定的最终授权方式与oauth2required指示的授权方式不一致，一般以网元间协商的最终授权方式为准。此时，nfc，或者nrf#1，或者nrf#2可以向nfp发送通知消息，即：
459.s1071-s1073，nfc通过nrf#1和nrf#2向nfp发送通知消息；对应的，nfp接收来自nfc的通知消息。
460.可选地，nfc向nrf#1发送拒绝消息，使得nrf#1确定oauth2required中指示的授权方式nfc不支持。
461.可选地，nrf#1根据之前实施例确定最终授权方式与oauth2required指示不一致，或根据接收到nfc发送的拒绝消息，发送不匹配的通知消息至nrf#2。
462.可选地，nrf#2根据之前实施例确定最终授权方式与oauth2required指示不一致，或根据接收到nrf#1发送的拒绝消息。
463.其中，该通知消息包括nfc id和plmn id1，nfc或者plmn id1对应授权方式的至少一项，以使nfp未来接收来自nfc id和/或plmn id1对应网络nf的业务请求，执行基于nfc或者plmn id1对应授权方式的授权，例如静态授权；当nfp接收到nfc发送的服务请求service request，其中携带nfc id和/或plmn id1，nfp根据此nfc id和/或plmn id1确定采用基于
nfc或者plmn id1对应授权方式的执行校验，则执行授权流程。例如，nfp的oauth2required指示为需要oauth授权，通过此通知消息使得nfp接收到nfc id和/或plmn id1也会允许采用静态授权方式。
464.可选的，上述通知消息也可以不携带nfc或者plmn id1对应授权方式，此时nfp接收来自nfc id和/或plmn id1对应网络nf的业务请求，执行与oauth2required中指示授权方式相反的授权方式。例如若oauth2required指示oauth，则接受静态授权；若oauth2required指示静态授权，则接受oauth授权。
465.s1080，nfc向nfp发送服务请求消息；对应的，nfp接收来自nfc的服务请求消息。
466.其中，该服务请求消息包括nfc id和/或plmn id1，以使nfp未来接收来自nfc id对应的业务请求，执行静态授权；当nfp接收到nfc发送的service request，其中携带nfc id和/或plmn id1。nfp根据此nfc id和/或plmn id1确定采用静态授权的执行校验，则执行静态授权流程。
467.综上所述，在上述实施例中，首先nfc通过向nrf或sepp发送请求消息，用于请求获得访问nfp最终的授权方式，该请求消息中包括nfc希望访问的nfp所在网络标识plmn id2。其中，nrf或sepp配置对端的授权方式，即plmn id2的授权方式。nrf或sepp根据本端plmn id1的授权方式和配置的plmn id2的授权方式确定的最终的授权方式，并发送给nfc。nfc基于最终的授权方式确定最终的授权执行方式。即如果最终授权方式为static就直接访问nfp；若授权方式为oauth，则向nrf发起token请求，并携带该token访问nfp。或者增加nfc和nfp之间的nrf协商或sepp协商，确定最终的授权方式。又或者扩展oauth2required，减少不必要的协商流程，完成授权策略的确定，使得服务消费功能网元nfc获得访问服务提供功能网元nfp的授权方式，进而解决授权冲突的问题，保证业务访问的正常进行。
468.在本技术实施例中，将最终授权方式、oauth2required等参数携带在header中能够不影响payload的内容，可以更好地让接收者识别header中携带的信息。
469.在本技术实施例中，以上述plmn id作为漫游场景下域标识进行了描述。应理解，本技术同时也适用于其他域和域标识的非漫游场景，例如运营商内包括多个scp域，scp域标识；或者运营商内包括多个nrf域，nrf域标识，或者运营商内包括多个安全域，安全域标识，或者运营商内包括多个nf set域，nf set域标识，等等不做限制。上述流程可以将plmnid替换为上述其他域标识。另外，本技术实施例中提到了nrf和sepp两个实体，其他区分不同域管理的功能网元，也可以替换上述nrf或者sepp网元进行授权机制的协商和确定。
470.需要说明的是，本技术对于服务消息的名称不做限制。
471.上文结合图5至图10，详细描述了本技术实施例提供的网元间授权机制协商的方法侧实施例，下面将结合图11至图16，详细描述本技术的网元间授权机制协商的装置侧实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
472.根据前述方法，图11是适用于本技术实施例的通信装置10的示意图。可以理解的是，该通信装置10可以是网络设备(例如，nrf或sepp)。如图11所示，该通信装置10包括：收发单元11和处理单元12。
473.一种可能的实现方式，该处理单元22用于确定第一授权方式和第二授权方式，第一授权方式是服务消费功能网元所属网络对应的授权方式，第二授权方式是服务提供功能
网元所属网络对应的授权方式；该处理单元22还用于根据第一授权方式和第二授权方式确定第三授权方式，第三授权方式是访问服务提供功能网元的授权方式；该收发单元21用于发送第三授权方式。
474.另一种可能的实现方式，该处理单元22用于确定第一功能网元所属网络对应的授权方式；该收发单元21用于发送请求消息，请求消息用于请求获取访问第二功能网元的授权方式，请求消息包括第一功能网元所属网络对应的授权方式；该收发单元21还用于接收访问第二功能网元的授权方式，访问第二功能网元的授权方式是根据第一功能网元所属网络对应的授权方式和第二功能网元所属网络对应的授权方式确定的；该收发单元21还用于发送问第二功能网元的授权方式。
475.在该另一种可能的实现方式中，该收发单元21还用于接收请求消息，请求消息用于请求获取访问第二功能网元的授权方式，请求消息包括第一功能网元所属网络对应的授权方式；该处理单元22还用于确定第二功能网元所属网络对应的授权方式；该处理单元22还用于根据第一功能网元所属网络对应的授权方式和第二功能网元所属网络对应的授权方式确定访问第二功能网元的授权方式；该收发单元21发送访问第二功能网元的授权方式。
476.又一种可能的实现方式，该收发单元21用于发送请求消息，请求消息包括获取第二功能网元所属网络对应的授权方式的指示信息；该收发单元21还用于接收第二功能网元所属网络对应的授权方式；该处理单元22用于根据第二功能网元所属网络对应的授权方式和第一功能网元所属网络对应的授权方式确定访问第二功能网元的授权方式；该收发单元21还用于发送访问第二功能网元的授权方式。
477.应理解，通信装置10可以对应于根据本技术实施例的方法500/600/700/800/900/1000中的网络设备(例如，nrf或sepp)，该通信装置10可以包括用于执行图5/图6/图7/图8/图9/图10中网络设备执行的方法的模块(或单元)。并且，该通信装置10中的各模块(或单元)和上述其他操作和/或功能分别为了实现方法500/600/700/800/900/1000的相应流程。
478.应理解，图11示例的装置10的结构仅为一种可能的形态，而不应对本技术实施例构成任何限定。本技术并不排除未来可能出现的其他形态的网络设备的可能。
479.应理解，根据本技术实施例的通信装置10可对应于前述方法实施例的网络设备(例如，nrf或sepp)，并且通信装置10中的各个模块(或单元)的上述和其它管理操作和/或功能分别为了实现前述各个方法的相应步骤，因此也可以实现前述方法实施例中的有益效果。
480.还应理解，本技术实施例中的处理模块(或单元)可以由处理器实现，收发模块(或单元)可以由收发器实现。
481.根据前述方法，图12是适用于本技术实施例的通信装置20的示意图。可以理解的是，该通信装置20可以是网络设备(例如，nfc)。如图12所示，该通信装置20包括：收发单元21和处理单元22。
482.一种可能的实现方式，该收发单元11用于接收第三授权方式，第三授权方式是访问服务提供功能网元的授权方式，第三授权方式是根据第一授权方式和第二授权方式确定的，第一授权方式是服务消费功能网元所属网络对应的授权方式，第二授权方式是服务提供功能网元所属网络对应的授权方式；该处理单元12用于根据第三授权方式向服务提供功
能网元请求第一服务。
483.另一种可能的实现方式，该收发单元11用于接收授权指示信息，授权指示信息用于确定访问服务提供功能网元的授权方式，授权指示信息为多个指示信息中的一个，多个指示信息包括第一指示信息和第二指示信息，第一指示信息用于指示静态授权方式，第二指示信息用于指示在静态授权方式和开放授权方式中优先使用开放授权方式；该处理单元12用于根据授权指示信息确定访问服务提供功能网元的授权方式；该处理单元12还用于根据访问服务提供功能网元的授权方式向服务提供功能网元请求第二服务。
484.应理解，通信装置20可以对应于根据本技术实施例的方法500/600/700/800/900/1000中的网络设备(例如，nfc)，该通信装置20可以包括用于执行图5/图6/图7/图8/图9/图10中网络设备(例如，nfc)执行的方法的模块(或单元)。并且，该通信装置20中的各模块(或单元)和上述其他操作和/或功能分别为了实现方法500/600/700/800/900/1000的相应流程。
485.应理解，图12示例的装置20的结构仅为一种可能的形态，而不应对本技术实施例构成任何限定。本技术并不排除未来可能出现的其他形态的网络设备的可能。
486.应理解，根据本技术实施例的通信装置20可对应于前述方法实施例的网络设备(例如，nfc)，并且通信装置20中的各个模块(或单元)的上述和其它管理操作和/或功能分别为了实现前述各个方法的相应步骤，因此也可以实现前述方法实施例中的有益效果。
487.还应理解，本技术实施例中的处理模块(或单元)可以由处理器实现，收发模块(或单元)可以由收发器实现。
488.根据前述方法，图13是适用于本技术实施例的通信装置30的示意图。可以理解的是，该通信装置30可以是网络设备(例如，nrf2)。如图13所示，该通信装置30包括：收发单元31和处理单元32。
489.示例地，该处理单元32用于确定访问服务提供功能网元的授权方式的授权指示信息，授权指示信息为多个指示信息中的一个，多个指示信息包括第一指示信息和第二指示信息，第一指示信息用于指示静态授权方式，第二指示信息用于指示在静态授权方式和开放授权方式中优先使用开放授权方式；该收发单元31用于发送授权指示信息。
490.应理解，通信装置30可以对应于根据本技术实施例的方法500/600/700/800/900/1000中的网络设备(例如，nrf2)，该通信装置30可以包括用于执行图5/图6/图7/图8/图9/图10中网络设备(例如，nrf2)执行的方法的模块。并且，该通信装置10中的各模块和上述其他操作和/或功能分别为了实现方法500/600/700/800/900/1000的相应流程。
491.应理解，图13示例的装置30的结构仅为一种可能的形态，而不应对本技术实施例构成任何限定。本技术并不排除未来可能出现的其他形态的网络设备的可能。
492.应理解，根据本技术实施例的通信装置30可对应于前述方法实施例的网络设备(例如，nrf2)，并且通信装置30中的各个模块(或单元)的上述和其它管理操作和/或功能分别为了实现前述各个方法的相应步骤，因此也可以实现前述方法实施例中的有益效果。
493.还应理解，本技术实施例中的处理模块(或单元)可以由处理器实现，收发模块(或单元)可以由收发器实现。
494.根据前述方法，图14为本技术实施例提供的通信装置(也可以称为网络设备)40的示意图，如图14所示，该装置40可以为网络设备(例如，nrf或sepp)，也可以为芯片或电路，
比如可设置于网络设备的芯片或电路。
495.该装置40可以包括处理器41(即，处理单元的一例)和存储器42。该存储器42用于存储指令，该处理器41用于执行该存储器42存储的指令，以使该装置40实现上述方法中网络设备(例如，nrf或sepp)执行的步骤。
496.可选地，该装置40还可以包括输入口43(即，通信单元的一例)和输出口44(即，通信单元的另一例)。应理解，该处理器41、存储器42、输入口43和输出口44可以通过内部连接通路互相通信，传递控制和/或数据信号。
497.该存储器42用于存储计算机程序，该处理器41可以用于从该存储器42中调用并运行该计算计程序，以控制输入口43接收信号，控制输出口44发送信号，完成上述方法中网络设备的步骤。
498.该存储器42可以集成在处理器41中，也可以与处理器41分开设置。
499.可选地，若该装置40为网络设备，该输入口43为接收器，该输出口44为发送器。其中，接收器和发送器可以为相同或者不同的物理实体。为相同的物理实体时，可以统称为收发器。
500.可选地，若该装置40为芯片或电路，该输入口43为输入接口，该输出口44为输出接口。
501.作为一种实现方式，输入口43和输出口44的功能可以考虑通过收发电路或者收发的专用芯片实现。处理器41可以考虑通过专用处理芯片、处理电路、处理器或者通用芯片实现。
502.作为另一种实现方式，可以考虑使用通用计算机的方式来实现本技术实施例提供的网络设备。即将实现处理器41、输入口43和输出口44功能的程序代码存储在存储器42中，通用处理器通过执行存储器42中的代码来实现处理器41、输入口43和输出口44的功能。
503.在本技术实施例中，该处理器41用于确定第一授权方式和第二授权方式，第一授权方式是服务消费功能网元所属网络对应的授权方式，第二授权方式是服务提供功能网元所属网络对应的授权方式；
504.该处理器41还用于根据第一授权方式和第二授权方式确定第三授权方式，第三授权方式是访问服务提供功能网元的授权方式；该输出口44用于发送第三授权方式。
505.一种可能的实现方式，该处理器41用于确定第一功能网元所属网络对应的授权方式；该输出口44用于发送请求消息，请求消息用于请求获取访问第二功能网元的授权方式，请求消息包括第一功能网元所属网络对应的授权方式；该输入口43用于接收访问第二功能网元的授权方式，访问第二功能网元的授权方式是根据第一功能网元所属网络对应的授权方式和第二功能网元所属网络对应的授权方式确定的；该输出口44还用于发送问第二功能网元的授权方式。
506.在该一种可能的实现方式中，该该输入口43还用于接收请求消息，请求消息用于请求获取访问第二功能网元的授权方式，请求消息包括第一功能网元所属网络对应的授权方式；该该处理器41还用于确定第二功能网元所属网络对应的授权方式；该处理器41还用于根据第一功能网元所属网络对应的授权方式和第二功能网元所属网络对应的授权方式确定访问第二功能网元的授权方式；该输出口44还用于发送访问第二功能网元的授权方式。
507.又一种可能的实现方式，该输出口44用于发送请求消息，请求消息包括获取第二功能网元所属网络对应的授权方式的指示信息；该输入口43用于接收第二功能网元所属网络对应的授权方式；该处理器41用于根据第二功能网元所属网络对应的授权方式和第一功能网元所属网络对应的授权方式确定访问第二功能网元的授权方式；该该输出口44还用于发送访问第二功能网元的授权方式。
508.可选地，该装置40配置在或本身即为网络设备，例如nrf或sepp。
509.其中，以上列举的装置40中各模块或单元的功能和动作仅为示例性说明，装置40中各模块或单元可以用于执行上述方法500/600/700/800/900/1000中由网络设备(例如，nrf或sepp)所执行的各动作或处理过程，这里，为了避免赘述，省略其详细说明。
510.该装置40所涉及的与本技术实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于这些内容的描述，此处不做赘述。
511.在一种可能的实施方式中，随着片上系统(system-on-chip，soc)技术的发展，装置30的全部或者部分功能由soc技术实现，例如由一网络设备功能芯片实现，该网络设备功能芯片集成了处理器、存储器、通信接口等器件，网络设备相关功能的程序存储在存储器中，由处理器执行程序以实现的相关功能。可选地，该网络设备功能芯片也能够读取该芯片外部的存储器以实现的相关功能。
512.应理解，图14示例的装置40的结构仅为一种可能的形态，而不应对本技术实施例构成任何限定。本技术并不排除未来可能出现的其他形态的结构的可能。
513.根据前述方法，图15为本技术实施例提供的通信装置(也可以称为网络设备)50的示意图，如图15所示，该装置50可以为网络设备(例如，nfc)，也可以为芯片或电路，比如可设置于网络设备的芯片或电路。
514.该装置50可以包括处理器51(即，处理单元的一例)和存储器52。该存储器52用于存储指令，该处理器51用于执行该存储器52存储的指令，以使该装置50实现上述方法中网络设备(例如，nfc)执行的步骤。
515.可选地，该装置50还可以包括输入口53(即，通信单元的一例)和输出口54(即，通信单元的另一例)。应理解，该处理器51、存储器52、输入口53和输出口54可以通过内部连接通路互相通信，传递控制和/或数据信号。
516.该存储器52用于存储计算机程序，该处理器51可以用于从该存储器52中调用并运行该计算计程序，以控制输入口53接收信号，控制输出口54发送信号，完成上述方法中网络设备的步骤。
517.该存储器52可以集成在处理器51中，也可以与处理器51分开设置。
518.可选地，若该装置50为网络设备，该输入口53为接收器，该输出口54为发送器。其中，接收器和发送器可以为相同或者不同的物理实体。为相同的物理实体时，可以统称为收发器。
519.可选地，若该装置50为芯片或电路，该输入口53为输入接口，该输出口54为输出接口。
520.作为一种实现方式，输入口53和输出口54的功能可以考虑通过收发电路或者收发的专用芯片实现。处理器51可以考虑通过专用处理芯片、处理电路、处理器或者通用芯片实现。
521.作为另一种实现方式，可以考虑使用通用计算机的方式来实现本技术实施例提供的网络设备。即将实现处理器51、输入口53和输出口54功能的程序代码存储在存储器52中，通用处理器通过执行存储器52中的代码来实现处理器51、输入口53和输出口54的功能。
522.在本技术实施例中，该输入口53用于接收第三授权方式，第三授权方式是访问服务提供功能网元的授权方式，第三授权方式是根据第一授权方式和第二授权方式确定的，第一授权方式是服务消费功能网元所属网络对应的授权方式，第二授权方式是服务提供功能网元所属网络对应的授权方式；该处理器51用于根据第三授权方式向服务提供功能网元请求第一服务。
523.一种可能的实现方式，该输入口53用于接收授权指示信息，授权指示信息用于确定访问服务提供功能网元的授权方式，授权指示信息为多个指示信息中的一个，多个指示信息包括第一指示信息和第二指示信息，第一指示信息用于指示静态授权方式，第二指示信息用于指示在静态授权方式和开放授权方式中优先使用开放授权方式；该处理器51用于根据授权指示信息确定访问服务提供功能网元的授权方式；该处理器51还用于根据访问服务提供功能网元的授权方式向服务提供功能网元请求第二服务。
524.可选地，该装置50配置在或本身即为网络设备，例如nfc。
525.其中，以上列举的装置50中各模块或单元的功能和动作仅为示例性说明，装置50中各模块或单元可以用于执行上述方法500/600/700/800/900/1000中由网络设备(例如，nfc)所执行的各动作或处理过程，这里，为了避免赘述，省略其详细说明。
526.该装置50所涉及的与本技术实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于这些内容的描述，此处不做赘述。
527.在一种可能的实施方式中，随着片上系统soc技术的发展，装置50的全部或者部分功能由soc技术实现，例如由一网络设备功能芯片实现，该网络设备功能芯片集成了处理器、存储器、通信接口等器件，网络设备相关功能的程序存储在存储器中，由处理器执行程序以实现的相关功能。可选地，该网络设备功能芯片也能够读取该芯片外部的存储器以实现的相关功能。
528.应理解，图15示例的装置50的结构仅为一种可能的形态，而不应对本技术实施例构成任何限定。本技术并不排除未来可能出现的其他形态的结构的可能。
529.根据前述方法，图16为本技术实施例提供的通信装置(也可以称为网络设备)60的示意图，如图16所示，该装置60可以为网络设备(例如，nrf2)，也可以为芯片或电路，比如可设置于网络设备的芯片或电路。
530.该装置60可以包括处理器61(即，处理单元的一例)和存储器62。该存储器62用于存储指令，该处理器61用于执行该存储器62存储的指令，以使该装置60实现上述方法中网络设备(例如，nrf2)执行的步骤。
531.可选地，该装置60还可以包括输入口63(即，通信单元的一例)和输出口64(即，通信单元的另一例)。应理解，该处理器61、存储器62、输入口63和输出口64可以通过内部连接通路互相通信，传递控制和/或数据信号。
532.该存储器62用于存储计算机程序，该处理器61可以用于从该存储器62中调用并运行该计算计程序，以控制输入口63接收信号，控制输出口64发送信号，完成上述方法中网络设备的步骤。
533.该存储器62可以集成在处理器61中，也可以与处理器61分开设置。
534.可选地，若该装置60为网络设备，该输入口63为接收器，该输出口64为发送器。其中，接收器和发送器可以为相同或者不同的物理实体。为相同的物理实体时，可以统称为收发器。
535.可选地，若该装置60为芯片或电路，该输入口63为输入接口，该输出口64为输出接口。
536.作为一种实现方式，输入口63和输出口64的功能可以考虑通过收发电路或者收发的专用芯片实现。处理器61可以考虑通过专用处理芯片、处理电路、处理器或者通用芯片实现。
537.作为另一种实现方式，可以考虑使用通用计算机的方式来实现本技术实施例提供的网络设备。即将实现处理器61、输入口63和输出口64功能的程序代码存储在存储器62中，通用处理器通过执行存储器62中的代码来实现处理器61、输入口63和输出口64的功能。
538.在本技术实施例中，该处理器61用于确定访问服务提供功能网元的授权方式的授权指示信息，授权指示信息为多个指示信息中的一个，多个指示信息包括第一指示信息和第二指示信息，第一指示信息用于指示静态授权方式，第二指示信息用于指示在静态授权方式和开放授权方式中优先使用开放授权方式；该输出口64用于发送授权指示信息。
539.可选地，该装置60配置在或本身即为网络设备，例如nrf2。
540.其中，以上列举的装置60中各模块或单元的功能和动作仅为示例性说明，装置60中各模块或单元可以用于执行上述方法500/600/700/800/900/1000中由网络设备(例如，nrf2)所执行的各动作或处理过程，这里，为了避免赘述，省略其详细说明。
541.该装置60所涉及的与本技术实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于这些内容的描述，此处不做赘述。
542.在一种可能的实施方式中，随着片上系统soc技术的发展，装置60的全部或者部分功能由soc技术实现，例如由一网络设备功能芯片实现，该网络设备功能芯片集成了处理器、存储器、通信接口等器件，网络设备相关功能的程序存储在存储器中，由处理器执行程序以实现的相关功能。可选地，该网络设备功能芯片也能够读取该芯片外部的存储器以实现的相关功能。
543.应理解，图16示例的装置60的结构仅为一种可能的形态，而不应对本技术实施例构成任何限定。本技术并不排除未来可能出现的其他形态的结构的可能。
544.应理解，本技术实施例中，该处理器可以为中央处理单元(central processing unit，cpu)，该处理器还可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
545.还应理解，本技术实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，rom)、可编程只读存储器(programmable rom，prom)、可擦除可编程只读存储器(erasable prom，eprom)、电可擦除可编程只读存储器(electrically eprom，eeprom)或
闪存。易失性存储器可以是随机存取存储器(random access memory，ram)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的ram可用，例如静态随机存取存储器(static ram，sram)、动态随机存取存储器(dram)、同步动态随机存取存储器(synchronous dram，sdram)、双倍数据速率同步动态随机存取存储器(double data rate sdram，ddr sdram)、增强型同步动态随机存取存储器(enhanced sdram，esdram)、同步连接动态随机存取存储器(synchlink dram，sldram)和直接内存总线随机存取存储器(direct rambus ram，dr ram)。
546.上述实施例，可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令或计算机程序。在计算机上加载或执行该计算机指令或计算机程序时，全部或部分地产生按照本技术实施例该的流程或功能。该计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质。半导体介质可以是固态硬盘。
547.应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
548.应理解，在本技术的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
549.还应理解，本文提及的“第一”和“第二”等等仅仅是为了更清楚地表述本技术的技术方案而加以区分，不应对本技术构成任何限定。
550.在本说明书中使用的术语“部件”、“模块”、“系统”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如，部件可以是但不限于，在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。通过图示，在计算设备上运行的应用和计算设备都可以是部件。一个或多个部件可驻留在进程和/或执行线程中，部件可位于一个计算机上和/或分布在2个或更多个计算机之间。此外，这些部件可从在上面存储有各种数据结构的各种计算机可读介质执行。部件可例如根据具有一个或多个数据分组(例如来自与本地系统、分布式系统和/或网络间的另一部件交互的二个部件的数据，例如通过信号与其它系统交互的互联网)的信号通过本地和/或远程进程来通信。
551.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
552.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
553.在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
554.作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
555.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
556.该功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
557.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。

技术特征：

1.一种通信方法，其特征在于，包括：确定第一授权方式和第二授权方式，所述第一授权方式是服务消费功能网元所属网络对应的授权方式，所述第二授权方式是服务提供功能网元所属网络对应的授权方式；根据所述第一授权方式和所述第二授权方式确定第三授权方式，所述第三授权方式是访问服务提供功能网元的授权方式；发送所述第三授权方式。2.根据权利要求1所述的方法，其特征在于，所述确定第二授权方式包括：接收第一请求消息，所述第一请求消息包括所述服务提供功能网元所属网络的标识信息；根据所述服务提供功能网元所属网络的标识信息确定所述第二授权方式；和/或，所述确定第一授权方式包括：获取所述服务消费功能网元所属网络的标识信息；根据所述服务消费功能网元所属网络的标识信息确定所述第一授权方式。3.根据权利要求1或2所述的方法，其特征在于，所述第三授权方式为开放授权方式，所述方法还包括：接收第二请求消息，所述第二请求消息用于请求获取第一令牌，所述第一令牌用于授权所述服务消费功能网元访问所述第一服务；确定所述第一令牌；发送所述第一令牌。4.根据权利要求1至3中任一项所述的方法，其特征在于，所述根据所述第一授权方式和所述第二授权方式确定第三授权方式，包括：根据所述第一授权方式和所述第二授权方式的共有授权方式确定所述第三授权方式；当所述共有授权方式为所述静态授权方式或所述开放授权方式，确定所述静态授权方式或所述开放授权方式为所述第三授权方式；当所述共有授权方式为所述静态授权方式和所述开放授权方式，根据本地策略确定所述第三授权方式，或者确定所述开放授权方式为所述第三授权方式。5.一种通信方法，其特征在于，包括：接收第三授权方式，所述第三授权方式是访问服务提供功能网元的授权方式，所述第三授权方式是根据第一授权方式和第二授权方式确定的，所述第一授权方式是服务消费功能网元所属网络对应的授权方式，所述第二授权方式是所述服务提供功能网元所属网络对应的授权方式；根据所述第三授权方式向所述服务提供功能网元请求第一服务。6.根据权利要求5所述的方法，其特征在于，在接收所述第三授权方式之前，所述方法还包括：发送第一请求消息，所述第一请求消息用于请求获取所述第三授权方式，所述第一请求消息包括所述服务提供功能网元所属网络的标识信息。7.根据权利要求5或6所述的方法，其特征在于，所述第三授权方式为开放授权方式，所述根据所述第三授权方式向所述服务提供功能网元请求第一服务，包括：发送第二请求消息，所述第二请求消息用于请求获取第一令牌，所述第一令牌用于授
权所述服务消费功能网元访问所述第一服务；接收所述第一令牌；向所述服务提供功能网元发送用于请求所述第一服务的消息，所述用于请求所述第一服务的消息中包括所述第一令牌。8.根据权利要求5至7中任一项所述的方法，其特征在于，所述接收第三授权方式包括：从网络存储功能网元或安全边缘保护代理网元接收所述第三授权方式。9.一种网络设备，其特征在于，包括：处理单元，用于确定第一授权方式和第二授权方式，所述第一授权方式是服务消费功能网元所属网络对应的授权方式，所述第二授权方式是服务提供功能网元所属网络对应的授权方式；所述处理单元，还用于根据所述第一授权方式和所述第二授权方式确定第三授权方式，所述第三授权方式是访问服务提供功能网元的授权方式；收发单元，用于发送所述第三授权方式。10.根据权利要求9所述的网络设备，其特征在于，所述收发单元，还用于接收第一请求消息，所述第一请求消息包括所述服务提供功能网元所属网络的标识信息；所述处理单元，还用于根据所述服务提供功能网元所属网络的标识信息确定所述第二授权方式；和/或，所述处理单元，还用于：获取所述服务消费功能网元所属网络的标识信息；根据所述服务消费功能网元所属网络的标识信息确定所述第一授权方式。11.根据权利要求9或10所述的网络设备，其特征在于，所述第三授权方式为开放授权方式，所述收发单元，还用于接收第二请求消息，所述第二请求消息用于请求获取第一令牌，所述第一令牌用于授权所述服务消费功能网元访问所述第一服务；所述处理单元，还用于确定所述第一令牌；所述收发单元，还用于发送所述第一令牌。12.根据权利要求9至11中任一项所述的网络设备，其特征在于，所述处理单元，还用于：根据所述第一授权方式和所述第二授权方式的共有授权方式确定所述第三授权方式；当所述共有授权方式为所述静态授权方式或所述开放授权方式，确定所述静态授权方式或所述开放授权方式为所述第三授权方式；当所述共有授权方式为所述静态授权方式和所述开放授权方式，根据本地策略确定所述第三授权方式，或者确定所述开放授权方式为所述第三授权方式。13.一种网络设备，其特征在于，包括：收发单元，用于接收第三授权方式，所述第三授权方式是访问服务提供功能网元的授权方式，所述第三授权方式是根据第一授权方式和第二授权方式确定的，所述第一授权方式是服务消费功能网元所属网络对应的授权方式，所述第二授权方式是所述服务提供功能网元所属网络对应的授权方式；
处理单元，用于根据所述第三授权方式向所述服务提供功能网元请求第一服务。14.根据权利要求13所述的网络设备，其特征在于，所述收发单元，在接收所述第三授权方式之前，还用于发送第一请求消息，所述第一请求消息用于请求获取所述第三授权方式，所述第一请求消息包括所述服务提供功能网元所属网络的标识信息。15.根据权利要求13或14所述的网络设备，其特征在于，所述收发单元，还用于发送第二请求消息，所述第二请求消息用于请求获取第一令牌，所述第一令牌用于授权所述服务消费功能网元访问所述第一服务；所述收发单元，还用于接收所述第一令牌；所述处理单元，还用于向所述服务提供功能网元发送用于请求所述第一服务的消息，所述用于请求所述第一服务的消息中包括所述第一令牌。16.根据权利要求13至15中任一项所述的网络设备，其特征在于，所述收发单元，还用于从第一网络存储功能网元或第一安全边缘保护代理网元接收所述第三授权方式。17.一种芯片系统，其特征在于，包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有所述芯片系统的网络设备执行如权利要求1至8中任意一项所述的方法。18.一种计算机程序产品，其特征在于，所述计算机程序产品在计算机上执行时，使得所述计算机执行如权利要求1至4中任一项所述的方法；或者使得所述计算机执行如权利要求5至8中任一项所述的方法。19.一种计算机可读存储介质，其特征在于，包括：所述计算机可读存储介质上存储有计算机程序，当所述计算机程序运行时，使得所述计算机执行如权利要求1至4中任一项所述的方法；或者使得所述计算机执行如权利要求5至8中任一项所述的方法。

技术总结

本申请提供了一种通信方法和网络设备，该通信方法包括：确定第二授权方式和第三授权方式，第二授权方式是服务消费功能网元所属网络对应的授权方式，第三授权方式是服务提供功能网元所属网络对应的授权方式；根据第二授权方式和第三授权方式确定第一授权方式，第一授权方式是访问服务提供功能网元的授权方式；发送该第三授权方式。本申请实施例的通信方法和网络设备，能够完成不同网络功能网元之间授权机制的协商，使得服务消费功能网元获得业务访问的授权方式，进而解决授权冲突的问题。进而解决授权冲突的问题。进而解决授权冲突的问题。