Patent Description:
Access tokens are used in various communication networks to ensure that only users and network entities that have a right to access certain services can do that. Management of access tokens is important for example in core networks of cellular communication systems, such as in <NUM> core networks developed by the 3rd Generation Partnership Project, 3GPP. The 3GPP still develops <NUM> core networks and there is a need to provide enhanced methods, apparatuses and computer programs for management of access tokens. Such enhancements may be useful in other communication networks as well.

According to some aspects, there is provided the subject-matter of the independent claims. Some example embodiments are defined in the dependent claims.

The scope of protection sought for various example embodiments of the invention is set out by the independent claims. The example embodiments and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various example embodiments of the invention.

According to a first aspect of the present invention, there is provided a method comprising transmitting to a Network Function, NF, service producer, by a Service Communication Proxy, SCP, a service request on behalf of an NF service consumer, wherein the service request comprises an access token, receiving, by the SCP, a service response from the NF service producer and upon receiving the service response, transmitting to the NF service consumer, by the SCP, information related to the access token.

Example embodiments of the first aspect may comprise at least one feature or any combination from the following bulleted list:.

According to a second aspect of the present invention, there is provided a method comprising transmitting, by a Network Function, NF, service consumer, a service request to a Service Communication Proxy, SCP and responsive to transmitting the service request, receiving from the SCP, by the NF service consumer, information related to an access token.

Example embodiments of the second aspect may comprise at least one feature or any combination from the following bulleted list:.

Example embodiments of the first or the second aspect may comprise at least one feature or any combination from the following bulleted list:.

According to a third aspect of the present invention, there is provided an apparatus, comprising one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform perform a method according to the first aspect. The at least one memory and the computer program code may be configured to, with the at least one processing core, cause the apparatus at least to perform, transmit to a Network Function, NF, service producer, by a Service Communication Proxy, SCP, a service request on behalf of an NF service consumer, wherein the service request comprises an access token, receive, by the SCP, a service response from the NF service producer and transmit to the NF service consumer, by the SCP, information related to the access token upon receiving the service response. The apparatus of the third aspect may be the SCP, or a device controlling functioning thereof.

According to a fourth aspect of the present invention, there is provided an apparatus, comprising one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform perform a method according to the second aspect. The at least one memory and the computer program code may be further configured to, with the at least one processing core, cause the apparatus at least to perform, transmit, by a Network Function, NF, service consumer, a service request to a Service Communication Proxy, SCP and receive from the SCP, by the NF service consumer, information related to an access token responsive to transmitting the service request. The apparatus of the fourth aspect may be the NF service consumer, or a device controlling functioning thereof.

According to a fifth aspect of the present invention, there is provided an apparatus, comprising means for performing a method according to the first aspect. The apparatus may comprise means for transmitting to a Network Function, NF, service producer, by a Service Communication Proxy, SCP, a service request on behalf of an NF service consumer, wherein the service request comprises an access token, means for receiving, by the SCP, a service response from the NF service producer and means for transmitting to the NF service consumer, by the SCP, information related to the access token upon receiving the service response. The apparatus of the fifth aspect may be the SCP, or a device controlling functioning thereof.

According to a sixth aspect of the present invention, there is provided an apparatus, comprising means for performing a method according to the second aspect. The apparatus may comprise means for transmitting, by a Network Function, NF, service consumer, a service request to a Service Communication Proxy, SCP and means for receiving from the SCP, by the NF service consumer, information related to an access token responsive to transmitting the service request. The apparatus of the sixth aspect may be the NF service consumer, or a device controlling functioning thereof.

According to a seventh aspect of the present invention, there is provided non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least perform the method of the first aspect. According to an eighth aspect of the present invention, there is provided non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least perform the method of the second aspect.

According to a ninth aspect of the present invention, there is provided a computer program configured to perform the method of the first aspect. According to a tenth aspect of the present invention, there is provided a computer program configured to perform the method of the second aspect.

Management of access tokens may be improved by the procedures described herein. A Service Communication Proxy, SCP, may incorporate information related to an access token to a service response and transmit the service response to a Network Function, NF, service consumer which transmitted a service request originally. The NF service consumer may thus use said information related to the access token for subsequent requests. Hence, processing of subsequent requests becomes more efficient, because the SCP can skip the discovery process.

<FIG> illustrates an exemplary system in accordance with at least some example embodiments of the present invention. The exemplary system of <FIG> comprises two Public Land Mobile Networks, PLMNs, <NUM> and <NUM>, each equipped with at least one NF, <NUM> and <NUM>, respectively. An NF may refer to an operational and/or a physical entity. An NF may be a specific network node or element, or a specific function or set of functions carried out by one or more entities, such as Virtual Network Elements, VNFs. At least some embodiments of the present invention may be applied in containerized deployments as well. One physical node may be configured to perform plural NFs. Examples of such network functions include a (radio) access or resource control or management function, session management or control function, interworking, data management or storage function, authentication function or a combination of one or more of these functions. It should be noted that even though <FIG> shows two PLMNs, embodiments of the present invention are not limited to such a scenario and NFs/SCP/NRFs may be the in same PLMN in some embodiments.

In case of a <NUM>rd Generation Partnership Project, 3GPP, Service-Based Architecture, SBA, of <NUM> core networks, NFs may comprise at least some of an Access and Mobility Function, AMF, a Session Management Function, SMF, a Network Slice Selection Function, NSSF, a NEF, an Network Repository Function, NRF, a UDM, an Authentication Server Function, AUSF, a Policy Control Function, PCF, an Application Function, AF, Operations Administration and Maintenance, OAM, and Network Data Analysis Function, NWDAF. In some example embodiments, the AF may not be a NF though as defined by the 3GPP. Instead, the AF may be a complement to the NF. The AF may be a third party AF, e.g., for an enterprise.

The PLMNs <NUM> and <NUM> may further comprise a Security Edge Protection Proxy, SEPP, <NUM> and <NUM>, respectively. The SEPPs <NUM> and <NUM> may be configured to operate as a security edge node or gateway. The NFs may communicate with each other using representational state transfer Application Programming Interfaces, APIs. These may be known as Restful APIs.

An inter-PLMN interconnection allows secure communication between a service-consuming NF and a service-producing NF, referred to as a NFc <NUM> and a NFp <NUM> in <FIG>. In some example embodiments of the present invention, the NFc <NUM> may be referred to as an NF service consumer, NFc, and the NFp <NUM> may be referred to as an NF service producer, NFp. A Service Communication Proxy, SCP, <NUM> and <NUM> may be deployed for indirect communication between network functions. The SCP <NUM> and <NUM> may be an intermediate function/element for assisting in routing of messages, such as control plane messages such as Diameter Routing Agent, DRA, messages between NFs.

Direct communication may be applied between the NFc <NUM> and the NFp <NUM> for an NF service, or NF service communication may be performed indirectly via SCP(s) <NUM>. In direct communication, the NFc <NUM> may perform discovery of the target NFp <NUM> by local configuration or via a local NRF, the NRFc <NUM>. The NFc <NUM> may delegate the discovery of the target NFp <NUM> to the SCPp <NUM> used for indirect communication. In the latter case, the SCPp <NUM> uses the parameters provided by the NFc <NUM> to perform discovery and/or selection of the target NFp. The SCPp <NUM> address may be locally configured or retrieved from NRF in SCPc <NUM> and SCPc <NUM> address may be locally configured in NFc <NUM>. In general, an SCP may be an intermediate function covering delegated NF discovery to help resolving the target NF producer instances and delegated routing to help route control plane messages between two NFs.

NF discovery and NF service discovery enable core network entities, such as the NFc <NUM> or the SCPc <NUM>, to discover a set of NF instance(s) and NF service instance(s) for a specific NF service or an NF type. The NRF is a function that is used to support the functionality of NFs and NF service discovery and status notification. The NRF may maintain an NF profile of available NF instances and their supported services. The NRF may notify about newly registered, updated, or deregistered NF instances along with its NF services to a subscribed NFc <NUM> or SCPc <NUM>. Unless the expected NF and/or NF service information is locally configured on the requester NF, such as when the expected NF service or NF is in the same PLMN as the requester NF, the NF and NF service discovery may be implemented via the NRF. The NRF may be a logical function. The NRF may also support status notification. An NRF may be co-located together with an SCP.

In order for the NFc <NUM> or the SCPc <NUM> to obtain information about the NF and/or NF service(s) registered or configured in a PLMN/slice, the NFc <NUM> or the SCPc <NUM> may initiate, based on local configuration, a discovery procedure with the NRFc <NUM>. The discovery procedure may be initiated by providing the type of the NF and optionally a list of the specific service(s) it is attempting to discover. The NFc <NUM> or the SCPc <NUM> may also provide other service parameters, such as slicing related information.

In case of indirect communication, during an NF service discovery in inter-PLMN (roaming) communication, the SCPc <NUM>, on behalf of the NFc <NUM>, may request service discovery from an NRF in its PLMN <NUM>, i.e., the NRFc <NUM>. The NRFc <NUM> may send a discovery request to an NRF, referred herein as the NRFp <NUM>, in another PLMN <NUM>, e.g. the home PLMN. The NRFp <NUM> in the other PLMN <NUM> may respond with a discovery response which may be forwarded to the SCPc via the NRFc <NUM> in the PLMN <NUM> of the NFc <NUM>. Then the SCPc may trigger service requests for the NFp via the SEPPc <NUM> and the SEPPp <NUM>. When using indirect communication, a NFc <NUM> may provide the SCP an address or name of the NRF which may be used by the SCP.

It is to be noted that at least some of the entities or nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may act in both service-consuming and service-providing roles and that their structure may also be similar or identical, even though their role in the example of <FIG> in delivery of a particular message is identified by "c" or "p" indicating whether they are acting for the service-consuming or service-producing NF. It is to be noted that instead of "c" and "p", "v" for visited and "h" for home may be used to refer to at least some respective entities in the visited and home PLMNs.

<FIG> illustrates a service request and a response in accordance with at least some example embodiments. In the 3GPP SBA indirect communication was introduced in Rel-<NUM> with the advent of the SCP, such as SCP <NUM> and SCP <NUM> as defined in TS <NUM> V-<NUM> clause <NUM>. Specifically, this then leads to two different deployment models for the operators, shown in <FIG>, Model C - without delegated discovery as specified in clause <NUM>. <NUM> of TS <NUM> V-<NUM> and Model D - with delegated discovery as specified in clause <NUM>. <NUM> of TS <NUM> V-<NUM>.

Therefore, the service request from NFc <NUM> for a particular NFp <NUM> always goes via SCP <NUM>, and similarly, the response sent by NFp <NUM> is first received by SCP <NUM> which is then forwarded to NFc. SCP <NUM> in Model D is also responsible for requesting and receiving the authorization token, e.g., from NRFp <NUM> on behalf on NFc <NUM>, sending a service request to NFp <NUM> on behalf of NFc <NUM>, and also receiving the response from NFp <NUM>, which is then forwarded to NFc <NUM>.

As specified in the clause <NUM> of TS <NUM> V-<NUM>, the current security mechanisms include establishing hop-by-hop TLS for securing messages at the transport layer. If the PLMN <NUM>, <NUM> does not use protection at the transport layer, NDS/IP or physical security may be used. In the clause <NUM> of TS <NUM>, a mechanism to support end to end authentication is proposed using the Client Credentials Assertion, CCA. CCA is a token signed by NFc <NUM>. The token enables NFc <NUM> to authenticate towards the receiving endpoint, such as NRFp <NUM> or NFp <NUM> by including the signed token in a service request.

If NFc <NUM> would add access token parameters to subsequent service requests on its own, such a solution would not be complete because how NFc <NUM> can know what access token parameters to be included towards SCP <NUM>. In Model D shown in <FIG>, token and discovery management is a job of SCP <NUM>, therefore, NFc <NUM> suggesting access token request might not be correct, it may lead to message failure.

As an example, if an AMF wants to send a registration request (service request) to an UDM with discovery parameter (TargetNFType= UDM, NSSAI=eMBB, SUPI=<NUM>), SCPc <NUM> would forward the service request to SCPp <NUM>. The SCPp <NUM> may use discovery parameters to discover the UDM and SCPp <NUM> may decide to contact the best, selected UDM (UDM instance Id or Set id received in the discovery request) for service request.

Accordingly, SCPp <NUM> may ask the access token. Based on operator policy, an access token may be at Set level or Instance level or NFtype level. Additionally, the target service producer, such as NFp <NUM>, may support and require the use of a service level access token (i.e. access token authorizing the access to any service operation of the API) or resource/operation specific access token (i.e. access token specific to access a specific service operation of an API).

See clause <NUM>. <NUM> of TS <NUM>: The access scope required to get access to a given resource may be, based on local configuration of the NF service producer, either:.

Each NFp <NUM> may register the allowed service operations per the NF type or NF instance of NFc <NUM>, as an array of scopes. See clause <NUM>. <NUM> of TS <NUM>: Definition of type NFService. Since NFc <NUM> in Model D does not interact with an NRF like NRF <NUM>, i.e., SCP <NUM>, <NUM> does the NF discovery towards the NRF, but NFc <NUM> cannot know which access token scope to request.

If a service request is successful, the SCPp <NUM> passes the access token to SCPc <NUM> and SCPc <NUM> passes this token to NFc <NUM>. NFc <NUM>, such as the AMF, may then want to send a subsequent request, such as a registration update, to SCP <NUM>, may reuse the previous received access token. However, if the access token has expired (in general, token may expire in <NUM>-<NUM>) NFc <NUM> may add a parameters to the subsequent request so that the SCPp <NUM> can get the access token accordingly. But if the parameter is decided by NFc <NUM>, the challenge is how NFc <NUM>, such as an AMF, can send those parameters which are relevant for NFp <NUM>, such as an UDM, considering NFc <NUM> has no idea how SCPp <NUM> has retrieved the access token in the previous/first service request.

It is first noted that a binding header defined by the 3GPP may be used in some cases only if NFc <NUM> supports the use of the binding header and token is at Set/Instance level. But if NFc <NUM> does not support binding, or token is at NFType/Group level, then the binding concept would not be useful at all.

Secondly, NRF <NUM> may have SUPI to Group Id mapping, therefore, in the discovery response, NRF <NUM> may have selected the Group for an UDM, and the same group is used for access token request. In this case also, an AMF does not have group details of the UDM for sending access token parameter to SCP <NUM>.

Embodiments of the present invention therefore enable SCP <NUM> to build for example a new header with access token request parameters, or more generally access token related information, and to pass said information related to the access token in the new header within the service response to NFc <NUM>. NFc <NUM> may store the received information and pass the information, such as the parameters, to SCP <NUM> in a subsequent request or include the necessary information (e.g. discovery headers) in subsequent requests according to the access token related information received in the earlier service response. Furthermore, communication between SCPp <NUM> and SCPc <NUM> may be enhanced to allow sending back the new header to SCPc <NUM> and then to NFc <NUM>.

The new header is particularly useful, because SCPs cannot read message content sent by an NFc, therefore the NFc should send the access token related information in a header, such as some HTTP header, example HTTP custom header "3GPP-SBI-AccessTokenRelatedInfo header". The existing defined HTTP headers cannot be used as is, therefore either a new HTTP header may be introduced or some existing available headers modified, to enable efficient management of access tokens.

<FIG> illustrates a first signalling example in accordance with at least some example embodiments. On the vertical axes are disposed, from the left to the right, NFc <NUM>, SCP <NUM>, NRF <NUM> and NFp <NUM> of <FIG>, however solution and problem statement are valid if NFs/SCP/NRFs are in same PLMN or different PLMNs. Time advances from the top towards the bottom. <FIG> illustrates an example for authorization and service invocation procedure, e.g., for indirect communication with delegated discovery.

At step <NUM>, NFc <NUM> may send a service request to SCP <NUM>. The service request may include CCA of NFc <NUM> as defined in clause <NUM>. <NUM> of TS <NUM> V-<NUM>. In the service request, NFc <NUM> may include discovery parameters.

At step <NUM>, SCP <NUM> may perform a service discovery with NRF <NUM>. At step <NUM>, SCP <NUM> may send an access token request (Nnrf_AccessToken_Get Request) to NRF <NUM>. The access token request may comprise parameters as defined for example in clause <NUM>. <NUM> of TS <NUM>. The access token request may include the CCA of NFc <NUM> if received at Step <NUM>.

At step <NUM>, NRF <NUM> may authenticate NFc <NUM> using one of the methods described in clause <NUM>. <NUM> of TS <NUM>. If authentication of NFc <NUM> is successful and NFc <NUM> is authorized based on policy of NRF <NUM>, NRF <NUM> may issue an access token as described in clause <NUM>. <NUM> of TS <NUM>. NRF <NUM> may use an instance ID of NFc <NUM> as the subject of the access token.

At step <NUM>, NRF <NUM> may send the access token to SCP <NUM> in an access token response (Nnrf_AccessToken_Get Response). At step <NUM>, SCP <NUM> may send the service request to NFp <NUM>. The service request may include the access token received at Step <NUM>, and also the CCA of NFc <NUM> if received at Step <NUM>.

At step <NUM>, NFp <NUM> may authenticate NFc <NUM> by one of the methods described in clause <NUM>. <NUM> of TS <NUM> and if successful, NFp <NUM> validates the access token as described in clause <NUM>. <NUM> of TS <NUM>. At step <NUM>, if the validation of the access token is successful, NFp <NUM> sends the service response to SCP <NUM>.

At step <NUM>, SCP <NUM> may include into the service response information related to the access token, such as the access token request parameters used by SCP <NUM> for sending the service request to NRF <NUM>, and forward the service response to NFc <NUM>. So if NFc <NUM> includes said information related to the access token to subsequent requests, SCP <NUM> can process subsequent requests more efficiently, since the SCP can skip the discovery process.

In some embodiments, at step <NUM>, SCP <NUM> may add a new header, such as 3GPP-SBI-AccessTokenRelatedInfo, which comprises said information related to the access token, like the parameter used by SCP <NUM> to retrieve the access token and/or access token related information telling the NF service consumer which information it should pass in subsequent requests for access authorization, i.e., what information NFc <NUM> should include to subsequent requests for access authorization.

Example <NUM>: 3GPP-SBI-AccessTokenRelatedInfo: targetNfType= UDM; targetPlmn= <NUM>; nflnstanceId= Source Instance Id; TargetGroupId = <NUM>; TargetSetId/instanceid= <NUM>; scope= nudm-sdm. Example <NUM>: 3GPP-SBI-AccessTokenRelatedInfo: targetNfType; targetPlmn; requesterNflnstanceId; scope= nudm-sdm; targetSnssai=eMBB; NOTE: In this second example, the parameters whose value is already known to NFc <NUM> need not be included in this header (e.g. target NF type = UDM).

Alternatively, in some embodiments, SCP <NUM> may, at step <NUM>, may return said information related to the access token, such as 3GPP-SBI-AccessTokenRelatedInfo, along with the access token itself to NFc <NUM>. NFc <NUM> may then store both, said information related to the access token and the access token. As token expiry may be limited to some minutes (for example <NUM>-<NUM>), the stored access token may become invalid after that time. If NFc <NUM> wants to initiate a subsequent request and the access token is valid (not expired), then same access token is to be used by NFc <NUM>. However, if the access token has expired (not valid anymore), then NFc <NUM> must transmit said information related to the access token, such as the 3GPP-SBI-AccessTokenRelatedInfo header, back to SCP <NUM> for subsequent requests, or instead must include the requested information using a discovery header, such as the 3gpp-Sbi-Discovery header (e.g. 3gpp-Sbi-Discovery-target-nf-type: UDM), see clause <NUM>. <NUM> of TS <NUM>. Based on this header, SCP <NUM> can make a quick decision to get the access token again. Hence the management of access tokens may be improved if the access token is transmitted along with said information related to the access token.

Alternatively, for example in case of multiple SCP deployment, if SCPp <NUM> is doing an access token retrieval, then, SCPp <NUM> may send said information related to the access token, such as 3GPP-SBI-AccessTokenRelatedInfo header, back to SCPc <NUM> and SCPc <NUM> may send said information to NFc <NUM>. Similarly, if NFc <NUM> sends a subsequent request to SCPc <NUM> with said information related to the access token, such as 3GPP-SBI-AccessTokenRelatedInfo header, SCPc <NUM> may forward the access token to SCPp <NUM> so that SCPp <NUM> can retrieve the access token accordingly.

Embodiments of the present invention therefore provide an optimization for SCP <NUM>, since SCP <NUM> does not need to do a new discovery request towards NRF <NUM> to discover what access authorization parameters are required by NFp <NUM> (e.g. required scopes). Instead, SCP <NUM> can straight away ask for the new access token, i.e. if SCP <NUM> gets provided with the access token request parameters, SCP <NUM> can directly contact NRF <NUM> with this earlier provided information, so discovery request is not needed, SCP <NUM> is going directly for the token request. Thus, NRF <NUM> only needs to provide the new access token.

Embodiments of the present invention also allow supporting extensions to the access authorization procedures without impacting NFc <NUM>. an access token cannot be requested today for a granularity of an NF group, but such extension could be done transparently for NFc <NUM>, by SCP <NUM> inserting in the 3GPP-SBI-AccessTokenRelatedInfo header the required information (e.g. nfGroupId=xyz).

<FIG> illustrates an example apparatus capable of supporting at least some example embodiments. Illustrated is device <NUM>, which may comprise, for example, SCP <NUM> or NFp <NUM>, or a device controlling functioning thereof. Comprised in device <NUM> is processor <NUM>, which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core. Processor <NUM> may comprise, in general, a control device. Processor <NUM> may comprise more than one processor. Processor <NUM> may be a control device. Processor <NUM> may comprise at least one Application-Specific Integrated Circuit, ASIC. Processor <NUM> may comprise at least one Field-Programmable Gate Array, FPGA. Processor <NUM> may comprise an Intel Xeon processor for example. Processor <NUM> may be means for performing method steps in device <NUM>, such as determining, causing transmitting and causing receiving. Processor <NUM> may be configured, at least in part by computer instructions, to perform actions.

A processor may comprise circuitry, or be constituted as circuitry or circuitries, the circuitry or circuitries being configured to perform phases of methods in accordance with example embodiments described herein. 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, and (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 network function, to perform various functions) and (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.

Device <NUM> may comprise a transmitter <NUM>. Device <NUM> may comprise a receiver <NUM>. Transmitter <NUM> and receiver <NUM> may be configured to transmit and receive, respectively, information in accordance with at least one cellular standard, such as a standard defined by the 3GPP. Transmitter <NUM> may comprise more than one transmitter. Receiver <NUM> may comprise more than one receiver. Transmitter <NUM> and/or receiver <NUM> may be configured to operate in accordance with a suitable communication standard.

Device <NUM> may comprise User Interface, UI, <NUM>. UI <NUM> may comprise at least one of a display, a keyboard, a touchscreen, a vibrator arranged to signal to a user by causing device <NUM> to vibrate, a speaker and a microphone. A user may be able to operate device <NUM> via UI <NUM>, for example to configure device <NUM> and/or functions it runs.

Device <NUM> may comprise further devices not illustrated in <FIG>. In some example embodiments, device <NUM> lacks at least one device described above. For example, device <NUM> may not have UI <NUM>.

Processor <NUM>, memory <NUM>, transmitter <NUM>, receiver <NUM> and/or UI <NUM> may be interconnected by electrical leads internal to device <NUM> in a multitude of different ways. For example, each of the aforementioned devices may be separately connected to a master bus internal to device <NUM>, to allow for the devices to exchange information. However, as the skilled person will appreciate, this is only one example and depending on the embodiment various ways of interconnecting at least two of the aforementioned devices may be selected without departing from the scope of the present invention.

<FIG> is a flow graph of a first method in accordance with at least some example embodiments. The phases of the illustrated first method may be performed by a SCP, such as SCP <NUM>, or by a control device configured to control the functioning thereof, possibly when installed therein.

The first method may comprise, at step <NUM>, transmitting to a Network Function, NF, service producer, by a Service Communication Proxy, SCP, a service request on behalf of an NF service consumer, wherein the service request comprises an access token. The first method may also comprise, at step <NUM>, receiving, by the SCP, a service response from the NF service producer. Finally, the first method may comprise, at step <NUM>, upon receiving the service response, transmitting to the NF service consumer, by the SCP, information related to the access token.

<FIG> is a flow graph of a second method in accordance with at least some example embodiments. The phases of the illustrated second method may be performed by an NF service consumer, such as a NFc <NUM>, or by a control device configured to control the functioning thereof, possibly when installed therein.

The second method may comprise, at step <NUM>, transmitting, by a Network Function, NF, service consumer, a service request to a Service Communication Proxy, SCP. The second method may also comprise, at step <NUM>, receiving from the SCP, by the NF service consumer, information related to an access token responsive to transmitting the service request.

In some embodiments, the SCP may receive in a (subsequent) request the new header, and for example request an access token to the (Access) Authorization Server using the information received in the new header, and receive an access token from the authorization server that it includes in the request it forwards to the NF service producer.

In some embodiments, the NFc may receive the access token info from the SCP in a service response, and include access token info in subsequent requests using said access token info. For example, the NFc may include the same access token info in subsequent request, as received from SCP or include the requested access token info (using for example discovery headers), according to the access token info received from the SCP.

It is to be understood that the embodiments disclosed are not limited to the particular structures, process steps, or materials disclosed herein, but are extended to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular example embodiments only and is not intended to be limiting.

Reference throughout this specification to one example embodiment or an example embodiment means that a particular feature, structure, or characteristic described in connection with the example embodiment is included in at least one example embodiment. Thus, appearances of the phrases "in one example embodiment" or "in an example embodiment" in various places throughout this specification are not necessarily all referring to the same example embodiment.

In addition, various example embodiments and examples may be referred to herein along with alternatives for the various components thereof. It is understood that such example embodiments, examples, and alternatives are not to be construed as de facto equivalents of one another, but are to be considered as separate and autonomous representations.

In an example embodiment, an apparatus, such as, for example, SCP <NUM> or NFp <NUM>, or a device controlling functioning thereof, may comprise means for carrying out the example embodiments described above and any combination thereof.

In an example embodiment, a computer program may be configured to cause a method in accordance with the example embodiments described above and any combination thereof. In an exemplary example embodiment, a computer program product, embodied on a non-transitory computer readable medium, may be configured to control a processor to perform a process comprising the example embodiments described above and any combination thereof.

In an example embodiment, an apparatus, such as, for example, SCP <NUM> or NFp <NUM>, or a device controlling functioning thereof, may comprise at least one processor, and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform the example embodiments described above and any combination thereof.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more example embodiments. In the preceding description, numerous specific details are provided, such as examples of lengths, widths, shapes, etc., to provide a thorough understanding of example embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.

While the forgoing examples are illustrative of the principles of the example embodiments in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation may be made without the exercise of inventive faculty, and without departing from the principles and concepts of the invention.

At least some example embodiments find industrial application at least in <NUM> core networks, wherein management of access tokens is important, and possibly in other networks in the future as well.

Claim 1:
A method, comprising:
- transmitting to a Network Function, NF, service producer, by a Service Communication Proxy, SCP, a service request on behalf of an NF service consumer, wherein the service request comprises an access token;
- receiving, by the SCP, a service response from the NF service producer;
- upon receiving the service response, transmitting to the NF service consumer, by the SCP, information related to the access token; and
- receiving, by the SCP, a subsequent service request from the NF service consumer, wherein the subsequent service request comprises said information related to the access token;
asking, by the SCP, for a new access token from a Network Repository Function, NRF, using said information related to the access token, wherein said information related to the access token comprises at least one access token request parameter and the at least one access token request parameter comprises a parameter used by the SCP to retrieve the access token.