Patent Description:
This section introduces aspects that may be helpful to facilitating a better understanding of the aspects of this disclosure.

Fourth generation (<NUM>) wireless mobile telecommunications technology, also known as Long Term Evolution (LTE) technology, was designed to provide high capacity mobile multimedia with high data rates particularly for human interaction. Next generation or fifth generation (<NUM>) technology is intended to be used not only for human interaction, but also for machine type communications in so-called Internet of Things (IoT) networks.

While <NUM> networks are intended to enable massive IoT services (e.g., very large numbers of limited capacity devices) and mission-critical IoT services (e.g., requiring high reliability), improvements over legacy mobile communication services are supported in the form of enhanced mobile broadband (eMBB) services providing improved wireless Internet access for mobile devices.

In an example communication system, user equipment (<NUM> UE in a <NUM> network or, more broadly, a UE) such as a mobile terminal (subscriber) communicates over an air interface with a base station or access point referred to as a gNB in a <NUM> network. The access point (e.g., gNB) is illustratively part of an access network of the communication system. For example, in a <NUM> network, the access network is referred to as a <NUM> System and is described in <NUM> Technical Specification (TS) <NUM>, V15. <NUM>, entitled "Technical Specification Group Services and System Aspects; System Architecture for the <NUM> System,". In general, the access point (e.g., gNB) provides access for the UE to a core network (CN), which then provides access for the UE to other UEs and/or a data network such as a packet data network (e.g., Internet).

TS <NUM> goes on to define a <NUM> Service-Based Architecture (SBA) which models services as network functions (NFs) that communicate with each other using representational state transfer application programming interfaces (Restful APIs).

Furthermore, <NUM> Technical Specification (TS) <NUM>, V15. <NUM>, entitled "Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the <NUM> System,", further describes security management details associated with a <NUM> network.

Security management is an important consideration in any communication system. For example, authorization of access to services is one example of security management in a <NUM> network. However, service access authorization presents several challenges in existing <NUM> approaches.

<CIT> describes techniques for securing a Web Service.

Illustrative aspects provide improved techniques for security management in communication systems particularly with respect to service access authorization.

For example, in one illustrative aspect, a method comprises the following steps. An authorization entity in a communication system comprising a service-based architecture receives a request from a service consumer in the communication system for access to a given service type. The authorization entity obtains an access token that identifies a plurality of service producers for the given service type and sends the access token to the service consumer.

In another aspect, a method comprises the following steps. A service consumer in a communication system comprising a service-based architecture sends to an authorization entity in the communication system a request for access to a given service type. The service consumer receives an access token from the authorization entity, wherein the access token identifies a plurality of service producers in the communication system for the given service type. One of the plurality of service producers from the access token is selected based on one or more selection criterion.

In a further aspect, a method comprises the following steps. A proxy element in a communication system comprising a service-based architecture receives an access token, wherein the access token identifies a plurality of service producers in the communication system for a given service type generated by an authorization entity in the communication system in response to a request by a service consumer in the communication system for access to the given service type. One of the plurality of service producers from the access token is selected at the proxy element based on one or more selection criterion. In an additional aspect, the proxy element sends the service consumer identifying information for the selected service producer to the service consumer.

In yet another aspect, a method comprises the following steps. An access token is received at a service consumer in a communication system comprising a service-based architecture from an authorization entity, wherein the access token identifies a plurality of proxy elements corresponding to service producers in the communication system for a given service type. The service consumer selects one of the plurality of proxy elements from the access token and sends a request to access the given service type to the selected proxy element.

Further illustrative aspects are provided in the form of non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above steps. Still further illustrative aspects comprise apparatus with a processor and a memory configured to perform the above steps.

These and other features and advantages of aspects described herein will become more apparent from the accompanying drawings and the following detailed description.

Aspects will be illustrated herein in conjunction with example communication systems and associated techniques for providing security management in communication systems. It should be understood, however, that the scope of the claims is not limited to particular types of communication systems and/or processes disclosed. Aspects can be implemented in a wide variety of other types of communication systems, using alternative processes and operations. For example, although illustrated in the context of wireless cellular systems utilizing 3GPP system elements such as a 3GPP next generation system (<NUM>), the disclosed aspects can be adapted in a straightforward manner to a variety of other types of communication systems.

In accordance with illustrative aspects implemented in a <NUM> communication system environment, one or more 3GPP technical specifications (TS) and technical reports (TR) provide further explanation of network elements/functions and/or operations that interact with one or more illustrative aspects, e.g., the above-referenced 3GPP TS <NUM> and 3GPP TS <NUM>. Other 3GPP TS/TR documents provide other conventional details that one of ordinary skill in the art will realize. However, while well-suited for <NUM>-related 3GPP standards, aspects are not necessarily intended to be limited to any particular standards.

Illustrative aspects are related to security management associated with the Service-Based Architecture (SBA) for <NUM> networks. Prior to describing such illustrative aspects, a general description of main components of a <NUM> network will be described below in the context of <FIG> and <FIG>.

<FIG> shows a communication system <NUM> within which illustrative aspects are implemented. It is to be understood that the elements shown in communication system <NUM> are intended to represent main functions provided within the system, e.g., UE access functions, mobility management functions, authentication functions, serving gateway functions, etc. As such, the blocks shown in <FIG> reference specific elements in <NUM> networks that provide these main functions. However, other network elements are used in other aspects to implement some or all of the main functions represented. Also, it is to be understood that not all functions of a <NUM> network are depicted in <FIG>. Rather, functions that facilitate an explanation of illustrative aspects are represented. Subsequent figures depict some additional elements/functions.

Accordingly, as shown, communication system <NUM> comprises user equipment (UE) <NUM> that communicates via an air interface <NUM> with an access point (gNB) <NUM>. The UE <NUM> in some aspects is a mobile station, and such a mobile station may comprise, by way of example, a mobile telephone, a computer, or any other type of communication device. The term "user equipment" as used herein is therefore intended to be construed broadly, so as to encompass a variety of different types of mobile stations, subscriber stations or, more generally, communication devices, including examples such as a combination of a data card inserted in a laptop or other equipment such as a smart phone. Such communication devices are also intended to encompass devices commonly referred to as access terminals.

In one aspect, UE <NUM> is comprised of a Universal Integrated Circuit Card (UICC) part and a Mobile Equipment (ME) part. The UICC is the user-dependent part of the UE and contains at least one Universal Subscriber Identity Module (USIM) and appropriate application software. The USIM securely stores the permanent subscription identifier and its related key, which are used to identify and authenticate subscribers to access networks. The ME is the user-independent part of the UE and contains terminal equipment (TE) functions and various mobile termination (MT) functions.

Note that, in one example, the permanent subscription identifier is an International Mobile Subscriber Identity (IMSI) of a UE. In one aspect, the IMSI is a fixed <NUM>-digit length and consists of a <NUM>-digit Mobile Country Code (MCC), a <NUM>-digit Mobile Network Code (MNC), and a <NUM>-digit Mobile Station Identification Number (MSIN). In a <NUM> communication system, an IMSI is referred to as a Subscription Permanent Identifier (SUPI). In the case of an IMSI as a SUPI, the MSIN provides the subscriber identity. Thus, only the MSIN portion of the IMSI typically needs to be encrypted. The MNC and MCC portions of the IMSI provide routing information, used by the serving network to route to the correct home network. When the MSIN of a SUPI is encrypted, it is referred to as Subscription Concealed Identifier (SUCI).

The access point <NUM> is illustratively part of an access network of the communication system <NUM>. Such an access network comprises, for example, a <NUM> System having a plurality of base stations and one or more associated radio network control functions. The base stations and radio network control functions in some aspects are logically separate entities, but in some aspects are implemented in the same physical network element, such as, for example, a base station router or femto cellular access point.

The access point <NUM> in this illustrative aspect is operatively coupled to mobility management functions <NUM>. In a <NUM> network, the mobility management function is implemented by an Access and Mobility Management Function (AMF). A Security Anchor Function (SEAF) in some aspects is also implemented with the AMF connecting a UE with the mobility management function. A mobility management function, as used herein, is the element or function (i.e., entity) in the core network (CN) part of the communication system that manages or otherwise participates in, among other network operations, access and mobility (including authentication/authorization) operations with the UE (through the access point <NUM>). The AMF is also referred to herein, more generally, as an access and mobility management entity.

The AMF <NUM> in this illustrative aspect is operatively coupled to home subscriber functions <NUM>, i.e., one or more functions that are resident in the home network of the subscriber. As shown, some of these functions include the Unified Data Management (UDM) function, as well as an Authentication Server Function (AUSF). The AUSF and UDM (separately or collectively) are also referred to herein, more generally, as an authentication entity. In addition, home subscriber functions include, but are not limited to, Network Slice Selection Function (NSSF), Network Exposure Function (NEF), Network Function Repository Function (NRF), Policy Control Function (PCF), and Application Function (AF).

One important point to note is that in an SBA communication system, such as a <NUM> system, the control plane uses a services model approach in which components (NFs) query the NRF to discover and communicate with each other over application programming interfaces (APIs). The NF services discovery and authorization method will be described in further detail below.

The access point <NUM> is also operatively coupled to a serving gateway function, i.e., Session Management Function (SMF) <NUM>, which is operatively coupled to a User Plane Function (UPF) <NUM>. UPF <NUM> is operatively coupled to a Packet Data Network, e.g., Internet <NUM>. Further typical operations and functions of such network elements are not described here since they are not the focus of the illustrative aspects and can be found in appropriate 3GPP <NUM> documentation.

It is to be appreciated that this particular arrangement of system elements is an example only, and other types and arrangements of additional or alternative elements can be used to implement a communication system in other aspects. For example, in other aspects, the system <NUM> comprises other elements/functions not expressly shown herein.

Accordingly, the <FIG> arrangement is just one example configuration of a wireless cellular system, and numerous alternative configurations of system elements may be used. For example, although only single elements/functions are shown in the <FIG> aspect, this is for simplicity and clarity of description only. A given alternative aspect may of course include larger numbers of such system elements, as well as additional or alternative elements of a type commonly associated with conventional system implementations.

It is also to be noted that while <FIG> illustrates system elements as singular functional blocks, the various subnetworks that make up the <NUM> network are partitioned into so-called network slices. Network slices (network partitions) comprise a series of network function (NF) sets (i.e., function chains) for each corresponding service type using network function virtualization (NFV) on a common physical infrastructure. The network slices are instantiated as needed for a given service, e.g., eMBB service, massive IoT service, and mission-critical IoT service. A network slice or function is thus instantiated when an instance of that network slice or function is created. In some aspects, this involves installing or otherwise running the network slice or function on one or more host devices of the underlying physical infrastructure. UE <NUM> is configured to access one or more of these services via gNB <NUM>. NFs can also access services of other NFs.

<FIG> is a block diagram of network elements/functions for providing security management in an illustrative aspect. System <NUM> is shown comprising a first network element/function <NUM> and a second network element/function <NUM>. It is to be appreciated that the network elements/functions <NUM> and <NUM> represent any network elements/functions that are configured to provide security management and other techniques described herein, for example, but not limited to, AMF, SEAF, UDM, AUSF, NSSF, NEF, NRF, PCF and AF.

The network element/function <NUM> comprises a processor <NUM> coupled to a memory <NUM> and interface circuitry <NUM>. The processor <NUM> of the network element/function <NUM> includes a security management processing module <NUM> that may be implemented at least in part in the form of software executed by the processor. The processing module <NUM> performs security management described in conjunction with subsequent figures and otherwise herein. The memory <NUM> of the network element/function <NUM> includes a security management storage module <NUM> that stores data generated or otherwise used during security management operations.

The network element/function <NUM> comprises a processor <NUM> coupled to a memory <NUM> and interface circuitry <NUM>. The processor <NUM> of the network element/function <NUM> includes a security management processing module <NUM> that may be implemented at least in part in the form of software executed by the processor <NUM>. The processing module <NUM> performs security management described in conjunction with subsequent figures and otherwise herein. The memory <NUM> of the network element/function <NUM> includes a security management storage module <NUM> that stores data generated or otherwise used during security management operations.

The processors <NUM> and <NUM> of the respective network elements/functions <NUM> and <NUM> may comprise, for example, microprocessors, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs) or other types of processing devices or integrated circuits, as well as portions or combinations of such elements. Such integrated circuit devices, as well as portions or combinations thereof, are examples of "circuitry" as that term is used herein. A wide variety of other arrangements of hardware and associated software or firmware may be used in implementing the illustrative aspects.

The memories <NUM> and <NUM> of the respective network elements/functions <NUM> and <NUM> may be used to store one or more software programs that are executed by the respective processors <NUM> and <NUM> to implement at least a portion of the functionality described herein. For example, security management operations and other functionality as described in conjunction with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by processors <NUM> and <NUM>.

A given one of the memories <NUM> or <NUM> may therefore be viewed as an example of what is more generally referred to herein as a computer program product or still more generally as a processor-readable storage medium that has executable program code embodied therein. Other examples of processor-readable storage media may include disks or other types of magnetic or optical media, in any combination. Illustrative aspects can include articles of manufacture comprising such computer program products or other processor-readable storage media.

The memory <NUM> or <NUM> may more particularly comprise, for example, an electronic random access memory (RAM) such as static RAM (SRAM), dynamic RAM (DRAM) or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memories such as flash memory, magnetic RAM (MRAM), phase-change RAM (PC-RAM) or ferroelectric RAM (FRAM). The term "memory" as used herein is intended to be broadly construed, and may additionally or alternatively encompass, for example, a read-only memory (ROM), a disk-based memory, or other type of storage device, as well as portions or combinations of such devices.

The interface circuitries <NUM> and <NUM> of the respective network elements/functions <NUM> and <NUM> illustratively comprise transceivers or other communication hardware or firmware that allows the associated system elements to communicate with one another in the manner described herein.

It is apparent from <FIG> that network element/function <NUM> is configured for communication with network element/function <NUM> and vice-versa via their respective interface circuitries <NUM> and <NUM>. This communication involves network element/function <NUM> sending data to the network element/function <NUM>, and the network element/function <NUM> sending data to the network element/function <NUM>. However, in alternative aspects, other network elements may be operatively coupled between the network elements/functions <NUM> and <NUM>. The term "data" as used herein is intended to be construed broadly, so as to encompass any type of information that may be sent between network elements/functions (as well as between user equipment and a core network) including, but not limited to, messages, identifiers, keys, indicators, user data, control data, etc..

Thus, in one example, network element/function <NUM> is a NF, such as an AMF, and network element/function <NUM> is an NRF. In such case, the AMF and the NRF participate in a service access authorization methodology (discovery and selection) and exchange messages/data as needed. Such service access authorization methodology will be further described below.

It is to be appreciated that the particular arrangement of components shown in <FIG> is an example only, and numerous alternative configurations are used in other aspects. For example, any given network element/function can be configured to incorporate additional or alternative components and to support other communication protocols.

Other system elements such as UE <NUM> and gNB <NUM> may each also be configured to include components such as a processor, memory and network interface. These elements need not be implemented on separate stand-alone processing platforms, but could instead, for example, represent different functional portions of a single common processing platform.

Given the general concepts described above, illustrative aspects that address certain security management issues will now be described. More particularly, illustrative aspects provide security management techniques for <NUM> systems. The architecture for <NUM> systems is currently being standardized in 3GPP. As mentioned above, the 3GPP TS <NUM> defines the <NUM> system architecture as service-based, e.g., Service-Based Architecture (SBA).

<FIG> depicts a <NUM> architecture <NUM> in a configuration comprising a visited public land mobile network (VPLMN) <NUM> operatively coupled via an intermediate Internetwork Packet Exchange (IPX) network <NUM> to a home public land mobile network (HPLMN) <NUM>. Note that there can be more than one IPX network operatively coupled between VPLMN <NUM> and HPLMN <NUM>. <FIG> also illustrates the presence of a Security Edge Protection Proxy (SEPP) at the edge of each PLMN, i.e., vSEPP <NUM> in VPLMN <NUM> and hSEPP <NUM> in HPLMN <NUM>. It is to be appreciated that the various network functions shown in the VPLMN <NUM> and the HPLMN <NUM> are known and described in detail in various <NUM> specifications such as, but not limited to, the above-referenced TS <NUM> and TS <NUM>.

As mentioned above, in <NUM>, SBA is introduced to model services as network functions (NFs) that communicate with each other using Restful application programming interfaces (Representational State Transfer APIs). In the scenario where the two communicating NFs are in two different PLMNs (e.g., VPLMN <NUM> and HPLMN <NUM>), communication happens over a roaming inter-network interface (N32) between the two participating PLMNs.

To protect NF specific content in the messages that are sent over the roaming inter-network interface, <NUM> introduces the SEPP as the entity residing at the perimeter of the PLMN network to protect the PLMN from outside traffic and additionally to implement transport layer security (TLS) and application layer security (ALS) for all the data and signalling exchanged between two inter-network network functions at the service layer. For example, the SEPP performs security management functions on information elements (IE) in HyperText Transport Protocol (HTTP) messages before the messages are sent externally over the roaming N32 interface. The protected HTTP messages are referred to as N32 messages. Protection such as ALS involves protecting information sent in various parts of the HTTP message including, but not limited to, HTTP Request/Response Line, HTTP header and HTTP Payload. However, some parts of this message may need to be modified by intermediaries (e.g., network provider of IPX <NUM> as shown in <FIG>) between the two SEPPs.

Thus, in <NUM> SBA, the PLMN operator deploys a SEPP at the edge of its network to interoperate and obtain services from network functions in its roaming partner networks. The SEPP interfaces with one or more other SEPPs in one or more other networks over the N32 interface. As an edge proxy, the SEPP implements ALS as mentioned above to protect HTTP messages exchanged between a network function in its network and another network function in the roaming partner network.

While two NFs can be in different PLMNs as <FIG> illustrates, some NFs in the same PLMN also have a need to communicate. In either scenario (inter-PLMN communication or intra-PLMN communication), the SBA communication model includes security methods that enable an "NF service consumer" (service client) to be authenticated and authorized to access a service provided by or otherwise associated with an "NF service producer" (service server). One of the supported authorization methods in the above-referenced 3GPP TS <NUM> (Release <NUM>) is based on the OAuth <NUM> access token methodology. In a <NUM> system, the following model is adopted when OAuth <NUM> is used: (i) the NRF is the OAuth <NUM> authorization server; (ii) the NF service consumer is the OAuth <NUM> client; and (iii) the NF service producer is the OAuth <NUM> resource server.

The NF service consumer (client) discovers the NF service producer (resource server) via the NRF, and then obtains an access token to present to the NF service producer when invoking the service API request. In existing approaches (as described in the above-referenced 3GPP TS <NUM> (Release <NUM>)), the access token is bound to the specific NF producer instance that is selected by the NRF or the NF service consumer at the end of the discovery process.

Illustrative aspects realize that by binding the access token to a particular single NF producer instance, selection logic is prevented from selecting from a pool of NF producer instances. Illustrative aspects further realize that selection from a pool of instances is relevant for cases where the currently used instance fails, or when there is a desire to rapidly select a different instance for load balancing purposes, or in the case of an intermediary proxy entity that would do the selection on behalf of the NF service consumer. In addition, illustrative aspects realize that having a <NUM>:<NUM> association between the access token and NF producer instance is sub-optimal as it forces the NF consumer to obtain a new token every time there is a change in the service producer. In fact, the current 3GPP standardized solution requires the NF service consumer to fetch a new access token for each service request and such access token is per each NF producer instance from which it wants to obtain services. See the above-referenced 3GPP TS <NUM>, Clause <NUM>.

As will be further explained in detail herein, illustrative aspects provide for improved service access authorization that enables service selection logic to select from two or more NF producer instances. For example, in one aspect, the NRF generates a JavaScript Object Notation (JSON) Web Token based access token and populates the audience claim field in the token with end-point addresses (i.e., uniform resource locators or URLs) for the set of discovered producer NF instance(s) or producer NF service instance(s). The NRF returns the generated token when the NF service consumer requests an access token after the discovery step. NF selection logic uses the audience claim field to select a producer NF instance based on various factors such as, but not limited to, load balancing.

<FIG> illustrates an example of the overall process as methodology <NUM>.

As shown in step <NUM>, during the NF service discovery process, the NRF captures end-point addresses of all the discovered NF service producer instances in the access token.

In step <NUM>, the NRF returns the stored access token to the NF service consumer instance in an access token response message.

In step <NUM>, selection logic (in the NF service consumer or a proxy, as will be further explained below) applies a set of criteria to select an NF service producer instance based on the entries in the access token. If the selection logic is implemented in the proxy, the proxy may provide selected producer instance's address to the NF service consumer instance.

Each of steps <NUM>, <NUM>, and <NUM> will now be described in further detail.

Capturing all discovered NF service producer instances in the access token (step <NUM>). As part of the discovery procedure, the NRF determines the discovered NF instance(s) or NF service instance(s) and provides the information of a set of discovered NF instance(s) or NF service instance(s) to the NF service consumer via Nnrf_NFDiscovery_Request Response message. The information includes: FQDN (fully qualified domain name), IP (Internet Protocol) address, or end-point addresses (i.e., URLs) for the set of discovered NF instance(s) or NF service instance(s). Details of the discovery process are further described in Clause <NUM>. <NUM><NUM> Technical Specification (TS) <NUM>, V15. <NUM>, entitled "Technical Specification Group Services and System Aspects; Procedures for the <NUM> System, Stage <NUM>".

<FIG> illustrates a methodology <NUM> with additional steps that the NRF performs as part of the discovery procedure according to an illustrative aspect.

In step <NUM>, the NRF generates an access token in the JSON Web Token (JWT) format as described in Internet Engineering Task Force (IETF) Request for Comments (RFC) <NUM>, "JSON Web Token (JWT)," May <NUM>. As will be explained, this format is modified to include a plurality of discovered service producers as per the next step.

In step <NUM>, the NRF populates the audience claim field in the JSON Web Token structure with the end-point addresses of all the discovered NF service producer instance(s) or NF service instance(s). In another aspect, as will be further explained below, the access token can alternatively store end-point addresses of proxy elements corresponding to NF service producer instances.

In step <NUM>, the NRF stores the access token so that it can be provided to the NF service consumer instance in the access token response message (step <NUM>).

<FIG> illustrates at least a portion of a JSON Web Token (JWT) <NUM> and specifically how the audience claim field is used to capture addresses of the discovered NF producer instances with the access token. As shown, JWT <NUM> comprises an NRF identity field <NUM> (identifies the NRF that generates the access token), NF consumer identity <NUM> (identifies the NF requesting access token), and an audience claim field <NUM> with a plurality of NF producer identities and addresses.

In the aspect example shown in <FIG>, the audience claim is an array with each element of the array comprising the NF Instance Id (identity) and the end-point address of the discovered producer instance. Alternative aspects are possible on how the audience claim is formatted.

NRF returns the stored access token request in the Access Token Response message (step <NUM>). Clause <NUM>. <NUM> of the above-referenced 3GPP TS <NUM> describes a procedure for obtaining an access token from the NRF. This is executed by the Consumer NF Instance before service access. Illustrative aspects provide, inter alia, the following changes to the existing procedure:.

As described above in the context of step <NUM>, the access token is populated with all necessary information of the discovered NF service producer instances.

<FIG> illustrates a modified message flow for a service discovery methodology <NUM> according to an illustrative aspect. More particularly, as shown in step <NUM>, the NF service consumer <NUM> sends an Access Token Request to the NRF (Authorization Server) <NUM>. The Access Token Request comprises NF Instance ID, Expected NF service name, and Expected NF service type. In step <NUM>, the NRF <NUM> retrieves the stored access token for this request. Then, in step <NUM>, the NRF <NUM> sends an Access Token Response to the NF service consumer <NUM> which comprises access token, expiration time for the token, and scope of the token).

Selection logic selects a NF service producer instance (step <NUM>). The NF service consumer instance receives the Access Token Response message with the access token included. The NF service consumer instance then applies a set of evaluation factors to determine which NF service producer instance to use for the service request. The NF service consumer executes a service request API to obtain the service from the selected NF service producer instance. The access token is included in the request. Note that the selection logic in some aspects is part of the NF service consumer instance, while in other aspects the selection logic is part of a proxy element.

Given the above illustrative descriptions, some illustrative aspects are further described below.

Thus, in some aspects, the proxy receives the access token from the service consumer and not from the NRF.

As in scenario 2c. above, the proxy in some aspects applies load balancing, or some other selection related functionality, on the API service request by changing the selection made by the NF service consumer based on information in the access token.

In an alternative aspect, as mentioned above in step <NUM> of <FIG>, rather than the access token storing end-point addresses of the service producers, the NRF can generate an access token that stores end-point addresses of the proxy elements. This aspect is useful when, for example, a proxy sits between the two NFs (service consumer and service producer) and the service producer address is not externally visible. The proxy is used as a gatekeeper to one or more service producer instances in the backend. Thus, in this alternative model, the NRF populates the audience claim field with the end-point addresses of proxy agents (elements). The NF service consumer selects one address and sends the message to the proxy. The proxy then selects the service producer instance.

Thus, advantageously, in this model, the service consumer communicates with the proxy element associated with the service producer. In other words, there is no direct connection between the service consumer and the selected service producer. Connection goes through a proxy. Further, in this model, the proxy has an option to change the selected producer based on load balancing criteria or other criteria. The proxy uses the audience claim field in the access token to select a different service producer.

In other aspects, a proxy element may reside in the NRF, in the NF service consumer, and/or in one or more NF service producers.

In addition to load balancing criterion being used for service producer selection criteria, other criteria such as availability (e.g., the service producer has become unavailable/faulty) and/or planned maintenance (e.g., for software upgrade) can be used. Further, in some aspects, the selection criteria comprise one or more operator configured policy criterion.

Claim 1:
Apparatus comprising means for performing:
receiving at an authorization entity (<NUM>) in a communication system comprising a service-based architecture a request from a network function service consumer (<NUM>) in the communication system for access to a given network function service type;
obtaining at the authorization entity (<NUM>) an access token that identifies (i) the authorization entity and (ii) a plurality of network function service producers for the given network function service type and addresses for the plurality of network function service producers; and
sending the access token from the authorization entity (<NUM>) to the network function service consumer (<NUM>).