6.12 Binding between an NF Service Consumer and an NF Service Resource

29.5003GPP5G SystemRelease 17Stage 3Technical Realization of Service Based ArchitectureTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.12.1 General

A Binding Indication for an NF Service Resource may be provided to an NF Service Consumer of the resource as part of the Direct or Indirect Communication procedures, to be used in subsequent related service requests. This allows the NF Service Resource owner to indicate that the NF Service Consumer, for a particular resource, should be bound to an NF service instance, NF instance, NF service set or NF set. See clause 6.3.1.0 of 3GPP TS 23.501 [3] and clause 4.17.12 of 3GPP TS 23.502 [4].

A binding may be established or updated as part of a:

1) service response creating or modifying a resource, to be used for subsequent requests targeting this resource (see clause 4.17.12.2 of 3GPP TS 23.502 [4]), for any API that defines resources;

2) service request, if the NF Service Consumer can also act as an NF Service Producer for later communication from the contacted NF Service Producer, to be used for subsequent service requests initiated by the contacted NF Service Producer (see clause 4.17.12.3 of 3GPP TS 23.502 [4]);

3) service request creating or modifying an explicit or an implicit subscription, or as part of a notification response, to be used for subsequent notification requests initiated by the NF Service Producer (see clause 4.17.12.3 of 3GPP TS 23.502 [4]);

4) service response creating an implicit or explicit subscription or updating a subscription, or as part of a notification request, to be used for subsequent operations on the subscription (see clause 4.17.12.4 of 3GPP TS 23.502 [4]);

5) service request creating a callback (other than notification) resource (e.g. V-SMF or I-SMF callback URI sent to the H-SMF or SMF), or as part of a callback response, to be used for subsequent callback requests initiated by the NF Service Producer (e.g. H-SMF or SMF initiated PDU session modification);

6) callback request sent from a NF Service Producer to update the binding for the resource context, to be used by the NF Service Consumer for subsequent service requests addressing the resource context.

Two types of binding information are defined to manage the binding between an NF Service Consumer and an NF Service Resource:

1) A Binding Indication conveys binding information for a resource which must be stored by the consumer (client) of that resource and used by the client to direct future requests to the resource. When contained in a service request, the binding information is associated with a resource owned by the NF Service Consumer for the current transaction. When contained in a service response, the binding information is associated with a resource owned by the NF Service Producer for the current transaction.

2) A Routing Binding Indication conveys binding information to direct a request from a client to a server which has the context. A Routing Binding Indication shall only be contained in an HTTP request.

A same service request may convey more than one Binding Indication, e.g.:

– to provide bindings for notification or callback (i.e. bullets 3 or 5) and for other services that the NF service consumer can provide later as a NF Service Producer (i.e. bullet 2); or

– to provide binding information for different event notifications, when creating a subscription on behalf of another NF (see clause 6.12.4).

The scope parameter in a Binding Indication in a service request (or notification or callback response) identifies the applicability of (i.e. scenario associated with) the binding information.

A service request may convey one or more Binding Indications as described above using a 3gpp-Sbi-Binding header and/or include a Binding Routing Indication to influence routing of the request e.g. to an appropriate set of NF Service Producers or to an appropriate service set of the NF Service Producer using a 3gpp-Sbi-Routing-Binding header. A service response may convey a Binding Indication for a resource using a 3gpp-Sbi-Binding header.

NOTE 1: An HTTP request can contain for instance one 3gpp-Sbi-Binding header containing two Binding Indications for other services and for callbacks, and one 3gpp-Sbi-Routing-Binding header conveying a Routing Binding Indication.

Once a binding indication has been received for a particular resource or scope, the absence of a binding indication for the same resource or scope in a subsequent request/response message shall be interpreted as meaning that the earlier received binding indication for that resource or scope has not changed, unless specified otherwise in the rest of the specification (see scenarios with NF service producer or consumer change further down, and clause 6.12.4 for inter-AMF mobility scenarios).

In scenarios with NF service producer change (e.g. V-SMF or I-SMF change), the NF service consumer (e.g. AMF) shall delete any earlier binding indication received from the old NF service producer (e.g. old V-SMF/I-SMF) for the producer’s resource (e.g. SM context resource) and replace it by any new binding indication possibly received from the new NF service producer (e.g. new V-SMF/I-SMF).

In scenarios with NF service consumer change (e.g. inter-AMF mobility), the NF service producer (e.g. SMF) shall delete any earlier binding indication received from the old NF service consumer (e.g. binding indication for callback request received from the old AMF) and replace it by any new binding indication possibly received from the new NF service consumer (e.g. new AMF).

If an SCP receives a Routing Binding Indication within a service or notification request and decides to forward that request to a next-hop SCP, it shall include the Routing Binding Indication in the forwarded request. The SCP shall remove the Routing Binding Indication if it forwards the request to the target NF.

Binding Indications and Routing Binding Indications shall include the Binding level and one or more Binding entity IDs representing all NF service instances that are capable to serve service requests targeting the resource, i.e. that share the same resource contexts.

The Binding Level indicates a preferred binding to either a NF Instance, a NF set, a NF Service Instance or a NF Service Set.

When sending a request targeting the resource context in a NF Service Producer or the session context in a NF Service Consumer, the resource URI received in the Location header or the Notification/Callback URI shall be used first if available to set the "3gpp-Sbi-Target-apiRoot" header or target URI; as an exception, if the binding indication earlier received for the target resource context or session context indicates a binding level of "NF service set", "NF Instance" or "NF Set" and alternative NF service instances within the preferred binding entity corresponding to the binding level are available, the request may alternatively be sent to one of these alternative NF service instances. When the URI received in the Location header or the Notification/Callback URI is not reachable or when becoming aware of a NF Service Producer or Consumer change as specified in bullet 3 of clauses 6.5.3.2 and 6.5.3.3, the binding entity corresponding to the binding level shall be selected whenever possible. If this is not possible, e.g. because the preferred binding entity is not reachable, the request should be sent to any other Binding entity signalled in the Binding Indication or Routing Binding Indication, in the following decreasing order of priority:

– select an NF service instance if available in the backup NF instance, if a backup NF service instance and/or backup NF instance was signalled in the Binding Indication or Routing Binding Indication;

– select an NF service instance in the same NF service set, if a NF service Set ID was signalled in the Binding Indication or Routing Binding Indication;

– select an equivalent NF service instance in the same NF instance, if an NF instance ID was signalled in the Binding Indication or Routing Binding Indication;

– select an NF service instance in an equivalent NF service set of the backup AMF instance, if a NF service Set ID and backup AMF Instance ID was signalled in the Binding Indication or Routing Binding Indication;

– select an equivalent NF service instance in the backup AMF instance, if backup AMF Instance ID was signalled in the Binding Indication or Routing Binding Indication;

– select an NF service instance in an equivalent NF service set of another NF instance of the NF set, if an NF Service Set ID and an NF Set ID were signalled in the Binding Indication or Routing Binding Indication;

– select an equivalent NF service instance in another NF instance of the NF Set, if an NF Set ID was signalled in the Binding Indication or Routing Binding Indication.

NOTE 2: NF service instances from different NF instances are equivalent NF service instances if they share the same MCC, MNC, NID (for SNPN), ServiceName, API version, and, if applicable, NF Service Set ID (see clause 28.13 of 3GPP TS 23.003 [15]).

Binding Indications shall not be used if a particular resource can only be served by a specific NF service instance of an NF instance, i.e. if NF service instances of a same NF service are not capable to share resource inside the NF Instance, unless the receiver of the Binding Indication has indicated its support of the no-redundancy indication in the Binding Indication in the SupportFeatures attribute for a specific API (see clause 5.2.3.2.6). A resource for which no Binding Indication or Routing Binding Indication is signalled shall be considered to be bound exclusively to one NF service instance, unless the NF Service resource owner instance is part of an NF set (or AMF set) or an NF service set, or unless its NF profile in the NRF indicates that its supports NF service persistence within the NF instance (see clause 6.5 of 3GPP TS 23.527 [38]).

An NF service producer supporting different sets of NF service instances, e.g. serving different network slices, shall include the NF Service Set ID in the Binding Indication to enable the reselection (when required) of an alternative NF service instance from the same or an equivalent NF service set. See also clause 6.10.3.2 for requirements on the inclusion of "3gpp-Sbi-Discovery-*" headers in service requests targeting an existing resource context in the NF service producer.

A Binding Indication may be shared by multiple resource/session contexts, i.e. these resource contexts (in the NF Service Producer) or session contexts (in the NF Service Consumer) are sharing the same resilience information. The Binding Indication for multiple contexts has the same semantics as the one for a single resource/session context but with the following additions. When it is supported as indicated in the Supported Features for a specific service API:

– both NF Service Consumer and NF Service Producer can indicate if the Binding Indication for multiple contexts; and if the Binding Indication is for multiple contexts, the "group" parameter in the Binding Indication shall be set to "true";

– a group id may be included in the Binding Indication to indicate the group to which resource/session contexts pertain are sharing the same Binding Indication, when the resource/session context is created;

– the Binding Indication for a group of contexts may be updated towards each Resource URI with different apiRoot part (representing different peer NF (service) instances) or towards each Notification URI with different authority part, or with the same authority part but different callback-uri-prefix (see clause 5.2.3.3.7) if it is provided in 3gpp-Sbi-Consumer-Info header when the NF service consumer provides the Callback URI, e.g. when the NF is changed, by including an oldgroupid, oldnfinst, oldservset, oldservinst or uribase to address applicable contexts for the update of the Binding Indication. When the oldgroupid is present, the groupid shall also be present to indicate the new group id which is newly allocated. Additionally, the Binding Indication may be updated for a group of UE contexts by including the gumai to address applicable UE contexts for the update of the Binding Indication.

6.12.2 Binding created as part of a service response

An NF Service Producer may provide a Binding Indication in a service response by including a 3gpp-Sbi-Binding header (see clause 5.2.3.2.5) in the HTTP response with:

– the binding level (bl) parameter indicating a preferred binding to either a NF Service Instance, a NF Service Set, a NF Instance or a NF set;

– at least one of the NF Service Instance (nfservinst), NF Service Set (nfserviceset), NF instance (nfinst) and NF Set (nfset) parameters, set to a NF Service Instance ID, NF Service Set ID, NF Instance ID and NF Set ID respectively, as described in Table 6.3.1.0-1 of 3GPP TS 23.501 [3].

The NF Service Consumer shall store the Binding Indication received from the NF Service Producer and include it in a 3gpp-Sbi-Routing-Binding header in subsequent related service requests targeting the NF Service Resource. The NF Service Consumer or the SCP shall use this information for selecting or reselecting an NF Service Producer which has access to the NF Service Resource context, for direct or indirect communication respectively, as specified in clause 6.3.1.0 of 3GPP TS 23.501 [3].

NOTE: The Binding Indication can be part of an HTTP response with or without payload body, e.g. in a 204 No Content. The Routing Binding Indication can be part of an HTTP request with or without payload body, e.g. in a DELETE request.

6.12.3 Binding created as part of a service request

As specified in clause 4.17.12.3 of 3GPP TS 23.502 [4], when an AMF, V-SMF or I-SMF as NF Service Consumer sends a service request to an SMF as NF Service Producer, or when an AMF as NF Service Consumer sends a service request to an I-SMF or V-SMF, the NF Service Consumer may provide a Binding Indication in a service request by including a 3gpp-Sbi- Binding header (see clause 5.2.3.2.6) in an HTTP request with:

– the binding level (bl) parameter indicating a preferred binding to either a NF Service Instance, a NF Service Set, a NF Instance or a NF set;

– the scope parameter indicating "other-service";

– optionally the service name parameter indicating the service(s) for which the binding information applies. If no service name is indicated in the Binding Indication, the binding information applies to any service that the NF Service Consumer can provide as an NF Service Producer.

When receiving a service request from an NF Service Consumer with a Binding Indication with the scope set to "other-service", the V-SMF, the I-SMF, the (Home) SMF or the NEF acting as the NF Service Producer shall use this binding information when sending later on service requests for the "other-service" for existing or new resource context(s) in the original NF service consumer that are related to:

– the PDU session for which the service request is received, when the other service corresponds to an SMF service, e.g. SMF event exposure service or SMF NIDD service; or

– the UE owning the PDU session for which the service request is received, when the other service corresponds to an AMF service, e.g. AMF event exposure service.

The NF Service Producer shall store the Binding Indication received from the NF Service Consumer and include it in a 3gpp-Sbi-Routing-Binding header in subsequent service requests it sends, where the NF Service Consumer acts as an NF Service Producer. The NF Service Producer (when acting as a NF service consumer) or the SCP shall use this information for selecting or reselecting an NF Service Producer which has access to the original consumer’s NF Service Resource context, for direct or indirect communication respectively, as specified in clause 6.3.1.0 of 3GPP TS 23.501 [3].

6.12.4 Binding for explicit or implicit subscription requests

A NF Service Consumer may provide a Binding Indication:

– in a service request creating an explicit or an implicit subscription, or in a notification response, by including a 3gpp-Sbi-Binding header (see clause 5.2.3.2.6) in an HTTP request or response respectively; or

– for a default notification subscription in its NF profile in NRF (see clause 6.1.6.2.4 of 3GPP TS 29.510 [8]).

The Binding Indication shall contain:

– the binding level (bl) parameter indicating a preferred binding to either a NF Service Instance, a NF Service Set, a NF Instance or a NF set;

– the scope parameter indicating "subscription-events" if the binding information is applicable to subscription change event notification (see clause 4.17.12.4 of 3GPP TS 23.502 [4]);

– optionally, the scope parameter indicating "callback" if the binding information is applicable to notification and callback requests; the absence of this parameter shall also be interpreted as binding information is applicable to callback (i.e. notification) requests;

– optionally the service name parameter indicating the service that will handle the notification.

When binding information is applicable to notification/callback requests, corresponding notifications are bound to:

– the NF instance or NF set (according to the binding level), if no service name was received;

– the specific service (indicated by the service name parameter) of the NF instance or NF set (according to the binding level), if a service name was received; or

– the NF service instance or NF service set (according to the binding level).

NOTE 1: The NF Service Consumer in a NF Instance or NF Set can be identified by the NF Instance Id or NF Set Id, with or without a service name parameter, or a NF Service Instance Id (together with the NF Instance Id or the NF Service Set Id) or a NF Service Set Id, where the service can be either a standardised service or a custom service.

NOTE 2: A notification can be sent to a service instance of any binding entity included in the Binding Indication, i.e. the binding entity may be other than the one(s) indicated by the binding level, if the latter(s) are not reachable. For instance, if the Binding Indication contains an NF Set ID, an NF Instance ID and a binding level is set to NF Instance, the notification can be sent to any NF instance of the NF set if the NF instance identified by the NF Instance ID is not reachable. See clause 6.3.1.0 of 3GPP TS 23.501 [3].

The NF Service Producer shall store the Binding Indication received from the NF Service Consumer and include it in a 3gpp-Sbi-Routing-Binding header in subsequent notification requests it sends to the NF Service Consumer (that acts as an HTTP server) related to this subscription. See also clause 6.10.3.2 for requirements on the inclusion of "3gpp-Sbi-Discovery-*" headers in notification requests. For a default notification subscription, the NF Service Producer shall fetch the Binding Indication value (if available) from the NF profile of the NF Service Consumer and include it in a 3gpp-Sbi-Routing-Binding header in related notification requests. For notifications corresponding to default notification subscriptions using Indirect Communication with Delegated Discovery (see clause 6.10.3.3), when the notification is targeting a specific NF instance/NF service instance, the SCP shall fetch the Binding Indication value (if available) for the default notification subscription from the NF profile of the NF Service Consumer. The NF Service Producer or the SCP shall use this information for selecting or reselecting an NF Service Consumer (HTTP server) which has access to the original consumer’s NF Service Resource context, for direct or indirect communication respectively, as specified in clause 6.3.1.0 of 3GPP TS 23.501 [3]. If the notification endpoint provided in the subscription is not reachable, the NF Service Producer or SCP shall look up for an alternative notification endpoint address at the service level (i.e. NF Service registered in NRF) if the Binding Indication contains a service name or a binding to an NF Service Instance or NF Service Set, or at the NF instance level (i.e. NF Profile registered in NRF) otherwise. The NF Service Producer or SCP shall exchange the authority part of the notification URI (or callback URI) with the new notification endpoint address and shall use that URI in subsequent notifications.

The NF Service Consumer may provide an updated Binding Indication to the NF Service Producer in a service request modifying the subscription or in a notification response.

The NF Service Producer may also provide a Binding Indication in a service response creating or modifying an explicit or an implicit subscription, or in a notification request generated for this subscription, by including a 3gpp-Sbi-Binding header (see clause 5.2.3.2.5) in the HTTP response, or in the HTTP request respectively (without the scope parameter), as specified in clause 6.12.2. If the service request creates a resource and a subscription, the Binding Indication returned in the HTTP response shall apply to both the NF Service Resource and the subscription, i.e. the created resource and subscription shall be bound to the same (service) set of producers or producer instance. The NF Service Consumer shall store the Binding Indication received from the NF Service Producer and include it in a 3gpp-Sbi-Routing-Binding header in subsequent related service requests as specified in clause 6.12.2.

For a default notification subscription, a NF Service Consumer shall update the Binding Indication value in NF profile when binding information of the default notification subscription has changed.

A subscription request may also contain a Routing Binding Indication that can be used in case of indirect communication by the SCP to route the message to the NF Service Producer.

A service request may create an explicit subscription on behalf of another NF (e.g. UDM subscribing to an AMF event on behalf of the NEF); typically, this may happen when a "source" NF (e.g. NEF) issues a service request to an "intermediate" NF (e.g. UDM) who sends a subsequence service request to a "target" NF (e.g. AMF). The "intermediate" NF may include two Binding Indications: a first Binding Indication for subscription change event notification sent from the "target" NF to the "intermediate" NF (e.g. notifications to UDM upon AMF change) and a second Binding Indication for the event notifications sent from the "target" NF to the "source" NF (e.g. AMF notification to the NEF).

In the former Binding Indication, the scope parameter shall be set to "subscription-events"; in the latter Binding Indication (corresponding to the event notifications to the "target" NF to the "source" NF), the scope parameter shall be set to "callback" or be absent, and the other binding parameters ("bl", "nfset", etc.) shall be taken from the original service request from the "source" to the "intermediate" NF (e.g. binding parameters in the service request from NEF to UDM).

The "source" NF (e.g. NEF) or "intermediate" NF (e.g. UDM) may also include an "nr" (notification receiver) parameter in its Binding Indication conveying the notification URI used by the "target" NF (e.g. AMF) in subsequent event notifications. This "nr" parameter allows the "target" NF to match binding information with different types of notification events in scenarios in which the "intermediate" NF combines multiple subscriptions to the "target" NF, in a single subscription request.

Upon receipt of a subscription change event notification, the "intermediate" NF may include in the notification response an (updated) Binding Indication for subscription change event notification with the scope parameter set to "subscription-events".

Upon receipt of an event notification from the "target" NF, the "source" NF may include in the notification response an (updated) Binding Indication for event notifications sent from the "target" NF to the "source" NF with the scope parameter set to "callback" or absent.

NOTE 3: Binding indications for subscription change event notification and for event notifications sent from the "target" NF to the "source" NF are transferred by the source AMF to the target AMF during inter-AMF mobility procedures, if the source AMF supports the binding procedures. Accordingly, the "intermediate" NF only needs to include a Binding Indication for subscription change event notification in the notification response if the Binding Indication is updated.

NOTE 4: Upon receipt of a subscription change event notification, the "intermediate NF" needs not include a Binding Indication for event notifications sent from the "target" NF to the "source" NF. Doing so could conflict with binding updates sent by the "source" NF to the "target" NF, if the "intermediate" NF has not been updated (yet) by the "source" NF with the binding updates.

During an inter-AMF UE mobility, if the target AMF notifies an NF service consumer of an AMF event subscription that the subscription Id has changed (see clause 5.3.2.4.1 of 3GPP TS 29.518 [31]), the NF service consumer shall delete any earlier binding indication received from the source AMF for the AMF event subscription resource and replace it by any new binding indication possibly received from the target NF in the notification request.

6.12.5 Binding for service requests creating a callback resource

A NF Service Consumer may provide a Binding Indication in a service request creating a callback (other than notification) resource (e.g. V-SMF or I-SMF callback URI sent to the H-SMF or SMF), by including a 3gpp-Sbi-Binding header (see clause 5.2.3.2.6) in an HTTP request as specified in clause 6.12.4, with the scope parameter being absent or indicating "callback".

The NF Service Producer shall behave as specified in clause 6.12.4, with the "notification endpoint" being replaced by the callback endpoint.

The NF Service Consumer may provide an updated Binding Indication as part of a callback response, to be used for subsequent callback requests initiated by the NF Service Producer, by including a 3gpp-Sbi-Binding header (see clause 5.2.3.2.6) in an HTTP response as specified in clause 6.12.4, with the scope parameter being absent or indicating "callback".