Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 29.500  Word version:  17.5.0

Top   Top   Up   Prev   Next
1…   5…   5.2.3…   5.2.3.3…   5.2.4…   6…   6.4…   6.5…   6.6…   6.7…   6.10…   6.11…   A…

 

6.11  Detection and handling of late arriving requests |R16|Word‑p. 102

6.11.1  GeneralWord‑p. 102

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.

6.11.2  Detection and handling of requests which have timed out at the HTTP clientWord‑p. 103

6.11.2.1  GeneralWord‑p. 103

This procedure enables an HTTP server which receives a request to know when the request times out at the HTTP client, and to stop further processing, at the receiver and further upstream NFs, a request which has timed out at the HTTP client.
The HTTP client and HTTP server shall be NTP synchronized. This procedure may be used between NFs pertaining to the same PLMN, and if allowed by operator policy, between NFs pertaining to different PLMNs.

6.11.2.2  PrinciplesWord‑p. 103

An HTTP client originating a request may include in the request the 3gpp-Sbi-Sender-Timestamp and the 3gpp-Sbi-Max-Rsp-Time headers indicating respectively the absolute time at which the request is originated and the maximum time period to complete the processing of the request; both headers together indicate the absolute time at which the request times out at the HTTP client.
When forwarding a request that includes the 3gpp-Sbi-Sender-Timestamp and the 3gpp-Sbi-Max-Rsp-Time headers, the SCP or SEPP may forward these headers unmodified; if the SCP or SEPP modifies and sets the 3gpp-Sbi-Sender-Timestamp to the time when it forwards the request, it shall adjust the 3gpp-Sbi-Max-Rsp-Time accordingly such as to properly reflect the time until which the HTTP client waits for a response.
Upon receipt of a request which contains the 3gpp-Sbi-Sender-Timestamp and the 3gpp-Sbi-Max-Rsp-Time headers, the HTTP server should check that the request has not already timed out at the originating HTTP client. The HTTP server may perform additional similar checks during the processing of the request, e.g. upon receipt of a response from the next upstream NF service.
Based on local configuration, the HTTP server may reject a request that is known to have timed out with the HTTP status code "504 Gateway Timeout" and the protocol error "TIMED_OUT_REQUEST"; it may alternatively drop the request. If so, the HTTP server should initiate the release of any resource it may have successfully created towards an upstream entity, to avoid hanging resources in the network.
Up

6.12  Binding between an NF Service Consumer and an NF Service Resource |R16|Word‑p. 103

6.12.1  GeneralWord‑p. 103

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. 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 or uribase to address applicable contexts for the update of the Binding Indication, and when the oldgroupid is present, the groupid shall also be present to indicate the new group id which is newly allocated.
Up

6.12.2  Binding created as part of a service responseWord‑p. 106

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 (nfservset), 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.
Up

6.12.3  Binding created as part of a service requestWord‑p. 106

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 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;
  • at least one of the NF Service Instance (nfservinst), NF Service Set (nfservset), 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 or the (Home) SMF 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
  • 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 TS 23.501.
Up

6.12.4  Binding for explicit or implicit subscription requestsWord‑p. 107

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 (nfservset), 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.
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. 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 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.
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.
Up

6.12.5  Binding for service requests creating a callback resourceWord‑p. 109

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".
Up

6.13  SBI messages correlation for network troubleshooting |R17|Word‑p. 109

6.13.1  GeneralWord‑p. 109

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.

6.13.2  SBI messages correlation using UE identifierWord‑p. 109

6.13.2.1  GeneralWord‑p. 109

The procedure enables network analytics tools or probes, to easily identify messages that were exchanged for a given UE. When supported and configured to be used by operator's policy, an NF service consumer or NF service producer may include the UE identity in 3gpp-Sbi-Correlation-Info header, to identify the UE related to the HTTP request or response, as further defined in clause 6.13.2.2.
When included in an HTTP request or response, the 3gpp-Sbi-Correlation-Info header should contain at least one UE identifier, and no more than one of each type of UE identifier (ctype).
The NF should comply with 5GC SBI interface specific and security requirements while selecting a UE identifier to be included in the 3gpp-Sbi-Correlation-Info header. Additionally, based on operator's policy and regulatory requirements some UE identifiers may be not be allowed in the 3gpp-Sbi-Correlation-Info header for certain HTTP request or response messages.
Up

6.13.2.2  PrinciplesWord‑p. 109

An HTTP client originating a request may include in the request the 3gpp-Sbi-Correlation-Info header containing the UE identity that is related to the request. The HTTP client should include the SUPI in the 3gpp-Sbi-Correlation-Info header when it is available. If the SUPI is not available, the header should contain a UE identity that is known to the NF and is the most appropriate for the message context.
Upon receipt of a request that includes the 3gpp-Sbi-Correlation-Info header, the HTTP server, if it supports this header, may include the header in the response sent to the HTTP client, with the same UE identity that was contained in the 3gpp-Sbi-Correlation-Info header of the received HTTP request. If the HTTP request creates a subscription to notifications and the HTTP server supports this header, it should store the UE identifier received in the header and should include the header containing the stored UE identifier in subsequent callback notification requests.
The HTTP server may include the 3gpp-Sbi-Correlation-Info header in a successful response even when the header is not included in the request received from the HTTP client.
In an HTTP error response, the HTTP server may include the same UE identifier that was received in the 3gpp-Sbi-Correlation-Info header of the HTTP request or should not include the 3gpp-Sbi-Correlation-Info header if the header was not included in the HTTP request.
When forwarding a request or response that includes the 3gpp-Sbi-Correlation-Info header, the SCP should forward this header unmodified. For NF Discovery and (re)selection in indirect communication with or without Delegated Discovery, if the service request is received including the 3gpp-Sbi-Correlation-Info header, the SCP should include this header unmodified when it initiates a NF Discovery Request to the NRF. In indirect communication with or without Delegated Discovery, if the SCP reselects an alternative NF, the SCP should also include this header unmodified when it sends the HTTP request to the alternative NF service instance. In an inter-PLMN scenario, the SEPP may remove the header based on operator policies and regulatory requirements.
Up

6.13.3  SBI messages correlation using NF Peer InformationWord‑p. 110

6.13.3.1  GeneralWord‑p. 110

The procedure enables network analytics tools or probes, to easily identify messages that were exchanged between a specified pair of NF (Service) instances. When supported and configured to be used by operator's policy, an NF as HTTP client or NF as HTTP server may include the NF (Service) instance IDs in 3gpp-Sbi-NF-Peer-Info header, to identify the HTTP requests or responses between the given pair of NF (Service) instances, as further defined in clause 6.13.3.2.
Up

6.13.3.2  PrinciplesWord‑p. 110

An HTTP client originating a request may include in the request the 3gpp-Sbi-NF-Peer-Info header containing the Source NF (Service) instance ID and if available the Destination NF (Service) instance ID.
Upon receipt of a request that includes the 3gpp-Sbi-NF-Peer-Info, the HTTP server, if it supports this header, should insert the header in the response sent to the HTTP client, with source and destination peer info corresponding to the destination and source peer info in the request respectively (i.e. swap the received source and destination peer info in the response). The HTTP server may include the 3gpp-Sbi-NF-Peer-Info header in a response even when the header is not included in the request received from the HTTP client.
When forwarding a request or response that includes the 3gpp-Sbi-NF-Peer-Info header, the SCP should forward this header and may update the destination peer info if the receiver NF is (re)selected. In an inter-PLMN scenario, the SEPP may remove the header based on operator policies. If an SCP or SEPP generates an error response to a request including this header, the SCP and SEPP, if it supports this header, should insert the header in the response with source and/or destination peer info corresponding to the destination and/or source peer info in the request respectively.
Up

Up   Top   ToC