Authorization of application functions for policy management

Abstract

An Application Function (AF) or Network Exposure Function (NEF) requests an authorization token from a Network Repository Function (NRF) for each AI / ML loop to access a Policy Control Function (PCF), and receives a token that authorizes the AF to manage Quality of Service (QoS) policies for the next AIML training loop. Upon verification of the token, the AF transmits a request to the NEF to reserve resources for the AF session. Upon authorization, the NEF transmits a discovery request message to a binding support function (BSF) to train a cyclic discovery service in the request from the AF for the next AI / ML to the PCF indicating the group of WTRUs. The BSF transmits a discovery response to the NEF, the discovery response comprising a list of PCFs serving the identified WTRU. The authorization token is then requested from the NRF for training the PCF policy management circulating on each PCF for the next AIML.

Description

[0001] Related Applications

[0002] This application claims the benefit of and priority to U.S. Provisional Application No. 63 / 501,548, filed on May 11, 2023, entitled “Authorization of Application Function for Policy Management,” and U.S. Provisional Application No. 63 / 396,438, filed on August 9, 2022, entitled “Authorization of Application Function for Policy Management,” each of which is incorporated herein by reference in its entirety. Background Art

[0003] Key issues (KI) have been identified in 3GPP TR 23.700-80 V0.3.0, clause 5.7, which recommends that the 3GPP 5G system can be enhanced to assist in collaborative application of artificial intelligence machine learning (AIML) operations in the performance of tasks such as federated learning (FL) and module distribution, which tasks include FL member selection, group performance monitoring, and allocation of sufficient network resources. It is expected that these enhancements will benefit application AIML operations at both the application function (AF) (i.e., server side) and the UE (client side).

[0004] There have been several proposals to address the above-mentioned KI, many of which suggest solutions in which the AF contacts the 5G system (5GS) to request assistance information (e.g., the aggregate bit rate of a group of UEs participating in FL operation), such as in clause 6.37 of TR 23.700-80 V0.3.0, or the AF provides new or modified 5GS parameters (e.g., new parameters that enable reservation of resources dedicated to FL operation), such as in clause 6.42 of TR 23.700-80 V0.3.0.

[0005] A solution for FL operation supported by 5GS based on AF session with required QoS provided by application server is provided in clause 6.42 of 3GPP TR 23.700-80 V0.3.0 and listed below for reference. This solution maps to KI#7 and KI#6 described in clause 5.

[0006] Joint learning between UE and application functions requires a lot of computation on both UE and AIML application functions to perform one round / iteration of FL tasks. For each iteration, the server selects the FL members (UEs) that will participate in the iteration, performs relevant configurations, downloads the global model and relevant model parameters, and then waits for the UE to return a report of the updated local model. Only when enough UEs return reports is the iteration considered successful, otherwise the iteration may be abandoned. In view of this, in order to ensure that most iterations are successful and then generate the optimal global model, that is, in order to avoid decentralized devices (devices that do not return reports in time or do not respond to configuration requests from the server), it is beneficial if 5GS can expose relevant network status / information to help application functions select FL members with the best chance for successful iteration (e.g., based on their reputation scores). The selection of devices for a given iteration is within the scope of AF. However, 5GS can help AF make intelligent decisions about FL member selection (the best chance for successful iteration within a given period).

[0007] The following are the assumptions in this solution: How to select the candidate list of UEs to participate in each iteration of federated learning is within the scope of the application function.

[0008] The following summarizes the salient features of the solution: The AF transmits a request to the NEF to reserve resources for the AF session, which includes AIML group information and AIML group performance information. The AIML group information consists of an external group ID or a list of candidate UEs selected by the AF to participate in the FL iteration, and an area of ​​interest. The AIML group performance information includes the maximum delay of the AIML group, the maximum packet loss rate in the UL, the maximum packet loss rate in the DL, the duration of the requested QoS, and the minimum number of UEs in the AIML group. If multiple UEs from the AF group are served by the same PCF, the NEF can trigger an Npcf_GroupPolicyAuthorization_Create request toward the PCF with the UE address, AF identifier, flow description, AIML group performance information, and AIML session indicator as input parameters. If the Nnef_GroupAFsessionWithQoS_Create request in step 1 includes an AIML group performance container, the NEF includes an AIML session indicator. If the PCF determines that the SMF serving the UE needs to update policy information, the PCF issues an Npcf_SMPolicyControl_UpdateNotify request with updated policy information about the PDU session. QoS flow binding should ensure that when the PCF provides the PCC rules containing AIML group capability information and AIML session indicator in the SMF, the PCC rules are bound to the new QoS flow and no other PCC rules are bound to the QoS flow.

[0009] The process 200 of the AF requesting the required QoS for the potential list of UEs selected by the AF to participate in an iteration of the joint learning is as follows: Figure 6 .42.2-1( Figure 2 ).

[0010] 1. AF transmits a request to NEF to reserve resources for the AF session using the Nnef_GroupAFsessionWithQoS_Create request message (AF identifier, flow description or external application identifier, QoS reference, DNN, S-NSSAI, AIML group information, AIML group performance information). The AIML group information consists of an external group ID or a list of candidate UEs selected by the AF to participate in the FL iteration, and an area of ​​interest. The AIML group performance information includes the minimum and maximum delay of the AIML group, the minimum and maximum packet loss rate in UL, the minimum and maximum packet loss rate in DL, the duration of the requested QoS, and the minimum number of UEs in the AIML group. The maximum requested bandwidth DL / UL is the maximum bandwidth in DL / UL for all UEs included in the AIML group information. The maximum delay of the AIML group is the maximum reporting delay acceptable to all UEs included in the AIML group information. The maximum packet loss rate in UL / DL is the maximum packet loss rate acceptable to all UEs included in the AIML group information. The duration of the requested QoS is the time when the requested QoS is required for all UEs included in the AIML group information. The minimum number of UEs in the AIML group indicates the minimum number of UEs that can provide the requested QoS for the UE list included in the AIML group information.

[0011] 2. The NEF assigns a transaction reference ID to the Nnef_GroupAFsessionWithQoS_Create request. The NEF authorizes the AF request and may apply policies to control the total amount of QoS authorized for the AF. If authorization is not granted, the NEF replies to the AF with a result value indicating authorization failure.

[0012] 3. The NEF transmits a Nbsf_Management_Discovery request to the BSF using the external group ID or UE address list in step 1 to discover the PCF serving the UE of the group indicated in the AF request. If the AF is considered to be trusted by the operator, the AF uses the Npcf_PolicyAuthorization_Create request message to interact directly with the PCF to request to reserve resources for the AF session, or transmits a Nbsf_Management_Discovery request to the BSF to discover the PCF serving the UE.

[0013] 4. The BSF performs PCF discovery based on the input provided by the NEF in step 3.

[0014] 5. The BSF transmits an Nbsf_Management_Discovery response including a list of PCFs serving the UEs indicated in the AIML group information provided by the AF. If the AF is trusted by the operator, the BSF transmits an Nbsf_Management_Discovery response including a list of PCFs associated with the UEs of the AIML group provided by the AF, where each PCF may be associated with a different UE of the indicated group.

[0015] 6. If multiple UEs from an AF group are served by the same PCF, the NEF may trigger a Npcf_GroupPolicyAuthorization_Create request towards the PCF with UE address, AF identifier, flow description, AIML group capability information, AIML session indicator as input parameters. If the Nnef_GroupAFsessionWithQoS_Create request in step 1 includes an AIML group capability container, the NEF includes the AIML session indicator.

[0016] 7. For the request received from NEF in step 6, the PCF determines whether the request is authorized, and notifies the NEF if the request is not authorized. If the request is authorized, the PCF derives the required QoS parameters based on the information provided in the AIML group capability container, and determines whether the QoS is allowed (according to the PCF configuration), and notifies the NEF of the result. When the PCF authorizes the service information from the AF, it generates the PCC rules by deriving the QoS parameters of the PCC rules based on the service information, the AIML group capability information, and also includes the AIML session indicator. If multiple UEs from the AF group are served by the same PCF, the PCF transmits an Npcf_GroupAuthorization_Create response, the result of which (success or failure) is associated with the list of UEs for which policy authorization succeeded and the reason for failure of the list of UEs for which policy authorization failed. If the AF is trusted by the operator, the PCF transmits an Npcf_GroupPolicyAuthorization_Create response message directly to the AF. If the PCF determines that the SMF serving the UE needs to update policy information, the PCF issues an Npcf_SMPolicyControl_UpdateNotify request with updated policy information about the PDU session. QoS flow binding should ensure that when the PCF provides the PCC rule containing the AIML group capability information and the AIML session indicator in the SMF, the PCC rule is bound to the new QoS flow and no other PCC rule is bound to the QoS flow. Repeat steps 6 and 7 for all PCFs identified in step 5.

[0017] 8. The NEF tracks the results from all PCFs identified in step 5 included in step 7. If the minimum UEs in the group with the requested QoS parameters were provided in step 1 and the results from all PCFs match or exceed the minimum UEs in the group with the requested QoS parameters, the NEF transmits a Nnef_GroupAFsessionWithQoS_Create response message (transaction reference ID, results, list of UEs in the AIML group allowed for the requested QoS) to the AF, where the results indicate that the request is granted. The UEs in the AIML group allowed for QoS are included in the response only if the response from the PCF to the NEF in step 7 indicates that the requested QoS for the UE is not allowed for all UEs belonging to the AIML group provided as input in step 1.

[0018] 9. The NEF shall transmit a Npcf_PolicyAuthorization_Subscribe message to the PCF to subscribe for notifications of resource allocation status. In step 8, the PCF responds with a subscription correlation ID that allows the NEF to track all subscription notifications unique to each UE.

[0019] 10. When the event conditions are met, such as the success or failure of establishing the sending resources corresponding to the QoS update, the QoS target can no longer be achieved, and the QoS monitoring parameters, the PCF transmits the Npcf_PolicyAuthorization_Notify message to the NEF to notify the event. The PCF includes the event information and the notification related information identifying the AIML group AF session. If the operator trusts the AF, the PCF directly transmits the Npcf_PolicyAuthorization_Notify message to the AF.

[0020] 11. When the NEF receives Npcf_PolicyAuthorization_Notify for all UEs whose requests were granted in step 8, the NEF transmits a Nnef_GroupAFsessionWithQoS_Notify message with the event reported by the PCF to the AF, i.e., the QoS resources with the transaction reference ID allocated for all UEs whose requests were granted in step 8.

[0021] The above process lacks fine-grained authorization control: NEF and / or AF can access all selected PCFs and / or corresponding UEs, and / or obtain information about UE operations and parameters, resulting in potential security vulnerabilities or insecure vectors for malicious attacks. In particular, AF is given broad and pervasive access, which may be inappropriate if AF is not trusted or is not under the control of the system operator. Summary of the invention

[0022] For fine-grained authorization, if the existing token can no longer be used for authorization of policy operations, the AF needs to contact the authorization server (i.e., the Network Repository Function (NRF)) to obtain an authorization token on behalf of the untrusted AF to be used by the Policy Control Function (PCF) to authorize the AF for QoS policy management requests for each FL cycle. The token gives the AF authorization to operate (e.g., create, update, delete, read, etc.) on QoS policies at a specific PCF instance within a time period applied to a group of UEs.

[0023] The NEF may contact the authorization server (i.e., NRF) to obtain an authorization token on behalf of the untrusted AF to use when requesting service access from the PCF. The PCF may verify the token and may grant a QoS policy management request to the AF for each FL cycle to authorize the AF to operate (e.g., create, update, delete, read, etc.) on the AIML QoS policy at a specific PCF for a period of time that applies to a group of UEs.

[0024] The authorization token should be fine-grained to include at least the home NRF FQDN (issuer), AF ID and UE (subject), expected PCF service name (scope), PCF instances involved in the FL cycle (additional scope), PCF FQDN (audience), expiration time (expiration), and a digital signature generated by the NRF. In this case, the AF needs to contact the Binding Support Function (BSF) to discover the PCF instances involved before contacting the NRF to request the authorization token for QoS policy operations at each PCF instance.

[0025] If the AF is considered to be trusted, the AF has the option to request a token authorized for PCF type NF (i.e., the token is valid for all PCFs). Alternatively, the AF can first contact the BSF to obtain the PCF instance, and then request a token for each PCF instance from the NRF to authorize being contacted by the AF in the FL cycle. The token will be verified by the PCF instance to authorize the AF to perform QoS policy operations in the FL cycle.

[0026] This method can be used for operations on other policies in the core network from a third-party AF. This method can be used for operations on network resources in the core network from a third-party AF, but not for authorization of operations on policies.

[0027] This method can be used for both NF and UE to request access to other network functions using the Service Based Interface (SBI) API to request service authorization using the Service Authorization Token mechanism as specified in clause 13.4.1 of 3GPP TS 33.501 V17.6.0. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate like elements, and in which:

[0029] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

[0030] Figure 1B is an example of an embodiment in which Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within an illustrated communication system;

[0031] Figure 1C is an example of an embodiment in which Figure 1A A system diagram of an example Radio Access Network (RAN) and an example Core Network (CN) used within the illustrated communication system;

[0032] Figure 1D is an example of an embodiment in which Figure 1A A system diagram of another example RAN and another example CN used within the illustrated communication system;

[0033] Figure 2 shows the process of AF request for required QoS for a potential list of UEs selected by the AF;

[0034] Figure 3 An overview of third-party AF authorization and possible solutions to network resource operation issues is shown;

[0035] Figure 4 An example process of an AF request for required QoS for a potential list of UEs selected by the AF is shown;

[0036] Figure 5 An example process of an AF request for required QoS for a potential list of UEs selected by the AF is shown;

[0037] Figure 6 An example process of a trusted AF request for required QoS for a potential list of UEs selected by the AF is shown;

[0038] Figure 7 An example process of BDT session negotiation and AF authorization using time-dependent tokens is shown;

[0039] Figure 8 An example process is shown in which a UE acts as a NF and requests service access authorization from an NRF;

[0040] Fig. 9 illustrates an example process for dynamic policy management by a network exposure function node according to some embodiments;

[0041] Fig.10 Another example process of dynamic policy management by an application function node according to some embodiments is shown; and

[0042] Fig.11 Another example process of dynamic policy management by a network repository function node according to some embodiments is shown. DETAILED DESCRIPTION

[0043] Figure 1A1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), etc.

[0044] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a station (STA)) may be configured to send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), consumer electronic devices, and devices operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0045] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an evolved Node B (eNB), a Home Node B, a Home evolved Node B, a Next Generation Node B (such as a gNode B (gNB)), a New Radio (NR) Node B, a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0046] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSC), radio network controllers (RNC), and relay nodes. Base station 114a and / or base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of a licensed spectrum and an unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to send and / or receive signals in a desired spatial direction.

[0047] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0048] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, among others. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), that may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols, such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​Uplink (UL) Packet Access (HSUPA).

[0049] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA) that may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-APro).

[0050] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology (such as NR radio access) that may establish the air interface 116 using NR.

[0051] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may together implement LTE radio access and NR radio access, for example using the dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

[0052] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0053] Figure 1A The base station 114b in may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial venues, homes, vehicles, campuses, industrial facilities, sky corridors (e.g., for use by drones), and roads. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.11) to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As Figure 1A As shown, the base station 114 b may have a direct connection to the Internet 110. Therefore, the base station 114 b may not need to access the Internet 110 via the CN 106.

[0054] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not described in detail in the specification, the CN 106 may be configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Figure 1AAlthough not shown in the figure, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0055] The CN 106 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired communication networks and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0056] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0057] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0058] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), any other type of integrated circuit (IC), state machine, etc. The processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0059] The send / receive element 122 may be configured to send a signal to a base station (e.g., base station 114a) or receive a signal from a base station via an air interface 116. For example, in one embodiment, the send / receive element 122 may be an antenna configured to send and / or receive an RF signal. In an embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, an IR, UV, or visible light signal. In another embodiment, the send / receive element 122 may be configured to send and / or receive both an RF signal and an optical signal. It should be understood that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

[0060] Although the transmit / receive element 122 Figure 1B Although depicted as a single element in the figure, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0061] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. For example, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0062] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, and a secure digital (SD) memory card, among others. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0063] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0064] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0065] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices and activity trackers, etc. The peripheral device 138 may include one or more sensors. The sensor may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geographic location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and a humidity sensor, etc.

[0066] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

[0067] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0068] The RAN 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the evolved Node-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0069] Each of the evolved Node Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, and scheduling of users in the UL and / or DL, among other things. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0070] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0071] The MME 162 may be connected to each of the evolved Node-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0072] The SGW 164 may be connected to each of the evolved Node-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during an inter-evolved Node-B handover, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0073] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0074] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers.

[0075] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communications interface with a communications network.

[0076] In a representative embodiment, the other network 112 may be a WLAN.

[0077] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and destined for the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and destined for a target outside the BSS may be transmitted to the AP to be delivered to the corresponding target. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the target STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be transmitted between the source STA and the target STA (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0078] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may send beacons on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may listen to the primary channel. If the primary channel is listened / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0079] High throughput (HT) STAs may communicate using a 40 MHz wide channel (eg, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels) to form a 40 MHz wide channel.

[0080] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and the data can be sent by the transmitter STA. At the receiver of the receiver STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0081] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0082] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (which only supports a 1MHz operating mode) is transmitting to the AP, all available bands may be considered busy even if most of the available bands remain idle.

[0083] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0084] Figure 1D1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0085] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to send signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to send wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0086] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of varying or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute time lengths over time).

[0087] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeB 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0088] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, interworking between DC, NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b and routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0089] Figure 1DThe illustrated CN 106 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although the aforementioned elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0090] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, and mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, and services for MTC access. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0091] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 106 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 106 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy implementation and QoS, and providing DL data notifications. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0092] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring, etc.

[0093] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the DNs 185a, 185b via the UPFs 184a, 184b via the N3 interfaces to the UPFs 184a, 184b and the N6 interfaces between the UPFs 184a, 184b and the local DNs 185a, 185b.

[0094] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following items may be performed by one or more simulation devices (not shown): WTRU102a to 102d, base station 114a to 114b, evolved Node B 160a to 160c, MME 162, SGW 164, PGW 166, gNB180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0095] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, one or more simulation devices may perform one or more functions or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. A simulation device may be directly coupled to another device for the purpose of testing and / or performing tests using over-the-air wireless communications.

[0096] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0097] The following abbreviations and acronyms may be used for reference:

[0098] AF Application Function

[0099] AIML Artificial Intelligence Machine Learning

[0100] DL Downlink

[0101] FL Federated Learning

[0102] NEF Network Exposure Function

[0103] NF Network Function

[0104] NRF Network Repository Functionality

[0105] NWDAF network data analysis function

[0106] OAM Operations, Administration and Maintenance

[0107] PCF Policy Control Function

[0108] PDU Packet Data Unit

[0109] QoS Quality of Service

[0110] SMF session management functions

[0111] SBI Service-Based Interface

[0112] UE User Equipment

[0113] UL Uplink

[0114] UPF User Plane Function

[0115] Figure 3 An overview 300 of problems and possible solutions that arise in third party AF authorization for network resource operations is shown.

[0116] According to solution description #42 in clause 6.42 of 3GPP TR 23.700-80 V0.3.0, when the AF is considered to be trusted, it will directly contact the PCF and BSF. In step 3 of the solution, the following text describing the AF behavior can be quoted: If the AF is considered to be trusted by the operator, the AF uses the Npcf_PolicyAuthorization_Create request message to interact directly with the PCF to request to reserve resources for the AF session, or transmits the Nbsf_Management_Discovery request to the BSF to discover the PCF serving the UE.

[0117] However, in some instances, a NF service consumer requesting an access token from an NRF must provide a "scope" including (e.g., requested resources and actions on those resources, among other parameters).

[0118] The UEs participating in the previous cycle of FL may change due to many reasons, such as mobility, availability, coverage, battery power or AF changes, such as diversity of UE selection to cover more training parameter space, etc. When this happens, the set of UEs will be changed and the PCF involved may be different from the previous cycle.

[0119] The frequency or how often authorization tokens should be shared or generated may be different based on different UE sets (subjects), expected PCF service names and instances (scopes and additional scopes), PCFFQDN (audience), expiration time (expiration).

[0120] Some attempts at solutions assume that authorization of AF should be performed once based on policy, rather than for each FL cycle. However, secure and flexible access control using fine-grained authorization tokens should be refreshed for each FL cycle, as different UE sets (subjects), expected PCF service names and PCF instances (scopes and additional scopes), PCF FQDNs (audience), expiration times (expiration) may be different.

[0121] The problems solved by the present disclosure include: 1. When an AF performing FL operations requests direct access to the PCF / BSF, how to perform service access authorization given that the above-mentioned scope may change from FL cycle to FL cycle; and 2. How to perform fine-grained access control through NF instances (such as PCF instances from untrusted AFs) using authorization tokens issued by NRF.

[0122] For fine-grained authorization, if the existing token can no longer be used for authorization of policy operations, the AF needs to contact the authorization server (i.e., NRF) to obtain an authorization token on behalf of the untrusted AF to be used by the PCF to authorize the AF for QoS policy management requests for each FL cycle. The token gives the AF authorization to operate (e.g., create, update, delete, read, etc.) on QoS policies at a specific PCF instance within a time period applied to a group of UEs.

[0123] The authorization token should be fine-grained to include at least the home NRF FQDN (issuer), AF ID and UE (subject), expected PCF service name (scope), PCF instances involved in the FL cycle (additional scope), PCF FQDN (audience), expiration time (expiration), and a digital signature generated by the NRF. In this case, the AF needs to contact the BSF to discover the PCF instances involved before contacting the NRF to request an authorization token for QoS policy operations at each PCF instance.

[0124] If the AF is considered to be trusted, the AF has the option to request a token authorized for PCF type NF (i.e., the token is valid for all PCFs). Alternatively, the AF can first contact the BSF to obtain the PCF instance, and then request a token for each PCF instance from the NRF to authorize being contacted by the AF in the FL cycle. The token will be verified by the PCF instance to authorize the AF to perform QoS policy operations in the FL cycle.

[0125] This method can be used for operations from a third-party AF on other policies in the core network.

[0126] This method can be used for operations on network resources in the core network from a third-party AF, rather than authorization of operations on policies.

[0127] The method can be used for both NF and UE to request access to other network functions using the Service Based Interface (SBI) API to request service authorization using the Service Authorization Token mechanism.

[0128] In an embodiment, authorization of an untrusted AF using a token for policy management is disclosed.

[0129] Figure 4An example process 400 is shown for an AF request for required QoS for a potential list of UEs selected by the AF.

[0130] exist Figure 4 In step 0, the AF may request an authorization token from the Common API Framework (CAPIF) core functionality. The CAPIF core may act as an authorization server. The AF is first authorized by the CAPIF that the AF is authorized to access the NEF. The authorization request may be made in any appropriate form (e.g., as an API request, a request in a management frame, a remote procedure call, a representational state transfer (RESTful) request, etc.). The authorization request may include an identifier such as an account identifier, a password or code, or any other such information. The CAPIF may respond with an authorization token in any suitable format.

[0131] The token may be validated by the NEF (e.g., at step 2) to authorize the AF to manage policy in the PCF. If the token authorizes the AF to manage policy on behalf of the AF on a PCF service type (i.e., for all PCFs) through the NEF, it may be recycled across multiple AIMLFLs. In other embodiments discussed in more detail below, the token may be limited in scope and / or time (e.g., with an associated expiration time, limited to a specific PCF service type or one or more PCFs, etc.).

[0132] exist Figure 4 In step 1, the AF may transmit a request to the NEF to reserve resources for the AF session using a request message (e.g., Nnef_GroupAFsessionWithQoS_Create request message). The request message may include, for example, an authorization token, an AF identifier, a flow description or an external application identifier, a QoS reference, a DNN, S-NSSAI, AIML group information, and / or AIML group performance information.

[0133] exist Figure 4 In step 2 of , the NEF may determine whether the authorization token from the CAPIF is valid and may assign a transaction reference ID to the Nnef_GroupAFsessionWithQoS_Create request. The NEF may authorize the AF request and may apply policies to control the total amount of QoS authorized for the AF. The NEF may alternatively authorize the AF request based on the token requested in step 0. If authorization is not granted, the NEF may reply to the AF, for example by replying with a result value, indicating that the authorization failed.

[0134] exist Figure 4In step 3, the NEF may use the external group ID or UE address list received in step 1 to transmit a discovery request message (eg, Nbsf_Management_Discovery request) to the BSF to discover the PCF serving the UEs of the group indicated in the AF request.

[0135] exist Figure 4 In step 4, the BSF may perform PCF discovery based on the input provided by the NEF in step 3. The BSF may determine which PCFs provide policy control for the corresponding UE and which PCFs may be a subset of the PCFs (e.g., because the corresponding UE is a subset of the UEs in the system).

[0136] exist Figure 4 In step 5, the BSF may transmit a discovery response message (eg, Nbsf_Management_Discovery response) including a list of PCFs serving the UE indicated in the AIML group information provided by the AF.

[0137] exist Figure 4 In step 6, if fine-grained control of authorization is required, such as authorization based on each PCF, the NEF may request a PCF authorization token for the newly added PCF for the FL cycle. The authorization token may include an expiration time and / or date, and / or may specify which PCF the authorization corresponds to (e.g., by an identifier or address of the corresponding PCF).

[0138] exist Figure 4 In step 7, when NEF receives the authorization token from NRF, in some embodiments, it can store the token locally or can store the token as a data subset of the application data at UDR on behalf of AF for future use. In other embodiments, the token can be forwarded to AF or another device.

[0139] exist Figure 4 In step 8, if multiple UEs from the AF group are served by the same PCF, the NEF may trigger and transmit a Npcf_GroupPolicyAuthorization_Create request message toward the PCF with the UE address, AF identifier, flow description, AIML group capability information and / or AIML session indicator as input parameters. If the Nnef_GroupAFsessionWithQoS_Create request in step 1 includes an AIML group capability container and an authorization token for each PCF, the NEF may include the AIML session indicator. In the case where UEs are served by different PCFs, in some embodiments, the NEF may transmit multiple request messages (e.g., one request message to each PCF).

[0140] exist Figure 4 In step 9, for the request received from the NEF in step 8, each PCF receiving the request can determine whether the request is authorized (e.g., based on a token included in the request, via backchannel communication to the NRF or BSF, or any other such authentication means), and if the request is not authorized, the NEF can be notified. If the request is authorized, the PCF can derive the required QoS parameters based on the information provided in the AIML group capability container, and determine whether the QoS is allowed (e.g., based on the PCF configuration), and notify / transmit the result to the NEF. When the PCF authorizes service information from the AF, it can generate PCC rules by deriving QoS parameters for the PCC rules based on the service information, AIML group capability information, and also include an AIML session indicator.

[0141] exist Figure 4 In step 10, if multiple UEs from the AF group are served by the same PCF, the PCF may transmit an Npcf_GroupAuthorization_Create response, the result of which (e.g., success or failure) is associated with the list of UEs for which policy authorization succeeded and the reason for failure of the list of UEs for which policy authorization failed. If the PCF determines that the SMF serving the UE needs to update policy information, the PCF may issue / transmit an Npcf_SMPolicyControl_UpdateNotify request with updated policy information about the PDU session. QoS flow binding should ensure that when the PCF provides a PCC rule containing AIML group performance information and an AIML session indicator in the SMF, the PCC rule is bound to the new QoS flow and no other PCC rules are bound to the QoS flow. In the case where multiple PCFs serve different UEs from the AF group, step 10 may be performed by each PCF in parallel or serially.

[0142] exist Figure 4In step 11, the NEF may track the results of all PCFs in the data subset of the application data at the UDR identified in step 5 included in step 7. If the minimum UEs in the group with the requested QoS parameters are provided in step 1, and the results from all PCFs match or exceed the minimum UEs in the group with the requested QoS parameters, the NEF may transmit a Nnef_GroupAFsessionWithQoS_Create response message (transaction reference ID, result, list of UEs in the AIML group allowed for the requested QoS) to the AF, where the result indicates that the request is granted. The UEs in the AIML group allowed for QoS are included in the response only if the response from the PCF to the NEF in step 7 indicates that the requested QoS for the UE is not allowed for all UEs belonging to the AIML group provided as input in step 1.

[0143] exist Figure 4 In step 12, the NEF may transmit a Npcf_PolicyAuthorization_Subscribe message to the PCF to subscribe to notifications of resource allocation status. In step 8, each PCF may respond with a subscription correlation ID, which allows the NEF to track all subscription notifications unique to each UE (e.g., each correlation ID may be unique or semi-unique, such as unique to a session and / or token).

[0144] exist Figure 4 In step 13, when the event conditions are met, such as the success or failure of establishing the sending resources corresponding to the QoS update, the QoS target can no longer be achieved, and the QoS monitoring parameters, the PCF can transmit an Npcf_PolicyAuthorization_Notify message to the NEF to notify the event. The PCF may include event information and notification related information identifying the AIML group AF session.

[0145] exist Figure 4 In step 14, when NEF receives Npcf_PolicyAuthorization_Notify for all UEs whose requests are granted in step 8, NEF may transmit to AF a Nnef_GroupAFsessionWithQoS_Notify message with the event reported by PCF, i.e., QoS resources with transaction reference ID allocated to all UEs whose requests are granted in step 8.

[0146] Figure 5 Another example process 500 of an AF request for required QoS for a potential list of UEs selected by the AF is shown.

[0147] exist Figure 5At step 0, the AF requests an authorization token from the NRF. The token can be used by the NEF to authorize the AF to manage policies in the PCF. If the token authorizes the AF for policy management by the NEF on behalf of the AF on the PCF service type (i.e., for all PCFs), it can be recycled across multiple AIML FLs. If fine-grained control of authorization is necessary, such as authorization on a per-PCF instance basis, then at step 5c, the AF can request an authorization token for each PCF based on the response from the BSF after step 5a, and transmit the request Nnef_GroupAFsessionWithQoS_Create in step 6a, as discussed below.

[0148] exist Figure 5 At step 1, AF transmits a request to NEF to reserve resources for the AF session using the Nnef_GroupAFsessionWithQoS_Create request message (authorization token, AF identifier, flow description or external application identifier, QoS reference, DNN, S-NSSAI, AIML group information, AIML group performance information).

[0149] exist Figure 5 At step 2 of , the NEF assigns a transaction reference ID to the Nnef_GroupAFsessionWithQoS_Create request. The NEF authorizes the AF request and may apply policies to control the total amount of QoS authorized for the AF. The NEF may alternatively authorize the AF request based on the token requested in step 0. If authorization is not granted, the NEF replies to the AF with a result value indicating authorization failure.

[0150] exist Figure 5 At step 3, the NEF transmits a Nbsf_Management_Discovery request to the BSF using the external group ID or UE address list in step 1 to discover the PCF serving the UEs of the group indicated in the AF request.

[0151] exist Figure 5 At step 4, the BSF performs PCF discovery based on the input provided by the NEF in step 3.

[0152] exist Figure 5 At step 5a, the BSF transmits an Nbsf_Management_Discovery response including a list of PCFs serving the UE indicated in the AIML group information provided by the AF.

[0153] exist Figure 5At step 5b, if fine-grained control of authorization is required, such as authorization on a per-PCF basis, the NEF forwards the discovered PCFs to the AF by forwarding an Nbsf_Management_Discovery response including a list of PCFs serving the UEs indicated in the AIML group information provided by the AF.

[0154] exist Figure 5 At step 5c, when fine-grained access control is required for an untrusted AF, the AF requests an authorization token for policy operations in the PCF instance for the FL loop, including a list of PCFs associated with UEs of the AIML group provided by the AF, where each PCF can be associated with a different UE of the indicated group.

[0155] exist Figure 5 At step 5d of , the AF receives an authorization token for the PCF instance associated with the new FL cycle.

[0156] exist Figure 5 At step 6a, if fine-grained control of authorization is necessary, such as authorization based on each PCF instance, the AF will request an authorization token for each PCF using steps 5b and 5c. As an alternative to step 1, the AF transmits a request Nnef_GroupAFsessionWithQoS_Create. The AF transmits a request to the NEF to reserve resources for the AF session using the Nnef_GroupAFsessionWithQoS_Create request message (token for each PCF, AF identifier, flow description or external application identifier, QoS reference, DNN, S-NSSAI, AIML group information, AIML group performance information).

[0157] exist Figure 5 At step 6b, the NEF authorizes the AF to request and verify the QoS authorization for each PCF based on the authorization token for each PCF instance. If the authorization is not granted, the NEF replies to the AF with a result value indicating the authorization failure.

[0158] exist Figure 5 At step 6c, if multiple UEs from the AF group are served by the same PCF, the NEF may trigger a Npcf_GroupPolicyAuthorization_Create request towards the PCF with the UE address, AF identifier, flow description, AIML group capability information, and AIML session indicator as input parameters. If the Nnef_GroupAFsessionWithQoS_Create request in step 1 includes an AIML group capability container, the NEF includes the AIML session indicator.

[0159] exist Figure 5 At step 7, for the request received from the NEF in step 6, the PCF determines whether the request is authorized, and notifies the NEF if the request is not authorized. If the request is authorized, the PCF derives the required QoS parameters based on the information provided in the ALML group capability container, and determines whether the QoS is allowed (according to the PCF configuration), and notifies the NEF of the result. When the PCF authorizes the service information from the AF, it generates the PCC rules by deriving the QoS parameters of the PCC rules based on the service information, the AIML group capability information, and also includes the AIML session indicator. If multiple UEs from the AF group are served by the same PCF, the PCF transmits an Npcf_GroupAuthorization_Create response, the result of which (i.e., success or failure) is associated with the list of UEs for which policy authorization succeeded and the reason for failure of the list of UEs for which policy authorization failed. If the PCF determines that the SMF serving the UE needs to update policy information, the PCF issues an Npcf_SMPolicyControl_UpdateNotify request with updated policy information about the PDU session. QoS flow binding should ensure that when the PCF provides the PCC rules containing AIML group capability information and AIML session indicator in the SMF, the PCC rules are bound to the new QoS flow and no other PCC rules are bound to the QoS flow.

[0160] exist Figure 5 In step 8, the NEF tracks the results from all PCFs identified in step 5 included in step 7. If the minimum UEs in the group with the requested QoS parameters are provided in step 1, and the results from all PCFs match or exceed the minimum UEs in the group with the requested QoS parameters, the NEF transmits a Nnef_GroupAFsessionWithQoS_Create response message (transaction reference ID, result, list of UEs in the AIML group allowed for the requested QoS) to the AF, where the result indicates that the request is granted. The UEs in the AIML group allowed for QoS are included in the response only if the response from the PCF to the NEF in step 7 indicates that the requested QoS for the UE is not allowed for all UEs belonging to the AIML group provided as input in step 1.

[0161] exist Figure 5 In step 9, the NEF will transmit a Npcf_PolicyAuthorization_Subscribe message to the PCF to subscribe to the notification of resource allocation status. In step 8, the PCF responds with a subscription correlation ID that allows the NEF to track all subscription notifications unique to each UE.

[0162] exist Figure 5 In step 10, when the event condition is met (e.g., the establishment of the sending resource corresponding to the QoS update is successful or failed), the QoS target can no longer be achieved, the QoS monitoring parameters, and the PCF transmits an Npcf_PolicyAuthorization_Notify message to the NEF to notify the event. The PCF includes event information and notification related information identifying the AIML group AF session.

[0163] exist Figure 5 In step 11, when NEF receives Npcf_PolicyAuthorization_Notify for all UEs whose requests are granted in step 8, NEF transmits a Nnef_GroupAFsessionWithQoS_Notify message with the event reported by PCF to AF (i.e., QoS resources with transaction reference ID allocated to all UEs whose requests are granted in step 8).

[0164] In an embodiment, authorization of a trusted AF using a token for policy management is disclosed.

[0165] Figure 6 An example process 600 of a trusted AF request for required QoS for a potential list of UEs selected by the AF is shown.

[0166] exist Figure 6 In step 0 of , the trusted AF requests an authorization token from the NRF. The token can be used by the PCF to authorize the AF to manage policy. If the token authorizes the AF to manage policy by all PCFs, it can be recycled across multiple AIML FLs. If fine-grained control of authorization is necessary, such as authorization on a per-PCF basis, the AF will request an authorization token for each PCF based on the response from the BSF after step 5, and transmit the request Nnef_GroupAFsessionWithQoS_Create in step 6, discussed below.

[0167] exist Figure 6 In step 1, the AF transmits an Nbsf_Management_Discovery request to the BSF to discover the PCF serving the UE.

[0168] exist Figure 6 In step 2, the BSF performs PCF discovery based on the input provided by the AF in step 1.

[0169] exist Figure 6In step 3, the BSF transmits an Nbsf_Management_Discovery response including a list of PCFs serving the UEs indicated in the AIML group information provided by the AF. For a trusted AF of an operator, the BSF transmits an Nbsf_Management_Discovery response including a list of PCFs associated with the UEs of the AIML group provided by the AF, where each PCF can be associated with a different UE of the indicated group.

[0170] exist Figure 6 In step 4, the operator trusts the AF, and the AF may optionally request an authorization token for policy operations in the PCF instance for the FL loop, including a list of PCFs associated with UEs of the AIML group provided by the AF, where each PCF may be associated with a different UE of the indicated group.

[0171] exist Figure 6 In step 5 of , the AF receives an authorization token for the PCF associated with the new FL cycle.

[0172] exist Figure 6 In step 6, the operator trusts the AF, and the AF transmits a Npcf_GroupPolicyAuthorization_Create request to the PCF, with the authorization token received in step 0 that is valid for the PCF type (i.e., valid for all PCF instances) or the token requested for a specific PCF instance for this FL loop in steps 4 and 5, UE address, AF identifier, flow description, AIML group capability information, AIML session indicator as input parameters. The PCF verifies the authorization token before processing the request.

[0173] exist Figure 6In step 7, for the request received from the AF in step 6, the PCF determines whether the request is authorized, and notifies the AF if the request is not authorized. If the request is authorized, the PCF derives the required QoS parameters based on the information provided in the AIML group capability container, determines whether the QoS is allowed (according to the PCF configuration), and notifies the AF of the result. When the PCF authorizes the service information from the AF, it generates the PCC rules by deriving the QoS parameters of the PCC rules based on the service information, the AIML group capability information, and also includes the AIML session indicator. If multiple UEs from the AF group are served by the same PCF, the PCF transmits an Npcf_GroupPolicyAuthorization_Create response, the result of which (i.e., success or failure) is associated with the list of UEs for which the policy authorization succeeded and the reason for the failure of the list of UEs for which the policy authorization failed. If the PCF determines that the SMF serving the UE needs to update the policy information, the PCF issues an Npcf_SMPolicyControl_UpdateNotify request with the updated policy information about the PDU session. QoS flow binding should ensure that when the PCF provides the PCC rule containing AIML group capability information and AIML session indicator in the SMF, the PCC rule is bound to the new QoS flow and no other PCC rule is bound to the QoS flow. Repeat steps 6 and 7 for all identified PCFs.

[0174] exist Figure 6 In step 8, for a trusted AF, the PCF transmits a Npcf_PolicyAuthorization_Subscribe message directly to the PCF to subscribe to notifications of resource allocation status with the authorization token for the associated PCF. After validating the authorization token, each PCF responds with a subscription correlation ID.

[0175] exist Figure 6 In step 9, when the event condition is met (e.g., the establishment of the sending resource corresponding to the QoS update is successful or failed, the QoS target can no longer be achieved, the QoS monitoring parameter), the PCF transmits a Npcf_PolicyAuthorization_Notify message to the trusted AF to notify the event. The PCF includes event information and notification related information identifying the AIML group AF session.

[0176] Although the above embodiments in the previous clauses focus on QoS policy management of PCF, the same mechanism can be used for other policy management in PCF, such as security policy, routing policy (URSP), etc.

[0177] In an embodiment, to support fine-grained token management, token attributes may include a time window (in other words, a start time and a stop time) in addition to the previously mentioned expiration time.

[0178] For example, a network function such as an AF may request access to some network resource at some time in the future (e.g., some network resource calls some API). In this case, the AF does not need to be granted authorization for immediate use, but for future use at some start time. In this scenario, the expiration timer for the token validity will only start decrementing when the start time arrives, rather than immediately after the response from the authorization server (e.g., NRF) is generated. This will allow another aspect of fine-grainedness for token management.

[0179] In an example, only when the network function (eg, AF) starts using the token (eg, by calling a certain API using the token), the expiration timer will start decreasing.

[0180] In this embodiment, we will focus on negotiating background data delivery and show how the new time-related token aspect can be used for fine-grained AF authorization for BDT policy management.

[0181] The AF may contact the PCF via the NEF, or directly if the AF is trusted as described in detail in the first embodiment, to request a time window and related conditions for future background data transfer (BDT).

[0182] Later, before the BDT delivery window starts, the AF can contact the PCF based on the previously negotiated BDT policy by calling NEF API (such as Nnef_ApplyPolicy_Create service) to initiate the activation of the negotiated future PDU session. The PCF can use the negotiated BDT policy and create new PCC rules to accommodate the BDT traffic (e.g., by establishing a new PDU session).

[0183] In this embodiment, if the negotiation is successful, the authorization server (ie, NRF) generates a token for future use to allow the AF to use, for example, the API Nnef_ApplyPolicy_Create at the start of a BDT session.

[0184] In some scenarios, such as when network performance changes (e.g., network performance degrades), 5GS can renegotiate BDT policy with AF if possible. In this case, 5GS can update BDT policy or cancel BDT future sessions.

[0185] It is proposed that if the 5GS updates the BDT policy, the authorization server (i.e., NRF) can update the authorization token for future BDT session requests (e.g., calling the NEF API Nnef_ApplyPolicy_Create). For example, the NRF can change the start time or stop time attributes of the token. If the BDT session is cancelled, the authorization server can revoke the authorization token.

[0186] Figure 7 An example process 700 of BDT session negotiation and AF authorization utilizing time-dependent tokens is shown.

[0187] Figure 7 The process shown supports negotiation for future background data transfer. Figure 7 In this paper, we assume that a PCF is used to support BDT sessions.

[0188] exist Figure 7 In step 0, the AF requests an authorization token from the NRF. This token can be used by the NEF to authorize the AF to request BDT related policies.

[0189] exist Figure 7 In step 1a, the AF calls Nnef_BDTPNegotiation_create with attributes (eg, ASPID, number of UEs, desired time window amount per UE, request for notification) to provide BDT session information.

[0190] exist Figure 7 In step 1b, the NEF verifies the authorization token provided by the AF.

[0191] Figure 7 Step 2 of represents steps 2-10 in procedure 4.16.7.2 in 23.502, where the NEF forwards the AF request to the PCF, the PCF retrieves data about the UE from the UDR, and the PCF makes a policy decision and transmits a response to the NEF. If the AF is trusted, the AF directly contacts the PCF along with the authorization token requested from the NRF.

[0192] exist Figure 7 In step 3, the NEF transmits a Nnef_BDTPNegotiation_Create response to the AF to provide the AF with one or more background data transfer strategies and a BDT reference ID. The AF then selects the BDT strategy to be used in the future. The NEF then acknowledges the AF message.

[0193] exist Figure 7In step 4 of , after successful BDT negotiation between PCF and AF, the authorization server (i.e., NRF) generates a time-dependent access token for future use for BDT purposes (e.g., with a start time similar to the start time of the BDT session), where the AF can call services such as Nnef_ApplyPolicy_Create. Later, the AF does not need to request an authorization token to call the API for this purpose.

[0194] Figure 7 Step 5 of represents a situation where the BDT protocol may need to change. For example, if network conditions change, future BDT session policies may need to be updated. In step 5, steps 2-11 for BDT warning notifications in clause 4.16.7.3 in 23.502 are executed. Once it is known that the network performance has degraded, the PCF begins to reestablish a new BDT policy to be renegotiated. The PCF then communicates the new policy to the AF via the NEF, or directly to the AF if the AF is trusted. The AF then selects the new BDT policy to use.

[0195] exist Figure 7 In step 6, once the AF transmits the selected BDT policy to the PCF, the PCF updates the BDT policy.

[0196] exist Figure 7 In step 7, the NEF transmits a Nnef_BDTPNEgotiation_Create response to the AF to provide the AF with one or more background data delivery policies and a BDT reference ID. The AF then selects the BDT policy to be used in the future. The NEF then confirms the AF message. If the AF is trustworthy, in steps 6 and 7, the PCF can communicate directly with the AF to update the BDT policy without traversing the NEF.

[0197] exist Figure 7 In step 8, once the new BDT policy is successfully updated, the authorization server will generate a new authorization time-related token (with a new time window similar to the updated BDT policy) for future BDT sessions and provide it to the AF.

[0198] exist Figure 7 In step 9a, when the BDT session is about to start, the AF calls the API Nnef_ApplyPolicy_Create using the authorization token previously provided by the NRF. The NEF verifies the token in 9b (e.g., the time window of the token is still valid) and forwards the request to the PCF. If the AF is trusted, the AF communicates directly with the PCF.

[0199] When a third-party AF is deemed trusted to access core network functions / resources instead of traversing the NEF for policy management by the PCF, Figure 5 and 6 The same mechanism in the implementation scheme can be used for AF authorization.

[0200] In some implementations, both the UE and the AF can request 5GS performance metrics, predictions and statistics. This means that it is conceivable that the UE plays the role of the NF and uses mechanisms such as those described above.

[0201] Figure 8 An example process 800 is shown in which a UE acts as a NF and requests service access authorization from an NRF.

[0202] In this alternative, the UE plays the role of NF and obtains an access token from the NRF ( Figure 8 Option B) and it uses the access token to directly access the NF (e.g., the UE can use the access token to directly access the NWDAF via the established PDU session (i.e., on the user plane)).

[0203] The UE may use NAS transport mechanism to carry HTTP messages to the relevant NF (e.g., the UE may use UL NAS transport and then have the AMF relay the Nndwdaf_AnalyticsSubscription_Subscribe message directly to the NDWDAF).

[0204] Performed as in 3GPP TR 23.700-80 V0.3.0, clause 6.5 Figure 8 Follow steps 0a-3a in .

[0205] exist Figure 8 In step 3b, the UE requests a service authorization token from the NRF by using the "scope" and "additional scope" information (e.g., the requested resources and requested actions or service operations expected from the NF it wants to contact). The UE may also provide information about the validity of the service operation within the time window and whether the UE-requested resources acted upon by the service operation are expected to change in time.

[0206] Performed as in 3GPP TR 23.700-80 V0.3.0, clause 6.5 Figure 8 Follow steps 3c-6 in .

[0207] Fig. 9An example process 900 for dynamic policy management by a network exposure function node in accordance with some embodiments is shown. In some implementations, process 900 may be performed by a device such as a WTRU, UE, server, or any other type and form of computing device acting as an AF node. In some implementations, a device or AF node may perform an AI / ML training process for QoS policy management using measurements obtained by one or more WTRUs or UEs in the network. As discussed above, a device or AF node may not necessarily be a trusted node, and therefore, in some embodiments, another node may act as an intermediary or provide a network exposure function (NEF) for the AF node.

[0208] At 902, a first network node providing an exposed function (e.g., a NEF) may receive a request to reserve resources for a quality of service (QoS) training session from a second network node (e.g., an AF) that is not identified as trusted, the request including performance requirements for the training session. In some embodiments, the request may include an authorization token obtained from the CAPIF, as discussed above, or may include other authentication information (user name, password, device identifier, public key, signed transaction, etc.). In some embodiments, the request may include an identification of one or more UEs to be used for the training session. In other embodiments, the request may include an identification of parameters for the training session, such as the number of UEs to be selected, minimum bandwidth, device type, geographic area, or any other such parameter for the training session or test. In some embodiments, the request may include a Nnef_GroupAFsessionWithQoS_Create request.

[0209] At 904, the first network node may request, from a third network node (e.g., a BSF node) providing binding support management, identification of one or more policy controllers (e.g., a PCF node) associated with a subset of one or more wireless transmit / receive units (WTRUs) or UEs selected from a plurality of WTRUs or UEs for a QoS training session. The request may include parameters for the training session or test as discussed above. In some embodiments, the request may include an Nbsf_Management_Discovery request. Receipt of the request may enable the third network node (e.g., a BSF node) to select one or more policy controllers associated with the UEs or WTRUs to be included in the training set.

[0210] At 906, the first network node may receive a response from the third network node identifying one or more policy controllers. The response may be an Nbsf_Management_Discovery response.

[0211] At 908, the first network node may request an authorization token for each of the one or more policy controllers from a fourth network node (e.g., an NRF node) that provides a network repository function. The request may include the identification of the one or more policy controllers identified by the BSF node. In some embodiments, the request may include the identification of the AF node. The fourth network node (e.g., an NRF node) may generate an authorization token for each policy controller identified in the request (e.g., multiple tokens for corresponding multiple controllers).

[0212] At 910, the first network node may receive one or more authorization tokens corresponding to one or more policy controllers from the fourth network node, each authorization token including an identification of the corresponding policy controller, the second network node, and an expiration time of the QoS training session. In some embodiments, each authorization token may include an identifier of the corresponding policy controller. In some embodiments, each authorization token may include an expiration time or date. Steps 908-910 may be performed iteratively for each policy controller or authorization token, or may be performed in a single step of requesting and receiving multiple authorization tokens.

[0213] At 912, the first network node may send a request to each of the one or more policy controllers, the request including a corresponding authorization token in the one or more authorization tokens and the performance requirements for the training session. In some embodiments, the request may include an Npcf_PolicyAuthorization_Create request. In some embodiments, the request may include an identification of the AF node. The request may include identification of one or more UEs or WTRUs associated with the policy controller.

[0214] At 914, the first network node may receive from each policy controller an identification of a subgroup of WTRUs that meet the performance requirements for the training session, and the first network node provides the identification of the subgroup of WTRUs to the second network node. The response may include an Npcf_PolicyAuthorization_Create response. In some embodiments, the response may include identification of one or more UEs or WTRUs associated with the policy controller. Steps 912-914 may be performed iteratively for each policy controller, or may be performed in parallel (e.g., sending multiple requests and receiving responses when each policy controller processes the corresponding request). In some embodiments, as discussed above, the first network node may provide the AF with access to network measurements and device parameters of the UE or WTRU (e.g., forwarding policy change subscription requests, forwarding measurements or QoS parameters, etc.).

[0215] Fig.10Another example process 1000 of dynamic policy management by an application function node according to some embodiments is shown. Similar to process 900, in some embodiments, process 1000 may be implemented for a trusted AF node.

[0216] At 1004, a first network node (e.g., an application function or AF node or other network device) may send a request to a second network node (e.g., a BSF node) providing binding support management, i.e., an identification of one or more policy controllers associated with a subset of one or more wireless transmit / receive units (WTRUs) selected from a plurality of WTRUs for a QoS training session. In some embodiments, the AF node may select the WTRUs or UEs to be used for the QoS training session. In other embodiments, the AF node may provide requirements (e.g., device type, number of devices, geographic area, bandwidth, or any other such parameter). In some embodiments, the request may include an Nbsf_Management_Discovery request.

[0217] At 1006, the first network node may receive a response from the second network node identifying one or more policy controllers. As discussed above, the response may include an Nbsf_Management_Discovery response.

[0218] The first network node may request an authorization token for each of the one or more policy controllers from a third network node providing a network repository function at 1008. The request may include an identification of the first network node, the policy controller, and / or an associated WTRU or UE; an expiration time or date; an access authorization or token received from the CAPIF, or any other such information.

[0219] At 1010, the first network node may receive one or more authorization tokens corresponding to the one or more policy controllers from the third network node, each authorization token including an identification of the corresponding policy controller, the first network node, and an expiration time of the QoS training session. As discussed above, the authorization tokens may be transmitted together, or steps 1008 and 1010 may be repeated for each additional policy controller.

[0220] At 1012, the first network node may send a request to each of the one or more policy controllers, the request including a corresponding authorization token of the one or more authorization tokens and a performance requirement for the training session. As discussed above, the performance requirement may include bandwidth requirements, the number of devices or WTRUs to be included in the session, one or more geographic regions, device types, or any other type and form of parameters or requirements.

[0221] At 1014, in some embodiments, the first network node may receive from each policy controller an identification of a subset of WTRUs that meet the performance requirements for the training session. In some embodiments, the identification may include a list of identifiers, a list of device types, or any other such information. In some embodiments, steps 1012-1014 may be performed iteratively for each additional policy controller. In other embodiments, multiple requests may be sent at step 1012, and at step 1014, the first network node may receive a response from each policy controller as each policy controller processes the request.

[0222] Fig.11 Another example process 1100 of dynamic policy management by a network repository function node is shown according to some embodiments.

[0223] At 1102, a first network node providing a network repository function (e.g., NRF) may receive a request for one or more authorization tokens corresponding to one or more policy controllers associated with a subset of one or more wireless transmit / receive units (WTRUs) selected from a plurality of wireless transmit / receive units (WTRUs) for a QoS training session from a requesting node (e.g., an AF node or an NEF node, etc.). The request may be a request to reserve resources for the QoS training session for access by a second network node (which may be the requesting node when the requesting node is an AF node, or which may be a different node such as an AF node when the requesting node is an NEF node), the request including an identification of the second network node (e.g., an AF node). In some embodiments, the request may include an expiration time for the QoS training session.

[0224] At 1104, the first network node may generate one or more authorization tokens, each authorization token corresponding to a policy controller and including an identification of the corresponding policy controller and an identification of the second network node. Step 1104 may be repeated for each additional policy controller. In some embodiments, each authorization token may include an identification of an expiration time of the token.

[0225] At 1106, the first network node may send the generated one or more authorization tokens to the requesting node.

[0226] In some embodiments, the requesting node is a second network node (e.g., an AF node), and the second network node is identified as providing a trusted application function. In such embodiments, the second network node may utilize the authorization token to communicate directly with the policy controller (and / or associated WTRU or UE) at 1108. For example, in some implementations, receipt of the one or more authorization tokens causes the second network node to request the identities of the WTRUs of the subgroup from the policy controller using the generated one or more authorization tokens.

[0227] In some embodiments, the second network node (e.g., AF node) is not identified as providing trusted application functionality, and the requesting node includes a third network node (e.g., NEF node) that provides exposure functionality to the second network node. In such embodiments, at 1110, the third network node may use the generated one or more authorization tokens to request identities of the WTRUs of the subset from the policy controller and provide the identities to the second network node. For example, in some such embodiments, the requesting node is deployed as or acts as an intermediary between the second network node and one or more policy controllers.

[0228] In some embodiments, the authorization token may be revoked or invalidated. For example, in some implementations, such as when the token does not include an expiration time, or if the token is revoked or invalidated before any expiration time included in the token, the NRF node may send an identification that the corresponding authorization token has expired or has been revoked to each of the one or more policy controllers that have generated the authorization token and are to be revoked. Such identification may include a session identifier, an identifier of an AF or NEF node, or any other such information. In similar implementations, the NRF node may send one or more identifications that the authorization token has expired or has been revoked to the AF node or NEF node or any other such device.

[0229] Accordingly, the present disclosure relates to systems and methods for dynamic policy management in a wireless network environment. In a first aspect, a method for dynamic policy management includes identifying, by a first network node providing a network repository function, in response to a communication from a requesting node, one or more policy controllers associated with a subgroup of one or more wireless transmit / receive units (WTRUs) selected from a plurality of WTRUs for an artificial intelligence / machine learning (AI / ML) training session. The method includes generating, by the first network node, one or more authorization tokens, each authorization token corresponding to a policy controller and including an identification of the corresponding policy controller and an identification of a second network node. The method also includes sending, by the first network node, the generated one or more authorization tokens to the requesting node.

[0230] In some embodiments, the method includes receiving, by a first network node, a communication from a requesting node, the communication including a request to reserve resources for an AI / ML training session for access by a second network node, the request including an identification of the second network node. In other embodiments, the request also includes an expiration time of the validity of the authorization token.

[0231] In some embodiments, each authorization token also includes an identification of an expiration time of the token validity. In some embodiments, the requesting node includes a second network node, and the second network node is identified as providing a trusted application function; and sending the generated one or more authorization tokens to the requesting node causes the second network node to request an identification of the WTRU of the subset from the policy controller using the generated one or more authorization tokens.

[0232] In some embodiments, the second network node is not identified as providing a trusted application function, and the requesting node includes a third network node that provides an exposure function for the second network node; and sending the generated one or more authorization tokens to the requesting node causes the third network node to use the generated one or more authorization tokens to request an identity of the WTRU of the subset from the policy controller and provide the identity to the second network node. In other embodiments, the requesting node is deployed as an intermediary between the second network node and the one or more policy controllers.

[0233] In some embodiments, the method includes subsequently sending, by the first network node, to each of the one or more policy controllers, an indication that the corresponding authorization token has expired or has been revoked. In some embodiments, the method includes subsequently sending, by the first network node, to the requesting node, an indication that one or more authorization tokens have expired or have been revoked.

[0234] In another aspect, the present disclosure relates to a system for dynamic policy management in a wireless network environment. The system includes a first network node, the first network node including one or more network interfaces and one or more processors. The one or more processors are configured to: identify one or more policy controllers associated with a subgroup of one or more wireless transmit / receive units (WTRUs) selected from a plurality of wireless transmit / receive units (WTRUs) for an artificial intelligence / machine learning (AI / ML) training session in response to a communication from a requesting node; generate one or more authorization tokens, each authorization token corresponding to a policy controller and including an identification of the corresponding policy controller and an identification of a second network node; and send the generated one or more authorization tokens to the requesting node.

[0235] In some embodiments, the one or more processors are further configured to receive a communication from the requesting node, the communication comprising a request to reserve resources for access by a second network node for an AI / ML training session, the request comprising an identification of the second network node. In further embodiments, the request further comprises an expiration time of the validity of the authorization token. In some embodiments, each authorization token further comprises an identification of the expiration time of the token validity.

[0236] In some embodiments, the requesting node includes a second network node, and the second network node is identified as providing trusted application functionality; and sending the generated one or more authorization tokens to the requesting node enables the second network node to use the generated one or more authorization tokens to request the identification of the WTRU of the sub-group from the policy controller.

[0237] In some embodiments, the second network node is not identified as providing a trusted application function, and the requesting node includes a third network node that provides an exposure function for the second network node; and sending the generated one or more authorization tokens to the requesting node causes the third network node to use the generated one or more authorization tokens to request an identity of the WTRU of the subset from the policy controller and provide the identity to the second network node. In other embodiments, the requesting node is deployed as an intermediary between the second network node and the one or more policy controllers.

[0238] In some embodiments, the one or more processors are further configured to send an identification that the corresponding authorization token has expired or has been revoked to each of the one or more policy controllers. In some embodiments, the one or more processors are further configured to send an identification that the one or more authorization tokens have expired or have been revoked to the requesting node.

[0239] In another aspect, the present disclosure relates to a method for dynamic policy management in a wireless network environment. The method includes receiving, by a first network node providing an exposure function, a request to reserve quality of service (QoS) resources for an artificial intelligence / machine learning (AI / ML) training session from a second network node that is not identified as trusted, the request including performance requirements for the training session. The method also includes requesting, by the first network node, from a third network node providing binding support management, an identification of one or more policy controllers associated with a subgroup of one or more WTRUs selected from a plurality of wireless transmit / receive units (WTRUs) for the AI / ML training session. The method also includes receiving, by the first network node, a response identifying one or more policy controllers from the third network node. The method also includes requesting, by the first network node, an authorization token for each of the one or more policy controllers from a fourth network node providing a network repository function. The method also includes receiving, by the first network node, one or more authorization tokens corresponding to the one or more policy controllers from the fourth network node, each authorization token including an identification of the corresponding policy controller, the second network node, and the expiration time of the validity of the authorization token. The method also includes transmitting, by the first network node, a request to each of the one or more policy controllers, the request including a corresponding authorization token in the one or more authorization tokens and the performance requirements for the training session. The method also includes receiving, by the first network node from each policy controller, an identification of a subset of WTRUs that meet the performance requirement for the training session, the first network node providing the identification of the subset of WTRUs to the second network node.

[0240] On the other hand, the present disclosure relates to a method for dynamic policy management in a wireless network environment. The method includes requesting, by a first network node, from a second network node providing binding support management, an identifier of one or more policy controllers associated with a subgroup of one or more WTRUs selected from a plurality of wireless transmit / receive units (WTRUs) for an artificial intelligence / machine learning (AI / ML) training session. The method also includes receiving, by the first network node, a response identifying one or more policy controllers from the second network node. The method also includes requesting, by the first network node, an authorization token for each of the one or more policy controllers from a third network node providing a network repository function. The method also includes receiving, by the first network node, one or more authorization tokens corresponding to the one or more policy controllers from the third network node, each authorization token including an identifier of the corresponding policy controller, the first network node, and an expiration time of the validity of the authorization token. The method also includes transmitting, by the first network node, a request to each of the one or more policy controllers, the request including a corresponding authorization token in the one or more authorization tokens and a performance requirement for the AI / ML training session. The method also includes receiving, by the first network node, from each policy controller, an identifier of a subgroup of WTRUs that meets the performance requirements for the training session.

[0241] Although the features and elements are described above in specific combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (sent via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for dynamic policy management in a wireless network environment, the method comprising: identifying, by a first network node providing a network repository functionality, in response to a communication from a requesting node, one or more policy controllers associated with a subset of one or more wireless transmit / receive units (WTRUs) selected from a plurality of WTRUs for an artificial intelligence / machine learning (AI / ML) training session; generating, by the first network node, one or more authorization tokens, each authorization token corresponding to a policy controller and comprising an identifier of the corresponding policy controller and an identifier of the second network node; as well as The generated one or more authorization tokens are sent by the first network node to the requesting node.

2. The method of claim 1 further comprises receiving, by the first network node, a communication from the requesting node, the communication comprising a request to reserve resources for the AI / ML training session for access by a second network node, the request comprising the identifier of the second network node. The method according to claim 2 , wherein the request further includes an expiration time of the validity of the authorization token. The method according to claim 1 , wherein each authorization token further comprises an identification of an expiration time of the validity of the token.

5. The method of claim 1 , wherein the requesting node comprises the second network node, and the second network node is identified as providing a trusted application function; and Wherein sending the generated one or more authorization tokens to the requesting node causes the second network node to request identities of the WTRUs of the subset from the policy controller using the generated one or more authorization tokens.

6. The method of claim 1 , wherein the second network node is not identified as providing a trusted application function, and the requesting node comprises a third network node that provides an exposure function for the second network node; and Sending the generated one or more authorization tokens to the requesting node causes the third network node to request identities of the WTRUs of the subset from the policy controller using the generated one or more authorization tokens and provide the identities to the second network node.

7. The method of claim 6, wherein the requesting node is deployed as an intermediary between the second network node and the one or more policy controllers.

8. The method according to claim 1, further comprising subsequently sending, by the first network node, to each of the one or more policy controllers an indication that the corresponding authorization token has expired or been revoked.

9. The method of claim 1, further comprising subsequently sending, by the first network node, to the requesting node an indication that the one or more authorization tokens have expired or have been revoked.

10. A system for dynamic policy management in a wireless network environment, the system comprising: A first network node, the first network node comprising one or more network interfaces and one or more processors, the one or more processors being configured to: identifying, in response to a communication from a requesting node, one or more policy controllers associated with a subset of one or more wireless transmit / receive units (WTRUs) selected from a plurality of WTRUs for an artificial intelligence / machine learning (AI / ML) training session; generating one or more authorization tokens, each authorization token corresponding to a policy controller and comprising an identification of the corresponding policy controller and an identification of the second network node; as well as and sending the generated one or more authorization tokens to the requesting node.

11. The system of claim 10, wherein the one or more processors are further configured to receive a communication from the requesting node, the communication comprising a request to reserve resources for the AI / ML training session for access by a second network node, the request comprising the identifier of the second network node.

12. The system of claim 11, wherein the request further includes an expiration time of the validity of the authorization token.

13. The system of claim 12, wherein each authorization token further comprises an identification of an expiration time of the validity of the token.

14. The system of claim 10, wherein the requesting node comprises the second network node, and the second network node is identified as providing a trusted application function; and Wherein sending the generated one or more authorization tokens to the requesting node causes the second network node to request identities of the WTRUs of the subset from the policy controller using the generated one or more authorization tokens.

15. The system of claim 10, wherein the second network node is not identified as providing a trusted application function, and the requesting node comprises a third network node that provides an exposure function for the second network node; and Sending the generated one or more authorization tokens to the requesting node causes the third network node to request identities of the WTRUs of the subset from the policy controller using the generated one or more authorization tokens and provide the identities to the second network node.

16. The system of claim 15, wherein the requesting node is deployed as an intermediary between the second network node and the one or more policy controllers. 17 . The system of claim 10 , wherein the one or more processors are further configured to send an indication that the corresponding authorization token has expired or has been revoked to each of the one or more policy controllers.

18. The system of claim 10, wherein the one or more processors are further configured to send an indication to the requesting node that the one or more authorization tokens have expired or have been revoked.

19. A method for dynamic policy management in a wireless network environment, the method comprising: receiving, by a first network node providing an exposure function, a request to reserve quality of service (QoS) resources for an artificial intelligence / machine learning (AI / ML) training session from a second network node that is not identified as trusted, the request including a performance requirement for the training session; requesting, by the first network node, from a third network node providing binding support management, identities of one or more policy controllers associated with a subset of one or more wireless transmit / receive units (WTRUs) selected from a plurality of WTRUs for the AI / ML training session; receiving, by the first network node, a response from the third network node identifying the one or more policy controllers; requesting, by the first network node, an authorization token for each of the one or more policy controllers from a fourth network node providing a network repository function; receiving, by the first network node from the fourth network node, one or more authorization tokens corresponding to the one or more policy controllers, each authorization token comprising an identification of the corresponding policy controller, the second network node, and an expiration time of the validity of the token; transmitting, by the first network node, to each of the one or more policy controllers a request, the request comprising a corresponding authorization token of the one or more authorization tokens and the performance requirement for the training session; as well as The first network node receives, from each policy controller, an identification of the subset of WTRUs that meet the performance requirement for the training session, and the first network node provides the identification of the subset of WTRUs to the second network node.

20. A method for dynamic policy management in a wireless network environment, the method comprising: requesting, by a first network node, from a second network node providing binding support management, identities of one or more policy controllers associated with a subset of one or more wireless transmit / receive units (WTRUs) selected from a plurality of WTRUs for an artificial intelligence / machine learning (AI / ML) training session; receiving, by the first network node, a response from the second network node identifying the one or more policy controllers; requesting, by the first network node, an authorization token for each of the one or more policy controllers from a third network node providing a network repository function; receiving, by the first network node from the third network node, one or more authorization tokens corresponding to the one or more policy controllers, each authorization token comprising an identification of the corresponding policy controller, the first network node, and an expiration time of the validity of the authorization token; transmitting, by the first network node, to each of the one or more policy controllers a request, the request comprising a corresponding authorization token of the one or more authorization tokens and the performance requirement for the AI / ML training session; as well as An identification of the subset of WTRUs that meet the performance requirement for the training session is received by the first network node from each policy controller.

Images