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 3GPP TS <NUM> v16. <NUM> (available at https://portal. org/ desktopmodules/Specifications/SpecificationDetails. aspx?specificationId=<NUM> as of <NUM> July <NUM>). 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 does not carry out the discovery or selection process. Instead, the NF node of the consumer adds any necessary discovery and selection parameters (required to find a suitable NF node of the service producer) to the service request that it sends via the SCP. The SCP uses 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.

<CIT> discloses a method for locality-based selection and routing of network traffic to producer NFs. The method comprises producer NFs registering locality information with NRFs, and consumer NFs configuring locality preference rules. "<NPL> and "<NPL> are both 3GPP standard documents disclosing SCP mediated NF producer discovery mechanisms.

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>. Where communication mode D (as shown in <FIG>) is used, all discovery and selection processes are delegated to the SCP. Accordingly, if it is necessary to perform reselection, that is, selection of an alternative NFp, this reselection is the responsibility of the SCP. In some systems, binding (in which the NFp gives parameters to the NFc that dictate which NFp or set of NFps the NFc can connect to subsequently) may be used. For systems where binding between the NFc and NFp is not used, either because a decision not to use binding is made or because one of the NFc, NFp and SCP do not support binding, it may be necessary for the SCP to store execution context (for example, UE/session context) data. This can place an unnecessary storage burden on the SCP, which may essentially function as an intermediary in communications between the NFc and NFp.

It is an object of the disclosure to obviate or eliminate at least some of the above-described disadvantages associated with existing techniques by means of a method for handling a service request in a network, wherein the method is performed by a first service communication proxy, SCP, node, a corresponding SCP node, a corresponding system and corresponding computer program and computer program product according to the independent claims. Preferred embodiments are covered by the appended dependent claims.

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 optionally also a first network function (NF) node of a service consumer. The first SCP node can be configured to operate as an SCP between the first NF node and at least one NF node of a service producer 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 of a service consumer and a second NF node 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, in response to receiving a first request from a first NF node <NUM> for a further NF node to provide (e.g. execute or run) a first service <NUM> requested by the first NF node <NUM>, select a second NF node <NUM> as the NF node to provide the first service <NUM>. The processing circuitry <NUM> of the first SCP node <NUM> is further configured to store an identifier of the second NF node <NUM>, and initiate transmission towards the second NF node <NUM> of the first request. The processing circuitry <NUM> of the first SCP node <NUM> is also configured, in response to receiving a first response from the second NF node <NUM>, to store location information of the second NF node <NUM> in association with the identifier of the second NF node <NUM>; and to initiate transmission of the first response towards 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> can 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 the first SCP node <NUM> receives a first request, for a first service to be provided by a further NF node, from the first NF node <NUM>. The first SCP node <NUM> selects an NF node, referred to herein as the second NF node, as the further node to provide the service (see block <NUM> of <FIG>). The selection may be made by the first SCP node <NUM> using discovery parameters received from the first NF node in the first request, for example. After selecting the second NF node to provide the first service, the first SCP node <NUM> stores an identifier of the second NF node (see block <NUM> of <FIG>). The identifier (ID) may be, for example, an instance ID of the second NF node, and may be obtained from a profile of second NF node. An instance ID can be an ID that identifies the instance of the second NF node.

Where the identifier of the second NF node (which may be an instance ID) is obtained from a profile of the second NF node, said profile may be received at the first SCP node <NUM> in a discovery response from a Network Repository Function, NRF node, the discovery response being sent by the NRF node in response to a discovery request from the first SCP node <NUM>. The discovery request may be sent by the first SCP node <NUM> after receiving the first request from the first NF node. Alternatively, the profile of the second NF node may be stored in the first SCP node <NUM>.

The first SCP node <NUM> then initiates transmission of the first request towards the second NF node, as illustrated by block <NUM> of <FIG>. 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 first request (e.g. via a communications interface <NUM> of the first SCP node <NUM>) or can be configured to cause another node to transmit the first request. The first SCP node <NUM> may, for example, modify the address in the first request (received from the first NF node) from the address of the first SCP node <NUM> to the address of the host of the second NF node.

In response to receiving a response from the second NF node, the first SCP node then stores location information of the second NF node (see block <NUM> of <FIG>). The location information may be obtained, for example, from a response from the second NF node. Alternatively, the location information may be obtained from another source. The location information of the second NF node may be, for example, an apiRoot of the second NF node <NUM>. The apiRoot is a Uniform Resource Indicator (URI) that identifies a particular resource (in this case, the second NF node). Where the location information is an apiRoot, this may be obtained from a location header included in the first response from the second NF node (for example, a 3GPP-Sbi-Target-apiRoot header, which is a header comprising an application programming interface (API) root of a uniform resource identifier (URI) used to reach of the second NF node).

The location information of the second NF node may be stored in association (that is linked to) the identifier of the second NF node. The location information and identifier may be stored, for example, in a mapping table. Where a mapping table is used, this mapping table may include a <NUM>-<NUM> association between the location information of NF nodes and identifiers of NF nodes, that is, each NF node identifier may be associated with a single NF node location and vice versa. Alternatively, there may be a many-<NUM> or <NUM>-many relationship between the identifiers and locations. Where a mapping table is used, this mapping table may be stored in a memory of the SCP node <NUM>, or stored in a memory contactable by the SCP node <NUM>.

The response from the second NF node is then transmitted to the first NF node. The first SCP node <NUM> initiates the transmission of this response (see block <NUM> of <FIG>). As in the case of the sending of the first request to the second NF node, the first SCP node <NUM> may simply modify the address in the response (received from the second NF node) from the address of the first SCP node <NUM> to the address of the first NF node. The processing of the first request by the first SCP node <NUM> may then end.

The first SCP node <NUM> may subsequently receive a further request from the first NF node. This further request may be referred to as a second or subsequent request. The second request may be for the second NF node to provide the first service, that is, the same service as was requested in the first request. In response to receiving the second request, the first SCP node <NUM> may initiate transmission towards the second NF node of the second request (see block <NUM> of <FIG>), wherein the second request includes the location information of the second NF node. Again, the request may be sent to the second NF node by modifying the address in the request. The first SCP node <NUM> may then await a response from the second NF node. If the response is successful (the second NF node can provide the requested service), then this response may then be sent on to the first NF node. However, if the response is unsuccessful (the second NF node cannot provide the requested service, for example, there is an error), there is a lack of response from the second NF node to the second request, or the first SCP node <NUM> is prevented from transmitting the second request towards the second NF node, then the second request cannot be fulfilled by the second NF node.

Where the second request cannot be fulfilled by the second NF node, the first SCP node <NUM> may use the location information for the second NF node to identify the associated identifier of the second NF node (see block <NUM> of <FIG>), by consulting the storage in which the location information and identifiers are associated. For example, where a mapping table is used, this mapping table may be consulted to identify the identifier of the second NF node.

Once the identifier of the second NF node has been identified, this may be used to obtain a profile of the second NF node <NUM> (see block <NUM> of <FIG>). The identifier of the second NF node may be used in a discovery process to obtain the profile of the second NF node, where the discovery process may be a new discovery, or where the discovery process comprises checking stored discovery results (which may be stored, for example, at the first SCP node <NUM>). When the profile of the second NF node has been obtained, this profile may be used to re-select a third NF node of a service producer (see block <NUM> of <FIG>) to provide the service requested in the subsequent request. The third NF node may be related to the second NF node, for example, the second and third NF nodes may both be part of a set of NF nodes. When the profile of the second NF node is an NFp profile, this may be used to identify a set of NF nodes of the service producer that comprises the second NF node, and the set of NF nodes may further comprise the third NF node of the service producer. The set of NF nodes of the service producer that comprises the second NF node may be identified using a Set identifier (ID), and the third NF node may be selected from the NF nodes specified by the Set ID. The identifier of the third NF node may then be stored by the third NF node.

When the third NF node has been reselected, the first SCP node <NUM> may initiate transmission of the second request to the third NF node, as discussed above (see block <NUM> of <FIG>). The first SCP node <NUM> may then receive a response from the third NF node. If a response received from the third NF node is an acceptance response, the first SCP node <NUM> may store the identifier of the third NF node at that point. Further, if the acceptance response from the third NF node includes location information of the third NF node, this location information may be stored in association with the identifier of the third NF node as discussed above in the context of the second NF node.

If the location information and identifier of the third NF node are stored, this may replace the identifier of the second NF node and location information of the second NF node. Alternatively, the identifier of the third NF node and location information of the third NF node may be stored in addition to the location information of the second NF node, wherein the location information of the second NF node is associated with the stored identifier of the third NF node and the identifier of the second NF node may be deleted or may simply no longer be associated with the location information of the second NF node <NUM>.

<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 first SCP node <NUM> can be configured to operate as an SCP between the first NF node <NUM> and the third NF node <NUM>.

The second NF node <NUM> can provide (e.g. be configured to execute or run) a service <NUM> and the third NF node <NUM> can provide (e.g. be configured to execute or run) a service <NUM>. The second NF node <NUM> and the third NF node <NUM> can provide (e.g. be configured to 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 an NRF node <NUM>. In some embodiments, an entity may comprise the first SCP node <NUM> and the NRF node <NUM>. That is, in some embodiments, the first SCP node <NUM> can be merged with the NRF node <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> V <NUM>. <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> V <NUM>.

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.

In <FIG>, steps <NUM>-<NUM>, <NUM>-<NUM>, <NUM> and <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. 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 block <NUM> of <FIG>, the first NF node <NUM> may store the UE/session context for the request. As illustrated by arrow <NUM> of <FIG>, the first request is sent to the first SCP node <NUM>. More specifically, the first NF node <NUM> initiates transmission of the first request towards the first SCP node <NUM>. The first SCP node <NUM> thus receives the first request.

As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> uses a discovery request to obtain NF profile(s) of one or more NF nodes of the service producer for the service that needs to be executed from the NRF node <NUM>. As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> receives a response from the NRF node <NUM>. Then, as illustrated by block <NUM> of <FIG>, the SCP node <NUM> selects one of the NFp nodes to provide the service (in this instance, the second NF node <NUM> is selected). As illustrated by blocks <NUM> and <NUM> of <FIG>, the NFp instance ID of the selected NFp node is stored, e.g. in the mapping data.

As illustrated by arrow <NUM> of <FIG>, in addition to storing the NFp instance ID, the first SCP node <NUM> modifies the first request to replace the SCP address with that of the selected host (the second NF node <NUM>). The first SCP node <NUM> may also perform additional tasks, such as monitoring, as indicated by block <NUM> of <FIG>. As illustrated by arrow <NUM> of <FIG>, the (modified) first request is then sent to the second NF node <NUM>. As illustrated by arrow <NUM> of <FIG>, a successful response is sent by the second NF node <NUM>. As illustrated by block <NUM> of <FIG>, when the successful response is received by the SCP node <NUM>, the first SCP node extracts location information of the second NF node from a header of the received response. The location information can, for example, be the 3GPP-sbi-target-apiroot, which is an API root of a URI used to reach of the second NF node <NUM> (and may be the fully qualified domain name, FQDN, or internet protocol, IP, address the NFc <NUM> can use later to fill the 3GPP-sbi-target-apiroot header). The header may also be referred to as a location header and can, for example, be a hypertext transfer protocol (HTTP) header. In the present embodiment, the location information is stored in a mapping table, e.g. so a <NUM>-<NUM> association between an NFp instance ID and sbi-target-apiroot may be created (see block <NUM> of <FIG>).

As illustrated by arrow <NUM> of <FIG>, the response from the second NF node <NUM> may then be sent back to the first NF node <NUM>. As illustrated by blocks <NUM> and <NUM> of <FIG>, the response may be stored by the first NF node <NUM>, e.g. in the execution context (in this instance, UE/session context).

In <FIG>, steps <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> relate to a subsequent service request for an existing UE/session context. At block <NUM> of <FIG>, the first NF node <NUM> identifies that the subsequent request corresponds to the same execution context (UE/session context in this embodiment). At block <NUM> of <FIG>, the first NF node <NUM> extracts the sbi-apiroot (API root of a URI) and then, at arrow <NUM> of <FIG>, the first NF node <NUM> sends a service request, also referred to as a subsequent service request. The first NF node <NUM> initiates transmission of the subsequent service request towards the first SCP node <NUM>. Thus, the first SCP node <NUM> receives the subsequent service request.

At block <NUM> of <FIG>, the first SCP node <NUM> modifies the subsequent service request to replace the SCP address with that of the selected host (the second NF node <NUM>). The first SCP node <NUM> may also perform additional tasks, such as monitoring, as indicated by block <NUM> of <FIG>. At block <NUM> of <FIG>, the (modified) subsequent service request is then sent to the second NF node <NUM>. Steps <NUM>, <NUM> and <NUM> of <FIG> are similar to steps <NUM>, <NUM> and <NUM> of <FIG> as discussed above. However, in this instance, there is no successful response from the second NF node <NUM>. Instead, at arrow <NUM> of <FIG>, a failure response (that is an error response or lack of response to the subsequent service request) occurs. The second NF node <NUM> is therefore not able to provide the service requested in the subsequent request. The second NF node <NUM> may also be prevented from providing the service if the first SCP node <NUM> is prevented from sending the subsequent request to the second NF node <NUM>, as discussed above. In the present embodiment, an error response is received.

At block <NUM> of <FIG>, in response to the lack of a successful response (the error response in this embodiment), the first SCP node <NUM> identifies that a re-selection of the NFp instance is required. In this embodiment, the first SCP node <NUM> then removes the mapping information of the second NF node <NUM> from the mapping table, at block <NUM> of <FIG>. At block <NUM> of <FIG>, the location information of the second NF node <NUM> is used in a discovery process to identify the associated identifier of the second NF node <NUM>. At block <NUM> of <FIG>, this identifier is then used to obtain a profile of the second NF node <NUM> from which a set ID (Set X ID) can be found. The discovery process may be a new discovery process involving sending a discovery request to the NRF node <NUM> (not shown), and/or may involve the first SCP node <NUM> searching stored results (also not shown).

Once the set ID has been obtained, a further NFp instance can be selected from the set, as illustrated by block <NUM> of <FIG>. In this embodiment, the set is Set X <NUM>, as shown in <FIG>. The second NF node <NUM> (NFp1) is part of Set X <NUM>, and the third NF node <NUM> is also part of Set X. As also shown in <FIG>, both of these nodes can support Service A <NUM>, <NUM>. At blocks <NUM> and <NUM> of <FIG>, the identifier of the (re-selected) third NF node <NUM> is obtained from the profile of that node and is stored, e.g. in the mapping data. As illustrated by arrow <NUM> of <FIG>, the subsequent service request is then sent to the third NF node <NUM>. As illustrated by arrow <NUM> of <FIG>, a successful response to the subsequent service request is received.

Once this successful response has been received by the first SCP node <NUM>, the mapping table can be updated to associate the identifier of the third NF node <NUM> with the location information of the third NF node <NUM> (the location information being obtained from the response), as shown at blocks <NUM> and <NUM> of <FIG>. The location information for the second NF node <NUM> may also be retained and associated with the identifier of the third NF node <NUM>; this may provide support for situations where the first NF node <NUM> may send a further subsequent request that includes the location information for the second NF node <NUM>, rather than the location information for the third NF node <NUM>. By allowing the identifier of the third NF node <NUM> to be associated with the locations of both the (old) second NF node <NUM> and (current) third NF node <NUM>, the correct response to the further subsequent request by the first SCP node <NUM> may be ensured.

As illustrated by arrow <NUM> of <FIG>, e.g. following the update of the mapping table, the response from the third NF node <NUM> may then be sent to the first NF node <NUM>. More specifically, the first SCP node <NUM> may initiate transmission of this response towards the first NF node <NUM>. The first NF node <NUM> thus receives this response. As illustrated by blocks <NUM> and <NUM> of <FIG>, the first NF node <NUM> may then store the response (or information from the response), e.g. in the execution context. Steps <NUM>, <NUM> and <NUM> of <FIG> are similar to steps <NUM>, <NUM> and <NUM> of <FIG>in the context of the first request for the service as discussed above.

<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 selection module <NUM> configured to, in response to receiving a first request for a further NF node to provide a first service <NUM> requested by a first NF node <NUM> in a first request, select a second NF node <NUM> as the further NF node. The first SCP node <NUM> further comprises a storage module <NUM> configured to store an identifier of the second NF node <NUM>. The first SCP node <NUM> further comprises a transmission module <NUM> configured to initiate transmission towards the second NF node <NUM> of the first request. The storage module <NUM> is further configured to store location information of the second NF node <NUM>. The transmission module <NUM> is further configured to initiate transmission of a first response from the second NF node <NUM> towards the first NF node <NUM>, and in response to a subsequent request to initiate transmission of the subsequent request towards the second NF node <NUM>. The first SCP node <NUM> further comprises an identification module <NUM> configured to, if the second request cannot be fulfilled by the second NF node <NUM>, identify the identifier of the second NF node <NUM> using the associated location information. The first SCP node <NUM> further comprises an obtaining module <NUM> configured to obtain a profile of the second NF node <NUM> using the identifier of the second NF node <NUM>. The selection module <NUM> is further configured to reselect a third NF node <NUM> using the profile of the second NF node <NUM>. The transmission module <NUM> is further configured to initiate transmission of the subsequent request to the third NF node <NUM>.

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), 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) 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) 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 computer-readable storage medium.

In some embodiments, the first SCP node functionality described herein can be performed by hardware. Thus, in some embodiments, the first SCP 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 described herein can be virtualized. For example, the functions performed by the first SCP 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, the first SCP node <NUM> described herein can be a virtual node. In some embodiments, at least part or all of the first SCP node functionality described herein may be performed in a network enabled cloud. The first SCP 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 SCP node <NUM> can operate in mode D without requiring UE/session context information and without requiring binding to be used, and thereby the versatility of the system is improved.

Claim 1:
A method for handling a service request in a network, wherein the method is performed by a first service communication proxy, SCP, node (<NUM>) that 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, the method comprising:
in response to receiving, from the first NF node (<NUM>), a first request for a further NF node to provide a first service (<NUM>) requested by the first NF node (<NUM>):
selecting (<NUM>) the second NF node (<NUM>) using discovery parameters received from the first NF node (<NUM>) as the further NF node to provide the first service (<NUM>);
storing (<NUM>) an identifier of the selected second NF node (<NUM>) obtained from a profile of the second NF node;
initiating (<NUM>) transmission towards the selected second NF node (<NUM>) of the first request;
receiving, from the second NF node (<NUM>), a first response to the first request;
obtaining and storing (<NUM>) location information of the selected second NF node (<NUM>) from the first response, wherein the location information of the selected second NF node (<NUM>) is stored in association with the identifier of the selected second NF node (<NUM>); and
initiating (<NUM>) transmission of the first response towards the first NF node (<NUM>).