Content for  TS 29.500  Word version:  18.4.0

The procedures specified in this clause aim at handling more efficiently requests which may arrive late at upstream entities, e.g. in networks experiencing processing or transport delays. These procedures are optional to support. When supported, the use of these procedures is dependent on operator policy.

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 TS 23.501 and clause 4.17.12 of TS 23.502. 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 TS 23.502), 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 TS 23.502);
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 TS 23.502);
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 TS 23.502);
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. 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.

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 TS 23.527). 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.

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 TS 23.501.

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 TS 23.501.

As specified in clause 4.17.12.3 of TS 23.502, 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 a PCF or an SMSF as NF Service Producer or when an AMF as NF Service Consumer sends a service request to an I-SMF or V-SMF, or when a SMF as NF Service Consumer sends a service request to a NEF as NF Service Producer, 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;
• 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 TS 23.501;
• 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, the SMSF, the PCF 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 for which the service request is received, when the other service corresponds to an AMF service, e.g. AMF event exposure service or AMF Communication 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 TS 23.501.

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 TS 29.510).
  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;
• 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 TS 23.501;
• the scope parameter indicating "subscription-events" if the binding information is applicable to subscription change event notification (see clause 4.17.12.4 of TS 23.502);
• 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.
• optionally the prefix of the Callback URI.

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).

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 TS 23.501. 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 derive the alternative notification URI (or callback URI) as described in clauses 6.5.2.2 and 6.5.3.2 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. 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 TS 29.518), 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.

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 and callback URI prefix" being replaced by the callback endpoint and callback URI prefix. 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".

The procedures defined in this clause provide means for correlating 5GC internal SBI messages (request or response) with a UE identity, by network management tools or probes that are used for network performance analysis and troubleshooting. The procedures are optional to support. When supported, the use of these procedures is dependent on operator's policy, regulatory guidelines and security considerations.

The procedures defined in this clause provide means for two PLMNs to send/receive the purpose of inter-PLMN signaling. This can be used to help operators to avoid receiving any signaling from different operator without any relevant contract. SEPP shall be preconfigured to understand the relationship with other PLMNs, e.g. roaming. The means on how to configure the relationship is outside the scope of the Release.

An NF Consumer or SCP in case of model D may include in the HTTP request the intended purpose of the request that is targeted to PLMN different from the source PLMN, using 3gpp-Sbi-Interplmn-Purpose as defined in clause 5.2.3.3.11. The purposes shall be selected from the values specified in clause 6.1.5.3.9 of TS 29.573. In addition, the any additional information may be associated for indicating the exact purpose.

When the SEPP receives request from NF consumer or SCP of the same network bound to another network (in case of cSEPP), or from the peer SEPP (in case of pSEPP), the SEPP shall evaluate the intended purpose of the signaling from the following information:

• Source PLMN;
• Target PLMN; and
• intended purpose in the received in the 3gpp-Sbi-Interplmn-Purpose header, if available

If the SEPP (i.e. cSEPP) receives request from NF consumer or SCP of the same network bound to another network including 3gpp-Sbi-Interplmn-Purpose header, the receiving SEPP shall compare the value received in the header with the preconfigued value of allowed intended purpose between the source and target PLMN. If the SEPP (i.e. pSEPP) receives from the peer SEPP including 3gpp-Sbi-Interplmn-Purpose header, the receiving SEPP shall compare the value received in the header with the pre-negotiated value of allowed intended purpose between the source and target PLMN during Security Capability Negotiation procedure specified in TS 29.573. The receiving SEPP shall:

• If the purpose in the 3gpp-Sbi-Interplmn-Purpose header matches with any one of the preconfigured purposes (for cSEPP) or pre-negotiated purposes (for pSEPP) as allowed by the receiving SEPP, then the receiving SEPP shall continue processing the request.
• Else, the receiving SEPP shall reject the message with 403 Forbidden with ProblemDetails REQUESTED_PURPOSE_NOT_ALLOWED as defined in Table 5.2.7.4-1.

EXAMPLE

1. cSEPP and pSEPP are configured with the allowed purpose =X, Y
   • Case 1:
     NFc/SCP sends the first message to cSEPP with purpose = X. In this case, cSEPP validate the message against the configured purpose and allow it. Using the N32 connection established between cSEPP and pSEPP for purpose = X , cSEPP deliver the message to pSEPP. Then only pSEPP checks the purpose=X over N32f with the pre-negotiated purpose.
   • Case 2:
     NFc/SCP sends a second message to cSEPP with the purpose=Z. Here, cSEPP rejects it on its own because it is not allowed purpose for cSEPP (configured).
2. cSEPP is configured with allowed purpose X, Y and pSEPP is configured with X, K
   • Case 3:
     NFc/SCP sends a second message to cSEPP with purpose =Y. In this case, cSEPP validates the message against the configured purpose and allow it. Then cSEPP will negotiate purpose=Y with pSEPP over N32-c and the negotiation will fail. Then cSEPP rejects the message.

If the SEPP receives request from NF consumer or SCP of the same network bound to another network (in case of cSEPP), or from the peer SEPP (in case of pSEPP) that does not include 3gpp-Sbi-Interplmn-Purpose header, the receiving SEPP shall by default consider this as roaming in order to allow backward compatibility for NF consumers not support the 3gpp-Sbi-Interplmn-Purpose header, and apply the policy accordingly. The purpose of transactions of AMFs or SMFs between two different VPLMNs, i.e. inter AMF or inter V-SMF signalling from VPLMN1 to VPLMN2 shall be considered as inter PLMN mobility.