Patent Description:
There exist various techniques for handling a request for a service in a network. A service request is generally from a consumer of the service ("service consumer") to a producer of the service ("service producer"). For example, a service request may be from a network function (NF) node of a service consumer to an NF node of a service producer. The NF node of the service consumer (NFc) and the NF node of the service producer (NFp) can communicate directly or indirectly. This is referred to as direct communication and indirect communication respectively. In the case of indirect communication, the NF node of the service consumer and the NF node of the service producer may communicate via a service communication proxy (SCP) node.

<FIG>illustrates different existing systems for handling service requests, as set out in <NPL>). In more detail, <FIG> illustrates a system that uses direct communication, while <FIG> illustrates a system that uses indirect communication.

In the systems illustrated in <FIG>, a service request is sent directly from the NF node of the service consumer to the NF node of the service producer. A response to the service request is sent directly from the NF node of the service producer to the NF node of the service consumer. Similarly, any subsequent service requests are sent directly from the NF node of the service consumer to the NF node of the service producer. The system illustrated in <FIG> also comprises a network repository function (NRF). Thus, in the system illustrated in <FIG>, the NF node of the consumer can query the NRF to discover suitable NF nodes of the service producer to which to send the service request. In response to such a query, the NF node of the consumer can receive an NF profile for one or more NF nodes of the service producer and, based on the received NF profile(s) can select an NF node of the service producer to which to send the service request. In the system illustrated in <FIG>, the NRF is not used and instead the NF node of the consumer may be configured with the NF profile(s) of the NF node(s) of the service producer.

In the systems illustrated in <FIG>, a service request is sent indirectly from the NF node of the service consumer to the NF node of the service producer via a service communication proxy (SCP) node. A response to the service request is sent indirectly from the NF node of the service producer to the NF node of the service consumer via the SCP. Similarly, any subsequent service requests are sent indirectly from the NF node of the service consumer to the NF node of the service producer via the SCP. The systems illustrated in <FIG>also comprise an NRF.

In the system illustrated in <FIG>, the NF node of the consumer can query the NRF to discover suitable NF nodes of the service producer to which to send the service request. In response to such a query, the NF node of the consumer can receive an NF profile for one or more NF nodes of the service producer and, based on the received NF profile(s) can select an NF node of the service producer to which to send the service request. In this case, the service request sent from the NF node of the service consumer to the SCP comprises the address of the selected NF node of the service producer. The NF node of the service consumer can forward the service request without performing any further discovery or selection. In case the selected NF node of the service producer is not accessible for any reason, it may be up to the NF node of the service consumer to find an alternative. In other cases, the SCP may communicate with the NRF to acquire selection parameters (e.g. location, capacity, etc.) and the SCP may select an NF node of the service producer to which to send the service request.

In the system illustrated in <FIG>, the NF node of the consumer (NFc) does not carry out the discovery or selection process. Instead, the NF node of the consumer may add any necessary discovery and selection parameters (required to find a suitable NF node of the service producer, NFp) to the service request that it sends via the SCP. The SCP may then use the request address and the discovery and selection parameters in the service request to route the service request to a suitable NF node of the service producer. The SCP can perform discovery with the NRF. The NF node of the consumer may also include a client credentials assertion in the service request, to be used by the SCP in authorisation processes. Client credentials assertions are tokens signed by the NF node of the consumer, that enable the NF node of the consumer to authenticate towards the receiving end point (NRF, NF node of a producer) by including the signed token in a service request. The use of client credentials assertions is discussed in <NPL>), particularly in section <NUM>.

For the fifth generation core (5GC), from Release <NUM>, the SCP is included as a network element to allow indirect communication between an NF node of a service consumer and an NF node of a service producer. The indirect communication that is used can be either of the two indirect communications options described earlier with reference to <FIG>.

<FIG> is a signalling diagram illustrating an exchange of signals in an existing system, such as the system illustrated in <FIG>. The system illustrated in <FIG> comprises a first SCP node <NUM>, a first NF node <NUM> of a service consumer ("NFc"), a second NF node <NUM> of a service producer ("NFp1"), and a third NF node <NUM> of a service producer ("NFp2"). The first SCP node <NUM> is configured to operate as an SCP between the first NF node <NUM> and the second NF node <NUM>. The second NF node <NUM> can be configured to run a service <NUM> and the third NF node <NUM> can be configured to run a service <NUM>. The second NF node <NUM> and the third NF node <NUM> can be configured to run the same service or a different service. The second NF node <NUM> and the third NF node <NUM> can be part of a set <NUM> of NF nodes of a service producer. The system illustrated in <FIG> also comprises a network repository function <NUM>.

In <FIG>, steps <NUM>-<NUM> relate to a first request for a user equipment (UE)/session context. As illustrated by block <NUM> of <FIG>, the UE/session context may be stored. In more detail, as illustrated by block <NUM> of <FIG>, the first NF node <NUM> determines what discovery and selection parameters to use. The parameters can be associated with a certain service in a received request, which is not illustrated in <FIG>. As illustrated by blocks <NUM> and <NUM> of <FIG>, the first NF node <NUM> stores the UE/session context for the request. This storage may be cached or externally stored.

As illustrated by arrow <NUM> of <FIG>, the first NF node (NFc) <NUM> initiates transmission of a discovery request to the first SCP node <NUM>. The discovery request includes a client credentials assertion, which provides information that validates the client and which can be used by the first SCP to obtain an access token on behalf of the first NF node <NUM>. The first SCP node <NUM> uses the discovery request to obtain NF profile(s) of one or more NF nodes of the service producer (NFp)_for the service that needs to be executed from the NRF <NUM> (see arrows <NUM> and <NUM>). As illustrated by blocks <NUM> and <NUM> of <FIG>, the first SCP node <NUM> can store the discovery results (the returned NF profile(s)).

As illustrated by arrow <NUM>, the first SCP node <NUM> sends an access token request to the NRF <NUM>. The access token request includes some of parameters from the discovery parameters received in the request (see arrow <NUM>) and may also include other information from the first SCP node <NUM> such as the scope (one or multiple services). Which discovery parameters would need to be used to grant an access token may be configured in the first SCP node <NUM>. Access token request parameters are discussed in more detail in 3GPP TS <NUM> (as cited above), particularly in section <NUM>. Discovery parameters are discussed in greater detail in <NPL>, particularly in section <NUM>. <NUM> Tokens may need to be granted with different granularity, for example, they may be required at service level plus network slice level (using Single - Network Slice Selection Assistance Information, S-NSSAI, which may therefore be required to grant an access token in this example). Then, at arrow <NUM>, the NRF grants an access token for the indicated granularity. The access token is then cached by the first SCP node <NUM> (see block <NUM> and <NUM>) in conjunction with the criteria of the access token (scope and granularity). The access token may be valid for a predetermined period of time, the duration of which may be indicated by the NRF <NUM>, for example, when the NRF <NUM> provides the access token response including the access token. After the predetermined period of time, the access token may expire.

As illustrated by block <NUM>, the first SCP node <NUM> then selects a NF node of the service producer from among the NF profile(s) obtained using the discovery request (at arrows <NUM> and <NUM>), in this example the second NF node <NUM>. The selected NF node of the service producer is a NF node which corresponds to the granted access token received by the first SCP node at arrow <NUM>. The determination of which of the obtained NF node profile(s) to select (assuming more than one NF node profile has been received) depends on the specific configuration of the SCP node <NUM>.

Once a NF node (in this example, the second NF node <NUM>) has been selected, the first SCP node <NUM> modifies the address in the request (received from the first NF node <NUM>) from the address of the first SCP node <NUM> to the address of the host of the second NF node <NUM>, as shown at block <NUM>. The first SCP node <NUM> may optionally perform further tasks such as NF producer node monitoring (see block <NUM>). The first SCP node <NUM> then initiates transmission of the service request towards the selected second NF node <NUM> at arrow <NUM>; the access token obtained by the first SCP node <NUM> has been added to the service request. As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> receives a response comprising the result from the second NF node <NUM>. If the selected NF producer node supports binding functionality, the result may comprise a client binding header with binding information, that is intended to be used by the NFc in subsequent requests. The response also includes the NF instance ID, and set ID. As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> initiates transmission of the response comprising the result towards the first NF node <NUM>. As illustrated by blocks <NUM> and <NUM> of <FIG>, the first NF node <NUM> can then store the result.

In <FIG>, steps <NUM>-<NUM> relate a subsequent service request for an existing UE/session context. At block <NUM>, the first NF node <NUM> identifies that the subsequent result corresponds to the same UE/session context. At block <NUM> the first NF node <NUM> copies the client binding information received in the result from the second NF node <NUM> to the routing binding, as the communication between the first NF node <NUM> and second NF node <NUM> is indirect (via the first SCP node <NUM>) in this example; this step is not necessary where binding is not used. The first NF node <NUM> then sends a service request (at arrow <NUM>) including the routing binding (in this example; as mentioned above binding is not necessarily used) and also including the client credentials assertion. The client credentials assertion may be required if the previously obtained token has expired.

At block <NUM>, the first SCP node <NUM> attempts to locate a valid access token from stored results (see blocks <NUM> and <NUM> for access token storage). However, the information included in the subsequent request at arrow <NUM> does not provide the means to identify a valid token. Although a client credentials assertion is included in the subsequent request, other information which may have been provided in a discovery request in the first request (see arrow <NUM>) is not included in the subsequent request at arrow <NUM>. The first SCP node <NUM> is therefore unable to locate a valid stored access token, and is also unable to request an applicable token as the information required for a token request is not provided. In this example, the S-NSSAI is not provided. Accordingly, it is not possible for the first SCP node <NUM> to obtain a valid token and the subsequent request procedure fails.

Thus in systems using indirect communication, a subsequent request for a service, after a first request that provided discovery parameters to a SCP node to allow selection, is not able to be proceeded by the SCP node. The SCP node cannot find a valid stored access token and does not have enough information to be able to request a new access token.

It is an object of the disclosure to obviate or eliminate at least some of the above-described disadvantages associated with existing techniques.

Therefore, according to an aspect of the disclosure, there is provided a method for handling a service request in a network, wherein the method is performed by a first network function, NF, node of a service consumer for connecting to a further NF node of a service producer via a first Service Communication Proxy, SCP, node. The method comprises initiating transmission to the first SCP node of a first request for provision of a first service by the further NF node. The first request comprises discovery parameters and access token request parameters. The access token request parameters facilitate obtaining and storing of an access token by the first SCP node and the discovery parameters facilitate the selection, by the first SCP node, of a second NF node of a service producer as the further NF node to provide the first service and forwarding the request to the second NF node by the first SCP node. The method further comprises receiving a response from the second NF node forwarded by the first SCP node. The method also comprises initiating transmission of a second request to the first SCP node where the second request is a subsequent request for the second NF node to provide the first service. The second request comprises the access token request parameters, and the first SCP node forwards the second request to the second NF node with the stored access token or a newly obtained access token included in the second request.

In some embodiments, the first request may comprise an encrypted token to enable the first SCP node to obtain an access token on behalf of the first NF node, where the encrypted token may be stored with the access token request parameters. The second request may also comprise the encrypted token. The encrypted token may be a NF Service consumer client credentials assertion.

In some embodiments, the second request may be for the second NF node to provide the first service in the same execution context as the first request.

In some embodiments, the access token request parameters may be stored in a User Equipment, UE, data record.

In some embodiments, the access token request parameters may comprise Single - Network Slice Selection Assistance Information, S-NSSAI.

In some embodiments the method may further comprise receiving, by the first SCP node, the first request for provision of a first service by the further NF node. The method may further comprise acquiring service producer NF node profiles, acquiring access tokens, and selecting the second NF node using the acquired service producer NF node profiles. The method may also comprise initiating transmission to the second NF node of a third request for the second NF node to provide a service, the third request including an acquired access token, receiving a response from the second NF node and initiating transmission of the response to the first NF node.

In some embodiments, the step of acquiring service producer NF node profiles may comprise initiating transmission to a Network Repository Function, NRF, node of a fourth request using the discovery parameters from the first request for service producer NF node profiles, and receiving a first response from the NRF node, or retrieving stored service producer NF node profiles. Also, the step of acquiring access tokens may comprise initiating transmission to the NRF node of a fifth request for access tokens using the access token request parameters from the first request, and receiving a second response from the NRF node, or retrieving stored access tokens. Further, the service producer NF node profiles and/or access tokens may be stored.

In some embodiments, the method may further comprise the first SCP node receiving the second request that is a subsequent request for the second NF node to provide the first service. The method may further comprise obtaining a valid access token using the access token request parameters from the second message. The method may also comprise initiating transmission to the second NF node of a sixth request for service provision, the sixth request including a valid access token, receiving a response from the second NF node, and initiating transmission to the first NF node.

According to another aspect of the disclosure, there is provided a first NF node comprising processing circuitry configured to operate in accordance with the method described earlier in respect of the first NF node. In some embodiments, the first NF node may comprise at least one memory for storing instructions which, when executed by the processing circuitry, cause the first NF node to operate in accordance with the method described earlier in respect of the first NF node.

According to another aspect of the disclosure, there is provided a method performed by a system. The method may comprise the method described earlier in respect of the first SCP node and/or the method as described earlier in respect of the first NF node.

According to another aspect of the disclosure, there is provided a system. The system may comprise at least one first SCP node as described earlier and/or at least one first NF node as described earlier.

According to another aspect of the disclosure, there is provided a computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method as described earlier in respect of the first SCP node and/or first NF node.

According to another aspect of the disclosure, there is provided a computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry to cause the processing circuitry to perform the method as described earlier in respect of the first SCP node and/or first NF node.

Thus, an improved technique for handling service requests in a network is provided.

For a better understanding of the technique, and to show how it may be put into effect, reference will now be made, by way of example, to the accompanying drawings, in which:.

Herein, techniques for handling a service request in a network are described. A service request can also be referred to as a request for a service. Generally, a service is software intended to be managed for users. Herein, a service can be any type of service, such as a communication service (e.g. a notification service or a callback service), a context management (e.g. user equipment context management (UECM)) service, a data management (DM) service, or any other type of service. The techniques described herein can be used in respect of any network, such as any communications or telecommunications network, e.g. cellular network. The network may be a fifth generation (<NUM>) network or any other generation network. In some embodiments, the network may be a core network or a radio access network (RAN). The techniques described herein are implemented by a first service communication proxy (SCP) node and a first network function (NF) node of a service consumer (NFc node). The SCP node can be configured to operate as an SCP between the NFc node and at least one NF node of a service producer (NFp node) in the network.

An NF is a third generation partnership project (3GPP) adopted or 3GPP defined processing function in a network, which has defined functional behaviour and 3GPP defined interfaces. An NF can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure. Herein, the term "node" in relation to an "NF node" will be understood to cover each of these scenarios.

<FIG> illustrates a first SCP node <NUM> in accordance with an embodiment. The first SCP node <NUM> is for handling a service request in a network. The first SCP node <NUM> is configured to operate as an SCP between a first network function, NF, node (<NUM>) of a service consumer and a second NF node (<NUM>) of a service producer in the network. In some embodiments, the first SCP node <NUM> can be, for example, be a physical machine (e.g. a server) or a virtual machine (VM).

As illustrated in <FIG>, the first SCP node <NUM> comprises processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the first SCP node <NUM> and can implement the method described herein in respect of the first SCP node <NUM>. The processing circuitry <NUM> can be configured or programmed to control the first SCP node <NUM> in the manner described herein. The processing circuitry <NUM> can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and/or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described herein in respect of the first SCP node <NUM>. In some embodiments, the processing circuitry <NUM> can be configured to run software to perform the method described herein in respect of the first SCP node <NUM>. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry <NUM> may be configured to run a container to perform the method described herein in respect of the first SCP node <NUM>.

Briefly, the processing circuitry <NUM> of the first SCP node <NUM> is configured to receive a first request (from a first NF node <NUM>, a consumer NF node) for provision of a first service by a further NF node (that is a provider NF node). The processing circuitry <NUM> of the first SCP node <NUM> is further configured to acquire service producer NF node profiles and access tokens, and select the second NF node <NUM> using the acquired service producer NF node profiles. The processing circuitry <NUM> of the first SCP node <NUM> is also configured to initiate transmission to the second NF node <NUM> of a third request for the second NF node <NUM> to provide a service, the third request including an acquired access token; receive a response from the second NF node <NUM>, and initiate transmission of the response to the first NF node <NUM>.

As illustrated in <FIG>, in some embodiments, the first SCP node <NUM> may optionally comprise a memory <NUM>. The memory <NUM> of the first SCP node <NUM> can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory <NUM> of the first SCP node <NUM> may comprise a non-transitory media. Examples of the memory <NUM> of the first SCP node <NUM> include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital video disk (DVD), and/or any other memory.

The processing circuitry <NUM> of the first SCP node <NUM> can be connected to the memory <NUM> of the first SCP node <NUM>. In some embodiments, the memory <NUM> of the first SCP node <NUM> may be for storing program code or instructions which, when executed by the processing circuitry <NUM> of the first SCP node <NUM>, cause the first SCP node <NUM> to operate in the manner described herein in respect of the first SCP node <NUM>. For example, in some embodiments, the memory <NUM> of the first SCP node <NUM> may be configured to store program code or instructions that can be executed by the processing circuitry <NUM> of the first SCP node <NUM> to cause the first SCP node <NUM> to operate in accordance with the method described herein in respect of the first SCP node <NUM>. Alternatively or in addition, the memory <NUM> of the first SCP node <NUM> can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry <NUM> of the first SCP node <NUM> may be configured to control the memory <NUM> of the first SCP node <NUM> to store information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

In some embodiments, as illustrated in <FIG>, the first SCP node <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the first SCP node <NUM> can be connected to the processing circuitry <NUM> of the first SCP node <NUM> and/or the memory <NUM> of first SCP node <NUM>. The communications interface <NUM> of the first SCP node <NUM> may be operable to allow the processing circuitry <NUM> of the first SCP node <NUM> to communicate with the memory <NUM> of the first SCP node <NUM> and/or vice versa. Similarly, the communications interface <NUM> of the first SCP node <NUM> may be operable to allow the processing circuitry <NUM> of the first SCP node <NUM> to communicate with the first NF node and/or any other node. The communications interface <NUM> of the first SCP node <NUM> can be configured to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry <NUM> of the first SCP node <NUM> may be configured to control the communications interface <NUM> of the first SCP node <NUM> to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

Although the first SCP node <NUM> is illustrated in <FIG> as comprising a single memory <NUM>, it will be appreciated that the first SCP node <NUM> may comprise at least one memory (i.e. a single memory or a plurality of memories) <NUM> that operate in the manner described herein. Similarly, although the first SCP node <NUM> is illustrated in <FIG> as comprising a single communications interface <NUM>, it will be appreciated that the first SCP node <NUM> may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interfaces) <NUM> that operate in the manner described herein. It will also be appreciated that <FIG> only shows the components required to illustrate an embodiment of the first SCP node <NUM> and, in practical implementations, the first SCP node <NUM> may comprise additional or alternative components to those shown.

<FIG> is a flowchart illustrating a method performed by a first SCP node <NUM> in accordance with an embodiment. The first SCP node <NUM> is configured to operate as an SCP between a first NF node of a service consumer and a second NF node of a service producer in the network. The method is for handling a service request in the network. The first SCP node <NUM> described earlier with referenced to <FIG> may be configured to operate in accordance with the method of <FIG>. The method can be performed by or under the control of the processing circuitry <NUM> of the first SCP node <NUM>.

The method of <FIG> is performed when a first request, for a first service to be provided, is received from the first NF node <NUM> (see block <NUM> of <FIG>). The initiation of transmission of the first request by the first NF node <NUM> is discussed below with reference to <FIG>. After receiving the first request, the first SCP node <NUM> acquires service producer NF node (NFp) profiles (see block <NUM>). The NFp profiles may be acquired from a NRF <NUM>; the first SCP node <NUM> may submit a discovery request to the NRF <NUM> and may then receive a response from the NRF <NUM> including the NFp profiles. Where a discovery request to the NRF <NUM> is used, this discovery request may use discovery parameters included in the first request from the first NF node <NUM>, and may also include parameters from the first SCP node <NUM> based on the local configuration of the first SCP node <NUM>. The acquired NFp profiles may then be stored by the first SCP node <NUM>. Alternatively, the first SCP node <NUM> may retrieve stored NFp profiles from storage that is part of or connected to the first SCP node <NUM> if stored NFp profiles are available.

The first SCP node <NUM> also acquires one or more access tokens, as illustrated by block <NUM>. The access tokens may be acquired from a NRF <NUM>, by submitting an access token request and receiving an access token response including the access token(s). The access token request may include access token request parameters, which may form part of the discovery parameters sent in the first request by the first NF node <NUM>. The access token request parameters may include an encryption token such as a client credentials assertion from the first NF node <NUM>. Using such an encrypted token, the first SCP node <NUM> may be able to obtain an access token on behalf of the first NF node <NUM>. The acquired access token(s) may then be stored by the first SCP node <NUM>. The first SCP node <NUM> may also include information in the access token request not taken from the discovery parameters, for example, the scope of the requested token(s), the granularity of the requested token(s), and so on. Alternatively, the first SCP node <NUM> may retrieve stored access tokens from storage that is part of or connected to the first SCP node <NUM> if stored access tokens are available.

The first SCP node <NUM> then selects one of the NFp nodes for which a profile has been obtained, using the acquired NFp profiles and with reference to the acquired access tokens (see block <NUM>). That is, the first SCP node <NUM> may prioritise selection of a NFp node for which an access token has been obtained, or may only select a NFp node for which an access token has been obtained. In the following text, the selected NFp node may be referred to as the second NF node <NUM>, for ease of understanding.

Having selected a NFp node (the second NF node <NUM>), the first SCP node <NUM> then initiates transmission, to the second NF node <NUM>, of a request for the second NF node <NUM> to provide the first service <NUM> to the first NF node <NUM>, as illustrated by block <NUM> of <FIG>. The request sent to the second NF node <NUM> is essentially the same as the first request received by the first SCP node <NUM> from the first NF node <NUM>, but with the SCP address replaced with the address of the second NF node and with the access token acquired by the first SCP node <NUM> included in the request.

Herein, the term "initiate" can mean, for example, cause or establish. Thus, the processing circuitry <NUM> of the first SCP node <NUM> can be configured to itself transmit the information (e.g. via a communications interface <NUM> of the first SCP node <NUM>) or can be configured to cause another node to transmit the information. Similarly, where the first NF node <NUM> initiates transmission, the first NF node <NUM> may be configured to itself transmit the information (e.g. via a communications interface <NUM> of the first NF node <NUM>) or can be configured to cause another node to transmit the information.

The first SCP node <NUM> then receives a response to the request from the second NF node <NUM> (including the NF instance ID and potentially also including binding information if binding is used), and initiates transmission of this response to the first NF node <NUM> (see block <NUM>). Upon receiving this response, the first NF node <NUM> may store the information in the execution context, for example, UE/session context, as discussed in detail below.

The first SCP node <NUM> may be further configured to receive a subsequent request from the first NF node <NUM>, the subsequent request being for the second NF node <NUM> to provide the first service. As discussed in greater detail below, the subsequent request may include access token request parameters, which may be used by the first SCP node <NUM> to obtain a valid access token. Where the first SCP node has stored a valid access token, this access token may be retrieved using the access token request parameters from the subsequent request. Alternatively, where the first SCP node does not have a valid access token stored (either because no valid token was stored or because a previously valid stored token has expired), the access token request parameters may be used to request a new access token, for example, from a NRF <NUM>. When a valid access token has been obtained using the access token request parameters from the subsequent request, the first SCP node <NUM> may then initiate transmission of a request to the second NF node <NUM> for service provision; the request may be essentially the same as the subsequent request received by the first SCP node <NUM> from the first NF node <NUM>, but with the SCP address replaced with the address of the second NF node <NUM> and with the access token acquired by the first SCP node <NUM> included in the request. Upon receiving a response from the second NF node <NUM>, the first SCP node <NUM> may then initiate transmission of this response to the first NF node <NUM>.

<FIG> illustrates a first NF node <NUM> in accordance with an embodiment. The first NF node <NUM> is for handling a service request in a network. The first NF node <NUM> is configured to operate as a first NF node of a service consumer. In some embodiments, the first NF node <NUM> can be, for example, be a physical machine (e.g. a server) or a virtual machine (VM). The first NF node <NUM> can be, for example, a user equipment (UE).

As illustrated in <FIG>, the first NF node <NUM> comprises processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the first NF node <NUM> and can implement the method described herein in respect of the first NF node <NUM>. The processing circuitry <NUM> can be configured or programmed to control the first NF node <NUM> in the manner described herein. The processing circuitry <NUM> can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and/or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described herein in respect of the first NF node <NUM>. In some embodiments, the processing circuitry <NUM> can be configured to run software to perform the method described herein in respect of the first NF node <NUM>. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry <NUM> may be configured to run a container to perform the method described herein in respect of the first NF node <NUM>.

Briefly, the processing circuitry <NUM> of the first NF node <NUM> is configured to initiate transmission to a first SCP node <NUM> of a first request for provision of a first service <NUM> by a further NF node (the further NF node being a service provider NF node). The first request comprises discovery parameters including access token request parameters, wherein the discovery parameters facilitate the selection, by the first SCP node <NUM>, of a second NF node <NUM> of a service producer as the further NF node to provide the first service <NUM>. In addition to including the access token request parameters in the discovery parameters, the access token request parameters may also be sent in a separate header to the discovery parameters, for example, an access token parameter header. In addition to initiating transmission of the first request, the processing circuitry <NUM> of the first NF node <NUM> is configured to store the access token request parameters, and receive a response from the second NF node <NUM> (via the first SCP node <NUM>). The processing circuitry <NUM> of the first NF node <NUM> is also configured to initiate transmission of a second request to the first SCP node <NUM>, where the second request is a subsequent request for the second NF node <NUM> to provide the first service <NUM>. The second request comprises stored access token request parameters useable (for example, by the first SCP node <NUM>) to identify a stored access token or request an access token.

As illustrated in <FIG>, in some embodiments, the first NF node <NUM> may optionally comprise a memory <NUM>. The memory <NUM> of the first NF node <NUM> can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory <NUM> of the first NF node <NUM> may comprise a non-transitory media. Examples of the memory <NUM> of the first NF node <NUM> include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital video disk (DVD), and/or any other memory.

The processing circuitry <NUM> of the first NF node <NUM> can be connected to the memory <NUM> of the first NF node <NUM>. In some embodiments, the memory <NUM> of the first NF node <NUM> may be for storing program code or instructions which, when executed by the processing circuitry <NUM> of the first NF node <NUM>, cause the first NF node <NUM> to operate in the manner described herein in respect of the first NF node <NUM>. For example, in some embodiments, the memory <NUM> of the first NF node <NUM> may be configured to store program code or instructions that can be executed by the processing circuitry <NUM> of the first NF node <NUM> to cause the first NF node <NUM> to operate in accordance with the method described herein in respect of the first NF node <NUM>. Alternatively or in addition, the memory <NUM> of the first NF node <NUM> can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry <NUM> of the first NF node <NUM> may be configured to control the memory <NUM> of the first NF node <NUM> to store information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

In some embodiments, as illustrated in <FIG>, the first NF node <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the first NF node <NUM> can be connected to the processing circuitry <NUM> of the first NF node <NUM> and/or the memory <NUM> of first NF node <NUM>. The communications interface <NUM> of the first NF node <NUM> may be operable to allow the processing circuitry <NUM> of the first NF node <NUM> to communicate with the memory <NUM> of the first NF node <NUM> and/or vice versa. Similarly, the communications interface <NUM> of the first NF node <NUM> may be operable to allow the processing circuitry <NUM> of the first NF node <NUM> to communicate with the first SCP node <NUM> and/or any other node. The communications interface <NUM> of the first NF node <NUM> can be configured to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry <NUM> of the first NF node <NUM> may be configured to control the communications interface <NUM> of the first NF node <NUM> to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

Although the first NF node <NUM> is illustrated in <FIG> as comprising a single memory <NUM>, it will be appreciated that the first NF node <NUM> may comprise at least one memory (i.e. a single memory or a plurality of memories) <NUM> that operate in the manner described herein. Similarly, although the first NF node <NUM> is illustrated in <FIG> as comprising a single communications interface <NUM>, it will be appreciated that the first NF node <NUM> may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interface) <NUM> that operate in the manner described herein. It will also be appreciated that <FIG> only shows the components required to illustrate an embodiment of the first NF node <NUM> and, in practical implementations, the first NF node <NUM> may comprise additional or alternative components to those shown.

<FIG> is a flowchart illustrating a method performed by a first NF node <NUM> in accordance with an embodiment. The method of <FIG> is for handling a service request in the network. The first NF node <NUM> described earlier with referenced to <FIG> is configured to operate in accordance with the method of <FIG>. The method can be performed by or under the control of the processing circuitry <NUM> of the first NF node <NUM>. A first SCP node <NUM> is configured to operate as an SCP between the first NF node <NUM> and a second NF node of a service producer in the network,.

The method of <FIG> is performed for connecting to a further NF node of a service producer (such as the second NF node <NUM>) via the first SCP node <NUM>. The first request is for provision of a first service (<NUM>) by the further NF node, and transmission of this first request is initiated to the first SCP node <NUM> (see block <NUM>). The first request comprises discovery parameters, comprising access token request parameters, wherein the discovery parameters facilitate the selection, by the first SCP node <NUM>, of a second NF node <NUM> of a service producer as the further NF node to provide the first service <NUM>. The access token request parameters are stored by the first NF node <NUM> (see block <NUM>). The access token request parameters may comprise, for example, an encrypted token such as a client credentials assertion for the first NF node <NUM> (a NF Service consumer client credentials assertion) or another type of encrypted token. Using such an encrypted token, the first SCP node <NUM> may be able to obtain an access token on behalf of the first NF node <NUM>. Where the first request includes an encrypted token, this may be stored as part of the access token request parameters.

The access token request parameters may be stored in the execution context of the first request, which may be a UE/session context, a Protocol Data Unit (PDU)/session context, or another context. In particular, the access token request parameters may be stored in a UE data record. The access token request parameters may further comprise various other information, such as Single - Network Slice Selection Assistance Information (S-NSSAI), Fully Qualified Domain Names (FQDN), and so on. A discussion of various parameters which may be included in access token requests can be found in 3GPP TS <NUM> V <NUM>. <NUM>, as cited above. In particular, section <NUM>. <NUM> of the cited document provides an overview of relevant data types. A corresponding overview of discovery data types can be found in section <NUM>. <NUM> of the same cited document. Once received by the first SCP node <NUM>, the access token request parameters may be used to obtain an access token, potentially in conjunction with further parameters such as scope information that are not derived from the access token request parameters in the first request. The method further comprises receiving a response from the second NF node <NUM> (see block <NUM>), via the first SCP node <NUM>.

The method additionally comprises initiating transmission (see block <NUM>) of a second request to the first SCP node <NUM>. The second request is a subsequent request for the provision of the first service; the subsequent request is for the first service to be provided by the second NF node <NUM>. The second request includes at least a portion of the stored access token request parameters that were included in the discovery parameters sent in the first request. The access token request parameters may be sent in a specific access token parameter header in the subsequent request. Where the stored access token request parameters comprise an encrypted token (as discussed above), this encrypted token may be included in the second request. The access token request parameters in the second request may allow the first SCP node <NUM> to obtain a valid access token; the valid access token may be obtained by retrieving a stored access token, or by requesting an access token (for example, from the NRF <NUM>). Where a stored access token is retrieved, the access token parameters are used to locate by the first SCP node <NUM> the said stored access token. Where no valid stored access token is available, either because no stored access tokens are available or because the stored access tokens have expired (timed out), the access token parameters may be used to request a new access token from the NRF <NUM>, using a similar process to that which may be used to obtain an access token in respect of the first request. Using the obtained access token, the first SCP node <NUM> may then send a request to the second NF node <NUM>, receive a response which is passed to the first NF node <NUM>, and so on.

There is also provided a system. The system can comprise at least one first SCP node <NUM> as described herein and/or at least one first NF node <NUM> as described herein. The system may also comprise any one or more of the other nodes mentioned herein.

<FIG>is a signalling diagram illustrating is a signalling diagram illustrating an exchange of signals. The system illustrated in <FIG>comprises a first SCP node <NUM>, a first NF node <NUM> of a service consumer ("NFc"), a second NF node <NUM> of a service producer ("NFp1"), and a third NF node <NUM> of a service producer ("NFp2"). The first SCP node <NUM> is configured to operate as an SCP between the first NF node <NUM> and the second NF node <NUM>. The second NF node <NUM> can be configured to provide (e.g. execute or run) a service <NUM> and the third NF node <NUM> can be configured to provide (e.g. execute or run) a service <NUM>. The second NF node <NUM> and the third NF node <NUM> can be configured to provide (e.g. execute or run) the same service or a different service. The second NF node <NUM> and the third NF node <NUM> can be part of a set <NUM> of NF nodes of a service producer. The system illustrated in <FIG>also comprises a NRF <NUM>. In some embodiments, an entity may comprise the first SCP node <NUM> and the NRF <NUM>. That is, in some embodiments, the first SCP node <NUM> can be merged with the NRF <NUM> in a combined entity.

In some embodiments, the first SCP node <NUM> and the first NF node <NUM> may be deployed in independent deployment units and/or the first SCP node <NUM> and the second NF node <NUM> may be deployed in independent deployment units. Thus, an SCP node based on independent deployment units is possible, as described in 3GPP TS <NUM> v16. <NUM> (as cited above). In other embodiments, the first SCP node <NUM> may be deployed as a distributed network element. For example, in some embodiments, part (e.g. a service agent) of the first SCP node <NUM> may be deployed in the same deployment unit as the first NF node <NUM> and/or part (e.g. a service agent) of the first SCP node <NUM> may be deployed in the same deployment unit as the second NF node <NUM>. Thus, an SCP node based on service mesh is possible, as described in 3GPP TS <NUM> V16.

In some embodiments, at least one second SCP node may be configured to operate as an SCP between the first NF node <NUM> and the first SCP node <NUM> and/or at least one third SCP node may be configured to operate as an SCP between the first SCP node <NUM> and the second NF node <NUM>. Thus, a multipath of SCP nodes is possible. In some of these embodiments, the first SCP node <NUM> and one or both of the at least one second SCP node and the at least one third SCP node may be deployed in independent deployment units. In some embodiments, the at least one second SCP node and/or the at least one third SCP node may be deployed as distributed network elements.

Steps <NUM>, <NUM>, <NUM> and <NUM> and <NUM>-<NUM> of <FIG> are as described earlier with reference to <FIG>. Some key differences between the example illustrated in <FIG>and the embodiment of <FIG>are as follows. In step <NUM>, similarly to step <NUM> the first NF node <NUM> stores the context (UE/session context, PDU/session context, and so on). Step <NUM> comprises additionally storing the access token request parameters as may be used by the first SCP node <NUM> to obtain an access token. As discussed above in the context of <FIG> and <FIG>, the access token request parameters may include an encryption token which, if present, may also be stored in step <NUM>. The access token request parameters may then be sent (as part of the discovery parameters) to the first SCP node <NUM> in step <NUM>, and the process of the first request proceeds as shown in <FIG>. At step <NUM>, the process related to a subsequent request for the same service begins. The subsequent request may be a second request, third request, fourth request, and so on. In the embodiment illustrated in <FIG>, binding has been used, and therefore the client binding information provided to the first NF node <NUM> is included as routing binding information in step <NUM>; as mentioned previously the use of binding is optional and binding is not necessarily used. In step <NUM>, the subsequent service request is sent to the first SCP node <NUM>. However, as the access token request parameters were stored by the first NF node <NUM> in step <NUM>, these parameters may also be included in the subsequent request of step <NUM>. In the embodiment illustrated in <FIG>, the encryption token (client credential assertion in this example) is included as part of the access token request parameters.

The first SCP node <NUM> receives the subsequent request and, at step <NUM>, attempts to locate a valid access token. In the example illustrated in <FIG>, this attempt fails as the information included in the subsequent request at arrow <NUM> does not provide the means to identify a valid token. The first SCP node in <FIG> is also unable to request an applicable token as the information required for a token request is not provided in the subsequent request of that example. By contrast, the access token request parameters included in the subsequent request of the embodiment illustrated in <FIG> allows the stored access token to be retrieved (for example, from a memory of the first SCP node <NUM>). In this embodiment, the S-NSSAI is required and is included in the access token request parameters. The stored access token is valid in this embodiment, however even if the stored access token were to not be valid (that is, not present or expired, or a token of a different scope is required), then the access token request parameters included in the subsequent request could be used by the first SCP node <NUM> to obtain a new access token from the NRF <NUM>. In some embodiments the first SCP node <NUM> may be combined with the NRF <NUM>, and the access token request parameters may therefore be used to retrieve an access token from the NRF that is combined with the first SCP node <NUM>.

As a valid access token can be obtained in by the first SCP node <NUM>, unlike the process illustrated in <FIG>, the subsequent request process of the embodiment illustrated by <FIG> does not fail. Instead, similar steps to those that occur in the first request are performed. The SCP node <NUM> modifies the address in the request (received from the first NF node <NUM>) from the address of the first SCP node <NUM> to the address of the host of the second NF node <NUM>, as shown at block <NUM>. Optional further tasks may then be performed by the first SCP node <NUM> (such as monitoring), as shown in step <NUM>. The first SCP node <NUM> then initiates transmission of the subsequent service request towards the selected second NF node <NUM> at step <NUM>; the valid access token obtained by the first SCP node <NUM> has been added to the service request. At step <NUM> the first SCP node <NUM> receives the response comprising the result from the second NF node <NUM>, then at step <NUM> this response is sent to the first NF node <NUM> and stored in the execution context (step <NUM> and <NUM>, in this embodiment the execution context is the UE/session context). Accordingly, as a result of the inclusion of the access token request parameters in the subsequent service request, a valid access token that is either a stored token or new token may be obtained and the request process may succeed.

<FIG> is a block diagram illustrating a first SCP node <NUM> in accordance with an embodiment. The first SCP node <NUM> can handle a service request in a network. The first SCP node <NUM> can operate as an SCP between a first NF node of a service consumer and a second NF node of a service producer in the network. The first SCP node <NUM> comprises a receiving module <NUM> configured to receive the first request, from the first NF node <NUM>, requesting provision of the first service. The first SCP node <NUM> comprises an acquiring module <NUM> configured to acquire service producer NF node profiles and access tokens. The first SCP node <NUM> also comprises a selecting module <NUM> configured to select a producer NF node (such as the second NF node <NUM>) using the acquired service producer NF node profiles. The first SCP node <NUM> additionally comprises a transmission module <NUM> configured to initiate transmission to the selected producer NF node a request to provide a service, the request including the acquired access token. The receiving module is further configured to receive the response from the second NF node <NUM>. The first SCP node <NUM> may operate in the manner described herein in respect of any process performed by the first SCP node.

<FIG> is a block diagram illustrating a first NF node <NUM> of a service consumer in accordance with an embodiment. The first NF node <NUM> can handle a service request in a network, in particular, may operate as a first NF node of a service consumer. The first NF node <NUM> comprises a transmitting module <NUM> configured to initiate transmission of a first request for a first service to be provided by a further NF node, the first request being transmitted to a first SCP node <NUM>. The first request comprises discovery parameters comprising access token request parameters, wherein the discovery parameters facilitate the selection, by the first SCP node <NUM>, of a second NF node <NUM> of a service producer as the further NF node to provide the first service <NUM>. The first NF node <NUM> also comprises a storage module <NUM> configured to store the access token request parameters, wherein the access token request parameters may be stored in, for example, an execution context. The first NF node <NUM> further comprises a receiving module <NUM> configured to receive a response from the second NF node. The transmission module <NUM> is further configured to initiate transmission of a second request to the first SCP node <NUM>, the second request being a subsequent request for the second NF node <NUM> to provide the first service <NUM>, wherein the second request comprises stored access token request parameters useable to identify a stored access token or request an access token. The second request may be for the second NF node <NUM> to provide the first service <NUM> in the same execution context (for example, UE/session context or PDU/session context) as the first request. The first NF node <NUM> may operate in the manner described herein in respect of any process performed by the first NF node.

There is also provided a computer program comprising instructions which, when executed by processing circuitry (such as the processing circuitry <NUM> of the first SCP node <NUM> described earlier and/or the processing circuitry <NUM> of the first NF node <NUM> described earlier), cause the processing circuitry to perform at least part of the method described herein. There is provided a computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry (such as the processing circuitry <NUM> of the first SCP node <NUM> described earlier and/or the processing circuitry <NUM> of the first NF node <NUM> described earlier) to cause the processing circuitry to perform at least part of the method described herein. There is provided a computer program product comprising a carrier containing instructions for causing processing circuitry (such as the processing circuitry <NUM> of the first SCP node <NUM> described earlier and/or the processing circuitry <NUM> of the first NF node <NUM> described earlier) to perform at least part of the method described herein. In some embodiments, the carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, a microwave signal, or a computerreadable storage medium.

Below a summary of implementation options is provided for the skilled person for working of the claimed invention:
Handling a service request in a network, performed by a first network function, NF, node (<NUM>) of a service consumer for connecting to a further NF node of a service producer via a first Service Communication Proxy, SCP, node (<NUM>), including:.

The second request comprises stored access token request parameters useable to identify a stored access token or request an access token.

The first request may further comprise an encrypted token to enable the first SCP node (<NUM>) to obtain an access token on behalf of the first NF node (<NUM>).

The encrypted token may be stored with the access token request parameters.

The second request may comprise the encrypted token.

The encrypted token may be a NF Service consumer client credentials assertion.

The second request is for the second NF node (<NUM>) to provide the first service (<NUM>) in the same execution context as the first request.

The storage of the access token request parameters may be in a User Equipment, UE, data record.

The access token request parameters may comprise Single - Network Slice Selection Assistance Information, S-NSSAI.

Acquiring service producer NF node profiles may comprise:.

Aacquiring access tokens may comprises:
initiating transmission (<NUM>) to the NRF node of a fifth request for access tokens using the access token request parameters from the first request and receiving (<NUM>) a second response from the NRF node, or retrieving stored access tokens.

The first SCP node (<NUM>) may perform storing (<NUM>) the service producer NF node profiles and/or storing (<NUM>) the access tokens.

The first SCP node (<NUM>) and the first NF node (<NUM>) are deployed in independent deployment units and/or the first SCP node (<NUM>) and the second NF node (<NUM>) are deployed in independent deployment units.

The first SCP node (<NUM>) is deployed as a distributed network element.

Part of the first SCP node (<NUM>) is deployed in the same deployment unit as the first NF node (<NUM>) and/or part of the first SCP node (<NUM>) is deployed in the same deployment unit as the second NF node (<NUM>).

At least one second SCP node is configured to operate as an SCP between the first NF node (<NUM>) and the first SCP node (<NUM>) and/or at least one third SCP node is configured to operate as an SCP between the first SCP node (<NUM>) and the second NF node (<NUM>).

The first SCP node (<NUM>) and one or both of the at least one second SCP node and the at least one third SCP node are deployed in independent deployment units.

The at least one second SCP node and/or the at least one third SCP node are deployed as distributed network elements.

An entity comprises the first SCP node (<NUM>) and the NRF node (<NUM>).

A first NF node (<NUM>) comprising processing circuitry (<NUM>).

In some embodiments, the first SCP node functionality and/or the first NF node functionality described herein can be performed by hardware. Thus, in some embodiments, any one or more of the first SCP node <NUM> and the first NF node <NUM> described herein can be a hardware node. However, it will also be understood that optionally at least part or all of the first SCP node functionality and/or the first NF node functionality described herein can be virtualized. For example, the functions performed by any one or more of the first SCP node <NUM> and the first NF node <NUM> described herein can be implemented in software running on generic hardware that is configured to orchestrate the node functionality. Thus, in some embodiments, any one or more of the first SCP node <NUM> and the first NF node <NUM> described herein can be a virtual node. In some embodiments, at least part or all of the first SCP node functionality and/or the first NF node functionality described herein may be performed in a network enabled cloud. The first SCP node functionality and/or the first NF node functionality described herein may all be at the same location or at least some of the node functionality may be distributed.

It will be understood that at least some or all of the method steps described herein can be automated in some embodiments. That is, in some embodiments, at least some or all of the method steps described herein can be performed automatically. The method described herein can be a computer-implemented method.

Thus, in the manner described herein, there is advantageously provided an improved technique for handling service requests in a network. The first NF node <NUM> can store access token request parameters and include the stored parameters in subsequent service requests. Using the provided access token request parameters, the first SCP node <NUM> can retrieve a valid access token and proceed the subsequent service request. Accordingly system performance is improved.

Claim 1:
A method for handling a service request in a network, wherein the method is performed by a first network function, NF, node (<NUM>) of a service consumer for connecting to a further NF node of a service producer via a first Service Communication Proxy, SCP, node (<NUM>), the method comprising:
initiating transmission (<NUM>), to the first SCP node (<NUM>), of a first request for provision of a first service (<NUM>) by the further NF node, wherein the first request comprises discovery parameters and access token request parameters, wherein: the access token request parameters facilitate obtaining and storing of an access token by the first SCP node (<NUM>); and the discovery parameters facilitate the selection, by the first SCP node (<NUM>), of a second NF node (<NUM>) of a service producer as the further NF node to provide the first service (<NUM>), and forwarding the request to the second NF node (<NUM>) by the first SCP node (<NUM>);
receiving (<NUM>) a response from the second NF node (<NUM>) forwarded by the first SCP node (<NUM>); and
initiating transmission (<NUM>) of a second request to the first SCP node (<NUM>), the second request being a subsequent request for the second NF node (<NUM>) to provide the first service (<NUM>), wherein the second request comprises the access token request parameters facilitating the SCP to use the stored access token or obtain a new access token, and wherein the second request is forwarded by the first SCP node (<NUM>) to the second NF node (<NUM>) with the stored access token or a newly obtained access token, included in the second request.