Application programming interface (API) invoker accessing resource(s) of a group of user equipment(s)

Abstract

A method performed by a common application programming interface (API) framework (CAPIF) core function is provided. The method includes receiving from an API invoker an authorization request for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs). The at least one resource is provided by a service API, and the authorization request includes an indication of the group of one or more UEs. The method includes determining the resource owner for the at least one resource based on the indication of the group of one or more UEs. The method includes means for obtaining consent of the resource owner to access the at least one resource, and sending, based on the authorization from the resource owner, authorization information to the API invoker for use in an invocation of the service API that provides the at least one resource.

Description

APPLICATION PROGRAMMING INTERFACE (API) INVOKER ACCESSING RESOURCE(S) OF A GROUP OF USER EQUIPMENT(S) TECHNOLOGICAL FIELD

[0001] The present disclosure relates generally to telecommunications and, in particular, to procedures in the common application programming interface (API) framework for API invoker to access resource(s) of a group of user equipment(s). BACKGROUND

[0002] A telecommunications system can be seen as a facility that enables communication sessions between two or more entities such as user terminals, base stations and / or other nodes by providing carriers between the various entities involved in the communications path. A telecommunications system can be provided for example by means of a communication network and one or more compatible communication devices. The communication sessions may comprise, for example, communication of data for carrying communications such as voice, video, electronic mail (email), text message, multimedia and / or content data and so on. Non-limiting examples of services provided comprise two-way or multi-way calls, data communication or multimedia services and access to a data network system, such as the Internet.

[0003] In a wireless telecommunications system, at least a part of a communication session between at least two stations occurs over a wireless link. Examples of wireless telecommunications systems comprise public land mobile networks (PLMN), satellite based communication systems and different wireless local networks, for example wireless local area networks (WLAN). Some wireless systems can be divided into cells, and are therefore often referred to as cellular systems.

[0004] A user can access the telecommunications system by means of an appropriate communication device or terminal. A communication device of a user may be referred to herein as user equipment (UE) or user device. A communication device is provided with an appropriate signal receiving and transmitting apparatus for enabling communications, for example enabling access to a communication network via an access node of the communication network or enabling communications directly with other user equipments. The communication device may access a carrier provided by a station, for example a base station of a cell, and transmit and / or receive communications on the carrier.

[0005] The telecommunications system and associated devices typically operate in accordance with a given standard or specification which sets out what the various entities associated with the communication system are permitted to do and how operations should be achieved. Communication protocols and / or parameters which shall be used for connection of the various entities are also typically defined. One example of a telecommunications system is the Universal Mobile Telecommunications System (UMTS). Other examples of telecommunications systems are Long-Term Evolution (LTE) networks, LTE Advancednetworks and the so-called 5G or New Radio (NR) networks. NR is being standardized by the 3rd Generation Partnership Project (3GPP). BRIEF SUMMARY

[0006] Example implementations of the present disclosure are directed to telecommunications and, in particular, to procedures in the common API framework for an application programming interface (API) invoker to access resource(s) of a group of user equipment(s). The present disclosure includes, without limitation, the following example implementations.

[0007] Some example implementations provide an apparatus for implementing an application programming interface (API) invoker in a common API framework (CAPIF), the apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory, and execute the instructions to cause the apparatus to at least: send, to a CAPIF core function, an authorization request for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs), the at least one resource provided by a service API, and the authorization request including an indication of the group of one or more UEs; receive, based on consent of the resource owner to access the at least one resource, authorization information, from the CAPIF core function, to access the service API that provides the at least one resource; and perform an invocation of the service API using the authorization information.

[0008] Some example implementations provide an apparatus for implementing an application programming interface (API) invoker in a common API framework (CAPIF), the apparatus comprising: means for sending, to a CAPIF core function, an authorization request for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs), the at least one resource provided by a service API, and the authorization request including an indication of the group of one or more UEs; means for receiving, based on consent of the resource owner to access the at least one resource, authorization information from the CAPIF core function to access the service API that provides the at least one resource; and means for performing an invocation of the service API using the authorization information.

[0009] Some example implementations provide a method performed by an application programming interface (API) invoker in a common API framework (CAPIF), the method comprising: sending, to a CAPIF core function, an authorization request for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs), the at least one resource provided by a service API, and the authorization request including an indication of the group of one or more UEs; receiving, based on consent of the resource owner to access the at least one resource, authorization information from the CAPIF core function to access the service API that provides the at least one resource; and performing an invocation of the service API using the authorization information.

[0010] Some example implementations provide an apparatus comprising: at least one memory configured to store instructions of a common application programming interface (API) framework (CAPIF) core function; and at least one processing circuitry configured to access the at least one memory, and execute the instructions to cause the apparatus to at least: receive, from an API invoker, an authorization request for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs), the at least one resource provided by a service API, and the authorization request including an indication of the group of one or more UEs; determine the resource owner for the at least one resource based on the indication of the group of one or more UEs; obtain consent of the resource owner to access the at least one resource; and send, based on the authorization from the resource owner, authorization information to the API invoker for use by the API invoker in performing an invocation of the service API that provides the at least one resource.

[0011] Some example implementations provide an apparatus for implementinga common application programming interface (API) framework (CAPIF) core function, the apparatus comprising: means for receiving, from an API invoker an authorization request for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs), the at least one resource provided by a service API, and the authorization request including an indication of the group of one or more UEs; means for determining the resource owner for the at least one resource based on the indication of the group of one or more UEs; means for obtaining consent of the resource owner to access the at least one resource; and means for sending, based on the authorization from the resource owner, authorization information to the API invoker for use by the API invoker in performing an invocation of the service API that provides the at least one resource.

[0012] Some example implementations provide a method performed by a common application programming interface (API) framework (CAPIF) core function, the method comprising: receiving, from an API invoker, an authorization request for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs), the at least one resource provided by a service API, and the authorization request including an indication of the group of one or more UEs; determining the resource owner for the at least one resource based on the indication of the group of one or more UEs; obtaining consent of the resource owner to access the at least one resource; and sending, based on the authorization from the resource owner, authorization information to the API invoker for use by the API invoker in performing an invocation of the service API that provides the at least one resource.

[0013] These and other features, aspects, and advantages of the present disclosure will be apparent from a reading of the following detailed description together with the accompanying figures, which are briefly described below. The present disclosure includes any combination of two, three, four or more features or elements set forth in this disclosure, regardless of whether such features or elements are expressly combined or otherwise recited in a specific example implementation described herein. The presentdisclosure is intended to be read holistically such that any separable features or elements of the disclosure, in any of its aspects and example implementations, should be viewed as combinable unless the context of the disclosure clearly dictates otherwise.

[0014] It will therefore be appreciated that this Brief Summary is provided merely for purposes of summarizing some example implementations so as to provide a basic understanding of some aspects of the disclosure. Accordingly, it will be appreciated that the above described example implementations are merely examples and should not be construed to narrow the scope or spirit of the disclosure in any way. Other example implementations, aspects and advantages will become apparent from the following detailed description taken in conjunction with the accompanying figures which illustrate, by way of example, the principles of some described example implementations. BRIEF DESCRIPTION OF THE FIGURE(S)

[0015] Having thus described example implementations of the disclosure in general terms, reference will now be made to the accompanying figures, which are not necessarily drawn to scale, and wherein:

[0016] FIG.1 illustrates a telecommunications system that includes one or more public land mobile networks (PLMNs) coupled to one or more external data networks, according to some example implementations of the present disclosure;

[0017] FIG.2 illustrates a deployment of a PLMN, according to some example implementations;

[0018] FIG.3 more particularly depicts aspects of the deployment of FIG.2, according to some example implementations;

[0019] FIG.4 illustrates a functional model for resource owner-aware northbound application programming interface (API) access in the common API framework (CAPIF), according to some example implementations;

[0020] FIG.5 is a signaling chart of procedures for an API invoker accessing at least one resource of a group of one or more user equipments (UEs), according to some example implementations;

[0021] FIG.6 is a signaling chart of procedures for an API invoker accessing resource(s) of a group of UE(s), according to other example implementations;

[0022] FIG.7 is a flowchart illustrating various steps in a method performed by an API invoker in a CAPIF, according to various example implementations;

[0023] FIGS.8A, 8B and 8C are flowcharts illustrating various steps in a method performed by a CAPIF core function, according to various example implementations;

[0024] FIG.9 illustrates an apparatus according to some example implementations.DETAILED DESCRIPTION

[0025] Some implementations of the present disclosure will now be described more fully hereinafter with reference to the accompanying figures, in which some, but not all implementations of the disclosure are shown. Indeed, various implementations of the disclosure may be embodied in many different forms and should not be construed as limited to the implementations set forth herein; rather, these example implementations are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. Like reference numerals refer to like elements throughout.

[0026] Unless specified otherwise or clear from context, references to first, second or the like should not be construed to imply a particular order. A feature described as being above another feature (unless specified otherwise or clear from context) may instead be below, and vice versa; and similarly, features described as being to the left of another feature else may instead be to the right, and vice versa. Also, while reference may be made herein to quantitative measures, values, geometric relationships or the like, unless otherwise stated, any one or more if not all of these may be absolute or approximate to account for acceptable variations that may occur, such as those due to engineering tolerances or the like.

[0027] As used herein, unless specified otherwise or clear from context, the “or” of a set of operands is the “inclusive or” and thereby true if and only if one or more of the operands is true, as opposed to the “exclusive or” which is false when all of the operands are true. Thus, for example, “[A] or [B]” is true if [A] is true, or if [B] is true, or if both [A] and [B] are true. Further, the articles “a” and “an” mean “one or more,” unless specified otherwise or clear from context to be directed to a singular form. Furthermore, it should be understood that unless otherwise specified, the terms “data,” “content,” “digital content,” “information,” and similar terms may be at times used interchangeably. The term “network” may refer to a group of interconnected computers including clients and servers; and within a network, these computers may be interconnected directly or indirectly by various means including via one or more switches, routers, gateways, access points or the like.

[0028] The present disclosure discusses systems and architectures that, while specific terms may be used, are broadly applicable across various technologies. For instance, while the present disclosure may reference technologies from 3GPP such as Global System for Mobile Communications (GSM), UMTS, LTE, LTE Advanced, 5G NR, 5G Advanced, and 6G, the present disclosure is equally relevant to non-3GPP technologies like IEEE 802, Bluetooth, and Bluetooth Low Energy. Example implementations of the present disclosure described herein also mention public land mobile networks (PLMNs) and mobile network operators (MNOs), but example implementations are similarly applicable to standalone non-public networks (SNPNs) and the private entities operating these networks. Furthermore, although some examples and figures focus on radio access networks (RANs) and 3GPP access, example implementations are applicable to any type of network access. This includes not only 5G or 6G 3GPP access but also non-3GPP access,such as wireline access, untrusted non-3GPP access, and trusted non-3GPP access using wireless access gateway function (W-AGF), non-3GPP interworking function (N3IWF), or trusted non-3GPP gateway function (TNGF) to connect to a 5G or 6G core network.

[0029] Further, as used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry); (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and / or digital hardware circuit(s) with software / firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions); or (c) hardware circuit(s) and / or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0030] The above definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device, such as a user equipment, or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0031] FIG.1 illustrates a telecommunications system 100 according to various example implementations of the present disclosure. The telecommunications system generally includes one or more telecommunications networks. As shown, for example, the system includes one or more PLMNs 102 coupled to one or more other external data networks 104 – notably including a wide area network (WAN) such as the Internet. Each of the PLMNs includes a core network (CN) 106 such as the Evolved Packet Core (EPC) of LTE, the 5G core network (5GC) or the like; and each of the core networks and the Internet are coupled to one or more RANs 108, air interfaces or the like that implement one or more radio access technologies (RATs). As used herein, a “network device” refers to any suitable device at a network side of a telecommunications network. Examples of suitable network devices are described in greater detail below.

[0032] In addition, the system includes one or more radio units that may be varyingly known as user equipment (UE) 110, terminal device, terminal equipment, mobile station or the like. The UE is generally a device configured to communicate with a network device or a further UE in a telecommunications network. The UE may be a portable computer (e.g., laptop, notebook, tablet computer), mobile phone (e.g., cell phone, smartphone), wearable computer (e.g., smartwatch), or the like. In other examples, the UE may be an Internet of things (IoT) device, an industrial IoT (IIoT device), a vehicle equipped with a vehicle-to-everything (V2X) communication technology, or the like. In some examples, as referenced by 3GPP, the UE may be a narrowband IoT (NB-IoT) device, an enhanced machine-type communication (eMTC) device, a reduced capability (RedCap) device, an ambient IoT device, or the like.

[0033] In operation, these UEs 110 may be configured to connect to one or more of the RANs 108 via radio access nodes, according to their particular radio access technologies to thereby access a particular CN 106 of a PLMN 102, or to access one or more of the external data networks 104 (e.g., the Internet). The external data network may be configured to provide Internet access, operator services, 3rd party services, etc. For example, the International Telecommunication Union (ITU) has classified 5G mobile network services into three categories: enhanced mobile broadband (eMBB), ultra-reliable and low-latency communications (URLLC), and massive machine type communications (mMTC) or massive internet of things (MIoT).

[0034] Examples of radio access technologies include 3GPP radio access technologies such as GSM, UMTS, LTE, LTE Advanced, 5G NR, 5G Advanced, and 6G. Other examples of radio access technologies include IEEE 802 technologies such as IEEE 802.11 (Wi-Fi), IEEE 802.15 (including 802.15.1 (WPAN / Bluetooth), 802.15.4 (Zigbee) and 802.15.6 (WBAN)), Bluetooth, Bluetooth Low Energy (BLE), ultra wideband (UWB), and the like. Generally, a radio access technology may refer to any 2G, 3G, 4G, 5G, 6G or higher generation mobile communication technology and their different versions, as well as to any other wireless radio access technology that may be arranged to interwork with such a mobile communication technology to provide access to the CN 106 of a mobile network operator (MNO).

[0035] In various examples, a RAN 108 may be configured as one or more macrocells, microcells, picocells, femtocells or the like. The RAN may generally include one or more radio access nodes that are configured to interact with UEs 110. In various examples, a radio access node may be referred to as a base station (BS), access point (AP), base transceiver station (BTS), Node B (NB), evolved NB (eNB), macro BS, NB (MNB) or eNB (MeNB), home BS, NB (HNB) or eNB (HeNB), next generation NB (gNB), enhanced gNB (en-gNB), next generation eNB (ng-eNB), or the like. The RAN may include some type of network controlling / governing entity responsible for control of the radio access nodes. The network controlling / governing entity and radio access node may be separate or integrated into a single apparatus. The network controlling / governing entity may include processing circuity configured to carry out various management functions, etc. The processing circuity may be associated with a memory, computer-readable storage medium or database for maintaining information required in the management functions.

[0036] A RAN 108 may be centralized or distributed. In various examples, components of a RAN may be interconnected by Ethernet, Gigabit Ethernet, Asynchronous Transfer Mode (ATM), optical fiber, dark fiber, passive wavelength division multiplexing (WDM), WDM passive optical network (WDM-PON), optical transport network (OTN), time sensitive networking (TSN) and / or any other data link layer network, possiblyincluding radio links. The RAN may be connected to a CN 106 through one or more gateways, network functions or the like.

[0037] As will be appreciated, a PLMN 102 may be deployed in a number of different manners. In a 4G LTE network , the EPC is the CN, and the evolved UMTS terrestrial radio access network (E-UTRAN) is the RAN; and the E-UTRAN includes one or more eNBs (radio access nodes) configured to connect UEs to the E-UTRAN to thereby access the EPC. FIG.2 illustrates a network 200, such as a 5G network or 6G network. As shown, the 5GC 202 is the CN 106, and the next generation (NG) radio access network (NG- RAN) 204 is the RAN 108; and the NG-RAN includes one or more gNBs 206 (radio access nodes) configured to connect UEs 110 to the NG-RAN to thereby access the 5GC (at times referred to as the NGC). The term ‘gNB’ in 5G may correspond to the eNB in 4G LTE.

[0038] Some deployments of 4G LTE networks and 5G networks in particular are considered standalone (SA) networks . Other networks combine 4G LTE and 5G technologies, and are referred to as non- standalone (NSA) networks . In some deployments, the E-UTRAN includes one or more ng-eNBs that are configured to communicate with the 5GC, and that may also be configured to communicate with one or more other gNBs. Similarly, in another deployment, the NG-RAN may include one or more en-gNBs that are configured to communicate with the EPC, and that may also be configured to communicate with one or more other eNBs. In various instances, a single UE 110, a dual-mode or multimode UE, may support multiple (two or more) RANs—thereby being configured to connect to multiple RANs, such as 4G LTE networks and 5G networks.

[0039] FIG.3 more particularly depicts aspects of the deployment 200 for a MNO network, according to some example implementations. As shown, the MNO deployment includes the 5GC 202, and NG-RAN 204 with one or more gNBs 206 configured to connect UEs 110 to the NG-RAN to thereby access the 5GC. The 5GC may include a number of network functions (NFs) divided between the control plane and the user plane. In particular, the 5GC may include, for example, an access and mobility management function (AMF) 302, a session management function (SMF) 304, a user plane function (UPF) 306, a unified data management (UDM) 308, a unified data repository (UDR) 310, a network exposure function (NEF) 312, and / or an application function (AF) 314. Other examples of suitable NFs include a network repository function (NRF), a network slice selection function (NSSF), a policy control function (PCF), or the like. Also shown is a server hosting an application, referred to as an application server (AS) 316.

[0040] In the control plane, the AMF 302 is configured to provide UE-based authentication, authorization, mobility management, etc. The SMF 304 is configured to provide various functionality including session management (SM), UE Internet Protocol (IP) address allocation and management, selection and control of UPF(s) 306, control part of policy enforcement and Quality of Service (QoS), lawful intercept, termination of SM parts of NAS messages, Downlink Data Notification (DNN), roaming functionality, handling of local enforcement to apply QoS for Service Level Agreements (SLAs), charging data collection and charginginterface functionality, etc. If the UE 110 has multiple sessions, different SMFs may be allocated to each session to manage each session individually and possibly provide different functionalities per session.

[0041] The UDM 308 serves as a centralized repository for user-related subscription and authentication data. The UDM manages user authentication, authorization, and profile information, ensuring secure and authorized access to the 5GC 202. The UDR 310 is responsible for storing and managing user-related data, including session and policy information. The UDR facilitates functionalities such as data storage, retrieval, and update, ensuring the maintenance of user-related information across the 5G network.

[0042] The UPF 306 supports various user plane operations and functionalities, such as packet routing and forwarding, traffic handling (e.g., QoS enforcement), acting as an anchor point for intra-RAT / inter-RAT mobility (when applicable), packet inspection and policy rule enforcement, lawful intercept (UP collection), traffic accounting and reporting, etc. The UPF is the point of interconnect between the 5GC and at least one external data network (DN) 318 (i.e., point of ingress or egress for a DN), and routes packets to and from the DN. The DN may be configured to provide Internet access, operator services, 3rd party services, etc.

[0043] The AF 314 may interact with the 5GC 202 to enable the deployment of specific services and applications. The AF communicates with other NFs to request and manage network resources, ensuring that the network adapts to the requirements of different applications and services. The NEF 312 allows authorized third-party applications and services to access specific network functions and services in a controlled manner. The NEF enables the exposure of network capabilities to external entities, fostering innovation and the development of new services.

[0044] In some deployments, such as network 200, operations of the gNB 206 or other radio access node may be carried out, at least partly, in a central / centralized unit (CU), such as a server, host or node, operationally coupled to a distributed unit (DU), such as a radio head / node. It is also possible that node operations may be distributed among a plurality of servers, hosts or nodes. It should also be understood that the distribution of work between 5GC 202 (or other CN) operations and gNB (or other radio access node) operations may vary depending on implementation.

[0045] A 5G network architecture may be based on a so-called CU-DU split. One gNB-CU (central node) may control one or more gNB-DUs. The gNB-CU may control a plurality of spatially separated gNB-DUs, acting at least as transmit / receive (Tx / Rx) nodes. In some example implementations, however, the gNB- DUs (also called DU) may include, for example, a radio link control (RLC), medium access control (MAC) layer and a physical (PHY) layer, whereas the gNB-CU (also called a CU) may include the layers above the RLC layer, such as a packet data convergence protocol (PDCP) layer, a radio resource control (RRC), and an internet protocol (IP) layer. Other functional splits are also possible. It is considered that a skilled person is familiar with the open systems interconnection (OSI) model and the functionalities within each layer.

[0046] In some example implementations, the server or CU may generate a virtual network through which the server communicates with the radio node. In general, virtual networking may involve a process of combining hardware and software network resources and network functionality into a single, software- based administrative entity, a virtual network. Such virtual network may provide flexible distribution of operations between the server and the radio head / node. In practice, any digital signal processing task may be performed in either the CU or the DU, and the boundary where the responsibility is shifted between the CU and the DU may be selected according to implementation.

[0047] In 3GPP, the common application programming interface (API) framework (CAPIF) defines a standardized set of interfaces and protocols for NFs to expose their capabilities to external applications and other NFs. The CAPIF defines common API structures, data formats, and communication protocols for accessing northbound APIs across NFs, and enables different applications and NFs to interact with each other, regardless of their implementation details. The CAPIF provides mechanisms (e.g., publish service APIs, authorization, logging, charging) to support service API operations. The CAPIF enables one or more API invokers to discover and communicate with service APIs from API providers.

[0048] FIG.4 illustrates a functional model 400 for the CAPIF. As shown, the CAPIF may be hosted within a PLMN trust domain 402 including a MNO’s PLMN 102 or a stand-alone non-public network (SNPN). An API invoker 404 may request access to a NF’s capabilities through CAPIF APIs. The API invoker may be provided by a third-party application provider who has a SLA with the MNO network. An API invoker may reside outside or within the same trust domain as the PLMN.

[0049] In the PLMN trust domain, the CAPIF includes a CAPIF core function (CCF) 406 and an API provider domain 408, and the API provider domain includes an API exposing function (AEF) 410, API publishing function (APF) 412, and API management function (AMF) 414 (together known as API provider domain functions).

[0050] The CAPIF core function 406 performs onboarding and offboarding of API invokers 404. The CAPIF core function handles authentication, authorization, and service API discovery requests from API invokers. It verifies the API invoker’s identity, checks permissions, and provides the API invoker with the information needed to invoke a service API via an API exposing function. The API exposing function 410 is the provider of service APIs, and serves as a service communication entry point of the service API to the API invokers. The API publishing function 412 enables an API provider to publish service APIs information in order to enable the discovery of service APIs by the API invoker, and the API management function 414 enables administration of service APIs by the API provider.

[0051] As also shown, the CAPIF includes a number of reference points between the various entities. The API invoker 404 within the PLMN trust domain 402 interacts with the CAPIF core function 406 via CAPIF-1, and interacts with the API exposing function 410 via CAPIF-2. The API invoker from outside the PLMN trust domain interacts with the CAPIF core function via CAPIF-1e, and interacts with the API exposing functionvia CAPIF-2e. The API exposing function, the API publishing function 412 and the API management function 414 of the API provider domain 408 interacts with the CAPIF core function via respective ones of CAPIF-3, CAPIF-4 and CAPIF-5 (CAPIF-3e, CAPIF-4e and CAPIF-5e if the API provider domain is not in the same PLMN trusted domain).

[0052] As also shown, the CAPIF may include enhancements to support resource owner-aware northbound API access (RNAA) which allows a resource owner (RO) to provide authorization to an API invocation. That is, RNAA is an API invocation scenario where the API invoker needs an authorization from the resource owner. As shown, the CAPIF core function 406 may include an authorization function 416. Resource owner (RO) function(s) 418 may interact with the authorization function in the CAPIF core function via CAPIF-8, and the RO may communicate with the authorization function to manage resource owner consent. In the context of RNAA, a resource is the object or component of the API on which the operations are acted upon. The RO is a UE user or an MNO subscriber capable of granting access to a protected resource related to the invoked API via resource owner function, and the RO function is the entity that that enables the authorization for resource access and managing and revoking authorization for resource access.

[0053] The CAPIF may be implemented in any of a number of different manners. In some examples, the API invoker 404 may be implemented by a UE 110, an AF 314, an AS 316, a service capability server (SCS) or the like. Likewise, in some examples, the CAPIF core function 406 and API provider domain functions (API exposing function 410, API publishing function 412, API management function 414) may be implemented by a NEF 312, a service capability exposure function (SCEF) or the like.

[0054] Also in 3GPP, an application enablement layer is provided to support third-party application developers and vertical-specific application providers. In the application enablement layer, the service enabler architecture layer (SEAL) supports communication and functionality between vertical applications (e.g., V2X applications) and the underlying network. The SEAL architecture includes a common set of services (e.g. group management, location management) and reference points. The SEAL offers its services to a vertical application layer (VAL), and the architecture includes functional entities on a UE 110 (referred to at times as a VAL UE) and a server that are grouped into SEAL client(s) and SEAL server(s). For example, SEAL and VAL may be utilized to provide extended reality (XS) and metaverse applications.

[0055] In the SEAL architecture, one or more SEAL clients provide client-side functionalities corresponding to one or more SEAL services, and one or more SEAL servers provide server-side functionalities of the corresponding SEAL service(s). The SEAL architecture also specifies northbound APIs that are compliant with CAPIF to enable flexible integration with vertical applications. In this regard, a SEAL server may operate as an API exposing function 410 to expose its API(s) through the CAPIF. As explained in greater detail below, one example of a SEAL server is a group management server (GMS), at times referred to as a SEAL-GMS.

[0056] In the CAPIF, an API invoker 404 may be deployed in a number of different manners. For example, an API invoker may be deployed as an AF on a UE 110 (e.g., as a third party application), or as an AF on the UE supporting several other third party applications deployed on the UE. In another example, an API invoker may be deployed on the network as an AF, such as AF 314. The resource owner may be considered to be connected via a UE and can interact using a resource owner function 418 deployed on the UE, with the CAPIF core function providing the authorization function 416 for authentication and authorization. That is, the CAPIF core function may provide the authorization function for enabling granting / denying permission of the resource owner to the API invoker to access resource(s) provided by a service API.

[0057] As currently specified by 3GPP, the scope of an API invoker 404 on a UE 110 in RNAA is limited to accessing its own resources only. That is, the resource owner is a user of the UE hosting the API invoker that can authorize the API access. However, there may be cases in which it is desirable to support for API invoker(s) deployed on a UE accessing resource(s) of other UEs. One example of such as case relates to vehicle health monitoring in fleet management in which an application client on one UE may desire to access location and / or vehicle health information for another user (another UE). In view of the foregoing, example implementations of the present disclosure provide information flows, information elements and related procedures which enable an API invoker, such as a UE-hosted API invoker, to access at least one protected resource (hosted in the network) of a group of one or more UEs (other UEs). Examples of suitable protected resources include location, QoS parameters, or the like.

[0058] In CAPIF, a resource owner (RO) is an entity, such as a MNO subscriber, capable of granting access to a protected resource provided by a service API; and in RNAA, an API invoker 404 may need an authorization of the resource owner. According to some example implementations of the present disclosure, a resource owner may be an entity capable of granting access to at least one (protected) resource of a group of UE(s) 110 (e.g., for V2X platooning scenarios). In some examples, the API invoker may be hosted in a UE that is a member of the group of UE(s). Likewise, in some examples, resource owner function 418 for the resource owner may be hosted in another UE that is also a member of the group of UE(s). The resource owner for the resource(s) of the group of UE(s) may at times be referred to as a group resource owner (gRO).

[0059] In some example implementations of the present disclosure, a group subscription may be in place in the UDM 308 / UDR 310, and the group subscription may include group subscription information. In other example implementations, a group may be created in a SEAL-GMS, and the group may have group information. In these examples, the group subscription information / group information may include information about the gRO, such as an identifier (ID) of the gRO (an ID at times also referred to as an identity). Examples of suitable IDs include a general publication subscription ID (GPSI), subscription permanent ID (SUPI), or the like. The group subscription information / group information may also includeother relevant information, such as a group ID associated with the group of UE(s), a list of ID(s) associated with respective UEs of the group of UE(s), or the like.

[0060] In some examples, the members of the group of UE(s) 110 may be categorized within the group. One category of member may be the gRO capable of granting access to resource(s) of the group of UE(s). In some more specific examples, the gRO may be hosted in a UE that is not resource constrained and has front-end capabilities). In some of these more specific examples, another category may be for members of the group that might be resource-constrained UEs, which may include UEs with lower hardware capabilities and without a front-end, such as IoT devices, IIoT devices, NB-IoT devices, eMTC devices, RedCap devices, ambient IoT devices, or the like. This categorization of the members may enable a standard for authentication referred to as client initiated backchannel authentication (CIBA). In this regard, CIBA defines a decoupled authentication flow in which a client application may initiate authentication flow on one device (consumption device), while the actual authentication occurs on a separate device (authentication device).

[0061] According to some example implementations, when an API invoker 404 (e.g., hosted in a UE 110) targets personal, protected or other resource(s) (e.g., location) of a group of UE(s), the API invoker may request authorization for access to a service API that provides the resource(s). The authorization request may be sent to the CAPIF core function 406 and addressed by the group ID or the list of ID(s) associated with the respective UE(s). The CAPIF core function may receive the request, identify or otherwise determine the gRO for the resource(s) of the group of UE(s), and contact the gRO to obtain consent on behalf of the member(s) of the group of UE(s) (also recognizing that the resource owner function 418 may be one of those members).

[0062] The CAPIF core function 406 may determine the gRO for the resource(s) of the group of UE(s) 110 in a number of different manners. In some examples in which the authorization request is addressed by the group ID, and a group subscription is in place in the UDM 308 / UDR 310, the CAPIF core function may retrieve the gRO ID (e.g., in group subscription information) from the UDM / UDR based on the group ID. In other examples in which the authorization request is addressed by the group ID, and a group was created in a SEAL-GMS, the CAPIF core function may retrieve the gRO ID (e.g., in group information) from the SEAL-GMS based on the group ID.

[0063] In some examples in which the authorization request is addressed by list of ID(s) associated with respective UEs 110 of the group of UE(s), the CAPIF core function 406 may be preconfigured with group information for the group of UE(s), and this group information may include the UE ID(s) and the gRO ID. In some of these examples, the CAPIF core function may retrieve the gRO ID from the group information based on the list of ID(s). In some further examples, the authorization request may also include the gRO ID; and in some of these examples, the CAPIF core function may verify the gRO ID in the authorization request, from the group information based on the list of ID(s).

[0064] Once the CAPIF core function 406 has determined the gRO for the resource(s) of the group of UE(s) 110, the CAPIF core function may contact the resource owner function 416 for the gRO (via CAPIF- 8) to request consent for access to the resource(s). This authorization request may include an ID of the API invoker 404, and may also include information about a purpose and / or one or more operations (scope) to be performed on the resource(s). The gRO may grant (or deny) consent based on the API invoker ID, scope and / or purpose, and provide a corresponding consent result to the CAPIF core function (via the resource owner function). To grant (or deny) consent, the gRO interacts with the Authorization Function@CCF via resource owner function 418 and the CAPIF-8 reference point. The CAPIF core function may optionally store the corresponding consent result (e.g., in the UDM 308 / UDR 310), which the CAPIF core function may consult instead of repeating the same consent request to the gRO.

[0065] When the corresponding consent result indicates consent is granted, the CAPIF core function 406 may send authorization information to the API invoker 406 for accessing the service API providing the resource(s) of the group of UE(s) 110. In some examples, the authorization information may include an access token for access to the service API. The API invoker may receive the authorization information and perform an invocation of the service API (e.g., with an API exposing function 410) based on the authorization information.

[0066] To further illustrate some example implementations of the present disclosure, FIG.5 is a signaling chart 500 of procedures for an API invoker 404 accessing resource(s) of a group of UE(s) 110. In these example implementations, information of the group of UE(s) is available in the UDM 308 / UDR 310 or a SEAL-GMS 510 to which the CAPIF core function 406 has connectivity. The network may host the resource(s) which may be provided by a service API that is exposed by an API exposing function 410. The resource(s) may be accessed with consent of the gRO, but the identity of the gRO is unknown to the API invoker. Also, in some of these example implementations, a resource owner function 418 for the gRO, and the API invoker, may be hosted in respective UEs (a first UE and a second UE) that are members of the group of UE(s).

[0067] As shown in FIG.5, the network has information about the group creation including the gRO ID. As shown at step 501a, for example, group subscription information for the group of UE(s) may be in place in the UDM 308 / UDR 310, and the group subscription information may include the gRO ID. In another example in which a SEAL-GMS 510 is in place, a group creation procedure may be carried out in which group information including the gRO ID may be created, as shown at step 501b.

[0068] The API invoker 404 (e.g., in the second UE) may at step 502 send an obtain service API authorization request to the CAPIF core function (CCF) 406 for obtaining permission to access the service API that provides the resource(s) (e.g., location) of the group of UE(s). The obtain service API authorization request may include the API invoker ID and any other information that may be relevant for authentication of the API invoker. The request may also include a group ID of the group of UE(s) whose resource(s) the APIinvoker is attempting to access, as well as information about a purpose and / or one or more operations (scope) to be performed on the resource(s).

[0069] The CAPIF core function 406 may at step 503 validate and authenticate the API invoker 404 (using authentication information). The CAPIF core function 406 may determine that consent of a gRO for the resource(s) the API invoker is attempting to access is needed, which may be due to invocation of the service API implying the processing of protected information or other resource of the group of UE(s).

[0070] The CAPIF core function 406 may next determine the gRO for the resource(s) based on the group ID. In some examples, the CAPIF core function may at step 504a retrieve the group subscription information (including the gRO ID) from the UDM 308 / UDR 310. In other examples, the CAPIF core function may at step 504b carry out a group information query procedure with the SEAL-GMS 510 to obtain the group information (including the gRO ID). In either case, in some examples, the UDM / UDR or SEAL- GMS may require that the UE hosting the API invoker 404 is a member of the group of UE(s) in order to provide the information for the group.

[0071] Once the CAPIF core function 406 has determined the gRO for the resource(s), the CAPIF core function may at step 505 trigger a consent retrieval procedure with the resource owner function 418 (e.g., in the first UE) via CAPIF-8 using a consent retrieval request (including the API invoker ID, purpose and / or scope signaled by the API invoker at step 502). The gRO may at step 506 grant (or deny) the consent (on behalf of the group members) based on the API invoker ID, purpose and / or scope. The targeted resources may belong to at least some if not all of the members of the group of UE(s) identified by the group ID.

[0072] The CAPIF core function 406 may at step 507 store the result of the consent, such as in the UDM 308 / UDR 310.

[0073] If the gRO granted consent for accessing the resource(s) of the group of UE(s) 110, the CAPIF core function 406 may at step 508 send authorization information to access the service API (that provides the resource(s)) to the API invoker 404 in an obtain service API authorization response. The API invoker may then at step 509 carry out an invocation of the service API with the API exposing function 410 using the authorization information received in step 508.

[0074] FIG.6 is a signaling chart 600 of procedures for an API invoker 404 accessing resource(s) of a group of UE(s) 110, according to some other example implementations. In these example implementations, the CAPIF core function 406 may be preconfigured with information of the group of UE(s) 110. Similar to as the earlier described example implementations, the network may host the resource(s) which may be provided by a service API that is exposed by an API exposing function 410. The resource(s) may be accessed with consent of the gRO. Also similar to the earlier described, a resource owner function 418 for the gRO, and the API invoker, may be hosted in respective UEs (a first UE and a second UE) that are members of the group of UE(s).

[0075] As shown in FIG.6, the CAPIF core function 406, at step 601, may be preconfigured with group information for the group of UE(s) 110. The group information may include the gRO ID, and may also include ID(s) of the UE(s) in the group of UE(s).

[0076] The API invoker 404 (e.g., in the second UE) may send an obtain service API authorization request to the CAPIF core function 406 for obtaining permission to access the service API that provides the resource(s) (e.g., location) of the group of UE(s). The obtain service API authorization request may include the API invoker ID and any other information that may be relevant for authentication of the API invoker. As shown at step 602a, the request may include ID(s) of UE(s) in the group (may be a subset of the group preconfigured in the CAPIF core function), a purpose and / or one or more operations (scope) to be performed on the resource(s). In another example, as shown at step 602b, the request may also include the gRO ID.

[0077] The CAPIF core function 406 may at step 603 validate and authenticate the API invoker 404 (using authentication information). The CAPIF core function 406 may determine that consent of a gRO for the resource(s) the API invoker is attempting to access is needed, which may be due to invocation of the service API implying the processing of protected information or other resource of the group of UE(s).

[0078] The CAPIF core function 406 may next determine the gRO for the resource(s) based on the UE ID(s) in the request received at step 602a, 602b. In some examples, the CAPIF core function may at step 604 retrieve the preconfigured group information that includes the gRO ID, and determine / validate the gRO ID based on the preconfigured group information. In this regard, the CAPIF core function may determine the gRO ID when the request (at step 602a) does not include the gRO ID, or the CAPIF core function may validate the gRO ID included in the request (at step 602b). In either case, in some examples, the CAPIF core function may require that the UE hosting the API invoker 404 is a member of the group of UE(s). The CAPIF core function may also require that the list of UE ID(s) in the request is at least a subset of the members of the group of UE(s) preconfigured in the CAPIF core function.

[0079] Once the CAPIF core function 406 has determined the gRO for the resource(s), the CAPIF core function may at step 605 trigger a consent retrieval procedure with the resource owner function 418 (e.g., in the first UE) via CAPIF-8 using a consent retrieval request (including the API invoker ID, purpose and / or scope signaled by the API invoker at step 502). The gRO may at step 606 grant (or deny) the consent (on behalf of the group members) based on the API invoker ID, purpose and / or scope. The targeted resources may belong to at least some if not all of the members of the group of UE(s) identified by the group ID.

[0080] The CAPIF core function 406 may at step 607 store the result of the consent, such as in the UDM 308 / UDR 310.

[0081] If the gRO granted consent for accessing the resource(s) of the group of UE(s) 110, the CAPIF core function 406 may at step 608 send authorization information to access the service API (that provides the resource(s)) to the API invoker 404 in an obtain service API authorization response. The API invoker maythen at step 609 carry out an invocation of the service API with the API exposing function 410 using the authorization information received in step 508.

[0082] FIG.7 is a flowchart illustrating various steps in a method 700 performed by an application programming interface (API) invoker in a common API framework (CAPIF), according to various example implementations. The method includes sending, to a CAPIF core function, an authorization request for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs), the at least one resource provided by a service API, and the authorization request including an indication of the group of one or more UEs, as shown at block 702. The method also includes receiving, based on consent of the resource owner to access the at least one resource, authorization information from the CAPIF core function to access the service API that provides the at least one resource, as shown at block 704. And, the method includes performing an invocation of the service API using the authorization information, as shown at block 706.

[0083] In some examples, the method is performed by the API invoker hosted in a UE that is a member of the group of one or more UEs.

[0084] In some examples, the indication of the group of one or more UEs included in the authorization request comprises a group identifier associated with the group of one or more UEs.

[0085] In some examples, the indication of the group of one or more UEs included in the authorization request comprises a list of one or more identifiers associated with respective UEs of the group of one or more UEs.

[0086] In some examples, the authorization request further includes an identifier of the resource owner for the at least one resource of the group of one or more UEs.

[0087] In some examples, the at least one resource provides access to at least one of the following: information associated with a UE of the one or more UEs; personal information associated with a UE of the one or more UEs; information concerning a location of a UE of the one or more UEs; information concerning a health issue associated with a UE of the one or more UEs; information concerning a quality or service setting for a protocol data unit session of a UE of the one or more UEs; information concerning network activity in a specific zone or cell associated with a UE of the one or more UEs; information concerning mobility events of a UE of one or more UEs; or information concerning battery status of a UE of the one or more UEs.

[0088] FIGS.8A – 8C are flowcharts illustrating various steps in a method 800 performed by a common application programming interface (API) framework (CAPIF) core function, according to various example implementations. The method includes receiving, from an API invoker, an authorization request for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs), the at least one resource provided by a service API, and the authorization request including an indication of the group of one or more UEs, as shown at block 802 of FIG.8A. The methodalso includes determining the resource owner for the at least one resource based on the indication of the group of one or more UEs, as shown at block 804. The method includes obtaining consent of the resource owner to access the at least one resource, as shown at block 806. And, the method includes sending, based on the authorization from the resource owner, authorization information to the API invoker for use by the API invoker in performing an invocation of the service API that provides the at least one resource, as shown at block 808.

[0089] In some examples, the indication of the group of one or more UEs included in the authorization request comprises a group identifier associated with the group of one or more UEs.

[0090] In some examples, determining the resource owner at block 804 includes sending, to a unified data management (UDM) or a unified data repository (UDR), a request for group subscription information for the group of one or more UEs, wherein the request includes the group identifier associated with the group of one or more UEs, as shown at block 810 of FIG.8B. In some of these examples, determining the resource owner also includes receiving, from the UDM that sent the request or the UDR that sent the request, the group subscription information, the group subscription information including an identifier of the resource owner, as shown at block 812. And determining the resource owner includes the identifier of the resource owner from the group subscription information, as shown at block 814.

[0091] In some examples, determining the resource owner at block 804 includes sending, to a service enabler architecture layer (SEAL) group management server (GMS), a request for group information for the group of one or more UEs, wherein the request includes the group identifier associated with the group of one or more UEs, as shown at block 816 of FIG.8C. In some of these examples, determining the resource owner also includes receiving, from the SEAL GMS, the group information, the group information including an identifier of the resource owner, as shown at block 818. And determining the resource owner includes determining the identifier of the resource owner from the group information, as shown at block 820.

[0092] In some examples, the indication of the group of one or more UEs included in the authorization request comprises a list of one or more identifiers associated with respective UEs of the group of one or more UEs.

[0093] In some examples, the CAPIF core function is preconfigured with group information for the group of one or more UEs. In some of these examples, determining the resource owner at block 804 comprises determining an identifier of the resource owner from the group information, wherein the group information includes the list of one or more identifiers associated with the respective UEs and the identifier of the resource owner.

[0094] In some examples, the CAPIF core function is preconfigured with group information for the group of one or more UEs, and the authorization request further includes an identifier of the resource owner for the at least one resource of the group of one or more UEs. In some of these examples, determining the resource owner at block 804 comprises validating the identifier of the resource owner comprised in theauthorization request from the group information, the group information comprising the list of one or more identifiers associated with the respective UEs and the identifier of the resource owner.

[0095] According to example implementations of the present disclosure, a telecommunications system 100 or PLMN 102, and its components such as a UE 110, CN 106, RAN 108, 5GC 202, NG-RAN 204, gNB 206, AMF 302, SMF 304, UPF 306, UDM 308, UDR 310, NEF 312, AF 314, AS 316, API invoker 404, CAPIF core function 406, API exposing function 410, resource owner function 418 and / or SEAL-GMS 510 may be implemented by various means. Means for implementing the system and its components may include hardware, firmware, software, or combinations thereof. In some examples, one or more apparatuses may be configured to function as or otherwise implement the system and its components shown and described herein. In examples involving more than one apparatus, the respective apparatuses may be connected to or otherwise in communication with one another in a number of different manners, such as directly or indirectly via a wired or wireless network or the like.

[0096] According to some example implementations, at least some of the method 700 described with respect to FIG.7 may be carried out by an apparatus comprising means for performing functions corresponding steps of the method. Similarly, at least some of the method 800 described with respect to FIGS.8A – 8C may be carried out by an apparatus comprising means for performing functions corresponding steps of the method. Examples of a suitable apparatus may include a user equipment, user device, user terminal or the like. Other examples of a suitable apparatus may include an API invoker, CAPIF core function, a resource owner function, a NF (e.g., UDM, UDR, NEF, AF, AS, SCS, SCEF) or any suitable apparatus, such as a server, host or node.

[0097] FIG.9 illustrates an apparatus 900 in which means for performing various functions includes hardware, alone or under direction of one or more computer programs from a computer-readable storage medium or other memory, such as computer memory, according to some example implementations of the present disclosure. Generally, an apparatus of example implementations of the present disclosure may comprise, include or be embodied in one or more fixed or portable electronic devices. Examples of suitable electronic devices include a wearable computer, mobile phone, portable computer, desktop computer, workstation computer, server (server computer) or the like. The apparatus may include one or more of each of a number of components such as, for example, processing circuitry 902 connected to computer-readable storage medium or other memory 904.

[0098] The processing circuitry 902 may be composed of one or more processors alone or in combination with one or more computer-readable storage media. The processing circuitry is generally any piece of computer hardware that is capable of processing information such as, for example, data, computer programs and / or other suitable electronic information. The processing circuitry is composed of a collection of electronic circuits some of which may be packaged as an integrated circuit or multiple interconnected integrated circuits (an integrated circuit at times more commonly referred to as a “chip”). The processingcircuitry may be configured to execute computer programs, which may be stored onboard the processing circuitry or otherwise stored in the memory 904 (of the same or another apparatus).

[0099] The processing circuitry 902 may be a number of processors, a multi-core processor or some other type of processor, depending on the particular implementation. Further, the processing circuitry may be implemented using a number of heterogeneous processor systems in which a main processor is present with one or more secondary processors on a single chip. As another illustrative example, the processing circuitry may be a symmetric multi-processor system containing multiple processors of the same type. In yet another example, the processing circuitry may be embodied as or otherwise include one or more ASICs, FPGAs or the like. Thus, although the processing circuitry may be capable of executing a computer program to perform one or more functions, the processing circuitry of various examples may be capable of performing one or more functions without the aid of a computer program. In either instance, the processing circuitry may be appropriately programmed to perform functions or operations according to example implementations of the present disclosure.

[0100] The memory 904 is generally any piece of computer hardware that is capable of storing information such as, for example, data, computer programs, instructions 906 (e.g., computer-readable program code) and / or other suitable information either on a temporary basis and / or a permanent basis. The memory may include volatile and / or non-volatile memory, and may be fixed or removable. Examples of suitable memory include recording media, random access memory (RAM), read-only memory (ROM), a hard drive, a flash memory, a thumb drive, a removable computer diskette, an optical disk or some combination thereof.

[0101] The memory 904 is a non-transitory device capable of storing information. One example of a suitable memory is a computer-readable storage medium, which is distinguishable from a computer- readable transmission medium capable of carrying information from one location to another. Examples of suitable computer-readable transmission media comprise electronic carrier signals, telecommunications signals, or some combination thereof. As used herein, the term “non-transitory” is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM versus ROM). A computer-readable medium as described herein generally refers to a computer-readable storage medium or computer-readable transmission medium. A computer-readable medium is any entity or device capable in which information, such as one or more computer programs or portions thereof, may be stored and carried.

[0102] In addition to the memory 904 (e.g., computer-readable storage medium), the processing circuitry 902 may also be connected to one or more interfaces for displaying, transmitting and / or receiving information. The interfaces may include a communications interface 908 and / or one or more user interfaces. The communications interface may be configured to transmit and / or receive information, such as to and / or from other apparatus(es), network(s) or the like. The communications interface may be configured to transmit and / or receive information by physical (wired) and / or wireless communications links.Examples of suitable communication interfaces include a network interface controller (NIC), wireless NIC (WNIC) or the like.

[0103] The user interfaces may include a display 910 and / or one or more user input interfaces 912. The display may be configured to present or otherwise display information to a user, suitable examples of which include a liquid crystal display (LCD), light-emitting diode (LED) display, organic LED (OLED) display, active-matrix OLED (AMOLED) or the like. The user input interfaces may be wired or wireless, and may be configured to receive information from a user into the apparatus, such as for processing, storage and / or display. Suitable examples of user input interfaces include a microphone, image or video capture device, keyboard or keypad, joystick, touch-sensitive surface (separate from or integrated into a touchscreen), biometric sensor or the like. The user interfaces may further include one or more interfaces for communicating with peripherals such as printers, scanners or the like.

[0104] Execution of the instructions 906 by the processing circuitry 902, or storage of the instructions in the memory 904, supports combinations of operations for implementing example implementations of the present disclosure. In this manner, an apparatus 900 may comprise at least one processing circuitry and at least one memory coupled to the at least one processing circuitry, where the at least one processing circuitry is configured to execute instructions stored in the at least one memory. It will also be understood that one or more functions, and combinations of functions, may be implemented by special purpose hardware-based computer systems and / or processing circuitry which perform the specified functions, or combinations of special purpose hardware and program code instructions.

[0105] Some example implementations of the present disclosure may also be carried out in the form of a computer process defined by one or more computer programs or portions thereof. Example implementations of the present disclosure may be carried out by executing at least one portion of a computer program comprising instructions. The computer program may be in source code form, object code form, or in some intermediate form. The computer program may be stored in a computer-readable medium that is readable by a computer, processing circuitry or other suitable apparatus. As indicated above, for example, the computer program may be stored in a memory, such as a computer-readable storage medium. Additionally or alternatively, for example, the computer program may be stored in a computer-readable transmission medium. The coding of software for carrying out example implementations of the present disclosure is well within the scope of a person of ordinary skill in the art.

[0106] As will be appreciated, any suitable instructions may be loaded onto a computer, a processing circuitry or other programmable apparatus from a memory or a computer-readable medium (e.g., computer- readable storage medium, computer-readable transmission medium) to produce a particular machine, such that the particular machine becomes a means for implementing the functions specified herein. The instructions may also be stored in a computer-readable medium that can direct a computer, a processing circuitry or other programmable apparatus to function in a particular manner to thereby generate aparticular machine or particular article of manufacture. In some examples, the instructions stored in the computer-readable medium may produce an article of manufacture, where the article of manufacture becomes a means for implementing functions described herein. The instructions may be retrieved from a computer-readable medium and loaded into a computer, processing circuitry or other programmable apparatus to configure the computer, processing circuitry or other programmable apparatus to execute operations to be performed on or by the computer, processing circuitry or other programmable apparatus.

[0107] Retrieval, loading and execution of instructions comprising program code instructions may be performed sequentially such that one instruction is retrieved, loaded and executed at a time. In some example implementations, retrieval, loading and / or execution may be performed in parallel such that multiple instructions are retrieved, loaded, and / or executed together. Execution of the program code instructions may produce a computer-implemented process such that the instructions executed by the computer, processing circuitry or other programmable apparatus provide operations for implementing functions described herein.

[0108] As explained above and reiterated below, the present disclosure includes, without limitation, the following example implementations.

[0109] Clause 1. A method performed by an application programming interface (API) invoker in a common API framework (CAPIF), the method comprising: sending, to a CAPIF core function, an authorization request for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs), the at least one resource provided by a service API, and the authorization request including an indication of the group of one or more UEs; receiving, based on consent of the resource owner to access the at least one resource, authorization information from the CAPIF core function to access the service API that provides the at least one resource; and performing an invocation of the service API using the authorization information.

[0110] Clause 2. The method of clause 1, wherein the method is performed by the API invoker hosted in a UE that is a member of the group of one or more UEs.

[0111] Clause 3. The method of clause 1 or clause 2, wherein the indication of the group of one or more UEs included in the authorization request comprises a group identifier associated with the group of one or more UEs.

[0112] Clause 4. The method of any of clauses 1 to 3, wherein the indication of the group of one or more UEs included in the authorization request comprises a list of one or more identifiers associated with respective UEs of the group of one or more UEs.

[0113] Clause 5. The method of clause 4, wherein the authorization request further includes an identifier of the resource owner for the at least one resource of the group of one or more UEs.

[0114] Clause 6. The method of any of clauses 1 to 5, wherein the at least one resource provides access to at least one of the following: information associated with a UE of the one or more UEs; personalinformation associated with a UE of the one or more UEs; information concerning a location of a UE of the one or more UEs; information concerning a health issue associated with a UE of the one or more UEs; information concerning a quality or service setting for a protocol data unit session of a UE of the one or more UEs; information concerning network activity in a specific zone or cell associated with a UE of the one or more UEs; information concerning mobility events of a UE of one or more UEs; or battery status of a UE of the one or more UEs.

[0115] Clause 7. An apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory, and execute the instructions to cause the apparatus to perform the method of any of clauses 1 to 6.

[0116] Clause 8. An apparatus comprising means for performing the method of any of clauses 1 to 6.

[0117] Clause 9. A computer-readable medium comprising instructions that, in response to execution by at least one processing circuitry, causes an apparatus to perform the method of any of clauses 1 to 6.

[0118] Clause 10. A computer-readable storage medium comprising instructions that, in response to execution by at least one processing circuitry, causes an apparatus to perform the method of any of clauses 1 to 6.

[0119] Clause 11. A computer program comprising instructions that, in response to execution by at least one processing circuitry, causes an apparatus to perform the method of any of clauses 1 to 6.

[0120] Clause 12. A method performed by a common application programming interface (API) framework (CAPIF) core function, the method comprising: receiving an authorization request from an API invoker for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs), the at least one resource provided by a service API, and the authorization request including an indication of the group of one or more UEs; determining the resource owner for the at least one resource based on the indication of the group of one or more UEs; obtaining consent of the resource owner to access the at least one resource; and sending, based on the authorization from the resource owner, authorization information to the API invoker for use by the API invoker in performing an invocation of the service API that provides the at least one resource.

[0121] Clause 13. The method of clause 12, wherein the indication of the group of one or more UEs included in the authorization request comprises a group identifier associated with the group of one or more UEs.

[0122] Clause 14. The method of clause 13, wherein determining the resource owner comprises: sending, to a unified data management (UDM) or a unified data repository (UDR), a request for group subscription information for the group of one or more UEs, wherein the request includes the group identifier associated with the group of one or more UEs; receiving, from the UDM that sent the request or the UDR that sent the request, the group subscription information, the group subscription information including an identifier of theresource owner; and determining the identifier of the resource owner from the group subscription information.

[0123] Clause 15. The method of clause 13 or clause 14, wherein determining the resource owner comprises: sending, to a service enabler architecture layer (SEAL) group management server (GMS), a request for group information for the group of one or more UEs, wherein the request includes the group identifier associated with the group of one or more UEs; receiving, from the SEAL GMS, the group information, the group information including an identifier of the resource owner; and determining the identifier of the resource owner from the group information.

[0124] Clause 16. The method of any of clauses 12 to 15, wherein the indication of the group of one or more UEs included in the authorization request comprises a list of one or more identifiers associated with respective UEs of the group of one or more UEs.

[0125] Clause 17. The method of clause 16, wherein the CAPIF core function is preconfigured with group information for the group of one or more UEs, wherein determining the resource owner comprises determining an identifier of the resource owner from the group information, and wherein the group information includes the list of one or more identifiers associated with the respective UEs and the identifier of the resource owner.

[0126] Clause 18. The method of clause 16 or clause 17, wherein the CAPIF core function is preconfigured with group information for the group of one or more UEs, wherein the authorization request further includes an identifier of the resource owner for the at least one resource of the group of one or more UEs, and wherein determining the resource owner comprises validating the identifier of the resource owner comprised in the authorization request from the group information, the group information comprising the list of one or more identifiers associated with the respective UEs and the identifier of the resource owner.

[0127] Clause 19. An apparatus comprising: at least one memory configured to store instructions; and at least one processing circuitry configured to access the at least one memory, and execute the instructions to cause the apparatus to perform the method of any of clauses 12 to 18.

[0128] Clause 20. An apparatus comprising means for performing the method of any of clauses 12 to 18.

[0129] Clause 21. A computer-readable medium comprising instructions that, in response to execution by at least one processing circuitry, causes an apparatus to perform the method of any of clauses 12 to 18.

[0130] Clause 22. A computer-readable storage medium comprising instructions that, in response to execution by at least one processing circuitry, causes an apparatus to perform the method of any of clauses 12 to 18.

[0131] Clause 23. A computer program comprising instructions that, in response to execution by at least one processing circuitry, causes an apparatus to perform the method of any of clauses 12 to 18.

[0132] Many modifications and other implementations of the disclosure set forth herein will come to mind to one skilled in the art to which the disclosure pertains having the benefit of the teachings presented in theforegoing description and the associated figures. Therefore, it is to be understood that the disclosure is not to be limited to the specific implementations disclosed and that modifications and other implementations are intended to be included within the scope of the appended claims. Moreover, although the foregoing description and the associated figures describe example implementations in the context of certain example combinations of elements and / or functions, it should be appreciated that different combinations of elements and / or functions may be provided by alternative implementations without departing from the scope of the appended claims. In this regard, for example, different combinations of elements and / or functions than those explicitly described above are also contemplated as may be set forth in some of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

WE CLAIM:

1. An apparatus implementing an application programming interface (API) invoker in a common API framework (CAPIF), the apparatus comprising: means for sending, to a CAPIF core function, an authorization request for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs), the at least one resource provided by a service API, and the authorization request including an indication of the group of one or more UEs; means for receiving, based on consent of the resource owner to access the at least one resource, authorization information from the CAPIF core function to access the service API that provides the at least one resource; and means for performing an invocation of the service API using the authorization information.

2. The apparatus as claimed in claim 1, wherein the apparatus comprises a UE that is a member of the group of one or more UEs.

3. The apparatus as claimed in claim 1, wherein the indication of the group of one or more UEs included in the authorization request comprises a group identifier associated with the group of one or more UEs.

4. The apparatus as claimed in claim 1, wherein the indication of the group of one or more UEs included in the authorization request comprises a list of one or more identifiers associated with respective UEs of the group of one or more UEs.

5. The apparatus as claimed in claim 4, wherein the authorization request further includes an identifier of the resource owner for the at least one resource of the group of one or more UEs.

6. The apparatus as claimed in claim 1, wherein the at least one resource provides access to at least one of the following: information associated with a UE of the one or more UEs; personal information associated with a UE of the one or more UEs; information concerning a location of a UE of the one or more UEs; information concerning a health issue associated with a UE of the one or more UEs; information concerning a quality or service setting for a protocol data unit session of a UE of the one or more UEs; information concerning network activity in a specific zone or cell associated with a UE of the one or more UEs;information concerning mobility events of a UE of the one or more UEs; or information concerning battery status of a UE of the one or more UEs.

7. A method performed by an application programming interface (API) invoker in a common API framework (CAPIF), the method comprising: sending, to a CAPIF core function, an authorization request for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs), the at least one resource provided by a service API, and the authorization request including an indication of the group of one or more UEs; receiving, based on consent of the resource owner to access the at least one resource, authorization information from the CAPIF core function to access the service API that provides the at least one resource; and performing an invocation of the service API using the authorization information.

8. The method as claimed in claim 7, wherein the method is performed by the API invoker hosted in a UE that is a member of the group of one or more UEs.

9. The method as claimed in claim 7, wherein the indication of the group of one or more UEs included in the authorization request comprises a group identifier associated with the group of one or more UEs.

10. The method as claimed in claim 7, wherein the indication of the group of one or more UEs included in the authorization request comprises a list of one or more identifiers associated with respective UEs of the group of one or more UEs.

11. The method as claimed in claim 10, wherein the authorization request further includes an identifier of the resource owner for the at least one resource of the group of one or more UEs.

12. The method as claimed in claim 7, wherein the at least one resource provides access to at least one of the following: information associated with a UE of the one or more UEs; personal information associated with a UE of the one or more UEs; information concerning a location of a UE of the one or more UEs; information concerning a health issue associated with a UE of the one or more UEs; information concerning a quality or service setting for a protocol data unit session of a UE of the one or more UEs;information concerning network activity in a specific zone or cell associated with a UE of the one or more UEs; information concerning mobility events of a UE of the one or more UEs; or information concerning battery status of a UE of the one or more UEs.

13. An apparatus implementing a common application programming interface (API) framework (CAPIF) core function, the apparatus comprising: means for receiving, from an API invoker, an authorization request for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs), the at least one resource provided by a service API, and the authorization request including an indication of the group of one or more UEs; means for determining the resource owner for the at least one resource based on the indication of the group of one or more UEs; means for obtaining consent of the resource owner to access the at least one resource; and means for sending, based on the authorization from the resource owner, authorization information to the API invoker for use by the API invoker in performing an invocation of the service API that provides the at least one resource.

14. The apparatus as claimed in claim 13, wherein the indication of the group of one or more UEs included in the authorization request comprises a group identifier associated with the group of one or more UEs.

15. The apparatus as claimed in claim 14, wherein the means for determining the resource owner comprises: means for sending, to an unified data management (UDM) or an unified data repository (UDR), a request for group subscription information for the group of one or more UEs, wherein the request includes the group identifier associated with the group of one or more UEs; means for receiving, from the UDM that sent the request or the UDR that sent the request, the group subscription information, the group subscription information including an identifier of the resource owner; and means for determining the identifier of the resource owner from the group subscription information.

16. The apparatus as claimed in claim 14, wherein the means for determining the resource owner comprises:means for sending, to a service enabler architecture layer (SEAL) group management server (GMS), a request for group information for the group of one or more UEs, wherein the request includes the group identifier associated with the group of one or more UEs; means for receiving, from the SEAL GMS, the group information, the group information including an identifier of the resource owner; and means for determining the identifier of the resource owner from the group information.

17. The apparatus as claimed in claim 13, wherein the indication of the group of one or more UEs included in the authorization request comprises a list of one or more identifiers associated with respective UEs of the group of one or more UEs.

18. The apparatus as claimed in claim 17, wherein the CAPIF core function is preconfigured with group information for the group of one or more UEs, wherein means for determining the resource owner comprises means for determining an identifier of the resource owner from the group information, and wherein the group information includes the list of one or more identifiers associated with the respective UEs and the identifier of the resource owner.

19. The apparatus as claimed in claim 17, wherein the CAPIF core function is preconfigured with group information for the group of one or more UEs, wherein the authorization request further includes an identifier of the resource owner for the at least one resource of the group of one or more UEs, and wherein the means for determining the resource owner comprises means for validating the identifier of the resource owner comprised in the authorization request from the group information, the group information comprising the list of one or more identifiers associated with the respective UEs and the identifier of the resource owner.

20. A method performed by a common application programming interface (API) framework (CAPIF) core function, the method comprising: receiving, from an API invoker, an authorization request for authorization of a resource owner to access at least one resource of a group of one or more user equipments (UEs), the at least one resource provided by a service API, and the authorization request including an indication of the group of one or more UEs; determining the resource owner for the at least one resource based on the indication of the group of one or more UEs; obtaining consent of the resource owner to access the at least one resource; andsending, based on the authorization from the resource owner, authorization information to the API invoker for use by the API invoker in performing an invocation of the service API that provides the at least one resource.

21. The method as claimed in claim 20, wherein the indication of the group of one or more UEs included in the authorization request comprises a group identifier associated with the group of one or more UEs.

22. The method as claimed in claim 21, wherein determining the resource owner comprises: sending, to a unified data management (UDM) or a unified data repository (UDR), a request for group subscription information for the group of one or more UEs, wherein the request includes the group identifier associated with the group of one or more UEs; receiving, from the UDM that sent the request or the UDR that sent the request, the group subscription information, the group subscription information including an identifier of the resource owner; and determining the identifier of the resource owner from the group subscription information.

23. The method as claimed in claim 21, wherein determining the resource owner comprises: sending, to a service enabler architecture layer (SEAL) group management server (GMS), a request for group information for the group of one or more UEs, wherein the request includes the group identifier associated with the group of one or more UEs; receiving, from the SEAL GMS, the group information, the group information including an identifier of the resource owner; and determining the identifier of the resource owner from the group information.

24. The method as claimed in claim 20, wherein the indication of the group of one or more UEs included in the authorization request comprises a list of one or more identifiers associated with respective UEs of the group of one or more UEs.

25. The method as claimed in claim 24, wherein the CAPIF core function is preconfigured with group information for the group of one or more UEs, wherein determining the resource owner comprises determining an identifier of the resource owner from the group information, and wherein the group information includes the list of one or more identifiers associated with the respective UEs and the identifier of the resource owner.

26. The method as claimed in claim 24, wherein the CAPIF core function is preconfigured with group information for the group of one or more UEs, wherein the authorization request further includes an identifier of the resource owner for the at least one resource of the group of one or more UEs, and wherein determining the resource owner comprises validating the identifier of the resource owner comprised in the authorization request from the group information, the group information comprising the list of one or more identifiers associated with the respective UEs and the identifier of the resource owner.

Images