Patent Description:
It is intended that 3GPP SA3 and CT4 will complete their Rel-<NUM> stage <NUM> work on eSBA (enhanced Service Based Architecture) in Q1 <NUM>. eSBA introduces, among others, the support of indirect communication between a NF Service Consumer and a NF Service Producer via one or more SCPs (Service Communication Proxy). Details on the technical realization of support of Indirect Communication are available in clause <NUM> of 3GPP TS <NUM>.

Further prior art documents are <NPL>, "<NPL>, and <CIT> showing a method, registration center and device for service discovery.

It is an object of the present invention to improve the prior art.

According to aspects of the invention, there are provided an apparatus, a method, and a computer program product according to the respective claims.

According to some embodiments of the invention, at least one of the following advantages may be achieved:.

Further details, features, objects, and advantages are apparent from the following detailed description of the preferred embodiments of the present invention which is to be taken in conjunction with the appended drawings, wherein:.

Herein below, certain embodiments of the present invention and examples useful for understanding the invention are described in detail with reference to the accompanying drawings, wherein the features of the embodiments can be freely combined with each other unless otherwise described. However, it is to be expressly understood that the description of certain embodiments is given by way of example only, and that it is by no way intended to be understood as limiting the invention to the disclosed details.

Stage <NUM> work for eSBA is contained in 3GPP TS <NUM> and 3GPP TS <NUM>. Currently proposals to register special destination addresses for notification messages within the NF and/or NF service profiles within the NRF are being discussed (see document S2-<NUM> that will be taken as basis for contributions at the next SA2 meeting in February <NUM>).

A callback request is an asynchronous request that a service sends to some other service in response to certain events. A typical example of a callback is a notification, wherein, for subscription functionality, users subscribe to certain events of a service and receive a notification when this or that event occurs.

In SBA, a consumer may subscribe to a NF service producer to receive notifications from a producer when certain events occur. The NF service producer sends the notifications (e.g. status information) regularly and/or when a particular event happens, by sending a notification request message. The receiver of the notification requests acknowledges the receipt of the request by sending back a notification response. In the context of the present application, the terms "notification", "notification request", and "notification request message" are to be considered synonymous unless otherwise stated or made clear from the context. According to 3GPP TS <NUM>, clause <NUM>. <NUM>, a default notification subscription is a subscription registered in the NF profile in the NRF corresponding to notifications the NF is prepared to consume, as opposed to a notification subscription created by an explicit subscription request sent to the NF Service Producer.

A 3gpp-Sbi-Callback header has been defined by 3GPP in TS <NUM> (Rel-<NUM>) to indicate that a request is a notification or callback request that is sent across PLMNs. This header may be used between SEPPs (Security Edge Protection Proxy) to identify the security policies that may apply to a notification or a callback request (see 3GPP TS <NUM>). This is limited to the few APIs that are used over inter-PLMN interfaces, and this only applies to the N32 interface (inter-PLMN roaming interface) and is used only by the SEPP. This is not used nor visible to SCP and not used for intra-PLMN communications.

The introduction of indirect communication results in some technical problems:.

Some example embodiments of the invention provide solutions to these technical problems. ad <NUM>) An NF may register default notification subscriptions in its NF profile or NF services in the NRF for notifications the NF is prepared to consume, including for each type of notification the corresponding notification endpoint (i.e. callback URI).

A NF producer may be configured with the types of notifications corresponding to default notification subscriptions ) it needs to generate, and send such notifications using indirect communication with delegated discovery. In delegated discovery, an SCP discovers and selects an NF service consumer with a corresponding default notification subscription. See clause <NUM>. <NUM> of 3GPP TS <NUM>.

There is no mechanism though to signal to the SCP the API version used by the NF Service Producer to generate the notification request. This prevents the SCP from being able to select an NF Service Consumer supporting the corresponding API version, i.e. to select a NF Service Consumer capable to handle the notification.

According to some example embodiments (not covered by the claimed invention), the sender of a notification request includes an indication about the API version it used to generate the notification in addition to an existing indication about the notification type in the request. The SCP uses that API version to select an NF service consumer that supports receiving notifications corresponding to the notification type and complying with this API version. For this selection, SCP may retrieve NF profiles of candidate destination NF in the NRF and compare that API version with a version (new parameter) stored for that notification type in the profiles of that NF, or it may query the NRF for NFs that support that version. The SCP may then forward the notification request to the selected NF. For that purpose, a new apiversion parameter will be defined in the header of the request. In some example embodiments (not covered by the claimed invention), the header comprises the 3gpp-Sbi-Callback header to carry the API version in notification requests. In addition, the NF profile registered in the NRF may be extended with entrie(s) indicating the supported API versions(s) for each notification type in default notification subscriptions in the profile. In some example embodiments (not covered by the claimed invention), only the major API version is indicated in the header and/or the NF profile.

ad <NUM>) The SCP should differentiate notification requests from other service requests, as both types of requests require different treatments e.g. for authorization (OAuth2 is not used for notifications while it can be used in other service requests). For instance, for indirect communication with delegated discovery, it is anticipated that SA3 specifies that the SCP may be responsible for requesting / providing an access token (i.e. an example of an authorization) on behalf of the NF service consumer. In this case the SCP needs to request an access token for service requests. However, the SCP must not request an access token for notification requests. In addition, if destination addresses for notification requests are registered in addition to normal addresses applicable for other service requests in the NF profile and/or NF service profiles within the NRF, the SCP should use the destination addresses for notification messages, if any, to determine where to send notifications, or otherwise use the normal addresses.

There is no mechanism defined though to enable an SCP to distinguish notification requests from other service requests.

According to some example embodiments (not covered by the claimed invention), the sender of an HTTP request includes an indication in the HTTP request whether the request is a callback request (such as a notification request) or a request relating to other services, when using indirect communication. The SCP receiving that request uses that indication to select the appropriate security handling for that request (e.g. by applying OAuth2 authorization for other service requests but not for notifications). In addition or alternatively, the SCP may use the indication to select the appropriate destination address in the NF profile or NF service profile that the SCP retrieves from the NRF and to send the request to that address.

For that purpose, according to some example embodiments of the invention, the use of the 3gpp-Sbi-Callback header is extended to all notification and callback requests sent with indirect communication, for all intra-PLMN and inter-PLMNs exchanges. Thus, SCP is enabled to distinguish notification/callback requests from other service requests.

In some example embodiments (not covered by the claimed invention), a NF Service Producer sending a notification or a callback request, using indirect communication, includes in the request a 3gpp-Sbi-Callback header including the name of the notification or callback request and the API version for intra and inter-PLMN communications. In some example embodiments (not covered by the claimed invention), the NF Service Producer includes the API version only if its API (major) version is higher than <NUM> (i.e., if the API (major) version is not the first version of the API).

The SCP may derive from the presence of this header that a service request is a notification or callback request and apply treatments for notification and callback requests which is different from treatment for other service requests. , with respect to authorization, access token is not used in notification / callback, (see clause <NUM>. <NUM> of TS <NUM>). As another example, if a notification destination is included in the corresponding NF profile or NF service profile, this address is used instead of a normal destination address for that service if the request is a notification request of callback request.

<FIG> shows an example of a message flow with indirect communication and delegated discovery, for a service request other than a notification or callback request, i.e. for a request that does not correspond to a "Notify" request as explained hereinabove and specified at greater detail in clause <NUM>. <NUM> of 3GPP TS <NUM>. The messages shown in <FIG> are as follows:.

If the request contains a Routing Binding indication, the SCP sends a NF Discovery request to the NRF to retrieve candidate NF service producer with the NF service type as indicated in the request URI. The NRF returns corresponding NF profiles and/or NF service profiles that will contain a normal destination address and may contain a notification destination address in addition. The SCP uses the normal destination address.

In message <NUM>, the SCP sends the request to the destination address determined in that manner and exchanges the host portion of the request URI with that destination address.

The SCP requests the OAuth2 authorization server (NRF) to generate an access token to get authorization to access the requested service at the selected NF Service Producer.

The SCP sends the service request to the selected NF Service Producer, with the access token granted by the OAuth2 authorization server.

The NF Service Producer serves the request and returns a response.

<FIG> shows an example of a message flow with indirect communication, for a notification or a callback request. The messages are as follows:.

Examples of the 3gpp-Sbi-Callback header are as follows:.

In the first example, the header informs that the request is a notification request, sent by the NRF to notify a NF status change. The API (major) version is <NUM> (first version). Therefore, in this example, the header does not comprise an explicit indication of the API version. In the second example, the header informs that the request is a notification request, sent by the UDM to notify subscription data changes. In addition, it informs that the API (major) version is <NUM>.

The SCP determines that this is a notification or a callback request, based on the receipt of this header.

If the request contains neither a Routing Binding indication nor a notification address (i.e. URI) (or a URI that is known to be not reachable) (note: a notification sent for a default notification subscription will never contain a Routing Binding indication nor a notification address of the target NF, when using indirect communication), the SCP sends a NF Discovery request to the NRF to retrieve candidate NF service consumers that support the corresponding default notification type and that support the API version used by the NF Service Producer to generate the notification. The NRF selects NF service consumers where that API version is among the API versions registered for that default notification type (in default notification subscriptions). The NF service consumer has previously registered its NF profile in the NRF and has included entries indicating the supported version(s) for each default notification type it supports.

If the request contains a Routing Binding indication (e.g. notifications issued for an explicit event subscription) and the notification address (URI) is not reachable, the SCP sends a NF Discovery request to the NRF to retrieve candidate NF service consumers with the NF service type in the Routing Binding Indication and that support the service within the Routing Binding Indication (if any is included). The NRF returns corresponding NF profiles and/or NF service profiles that will contain a normal destination address and may contain a notification destination address in addition. If the Routing Binding indication contains a service name, the SCP uses the corresponding NF service profile. If a notification destination address is contained in that service profile, the SCP uses that address and otherwise the normal destination address. If the Routing Binding indication contains an Indication to use NF profile address (for instance "NF" as service name), the SCP uses the corresponding NF profile. If a notification destination address is contained in that profile, the SCP uses that address and otherwise the normal destination address.

The SCP sends the request to the destination address determined in that manner and exchanges the host portion of the request URI with that destination address.

The SCP sends the notification request to the NF Service Consumer, without any access token (i.e., without being authorized).

The NF Service Consumer acknowledges the receipt of the notification request.

According to some example embodiments of the invention, the apparatuses (such as NF, NRF (not covered by the claimed invention), or SCP or a component thereof) and methods are defined by 3GPP specifications. Hence, it is suggested to update these specifications. A motivation for an update is as follows:.

This can also be useful information for a SEPP to apply data encryption and modification policies applicable to the API version.

Thus, according to some example embodiments, apparatuses (such as NF or NRF (not covered by the claimed invention), or SCP or a component thereof) and methods will be defined at least partly by 3GPP TS <NUM>, updated as follows:.

Furthermore, according to some example embodiments, apparatuses (such as NF or NRF (not covered by the claimed invention), or SCP or a component thereof) and methods will be defined at least partly by 3GPP TS <NUM>, updated as shown in <FIG>.

The proposed changes may be summarized as follows:.

<FIG> shows an apparatus according to an example useful for understanding the invention. The apparatus may be a NF such as a producer or an element thereof. <FIG> shows a method according to an example useful for understanding the invention. The apparatus according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

The apparatus comprises means for sending <NUM>. The means for sending <NUM> may be an sending means. The means for sending <NUM> may be a sender configured to perform said sending. The means for sending <NUM> may be an sending processor configured to cause said sending to be performed.

The means for sending <NUM> sends a notification or callback request and indicates in said request a version of a programming interface configured to provide said request. An API is an example of a programming interface.

<FIG> shows an apparatus according to an example useful for understanding the invention. The apparatus may be a NF such as a consumer or an element thereof. <FIG> shows a method according to an example useful for understanding the invention. The apparatus according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

The apparatus comprises means for receiving <NUM> and a means for requesting <NUM>. The means for receiving <NUM> and means for requesting <NUM> may be a receiving means and requesting means, respectively. The means for receiving <NUM> and means for requesting <NUM> may be a receiver configured to perform said receiving and requestor configured to perform said requesting, respectively. The means for receiving <NUM> and means for requesting <NUM> may be a receiving processor configured to cause said receiving to be performed and requesting processor configured to cause said requesting to be performed, respectively.

The means for receiving <NUM> receives, on a programming interface of an interface version, a notification or callback request of a type (S20). An API is an example of a programming interface.

The means for requesting <NUM> requests, at a database (such as a NRF), a registration of the apparatus, the type, and one or more interface versions that the programming interface supports for the notification or callback (S30). The registration of the apparatus may be a subscription to a notification (notification subscription). The notification subscription may be a default notification subscription.

S20 and S30 may be performed in an arbitrary sequence. S20 and S30 may be performed fully or partly in parallel.

<FIG> shows an apparatus according to an example useful for understanding the invention. The apparatus may be a SCP or an NRF or an element thereof. <FIG> shows a method according to an example useful for understanding the invention. The apparatus according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

The apparatus comprises means for receiving <NUM>, means for selecting <NUM>, and means for sending <NUM>. The means for receiving <NUM>, means for selecting <NUM>, and means for sending <NUM> may be a receiving means, selecting means, and sending means, respectively. The means for receiving <NUM>, means for selecting <NUM>, and means for sending <NUM> may be a receiver configured to perform said receiving, selector configured to perform said selecting, and a sender configured to perform said sending, respectively. The means for receiving <NUM>, means for selecting <NUM>, and means for sending <NUM> may be a receiving processor configured to cause said receiving to be performed, selecting processor configured to cause said selecting to be performed, and sending processor configured to cause said sending to be performed, respectively.

The means for receiving <NUM> receives a first indication of a version of a producer programming interface and a second indication of a version of a programming interface (of a same type) that a consumer can support (S110). The producer programming interface is configured to produce a notification request or a callback request. The consumer is configured to consume the notification request or the callback request, respectively. The means for receiving may receive the indications of the versions directly from the respective programming interfaces, or jointly, e.g. in a profile (such as a NF Profile stored in NRF). Each of the programming interfaces may be an API.

The means for checking <NUM> checks if the version of the producer programming interface generating the notification is compatible with the version of the programming interface (of the same type) the consumer can support (S120). For example, it may compare the version numbers received in the notification request from the NF Service Producer and registered in the NF Profile of the NF Service Consumer.

If the version of the version of the producer programming interface is not compatible with the version of the programming interface (of the same type) the consumer supports (S120 = "no"), the means for inhibiting <NUM> inhibits selecting the consumer as a target for forwarding the notification request (S130).

<FIG> shows an apparatus according to an example useful for understanding the invention. The apparatus may be a data repository (database) such as a NRF or an element thereof. <FIG> shows a method according to an example useful for understanding the invention. The apparatus according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

The apparatus comprises first means for receiving <NUM>, means for storing <NUM>, second means for receiving <NUM>, means for selecting <NUM>, and means for responding <NUM>. The first means for receiving <NUM>, means for storing <NUM>, second means for receiving <NUM>, means for selecting <NUM>, and means for responding <NUM> may be a first receiving means, storing means, second receiving means, selecting means, and responding means, respectively. The first means for receiving <NUM>, means for storing <NUM>, second means for receiving <NUM>, means for selecting <NUM>, and means for responding <NUM> may be a first receiver configured to perform said receiving, storage configured to perform said storing, second receiver configured to perform said receiving, selector configured to perform said selecting, and responder configured to perform said responding, respectively. The first means for receiving <NUM>, means for storing <NUM>, second means for receiving <NUM>, means for selecting <NUM>, and means for responding <NUM> may be a first receiving processor configured to cause said receiving to be performed, storing processor configured to cause said storing to be performed, second receiving processor configured to cause said receiving to be performed, selecting processor configured to cause said selecting to be performed, and responding processor configured to cause said responding to be performed, respectively.

The first means for receiving <NUM> receives a registration request of a candidate receiver (S150). The registration request indicates that the candidate receiver is suitable for receiving, by a programming interface, a notification or callback request of a candidate type. The registration request contains an identification of said candidate receiver, an indication of the candidate type of said request, and an indication of one or multiple candidate versions the programming interface is compatible with. A candidate receiver may register itself several times.

The means for storing <NUM> stores the identification of said candidate receiver along with said candidate type and said one or multiple candidate versions (S160).

The second means for receiving <NUM> receives a query for an identification of a receiver (S170), The query comprises an indication of a requested type of notification or callback request and an indication of a requested version of a programming interface.

The means for selecting <NUM> selects an identification among the stored identifications of the candidate receivers (S180). For the selected identification, the stored candidate type matches the requested type and one of the stored candidate versions matches the requested version.

The means for responding <NUM> responds to the query indicating the selected identification (S190) including the supported versions of the programming interface generating the notification or callback requests.

The first means for receiving <NUM> receives a registration request of a candidate receiver (S250). The registration request indicates that the candidate receiver is suitable for receiving, by a programming interface, a notification or callback request of a candidate type. The registration request contains an identification of said candidate receiver, an indication of the candidate type of said request, and an indication of one or multiple candidate versions the programming interface is compatible with.

The second means for receiving <NUM> receives a query for an identification of a receiver (S270), The query comprises an indication of a requested type of notification or callback request.

The means for selecting <NUM> selects an identification among the stored identifications of the candidate receivers (S280). For the selected identification, the stored candidate type matches the requested type.

The means for responding <NUM> responds to the query indicating the selected identification and said one or more candidate versions stored along with the selected identification (S190).

As may be seen from the above examples and embodiments, the check if the API versions of producer and consumer match may be performed in NRF (not covered by the claimed invention) or in SCP. Accordingly, the API version must be present in the NRF (not covered by the claimed invention) or in the SCP. If NFProfiles comprising the API version(s) are stored in NRF, NRF provides the API version(s) of the selected consumer to SCP if the check is made in SCP.

<FIG> shows an apparatus according to an example useful for understanding the invention. The apparatus may be a network function or an element thereof. <FIG> shows a method according to an example useful for understanding the invention. The apparatus according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

The apparatus comprises means for providing <NUM>. The means for providing <NUM> may be a providing means. The means for providing <NUM> may be a provider configured to perform said providing. The means for providing <NUM> may be a providing processor configured to cause said providing to be performed.

The means for providing <NUM> provide, via a communication proxy, a (S210). The request comprises an indication of the request being one of a callback request and a notification request if, and only if, the request is the callback request and the notification request, respectively. The communication proxy may be a SCP.

<FIG> shows an apparatus according to an example useful for understanding the invention. The apparatus may be a communication proxy such as a SCP or an element thereof. <FIG> shows a method according to an example useful for understanding the invention. The apparatus according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

The apparatus comprises means for monitoring <NUM>, means for adding <NUM>, and means for forwarding <NUM>. The means for monitoring <NUM>, means for adding <NUM>, and means for forwarding <NUM> may be a monitoring means, adding means, and forwarding means, respectively. The means for monitoring <NUM>, means for adding <NUM>, and means for forwarding <NUM> may be a monitor configured to perform said monitoring, adder configured to perform said adding, and a forwarder configured to perform said forwarding, respectively. The means for monitoring <NUM>, means for adding <NUM>, and means for forwarding <NUM> may be a monitoring processor configured to cause said monitoring to be performed, adding processor configured to cause said adding to be performed, and forwarding processor configured to cause said forwarding to be performed, respectively.

The means for monitoring <NUM> monitors if a received request comprises a notification indication (S310). The notification indication indicates that the request is one of a callback request and a notification request.

If, and only if, said request does not contain said notification indication (S310 = "no"), the means for adding <NUM> adds an access token to said request (S320).

If said request contains said notification indication (S310 = "yes"), the means for forwarding <NUM> forwards the received request (S330). If said request does not contain said notification indication (S310 = "no"), the means for forwarding <NUM> forwards the request including the access token (S335).

<FIG> shows an apparatus according to an example useful for understanding the invention. The apparatus may be a communication proxy such as a SCP or an element thereof. <FIG> and <FIG> show a method according to an example useful for understanding the invention. The apparatus according to <FIG> may perform the method of <FIG> and <FIG> but is not limited to this method. The method of <FIG> and <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

The apparatus comprises means for monitoring <NUM>, means for querying <NUM>, means for receiving <NUM>, first means for selecting <NUM>, means for checking <NUM>, second means for selecting <NUM>, third means for selecting <NUM>, and means for sending <NUM>. The means for monitoring <NUM>, means for querying <NUM>, means for receiving <NUM>, first means for selecting <NUM>, means for checking <NUM>, second means for selecting <NUM>, third means for selecting <NUM>, and means for sending <NUM> may be a monitoring means, querying means, receiving means, first selecting means, checking means, second selecting means, third selecting means, and sending means, respectively. The means for monitoring <NUM>, means for querying <NUM>, means for receiving <NUM>, first means for selecting <NUM>, means for checking <NUM>, second means for selecting <NUM>, third means for selecting <NUM>, and means for sending <NUM> may be a monitor configured to perform said monitoring, questioner configured to perform said querying, receiver configured to perform said receiving, first selector configured to perform said selecting, checker configured to perform said checking, second selector configured to perform said selecting, third selector configured to perform said selecting, and sender configured to perform said sending, respectively. The means for monitoring <NUM>, means for querying <NUM>, means for receiving <NUM>, first means for selecting <NUM>, means for checking <NUM>, second means for selecting <NUM>, third means for selecting <NUM>, and means for sending <NUM> may be a monitoring processor configured to cause said monitoring to be performed, querying processor configured to cause said querying to be performed, receiving processor configured to cause said receiving to be performed, first selecting processor configured to cause said selecting to be performed, checking processor configured to cause said checking to be performed, second selecting processor configured to cause said selecting to be performed, third selecting processor configured to cause said selecting to be performed, and sending processor configured to cause said sending to be performed, respectively.

The means for monitoring <NUM> monitors if a received request comprises a notification indication (S410). The request comprises a binding indication. The binding indication includes a network function type. The notification indication indicates that the request is one of a callback request and a notification request. <FIG> shows the method for a case that the request comprises the notification indication (S410 = "yes"). <FIG> shows the method for a case that the request does not comprise the notification indication (S410 = "no").

The means for querying <NUM> queries a database (e.g. NRF) for a network function of said network function type (S420). The means for receiving <NUM> receives a response for said query from the database (S430). The response indicates one or several candidate network functions. In addition, the response indicates, for each of the candidate network functions, respective one or several candidate service destination addresses. Optionally, the response may comprise one or several candidate notification destination addresses in addition to the one or several candidate service destination addresses.

The first means for selecting <NUM> selects a selected network function among the candidate network functions indicated in the response (S440).

The means for checking <NUM> checks if the response comprises one or several respective candidate notification destination addresses for the selected network function (S450).

If the received request comprises the notification indication (S410 = "yes") and the response comprises the one or several respective candidate notification destination addresses for the selected network function (S450 = "yes"), the second means for selecting <NUM> selects a notification destination address among the candidate notification destination addresses of the selected network function as a target address (S460).

If the received request does not comprises the notification indication (S410 = "no") or the response does not comprise the one or several respective candidate notification destination addresses for the selected network function (S450 = "no"), the third means for selecting <NUM> selects a destination address among the candidate destination addresses of the selected network function as the target address (S470).

The means for sending <NUM> sends the request towards the target address (S480).

The apparatus comprises means for monitoring <NUM>, means for service request handling <NUM>, and means for notification request handling <NUM>. The means for monitoring <NUM>, means for service request handling <NUM>, and means for notification request handling <NUM> may be a monitoring means, service request handling means, and notification request handling means, respectively. The means for monitoring <NUM>, means for service request handling <NUM>, and means for notification request handling <NUM> may be a monitor configured to perform said monitoring, service request handler configured to perform said service request handling, and a notification request handler configured to perform said notification request handling, respectively. The means for monitoring <NUM>, means for service request handling <NUM>, and means for notification request handling <NUM> may be a monitoring processor configured to cause said monitoring to be performed, service request handling processor configured to cause said service request handling to be performed, and notification request handling processor configured to cause said notification request handling to be performed, respectively.

The means for monitoring <NUM> monitors if a received request comprises a notification indication (S510). The notification indication indicates that the request is one of a callback request and a notification request.

If, and only if, said request does not contain said notification indication (S310 = "no"), the means for service request handling <NUM> handles the request as a service request (S520).

If said request contains said notification indication (S510 = "yes"), the means for notification request handling <NUM> handles the request as a callback or notification request (S530). The handling of a callback or notification request is different from the handling of a service request. Examples are given above in <FIG> and related description.

<FIG> shows an apparatus according to an example useful for understanding the invention. The apparatus comprises at least one processor <NUM>, at least one memory <NUM> including computer program code, and the at least one processor <NUM>, with the at least one memory <NUM> and the computer program code, being arranged to cause the apparatus to at least perform at least one of the methods according to <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and <FIG> and related description.

Names of network elements, network functions, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or network functions and/or protocols and/or methods may be different, as long as they provide a corresponding functionality.

If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software.

That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software.

According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example, a communication proxy such as a SCP, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).

Implementations of any of the above described blocks, apparatuses, systems, techniques or methods include, as non-limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof. Each of the entities described in the present description may be embodied in the cloud.

Claim 1:
Apparatus, comprising
means for receiving (<NUM>), from a service producer, a service request ;
means for monitoring if the service request comprises a notification indication, wherein the notification indication indicates that the service request is one of a notification request or a callback request;
means for handling the service request as a service request other than said notification request or said callback request if the service request does not comprise the notification indication;
means for handling the service request as said notification request or said callback request, respectively, if the service request comprises the notification indication, wherein
the handling of the service request as said service request other than said callback request or said notification request is different from the handling of said service request as said notification request or said callback request,
if the service request is said notification request or said callback request, the service request includes a 3gpp-Sbi_callback header including a name of the notification request or the callback request, respectively, and a programming interface version if higher than <NUM>
the apparatus further comprising:
means for selecting a receiver of said service request with a programming interface that supports handling said programming interface version; and
means for sending said service request to said receiver; wherein
the programming interface version is an application programming interface version;
the apparatus is a service communication proxy.