Obtaining bulk user authorization

Abstract

This disclosure provides methods for an application service provider (ASP) to register the enablement of bulk registration of user authorization (e.g., a user's consent for certain information-or types of information-to be shared with certain other entities) for application programming interface (API) invokers across one or more API exposing functions (AEFs). This functionality may be enabled by providing user authorization-related parameters when registration towards the Common API Framework (CAPIF) core function (CCF) is initiated from the API provider domain. Following such registration, when an API invoker requests to obtain resource owner authorization information, the CCF, e.g., via its authorization function, can request bulk authorization (e. g., user consent permissions) from the resource owner (RO) (i.e., if such authorization hasn' t already been captured), e.g., via the resource owner function (ROF).

Description

OBTAINING BULK USER AUTHORIZATIONTECHNICAL FIELD

[0001] The present application relates to wireless devices and wireless networks, including user devices, terminals, circuits, computer-readable media, and methods for improved registration of bulk user authorization (e.g., consent) for application programming interface (API) invokers across one or more API exposing functions (AEFs) .BACKGROUND

[0002] Ensuring that appropriate user authorization (e.g., consent) has been obtained is a critical aspect when handling sensitive information relating to or collected from a user, their devices, or the applications installed at their devices. This is highlighted in Stage 1 of the Mobile Metaverse Services Technical Specification (3GPP TS 22.156) , where many of the requirements are subject to operator policy, regulatory requirements and user authorization-the latter being of particular importance to this disclosure.

[0003] With the introduction of support for Resource owner-aware Northbound API Access (RNAA)  / Subscriber-aware Northbound API access in 3GPP Rel-18 to Common API Framework for 3GPP northbound APIs (CAPIF) , a number of requirements were added at Stage 1, one of which was motivated by the desire for a resource owner (RO) , such as a user of a user equipment (UE) , to be able to control whether or not to provide information considered private to a third party entity.

[0004] Specifically, one requirement is that the 5G system shall be able to allow the UE to provide / revoke authorization for information (e.g., such as location, presence, etc. ) to be shared with any such third party entities.

[0005] At Stage 2 (3GPP TS 23.222) , the CAPIF-8 reference point was introduced to  CAPIF, whereby the aspect of user authorization was highlighted, e.g., via the statement that the resource owner (RO) communicates with the authorization function in the CAPIF core function (CCF) to manage resource owner authorization, with such communication being expected to be performed over CAPIF-8. However, the mechanism for managing such authorization was not specified, with the functionalities over CAPIF-8 being designated for further study and out of scope of the Rel-18 of the specification. Thus, there is an ongoing need to address this issue (and other related security-focused issues) in Rel-19.SUMMARY

[0006] In accordance with one or more embodiments, a method of obtaining bulk authorization from a resource owner (RO) is disclosed, the method comprising: requesting, by an application programming interface (API) invoker, to invoke a service exposed by at least one API exposing function (AEF) for which authorization information has been provided by the RO, wherein the authorization information comprises bulk authorization information; sending, from the API invoker, a service API invocation request to the at least one AEF, wherein the service API invocation request includes the authorization information; and receiving, at the API invoker, a response to the service API invocation request based on a determination, by the at least one AEF, that the API invoker is authorized to invoke the service API.

[0007] According to some aspects, requesting, by the API invoker, to invoke a service exposed by at least one AEF for which authorization information has been provided by the RO further comprises: requesting authorization information via a Common API Framework (CAPIF) core function (CCF) .

[0008] According to some such aspects, the CCF is configured to interact with the RO to  obtain the bulk authorization information.

[0009] According to other such aspects, the bulk authorization information is obtained by the CCF via at least one of the at least one AEFs.

[0010] According to still other such aspects, the CCF is further configured to refrain from requesting authorization from the RO if the requested authorization has already been obtained via the bulk authorization information.

[0011] According to yet other such aspects, an application service provider (ASP) to at least one of the at least one AEFs is configured to cause a parameter to be set at the CCF, wherein the parameter indicates whether requesting bulk authorization is permitted from the RO.

[0012] According to some aspects, the API invoker comprises one instance from among multiple application instances or versions of a first application server.

[0013] According to other aspects, the at least one AEF comprises two or more bundled AEFs.

[0014] According to other aspects, the bulk authorization information comprises authorization information for services exposed by two or more AEFs. According to some such aspects, the bulk authorization information comprises: a grant of authorization for a first AEF of the two or more AEFs; and a denial of authorization for a second AEF of the two or more AEFs.

[0015] According to some aspects, the RO is a user of a user equipment (UE) device.

[0016] According to some aspects, the bulk authorization information comprises: a list of service API names. According to other aspects, the bulk authorization information comprises: a list of AEF identifiers (IDs) . According to still other aspects, the bulk authorization  information comprises: a list of API IDs. According to yet other aspects, the bulk authorization information comprises: a list of key value pairs (e.g., an API name : attribute ID key value pair) .

[0017] According to other aspects, the bulk authorization information comprises: an Information Element (IE) of a service API publish request.

[0018] According to other aspects, the determination, by the at least one AEF, that the API invoker is authorized to invoke the service API is based, at least in part (i.e., because an API invoker and / or AEF should only be exposed to authorization information that is specific to themselves) , on the bulk authorization information.

[0019] According to other aspects, the determination, by the at least one AEF, that the API invoker is authorized to invoke the service API comprises: obtaining, by the at least one AEF, a service API access control policy. According to some such aspects, the service API access control policy is obtained from a Common API Framework (CAPIF) core function (CCF) .

[0020] According to other aspects, the authorization information is stored as part of security information generated by a Common API Framework (CAPIF) in response to a registration request received from an API provider domain.

[0021] According to other aspects, the API invoker comprises an Edge Application Server (EAS) , and wherein the EAS is configured to provide API provider domain function. According to some such aspects, at least one of the at least one AEF comprises an Edge Enabler Server (EES) , and wherein the EES is configured to host a Common API Framework (CAPIF) core function (CCF) function.

[0022] The various methods and techniques summarized in this section may likewise be performed by a device comprising: a receiver; a transmitter; at least one interface; and a processor configured to perform any of the various methods and techniques summarized herein.  The various methods and techniques summarized in this section may likewise be stored as instructions in a non-transitory computer-readable medium, wherein the instructions, when executed, cause the performance of the various methods and techniques summarized herein.

[0023] This Summary is intended to provide a brief overview of some of the subject matter described in this document. Accordingly, it will be appreciated that the above-described features are merely examples and should not be construed to narrow the scope or spirit of the subject matter described herein in any way. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following Detailed Description, Figures, and Claims.BRIEF DESCRIPTION OF DRAWINGS

[0024] A better understanding of the present subject matter may be obtained when the following detailed description of various aspects is considered in conjunction with the following drawings:

[0025] Figure 1 illustrates an example wireless communication system, according to some aspects.

[0026] Figure 2 illustrates another example of a wireless communication system, according to some aspects.

[0027] Figure 3 illustrates an example block diagram of a UE, according to some aspects.

[0028] Figure 4 illustrates an example block diagram of a Base Station (BS) , according to some aspects.

[0029] Figure 5A illustrates an exemplary high-level Common API Framework (CAPIF) architecture, according to some aspects.

[0030] Figure 5B illustrates the exemplary Third Generation Partnership Project (3GPP) EDGEAPP architecture.

[0031] Figure 6A illustrates a diagram detailing a method of an API invoker obtaining authorization from a resource owner, according to some aspects.

[0032] Figure 6B illustrates a diagram detailing a method of an API publishing function publishing service API service requests, according to some aspects.

[0033] Figure 6C illustrates a diagram detailing a method of an API exposing function (AEF) obtaining a service API access control policy, according to some aspects.

[0034] Figure 6D illustrates a diagram detailing a method of registering API provider domain functions on CAPIF, according to some aspects.

[0035] Figure 7 is a flowchart detailing a method of obtaining bulk authorization from a resource owner, according to some aspects.

[0036] While the features described herein may be susceptible to various modifications and alternative forms, specific aspects thereof are shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to be limiting to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the subject matter as defined by the appended claims.DETAILED DESCRIPTION

[0037] This disclosure provides methods for an application service provider (ASP) to register the enablement of bulk registration of user authorization (e.g., a user’s authorization for certain information-or types of information-to be shared with certain other entities) for application programming interface (API) invokers across one or more API exposing functions  (AEFs) . This functionality may be enabled by providing user authorization-related parameters when registration towards the Common API Framework (CAPIF) core function (CCF) is initiated from the API provider domain. Following such registration, when an API invoker requests to obtain resource owner authorization information, the CCF, e.g., via its authorization function, can request bulk authorization (e.g., user authorization permissions) from the resource owner (RO) (i.e., if such authorization hasn’ t already been captured) , e.g., via the resource owner function (ROF) .

[0038] The following is a glossary of additional terms that may be used in this disclosure:

[0039] Memory Medium –Any of various types of non-transitory memory devices or storage devices. The term “memory medium” is intended to include an installation medium, (e.g., a CD-ROM, floppy disks, or tape device; a computer system memory or random-access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM) , a non-volatile memory such as a Flash, magnetic media (e.g., a hard drive, or optical storage; registers, or other similar types of memory elements) . The memory medium may include other types of non-transitory memory as well or combinations thereof. In addition, the memory medium may be located in a first computer system in which the programs are executed or may be located in a second different computer system which connects to the first computer system over a network, such as the Internet. In the latter instance, the second computer system may provide program instructions to the first computer for execution. The term “memory medium” may include two or more memory mediums which may reside in different locations (e.g., in different computer systems that are connected over a network) . The memory medium may store program instructions (e.g., embodied as computer programs) that may be executed by one or more processors.

[0040] Carrier Medium –a memory medium as described above, as well as a physical  transmission medium, such as a bus, network, and / or other physical transmission medium that conveys signals such as electrical, electromagnetic, or digital signals.

[0041] Programmable Hardware Element -includes various hardware devices comprising multiple programmable function blocks connected via a programmable interconnect. Examples include FPGAs (Field Programmable Gate Arrays) , PLDs (Programmable Logic Devices) , FPOAs (Field Programmable Object Arrays) , and CPLDs (Complex PLDs) . The programmable function blocks may range from fine grained (combinatorial logic or look up tables) to coarse grained (arithmetic logic units or processor cores) . A programmable hardware element may also be referred to as “reconfigurable logic. ”

[0042] User Equipment (UE) (also “User Device, ” “UE Device, ” or “Terminal” ) –any of various types of computer systems or devices that are mobile or portable and that perform wireless communications. Examples of UE devices include mobile telephones or smart phones (e.g., iPhoneTM, AndroidTM-based phones) , portable gaming devices (e.g., Nintendo SwitchTM, Nintendo DSTM, PlayStation VitaTM, PlayStation PortableTM, Gameboy AdvanceTM, iPhoneTM) , laptops, wearable devices (e.g., smart watch, smart glasses) , PDAs, portable Internet devices, music players, data storage devices, other handheld devices, in-vehicle infotainment (IVI) , in-car entertainment (ICE) devices, an instrument cluster, head-up display (HUD) devices, onboard diagnostic (OBD) devices, dashtop mobile equipment (DME) , mobile data terminals (MDTs) , Electronic Engine Management System (EEMS) , electronic / engine control units (ECUs) , electronic / engine control modules (ECMs) , embedded systems, microcontrollers, control modules, engine management systems (EMS) , networked or “smart” appliances, machine type communications (MTC) devices, machine-to-machine (M2M) , internet of things (IoT) devices, and the like. In general, the terms “UE” or “UE device” or “terminal” or “user device” may be broadly defined to encompass any electronic, computing, and / or  telecommunications device (or combination of devices) that is easily transported by a user (or vehicle) and capable of wireless communication.

[0043] Wireless Device –any of various types of computer systems or devices that perform wireless communications. A wireless device may be portable (or mobile) or may be stationary or fixed at a certain location. A UE is an example of a wireless device.

[0044] Communication Device –any of various types of computer systems or devices that perform communications, where the communications may be wired or wireless. A communication device may be portable (or mobile) or may be stationary or fixed at a certain location. A wireless device is an example of a communication device. A UE is another example of a communication device.

[0045] Base Station –The terms “base station, ” “wireless base station, ” or “wireless station” have the full breadth of their ordinary meaning, and at least includes a wireless communication station installed at a fixed location and used to communicate as part of a wireless telephone system or radio system. For example, if the base station is implemented in the context of LTE, it may alternately be referred to as an ‘eNodeB’ or ‘eNB’ . If the base station is implemented in the context of 5G NR, it may alternately be referred to as a ‘gNodeB’ or ‘gNB’ . Although certain aspects are described in the context of LTE or 5G NR, references to “eNB, ” “gNB, ” “nodeB, ” “base station, ” “NB, ” and the like, may refer to one or more wireless nodes that service a cell to provide a wireless connection between user devices and a wider network generally and that the concepts discussed are not limited to any particular wireless technology. Although certain aspects are described in the context of LTE or 5G NR, references to “eNB, ” “gNB, ” “nodeB, ” “base station, ” “NB, ” and the like, are not intended to limit the concepts discussed herein to any particular wireless technology and the concepts discussed may be applied in any wireless system.

[0046] Node –The term “node, ” or “wireless node” as used herein, may refer to one more apparatus associated with a cell that provide a wireless connection between user devices and a wired network generally.

[0047] Processing Element (or Processor) –refers to various elements or combinations of elements that are capable of performing a function in a device, such as a user equipment or a cellular network device. Processing elements may include, for example: processors and associated memory, portions or circuits of individual processor cores, entire processor cores, individual processors, processor arrays, circuits such as an Application Specific Integrated Circuit (ASIC) , programmable hardware elements such as a field programmable gate array (FPGA) , as well any of various combinations of the above.

[0048] Channel -a medium used to convey information from a sender (transmitter) to a receiver. It should be noted that since characteristics of the term “channel” may differ according to different wireless protocols, the term “channel” as used herein may be considered as being used in a manner that is consistent with the standard of the type of device with reference to which the term is used. In some standards, channel widths may be variable (e.g., depending on device capability, band conditions, and the like) . For example, LTE may support scalable channel bandwidths from 1.4 MHz to 20MHz. WLAN channels may be 22MHz wide while Bluetooth channels may be 1Mhz wide. Other protocols and standards may include different definitions of channels. Furthermore, some standards may define and use multiple types of channels (e.g., different channels for uplink or downlink and / or different channels for different uses such as data, control information, and the like) .

[0049] Band -The term “band” has the full breadth of its ordinary meaning, and at least includes a section of spectrum (e.g., radio frequency spectrum) in which channels are used or set aside for the same purpose.

[0050] Configured to -Various components may be described as “configured to” perform a task or tasks. In such contexts, “configured to” is a broad recitation generally meaning “having structure that” performs the task or tasks during operation. As such, the component may be configured to perform the task even when the component is not currently performing that task (e.g., a set of electrical conductors may be configured to electrically connect a module to another module, even when the two modules are not connected) . In some contexts, “configured to” may be a broad recitation of structure generally meaning “having circuitry that” performs the task or tasks during operation. As such, the component may be configured to perform the task even when the component is not currently on. In general, the circuitry that forms the structure corresponding to “configured to” may include hardware circuits.

[0051] Various components may be described as performing a task or tasks, for convenience in the description. Such descriptions should be interpreted as including the phrase “configured to. ” Reciting a component that is configured to perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112 (f) interpretation for that component.

[0052] Example Wireless Communication System

[0053] Turning now to Figure 1, a simplified example of a wireless communication system is illustrated, according to some aspects. It is noted that the system of Figure 1 is a non-limiting example of a possible system, and that features of this disclosure may be implemented in any of various systems, as desired.

[0054] As shown, the example wireless communication system includes a base station 102A, which communicates over a transmission medium with one or more user devices 106A and 106B, through 106N. Each of the user devices may be referred to herein as a “user equipment” (UE) . Thus, the user devices 106 are referred to as UEs or UE devices.

[0055] The base station (BS) 102A may be a base transceiver station (BTS) or cell site (e.g., a “cellular base station” ) and may include hardware that enables wireless communication with the UEs 106A through 106N.

[0056] The communication area (or coverage area) of the base station may be referred to as a “cell. ” The base station 102A and the UEs 106 may be configured to communicate over the transmission medium using any of various radio access technologies (RATs) , also referred to as wireless communication technologies, or telecommunication standards, such as GSM, UMTS (associated with, for example, WCDMA or TD-SCDMA air interfaces) , LTE, LTE-A, 5G NR, HSPA, 3GPP2 CDMA2000. Note that if the base station 102A is implemented in the context of LTE, it may alternately be referred to as an ‘eNodeB’ or ‘eNB’ . Note that if the base station 102A is implemented in the context of 5G NR, it may alternately be referred to as a ‘gNodeB’ or ‘gNB’ .

[0057] In some aspects, the UEs 106 may be IoT UEs, which may comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections. An IoT UE may utilize technologies such as M2M or MTC for exchanging data with an MTC server or device via a public land mobile network (PLMN) , proximity service (ProSe) or device-to-device (D2D) communication, sensor networks, or IoT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An IoT network describes interconnecting IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) , with short-lived connections. As an example, vehicles to everything (V2X) may utilize ProSe features using an SL interface for direct communications between devices. The IoT UEs may also execute background applications (e.g., keep-alive messages, status updates, and the like) to facilitate the connections of the IoT network.

[0058] As shown, the UEs 106, such as UE 106A and UE 106B, may directly exchange communication data via an SL interface 108. The SL interface 108 may be a PC5 interface comprising one or more physical channels, including but not limited to a Physical Sidelink Shared Channel (PSSCH) , a Physical Sidelink Control Channel (PSCCH) , a Physical Sidelink Broadcast Channel (PSBCH) , and a Physical Sidelink Feedback Channel (PSFCH) .

[0059] In V2X scenarios, one or more of the base stations 102 may be or act as Road Side Units (RSUs) . The term RSU may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable wireless node or a stationary (or relatively stationary) UE, where an RSU implemented in or by a UE may be referred to as a “UE-type RSU, ” an RSU implemented in or by an eNB may be referred to as an “eNB-type RSU, ” an RSU implemented in or by a gNB may be referred to as a “gNB-type RSU, ” and the like. In one example, an RSU is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicle UEs (vUEs) . The RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications / software to sense and control ongoing vehicular and pedestrian traffic. The RSU may operate on the 5.9 GHz Intelligent Transport Systems (ITS) band to provide very low latency communications required for high speed events, such as crash avoidance, traffic warnings, and the like. Additionally, or alternatively, the RSU may operate on the cellular V2X band to provide the aforementioned low latency communications, as well as other cellular communications services. Additionally, or alternatively, the RSU may operate as a Wi-Fi hotspot (2.4 GHz band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communications. The computing device (s) and some or all of the radio frequency circuitry of the RSU may be packaged in a weather enclosure suitable for outdoor installation, and it may include a network  interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller and / or a backhaul network.

[0060] As shown, the base station 102A may also be equipped to communicate with a network 100 (e.g., a core network of a cellular service provider, a telecommunication network such as a public switched telephone network (PSTN) , and / or the Internet, among various possibilities) . Thus, the base station 102A may facilitate communication between the user devices and / or between the user devices and the network 100. In particular, the cellular base station 102A may provide UEs 106 with various telecommunication capabilities, such as voice, SMS and / or data services.

[0061] Base station 102A and other similar base stations (such as base stations 102B through 102N) operating according to the same or a different cellular communication standard may thus be provided as a network of cells, which may provide continuous or nearly continuous overlapping service to UEs 106A-106N and similar devices over a geographic area via one or more cellular communication standards.

[0062] Thus, while base station 102A may act as a “serving cell” for UEs 106A-106N as illustrated in Figure 1, each UE 106 may also be capable of receiving signals from (and possibly within communication range of) one or more other cells (which may be provided by base stations 102B-102N and / or any other base stations) , which may be referred to as “neighboring cells. ” Such cells may also be capable of facilitating communication between user devices and / or between user devices and the network 100. Such cells may include “macro” cells, “micro” cells, “pico” cells, and / or cells which provide any of various other granularities of service area size. For example, base stations 102A and 102B illustrated in Figure 1 may be macro cells, while base station 102N may be a micro cell. Other configurations are also possible.

[0063] In some aspects, base station 102A may be a next generation base station, (e.g., a 5G New Radio (5G NR) base station, or “gNB” ) . In some aspects, a gNB may be connected to a legacy evolved packet core (EPC) network and / or to a NR core (NRC)  / 5G core (5GC) network. In addition, a gNB cell may include one or more transition and reception points (TRPs) . In addition, a UE capable of operating according to 5G NR may be connected to one or more TRPs within one or more gNBs. For example, it may be possible that that the base station 102A and one or more other base stations 102 support joint transmission, such that UE 106 may be able to receive transmissions from multiple base stations (and / or multiple TRPs provided by the same base station) . For example, as illustrated in Figure 1, both base station 102A and base station 102C are shown as serving UE 106A.

[0064] Note that a UE 106 may be capable of communicating using multiple wireless communication standards. For example, the UE 106 may be configured to communicate using a wireless networking (e.g., Wi-Fi) and / or peer-to-peer wireless communication protocol (e.g., Bluetooth, Wi-Fi peer-to-peer, and the like) in addition to at least one of the cellular communication protocol discussed in the definitions above. The UE 106 may also or alternatively be configured to communicate using one or more global navigational satellite systems (GNSS) (e.g., GPS or GLONASS) , one or more mobile television broadcasting standards (e.g., ATSC-M / H) , and / or any other wireless communication protocol, if desired. Other combinations of wireless communication standards (including more than two wireless communication standards) are also possible.

[0065] As illustrated in Figure 2, in one or more embodiments, the UE 106 may be a device with cellular communication capability such as a mobile phone, a hand-held device, a computer, a laptop, a tablet, a smart watch, or other wearable device, or virtually any type of wireless device.

[0066] The UE 106 may include a processor (processing element) that is configured to execute program instructions stored in memory. The UE 106 may perform any of the method aspects described herein by executing such stored instructions. Alternatively, or in addition, the UE 106 may include a programmable hardware element such as an FPGA (field-programmable gate array) , an integrated circuit, and / or any of various other possible hardware components that are configured to perform (e.g., individually or in combination) any of the method aspects described herein, or any portion of any of the method aspects described herein.

[0067] The UE 106 may include one or more antennas for communicating using one or more wireless communication protocols or technologies. In some aspects, the UE 106 may be configured to communicate using, for example, NR or LTE using at least some shared radio components. As additional possibilities, the UE 106 could be configured to communicate using CDMA2000 (1xRTT  / 1xEV-DO  / HRPD  / eHRPD) or LTE using a single shared radio and / or GSM or LTE using the single shared radio. The shared radio may couple to a single antenna, or may couple to multiple antennas (e.g., for a multiple-input multiple output (MIMO) configuration) for performing wireless communications. In general, a radio may include any combination of a baseband processor, analog RF signal processing circuitry (e.g., including filters, mixers, oscillators, amplifiers, and the like) , or digital processing circuitry (e.g., for digital modulation as well as other digital processing) . Similarly, the radio may implement one or more receive and transmit chains using the aforementioned hardware. For example, the UE 106 may share one or more parts of a receive and / or transmit chain between multiple wireless communication technologies, such as those discussed above.

[0068] In some aspects, the UE 106 may include separate transmit and / or receive chains (e.g., including separate antennas and other radio components) for each wireless communication protocol with which it is configured to communicate. As a further possibility,  the UE 106 may include one or more radios which are shared between multiple wireless communication protocols, and one or more radios which are used exclusively by a single wireless communication protocol. For example, the UE 106 might include a shared radio for communicating using either of LTE or 5G NR (or either of LTE or 1xRTT, or either of LTE or GSM, among various possibilities) , and separate radios for communicating using each of Wi-Fi and Bluetooth. Other configurations are also possible.

[0069] In some aspects, a downlink resource grid may be used for downlink transmissions from any of the base stations 102 to the UEs 106, while uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. Such a time-frequency plane representation is a common practice for Orthogonal Frequency Division Multiplexing (OFDM) systems, which makes it intuitive for radio resource selection. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in a resource grid is denoted as a resource element. Each resource grid may comprise a number of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements. There are several different physical downlink channels that are conveyed using such resource blocks.

[0070] The physical downlink shared channel (PDSCH) may carry user data and higher layer signaling to the UEs 106. The physical downlink control channel (PDCCH) may carry information about the transport format and resource allocations related to the PDSCH channel, among other things. It may also inform the UEs 106 about the transport format, resource allocation, and HARQ (Hybrid Automatic Repeat Request) information related to the uplink  shared channel. Typically, downlink scheduling (assigning control and shared channel resource blocks to the UE 102 within a cell) may be performed at any of the base stations 102 based on channel quality information fed back from any of the UEs 106. The downlink resource assignment information may be sent on the PDCCH used for (e.g., assigned to) each of the UEs.

[0071] The PDCCH may use control channel elements (CCEs) to convey the control information. Before being mapped to resource elements, the PDCCH complex-valued symbols may first be organized into quadruplets, which may then be permuted using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements known as resource element groups (REGs) . Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH may be transmitted using one or more CCEs, depending on the size of the Downlink Control Information (DCI) and the channel condition. There may be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation level, L=1, 2, 4, or 8) .

[0072] Example Communication Device

[0073] Figure 3 illustrates an example simplified block diagram of a communication device 106, according to some aspects. It is noted that the block diagram of the communication device of Figure 3 is only one example of a possible communication device. According to aspects, communication device 106 may be a UE device or terminal, a mobile device or mobile station, a wireless device or wireless station, a desktop computer or computing device, a mobile computing device (e.g., a laptop, notebook, or portable computing device) , a tablet, and / or a combination of devices, among other devices. As shown, the communication device 106 may include a set of components configured to perform core functions. For example, this set of  components may be implemented as a system on chip (SOC) , which may include portions for various purposes. Alternatively, this set of components may be implemented as separate components or groups of components for the various purposes. The set of components may be coupled (e.g., communicatively; directly or indirectly) to various other circuits of the communication device 106.

[0074] For example, the communication device 106 may include various types of memory (e.g., including NAND flash 310) , an input / output interface such as connector I / F 320 (e.g., for connecting to a computer system; dock; charging station; input devices, such as a microphone, camera, keyboard; output devices, such as speakers; and the like) , the display 360, which may be integrated with or external to the communication device 106, and wireless communication circuitry 330 (e.g., for LTE, LTE-A, NR, UMTS, GSM, CDMA2000, Bluetooth, Wi-Fi, NFC, GPS, and the like) . In some aspects, communication device 106 may include wired communication circuitry (not shown) , such as a network interface card (e.g., for Ethernet connection) .

[0075] The wireless communication circuitry 330 may couple (e.g., communicatively; directly or indirectly) to one or more antennas, such as antenna (s) 335 as shown. The wireless communication circuitry 330 may include cellular communication circuitry and / or short to medium range wireless communication circuitry, and may include multiple receive chains and / or multiple transmit chains for receiving and / or transmitting multiple spatial streams, such as in a MIMO configuration.

[0076] In some aspects, as further described below, cellular communication circuitry 330 may include one or more receive chains (including and / or coupled to (e.g., communicatively; directly or indirectly) dedicated processors and / or radios) for multiple Radio Access Technologies (RATs) (e.g., a first receive chain for LTE and a second receive chain for 5G  NR) . In addition, in some aspects, cellular communication circuitry 330 may include a single transmit chain that may be switched between radios dedicated to specific RATs. For example, a first radio may be dedicated to a first RAT (e.g., LTE) and may be in communication with a dedicated receive chain and a transmit chain shared with a second radio. The second radio may be dedicated to a second RAT (e.g., 5G NR) and may be in communication with a dedicated receive chain and the shared transmit chain. In some aspects, the second RAT may operate at mmWave frequencies. As mmWave systems operate in higher frequencies than typically found in LTE systems, signals in the mmWave frequency range are heavily attenuated by environmental factors. To help address this attenuating, mmWave systems often utilize beamforming and include more antennas as compared LTE systems. These antennas may be organized into antenna arrays or panels made up of individual antenna elements. These antenna arrays may be coupled to the radio chains.

[0077] The communication device 106 may also include and / or be configured for use with one or more user interface elements.

[0078] The communication device 106 may further include one or more smart cards 345 that include Subscriber Identity Module (SIM) functionality, such as one or more Universal Integrated Circuit Card (s) (UICC (s) ) cards 345.

[0079] As shown, the SOC 300 may include processor (s) 302, which may execute program instructions for the communication device 106 and display circuitry 304, which may perform graphics processing and provide display signals to the display 360. The processor (s) 302 may also be coupled to memory management unit (MMU) 340, which may be configured to receive addresses from the processor (s) 302 and translate those addresses to locations in memory (e.g., memory 306, read only memory (ROM) 350, NAND flash memory 310) and / or to other circuits or devices, such as the display circuitry 304, wireless communication circuitry 330, connector  I / F 320, and / or display 360. The MMU 340 may be configured to perform memory protection and page table translation or set up. In some aspects, the MMU 340 may be included as a portion of the processor (s) 302.

[0080] As noted above, the communication device 106 may be configured to communicate using wireless and / or wired communication circuitry. As described herein, the communication device 106 may include hardware and software components for implementing any of the various features and techniques described herein. The processor 302 of the communication device 106 may be configured to implement part or all of the features described herein (e.g., by executing program instructions stored on a memory medium) . Alternatively (or in addition) , processor 302 may be configured as a programmable hardware element, such as a Field Programmable Gate Array (FPGA) , or as an Application Specific Integrated Circuit (ASIC) . Alternatively (or in addition) the processor 302 of the communication device 106, in conjunction with one or more of the other components 300, 304, 306, 310, 320, 330, 340, 345, 350, 360 may be configured to implement part or all of the features described herein.

[0081] In addition, as described herein, processor 302 may include one or more processing elements. Thus, processor 302 may include one or more integrated circuits (ICs) that are configured to perform the functions of processor 302. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and the like) configured to perform the functions of processor (s) 302.

[0082] Further, as described herein, wireless communication circuitry 330 may include one or more processing elements. In other words, one or more processing elements may be included in wireless communication circuitry 330. Thus, wireless communication circuitry 330 may include one or more integrated circuits (ICs) that are configured to perform the functions of wireless communication circuitry 330. In addition, each integrated circuit may include  circuitry (e.g., first circuitry, second circuitry, and the like) configured to perform the functions of wireless communication circuitry 330.

[0083] Example Base Station

[0084] Figure 4 illustrates an example block diagram of a base station 102, according to some aspects. It is noted that the base station of Figure 4 is a non-limiting example of a possible base station. As shown, the base station 102 may include processor (s) 404 which may execute program instructions for the base station 102. The processor (s) 404 may also be coupled to memory management unit (MMU) 440, which may be configured to receive addresses from the processor (s) 404 and translate those addresses to locations in memory (e.g., memory 460 and read only memory (ROM) 450) or to other circuits or devices.

[0085] The base station 102 may include at least one network port 470. The network port 470 may be configured to couple to a telephone network and provide a plurality of devices, such as UE devices 106, access to the telephone network as described above in Figure 1.

[0086] The network port 470 (or an additional network port) may also or alternatively be configured to couple to a cellular network, e.g., a core network of a cellular service provider. The core network may provide mobility related services and / or other services to a plurality of devices, such as UE devices 106. In some cases, the network port 470 may couple to a telephone network via the core network, and / or the core network may provide a telephone network (e.g., among other UE devices serviced by the cellular service provider) .

[0087] In some aspects, base station 102 may be a next generation base station, (e.g., a 5G New Radio (5G NR) base station, or “gNB” ) . In such aspects, base station 102 may be connected to a legacy evolved packet core (EPC) network and / or to a NR core (NRC)  / 5G core (5GC) network. In addition, base station 102 may be considered a 5G NR cell and may include  one or more transition and reception points (TRPs) . In addition, a UE capable of operating according to 5G NR may be connected to one or more TRPs within one or more gNBs.

[0088] The base station 102 may include at least one antenna 434, and possibly multiple antennas. The at least one antenna 434 may be configured to operate as a wireless transceiver and may be further configured to communicate with UE devices 106 via radio 430. The antenna 434 communicates with the radio 430 via communication chain 432. Communication chain 432 may be a receive chain, a transmit chain or both. The radio 430 may be configured to communicate via various wireless communication standards, including 5G NR, LTE, LTE-A, GSM, UMTS, CDMA2000, Wi-Fi, and the like.

[0089] The base station 102 may be configured to communicate wirelessly using multiple wireless communication standards. In some instances, the base station 102 may include multiple radios, which may enable the base station 102 to communicate according to multiple wireless communication technologies. For example, as one possibility, the base station 102 may include an LTE radio for performing communication according to LTE as well as a 5G NR radio for performing communication according to 5G NR. In such a case, the base station 102 may be capable of operating as both an LTE base station and a 5G NR base station. When the base station 102 supports mmWave, the 5G NR radio may be coupled to one or more mmWave antenna arrays or panels. As another possibility, the base station 102 may include a multi-mode radio, which is capable of performing communications according to any of multiple wireless communication technologies (e.g., 5G NR and LTE, 5G NR and Wi-Fi, LTE and Wi-Fi, LTE and UMTS, LTE and CDMA2000, UMTS and GSM, and the like) .

[0090] Further, the BS 102 may include hardware and software components for implementing or supporting implementation of features described herein. The processor 404 of the base station 102 may be configured to implement or support implementation of part or  all of the methods described herein (e.g., by executing program instructions stored on a memory medium) . Alternatively, the processor 404 may be configured as a programmable hardware element, such as a Field Programmable Gate Array (FPGA) , or as an Application Specific Integrated Circuit (ASIC) , or a combination thereof. Alternatively (or in addition) the processor 404 of the BS 102, in conjunction with one or more of the other components 430, 432, 434, 440, 450, 460, 470 may be configured to implement or support implementation of part or all of the features described herein.

[0091] In addition, as described herein, processor (s) 404 may include one or more processing elements. Thus, processor (s) 404 may include one or more integrated circuits (ICs) that are configured to perform the functions of processor (s) 404. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and the like) configured to perform the functions of processor (s) 404.

[0092] Further, as described herein, radio 430 may include one or more processing elements. Thus, radio 430 may include one or more integrated circuits (ICs) that are configured to perform the functions of radio 430. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, and the like) configured to perform the functions of radio 430.

[0093] An Exemplary High-Level CAPIF Architecture

[0094] Turning now to Figure 5A, an exemplary high-level Common API Framework (CAPIF) architecture is illustrated, according to some aspects.

[0095] An API invoker (e.g., 5021) is typically provided by a third party application provider, who has service agreement with a PLMN operator. The API invoker (e.g., 5022) may also reside within the same trust domain 530 as the PLMN operator network. The API invoker  502 may be either an application on a server or an application on a UE. In some implementations, an API invoker may comprise one instance from among multiple application instances or versions of a first application server.

[0096] The API invoker 502 may support the following capabilities: triggering API invoker onboarding / offboarding; supporting authentication by providing the API invoker identity and other information required for authentication of the API invoker; supporting mutual authentication with CAPIF 506 (e.g., through the CAPIF-1 (521) or CAPIF-1e (521e) reference points) ; obtaining authorization prior to accessing the service APIs 514; discovering service APIs 514 information; and invoking the service APIs 514 (e.g., through the CAPIF-2 (522) or CAPIF-2e (522e) reference points) .

[0097] The API exposing function (AEF) 516 is the provider of the service APIs 514 and is also the service communication entry point of the service API 514 to the API invokers 502. The API exposing function 516 consists of the following capabilities (e.g., through the CAPIF-3 (523) reference point) : authenticating the API invoker based on the identity and other information required for authentication of the API invoker provided by the CAPIF core function 506; validating the authorization provided by the CAPIF core function 506; logging the service API invocations at the CAPIF core function 506; and hiding the topology of the PLMN trust domain 530 from API invokers 502, depending on configured policy.

[0098] The API publishing function 518 enables the API provider domain 512 to publish the service API’s 514 information, in order to enable the discovery of service APIs 514 by the API invoker 502. The API publishing function 518 consists of the following capabilities (e.g., through the CAPIF-4 (524) reference point) : publishing the service API 514 information of the API provider domain 512 to the CAPIF core function 506; and retrieving service API information from the CAPIF core function 506.

[0099] The authorization function 508 consists of the following capabilities: receiving authorization from the resource owner; and providing the API invoker 502 with the authorization information that is needed to access the resource owner’s resources. In some embodiments, the CCF provides an authorization token that the API Invoker will be expected to include in subsequent requests to the AEF.

[0100] The resource owner function 504 is responsible for interactions with the resource owner, in a similar way to the resource owner’s user agent (e.g., as shown in clause 4.1 of IETF RFC 6749) . The resource owner function 504 enables the following capabilities: authorization for resource access; and managing and revoking authorization for resource access (e.g., through the CAPIF-8 (528) reference point) . According to embodiments described herein, when requesting user authorization / consent over CAPIF-8, the request for user authorization / consent may be for one or more API invokers and / or AEF.

[0101] The CAPIF core function 506 consists of the following capabilities: authenticating the API invoker 502 based on the identity and other information required for authentication of the API invoker 502; supporting mutual authentication with the API invoker 502; providing authorization for the API invoker 502 prior to accessing the service API 514; publishing, storing and supporting the discovery of service APIs information; controlling the service API 514 access based on PLMN operator configured policies; storing the logs for the service API invocations and providing the service API invocation logs to authorized entities; charging based on the logs of the service API invocations; monitoring the service API invocations; onboarding a new API invoker and offboarding an API invoker; storing policy configurations related to CAPIF and service APIs; support accessing the logs for auditing (e.g. detecting abuse) ; supports publishing, retrieving, unpublishing, updating, and discovering service APIs information with another CAPIF core function in CAPIF interconnection; and supporting slice- related API exposure in, e.g., API publish, API discovery, API invoker authorization, API access control.

[0102] The API management function 520 enables the API provider domain 512 to perform administration of the service APIs 514. The API management function 520 enables the following capabilities (e.g., through the CAPIF-5 (525) reference point) : auditing the service API invocation logs received from the CAPIF core function; monitoring the events reported by the CAPIF core function; configuring the API provider policies to the CAPIF core function; monitoring the status of the service APIs; onboarding new API invokers and offboarding API invokers; and registering and maintaining registration information of the API provider domain functions on the CAPIF core function.

[0103] EDGEAPP: 3GPP Architecture for Enabling Edge Applications

[0104] The deployment of edge computing involves establishing relationships between multiple providers. Edge Computing Service Providers (ECSP) will play an important role in the construction of the infrastructure used by the Mobile Network Operators (MNO) and Application Service Providers (ASP) going forward, thereby enabling them to host their Edge applications close to the users. EDGEAPP is the 3GPP framework for enabling Edge Computing applications.

[0105] Turning now to Figure 5B, the exemplary 3GPP EDGEAPP architecture 550 is illustrated. The architecture 550 illustrated in Figure 5B is documented in further detail in 3GPP TS 23.558. The EDGEAPP architecture 550 comprises various components, including: an exemplary UE 552, the 3GPP core network 570, an Edge Data Network (EDN) 574, and an Edge Configuration Server (ECS) 586.

[0106] UE 552 may comprise various Application Clients (ACs) 554 that connect to an  Edge Enabler Client (EEC) 558, e.g., via an EDGE-5 reference point (556) . The EEC 558 may provide various support functions, such as Edge Application Server (EAS) discovery to the Application Clients 554 in the UE 552. EEC 558 may connect to an Edge Enabler Server (EES) 578, e.g., via an EDGE-1 reference point (560) and may connect to an Edge Configuration Server (ECS) 586 via an EDGE-4 reference point (562) . In the edge computing scenario, the UE 552 may communicate through the 3GPP core network 570 over the user plane 572, i.e., to send its application-level data traffic to the EDN 574. An EAS and EES are assumed to be co-located in the same Edge Hosting Environment (EHE) (wherein the EHE in EDGEAPP is functionally analogous to the MEC host in ETSI) . The EHE, as used here, refers to a specific data center, whereas Edge Data Network (EDN) 574 is considered to be a network providing “edge” (i.e., more localized) specific end-user services. An EDN may also have a specific service area, i.e., users have to be within a certain location to access the services of the EDN. Therefore, there may also be multiple physical EHEs within a particular EDN.

[0107] Edge Data Network (EDN) 574 may comprise one or more EASs 576 and one or more Edge Enabler Servers (EES) 578. The EES 578 is primarily responsible for enabling discovery of the EASs 576. The ECS 586 may be used to provide various configurations to the EEC 558 to connect with an EES 578 that, in turn, enables discovery of EASs 576. The ECS 586 may also be connected to EES 578 via an EDGE-6 reference point (584) . An EES may also have an interface to other EESs, e.g., via an EDGE-9 reference point (582) . EAS 576 may connect to EES 578 via an EDGE-3 reference point (580) .

[0108] The 3GPP core network 570 may: connect to ECS 586, e.g., via an EDGE-8 reference point (568) ; may connect to EES 578, e.g., via an EDGE-2 reference point (566) ; and may connect to an EAS 576 via an EDGE-7 reference point (564) .

[0109] Application Clients 554 on the UE 552 can be “Edge-aware” and “Edge-unaware. ”  With Edge-aware applications, the Application Clients 554 get the full benefit of the EDGEAPP architecture by directly interacting with-and thus leveraging-all of the benefits of the EEC 558.

[0110] Obtaining Bulk Authorization from a Resource Owner

[0111] Turning first to Figure 6A, a diagram 600 detailing a method of an API invoker 602 obtaining authorization from a resource owner 604 is shown, according to some aspects. As shown in diagram 600, the API invoker 602 requests, e.g., at Step 1 (610) , to obtain resource owner authorization information to invoke a service API exposed by the API exposing function 608. The CCF / authorization function 606 provides the authorization by interacting with the resource owner via the resource owner function 604. (Further details regarding the procedure to obtain the resource owner’s authorization information are specified in 3GPP TS 33.122 and TS 23.222. )

[0112] Next, at Step 2 (612) , the API invoker 602 sends a service API invocation request to the API exposing function 608 with the resource owner authorization information received in Step 1 (610) .

[0113] Finally, at Step 3 (614) , the API invoker 602 receives the service API invocation response resulting from the service API invocation request, i.e., once the API exposing function 608 has checked whether the API invoker 602 is authorized to invoke that service API, i.e., based on the authorization information.

[0114] In 3GPP TR 23.700-22, a key issue on managing resource owner authorization has been captured. In that, two open issues are considered that are discussed further in this disclosure: 1) How authorization of the resource owner can be managed through communication between the resource owner and authorization function in the CAPIF core  function; and 2) How to enable retrieval of the resource owner authorization parameters by an API exposing function (AEF) from the authorization function.

[0115] Currently, in order to obtain user authorization for accessing the services (e.g., resources) exposed by an AEF, each API invoker will make a request towards the CAPIF core function (CCF) authorization function that will, in turn, interact with the resource owner (RO) via the resource owner function (ROF) .

[0116] As mentioned above, one issue is that every API invoker that wishes to access the services of a particular AEF will trigger the authorization information flow towards the RO, thereby causing the RO potentially frequent disturbances, e.g., being asked repeatedly to consent for their AEF hosted information to be exposed.

[0117] Depending on configuration, this may even be the case when the API invokers are simply different application instances (or versions) of the same overall application server.

[0118] EDGEAPP (3GPP TS 23.558, clause 4.11) introduces the concept of a “direct bundle” Edge Application Server (EAS) , whereby an application client (AC) interacts with multiple EASs (with no coordination between the EASs) , so that the AC can obtain services from multiple EAS, then AC can process the data from multiple EASs and calculate the result based on the data obtained from multiple EASs. ” In this case, even though the EASs (serving, in this case, as API exposing functions) are associated (to provide a “bundled” service) , requests for resource owner authorization will still be individually triggered by the requests made to each EAS.

[0119] The bundle information (e.g., ID &requirements) may be provided by the Application Service Provider (ASP) through the EAS profile, which is provided to the EES at registration (and attributes of that may be shared with the ECS by the EES) .

[0120] As mentioned above, this disclosure provides a method for an application service provider (ASP) to register enabling bulk registration of user authorization (e.g., consent) for API invokers across one or more API exposing functions. According to some embodiments, this may be enabled by providing user authorization-related parameters when registration towards the CAPIF core function (CCF) is initiated from the API provider domain.

[0121] Following such registration, when an API invoker requests to obtain resource owner authorization information, the CCF / authorization function can request bulk authorization (e.g., user authorization permissions) from the resource owner (i.e., if such authorization hasn’ t already been captured) , e.g., via the resource owner function (see Figure 6A, Step 1 (610)) .

[0122] If the resource owner is the user of a UE, a notification service may be required to trigger a resource owner response. In addition to the request for bulk authorization, the resource owner may preferably be provided with the choice of granting only permissions for the requesting API invoker.

[0123] Each API invoker may be issued with its own unique access ( / refresh) token (e.g., via OAuth 2.0) , but common user authorization parameters may be provided (e.g., through the access token “scope” ) according to the resource owners preferences. In some implementations, the API invoker may be either an application on a server (typically assumed to be network-side) or an application on a UE.

[0124] The particular parameters and / or attributes requiring user authorization may be based on factors such as: user preference, local device manufacturer (or operating system) policy, operator policy, legislative requirement. Such requirements may preclude, or limit the scope, of the granting of bulk authorization.

[0125] 3GPP 23.222 clause 8.32 describes a nested API invocation scenario, in which an  API invocation towards a first API exposing function triggers that API exposing function to request an API invocation towards a second API exposing function. It’s expected that the initial API invoker request would trigger the AEF via the CCF to obtain user authorization, however, it may be that the AEF triggers such a request prior to requesting towards the second AEF, or that the second request is able to leverage the authorization obtained in the first request (i.e., bulk authorization is obtained for both invokers in a single request towards the resource owner) . When bulk registration is enabled, bulk user authorization registration update and de-registration should be supported. A subscription  / un-subscribe service should also be supported, e.g., to allow authorized subscribers to be notified about bulk user authorization registration statuses.

[0126] Turning now to Figure 6B, a diagram 620 detailing a method of an API publishing function 622 publishing service API service requests is shown, according to some aspects. First, at Step 1 (626) , the API publishing function 622 may send a service API publish request to the CAPIF core function (CCF) 624. Next, at block 628, CCF 624 may store the API information. Finally, at Step 3 (630) , the CCF 624 may send a service API publish response to API publishing function 622.

[0127] In some embodiments disclosed herein, the service API information (which may, e.g., include the service API name, API provider name (optional) , List of public IP ranges of UEs (optional) , service API type, service API status (e.g. active, inactive) , communication category, description, Serving Area Information (optional) , AEF location (optional) , interface details (e.g. IP address, port number, URI) , protocols, version numbers, data format, Service KPIs (optional) , and Network Slice Info (optional) ) may also include optional so-called “bulk user authorization configuration” information.

[0128] Examples of the user authorization configuration may include indications that bulk  user authorization is requested for one or more of: 1) a list of service API names (e.g., as part of a URI structure) ; 2) a list of AEF IDs (e.g., a string identifying the AEF) ; or 3) a list of API IDs (e.g., a string identifying the service API) .

[0129] According to some embodiments, only a subset of resources exposed by a service (e.g., AEF / API) may require user authorization (e.g., location or MSISDN) , i.e., resources wherein a finer-granularity control may be desired. In some such embodiments, key value pairs could be used to express that, e.g., {apiName : attribute-X} .

[0130] In still other embodiments, the “bulk user authorization configuration” information could be promoted to be an Information Element (IE) of the “Service API publish request” itself (i.e., rather than it being a sub-information element of the Service API information) . The response could then include an acknowledgment of the requested bulk user authorization configuration.

[0131] In still other embodiments, the “bulk user authorization configuration” could be included wherever “service API information” is shared, e.g., Service API publish requests / responses, Onboard API invoker responses, Service API get responses, Service API update requests / responses, Service API discover responses, Interconnection API publish requests, Interconnection service API discover responses, Interconnection get service API responses, and / or Interconnection update service API request  / responses. (Note that this wouldn’ t be the case in embodiments wherein the “bulk user authorization configuration” was stored as an Information Element of the “Service API publish request” itself. )

[0132] As mentioned above, the CAPIF core function is the central repository of all the policies related to service APIs. An AEF executes this procedure when it needs to obtain the policy to perform access control on the service API invocations (e.g., when a policy for  performing access control on service API is unavailable at the AEF) . According to some embodiments, the user authorization information may provide an indication that the AEF is permitted to request, for example, the bulk user authorization information from the RO via the CCF. The configuration data may be stored in the CAPIF core function and may be provided by the CAPIF administrator.

[0133] Turning next to Figure 6C, a diagram 640 detailing a method of an API exposing function (AEF) 642 obtaining a service API access control policy from a CCF 624 is shown, according to some aspects. First, at Step 1 (644) , the AEF 642 may request to obtain an access control policy request. For example, in some embodiments, an application service provider (ASP) (i.e., a provider of the AEF) may be configured to record, at the CCF 624, that bulk authorization is applicable (e.g., via an attribute relating to bulk authorization stored at API service registration by an AEF, or, as mentioned at Step 644, through a policy applied at the CCF 624 that the ASP later requests (or is able to invoke) . In other words, by providing such information in this manner, the CCF 624 knows to request bulk user authorization and manage the response (e.g., according to whatever level of authorization is provided by the RO, i.e., bulk authorization or no bulk authorization) .

[0134] Next, at block 646, the CCF 624 may check whether the AEF 642 is authorized to receive an access control policy for the service API. Finally, at Step 3 (648) , the CCF 624 may send an access control policy response back to AEF 642. According to some embodiments, rather than the AEF 642 telling the CCF 624 what the policy is, the CCF 624 is providing the policy to the AEF, e.g., so the AEF 642 knows that it can make a “bulk” request when it makes a request for user authorization.

[0135] Turning finally to Figure 6D, a diagram 660 detailing a method of registering API provider domain functions 664 on CAPIF 624 is shown, according to some aspects. According  to diagram 660, the API provider domain 662 may comprise one or more API provider domain functions 664 and an API management function 520 (as previously described, with reference to Figure 5A) . First, at Step 1 (668) , the API management function 520 may send a registration request to the CCF 624. Next, at Step 2 (646) , the CCF 624 may perform a validation operation on the registration request, as well as any subsequent processing of the request that is needed. For example, according to some embodiments, the CAPIF core function (CCF) 624 validates the received request and generates the identity and other security-related information for all the API provider domain functions listed in the registration request.

[0136] Next, at Step 3 (672) , the CCF 624 may send a registration response back to the API management function 520. Finally, at Step 4 (674) , the API provider domain 662 may determine how to handle the registration response received from the CCF. For example, according to some embodiments, the API management function 520 may configure the received information to the individual API provider domain functions (e.g., in terms of the AEFs) . According to some embodiments, there may also be registration update and de-registration procedures.

[0137] According to some embodiments, the list of API provider domain functions 664 could include: a list of API provider domain functions including role (e.g. AEF, APF, AMF, etc. ) and, if required, specific security information, which could further include the user authorization information.

[0138] EDGEAPP Example

[0139] As introduced above with reference to Figure 5B, EDGEAPP is the 3GPP framework for enabling Edge Computing applications. According to some implementations, the EDGEAP computing architecture can leverage CAPIF to offer application enabler layer  capabilities and services to the “application layer” which sits above it. According to some such implementations, through the Edge Application Server (EAS) registration procedure, the Application Service Provider (ASP) can provide desired configurations towards the Edge Enabler Server (EES) by utilizing the EAS profile. In this context, the EAS is serving as an API invoker of the EES, which is serving as an AEF.

[0140] However, in other implementations, a different deployment choice may be for the EAS to provide the API provider domain functions (including the AEF) and the EES to host the CCF. According to some such implementations, the application service provider is able to register that it desires to utilize the requesting of bulk user authorization prior to the request being sent to the resource owner for obtaining such authorization. In still other implementations, an EAS may offer services as a service provider, in which case it is essentially serving as an AEF. In yet further implementations, an EAS may act as both a service consumer and provider, e.g., whereby a different EAS (or EES) is the API Invoker for the service-producing EAS.

[0141] As mentioned above, in some such EDGEAPP implementations, it may be desirable to include an additional (optional) bulk user authorization configuration parameter / Information Element in the EAS profile. This bulk user authorization parameter may comprise, e.g., parameters relating to the ASP preferences with regards to obtaining bulk user authorization, e.g., a list of EASID, EASID + EAS endpoint, Bundle ID, Application Client ID (ACID) , etc.

[0142] Exemplary Methods

[0143] Turning now to Figure 7, a flowchart detailing a method 700 of obtaining bulk authorization from a resource owner is shown, according to some aspects. First, at block 702, the method of 700 may request, by an application programming interface (API) invoker, to  invoke a service exposed by at least one API exposing function (AEF) for which authorization information has been provided by a resource owner (RO) , wherein the authorization information comprises bulk authorization information. In some embodiments, the bulk authorization information may comprise: a grant of authorization for a first AEF of two or more bundled AEFs; and a denial of authorization for a second AEF of two or more bundled AEFs.

[0144] Next, at block 704, various options for block 702 are further detailed. For example, at block 704, the requesting may further comprise requesting authorization information via a Common API Framework (CAPIF) core function (CCF) . At block 706, another option is described, wherein the CCF is configured to interact with the RO to obtain the bulk authorization information (e.g., via at least one of the at least one AEFs) . In this way, the bulk authorization can be obtained in a manner that is transparent to the API Invoker, but the API Invoker is still able to benefit from such bulk authorization, e.g., if it subsequently requests a service from another AEF, for which consent was already granted in the bulk authorization request. At block 708, yet another option is described, wherein the CCF is further configured to refrain from requesting authorization from the RO if the requested authorization has already been obtained via the bulk authorization information. At block 710, still another option is described, wherein an application service provider to at least one of the AEFs is configured to cause a parameter to be set at the CCF, wherein the parameter indicates whether requesting bulk authorization is permitted from the RO.

[0145] Next, at block 712, the method of 700 may send, from the API invoker, a service API invocation request to the at least one AEF, wherein the service API invocation request includes the authorization information.

[0146] Finally, at block 714, the method 700 may receive, at the API invoker, a response to the service API invocation request based on a determination, by the at least one AEF, that  the API invoker is authorized to invoke the service API.

[0147] In one “group-based” use case scenario, there may be a user B requesting (i.e., as an API Invoker) a resource belonging to another user A (e.g., their location) , with user A acting as the “resource owner. ” The location of user A would thus be the resource hosted by the AEF that the AEF would need authorization from user A for before exposing such resource to user B. In a bulk user authorization scenario, multiple users may wish to know user A’s location, e.g., family members, friends, other gamers (in a specific game session, followers in a game, etc. ) , other application users (e.g., followers in a social media or sporting App) , etc. In these user-based (i.e., application layer) scenarios, the user is likely to be a UE-hosted API invoker. However, CAPIF would not need to be notified as to why such an application layer group exists, but, regardless, it could offer the ability to the application layer to request bulk user authorization for the group. For example, when the first user (e.g., user B) requests user A’s location, user authorization can be requested from user A, such that all other users in the group would be permitted to access user A’s location (or not, depending on what user A consents to) through their respective API invokers. Thus, in this scenario, there are multiple possible API invokers.

[0148] Additional Comments

[0149] The use of the connective term “and / or” is meant to represent all possible alternatives of the conjunction “and” and the conjunction “or. ” For example, the sentence “configuration of A and / or B” includes the meaning and of sentences “configuration of A and B”and “configuration of A or B. ”

[0150] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding  industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

[0151] Aspects of the present disclosure may be realized in any of various forms. For example, some aspects may be realized as a computer-implemented method, a computer-readable memory medium, or a computer system. Other aspects may be realized using one or more custom-designed hardware devices such as ASICs. Still other aspects may be realized using one or more programmable hardware elements such as FPGAs.

[0152] In some aspects, a non-transitory computer-readable memory medium may be configured so that it stores program instructions and / or data, where the program instructions, if executed by a computer system, cause the computer system to perform a method (e.g., any of a method aspects described herein, or, any combination of the method aspects described herein, or any subset of any of the method aspects described herein, or any combination of such subsets) .

[0153] In some aspects, a device (e.g., a UE 106, a BS 102) may be configured to include a processor (or a set of processors) and a non-transitory memory medium, where the memory medium stores program instructions, where the processor is configured to read and execute the program instructions from the memory medium, where the program instructions are executable to implement any of the various method aspects described herein (or, any combination of the method aspects described herein, or, any subset of any of the method aspects described herein, or, any combination of such subsets) . The device may be realized in any of various forms.

[0154] Although the aspects above have been described in considerable detail, numerous  variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

1.A method of obtaining bulk authorization from a resource owner (RO) , the method comprising:requesting, by an application programming interface (API) invoker, to invoke a service exposed by at least one API exposing function (AEF) for which authorization information has been provided by the RO, wherein the authorization information comprises bulk authorization information;sending, from the API invoker, a service API invocation request to the at least one AEF, wherein the service API invocation request includes the authorization information; andreceiving, at the API invoker, a response to the service API invocation request based on a determination, by the at least one AEF, that the API invoker is authorized to invoke the service API.2.The method of claim 1, wherein requesting, by the API invoker, to invoke a service exposed by at least one AEF for which authorization information has been provided by the RO further comprises:requesting authorization information via a Common API Framework (CAPIF) core function (CCF) .3.The method of claim 2, wherein the CCF is configured to interact with the RO to obtain the bulk authorization information.4.The method of claim 3, wherein the bulk authorization information is obtained by the CCF via at least one of the at least one AEFs.5.The method of claim 2, wherein the CCF is further configured to refrain from requesting authorization from the RO if the requested authorization has already been obtained via the bulk authorization information.6.The method of claim 2, wherein an application service provider (ASP) to at least one of the at least one AEFs is configured to cause a parameter to be set at the CCF, wherein the parameter indicates whether requesting bulk authorization is permitted from the RO.7.The method of claim 1, wherein the API invoker comprises one instance from among multiple application instances or versions of a first application server.8.The method of claim 1, wherein the at least one AEF comprises two or more bundled AEFs.9.The method of claim 1, wherein the bulk authorization information comprises authorization information for services exposed by two or more AEFs.10.The method of claim 9, wherein the bulk authorization information comprises: a grant of authorization for a first AEF of the two or more AEFs; and a denial of authorization for a second AEF of the two or more AEFs.11.The method of claim 1, wherein the RO is a user of a user equipment (UE) device.12.The method of claim 1, wherein the bulk authorization information comprises: a list of service API names.13.The method of claim 1, wherein the bulk authorization information comprises: a list of AEF identifiers (IDs) .14.The method of claim 1, wherein the bulk authorization information comprises: a list of API IDs.15.The method of claim 1, wherein the bulk authorization information comprises: a list of key value pairs.16.The method of claim 1, wherein the bulk authorization information comprises: an Information Element (IE) of a service API publish request.17.The method of claim 1, wherein the determination, by the at least one AEF, that the API invoker is authorized to invoke the service API is based, at least in part, on the bulk authorization information.18.The method of claim 1, wherein the determination, by the at least one AEF, that the API invoker is authorized to invoke the service API comprises:obtaining, by the at least one AEF, a service API access control policy.19.The method of claim 18, wherein the service API access control policy is obtained from a Common API Framework (CAPIF) core function (CCF) .20.The method of claim 1, wherein the authorization information is stored as part of security information generated by a Common API Framework (CAPIF) in response to a registration request received from an API provider domain.21.The method of claim 1, wherein the API invoker comprises an Edge Application Server (EAS) , and wherein the EAS is configured to provide API provider domain function.22.The method of claim 21, wherein at least one of the at least one AEF comprises an Edge Enabler Server (EES) , and wherein the EES is configured to host a Common API Framework (CAPIF) core function (CCF) function.23.A device comprising: a receiver; a transmitter; at least one interface; and a processor configured to perform any of the methods of claims 1–22.24.A non-transitory computer-readable medium that stores instructions that, when executed, cause the performance of any of the methods of claims 1–22.

Images