Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 29.500  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   5…   5.2.3.2…   5.2.3.3…   5.2.4…   6…   6.3…   6.4…   6.5…   6.6…   6.7…   6.10…   6.10.3…   6.10.6…   6.10.11…   6.10.12…   6.11…   A   B   C   D…

 

5.2.3.2  Mandatory to support custom headersp. 19

5.2.3.2.1  Generalp. 19
The 3GPP NF Services shall support the HTTP custom headers specified in Table 5.2.3.2.1-1 below. A description of each custom header and the normative requirements on when to include them are also provided in Table 5.2.3.2.1-1.
Name Reference Description
3gpp-Sbi-Message-PriorityClause 5.2.3.2.2 This header is used to specify the HTTP/2 message priority for 3GPP service based interfaces. This header shall be included in HTTP/2 messages when a priority for the message needs to be conveyed (e.g. HTTP/2 messages related to Multimedia Priority Sessions).
3gpp-Sbi-CallbackClause 5.2.3.2.3 This header is used to indicate if a HTTP/2 message is a callback (e.g. notification).
This header shall be included in HTTP POST messages for callbacks towards NF service consumer(s) in another PLMN via the SEPP (See TS 29.573).
This header shall also be included in HTTP POST messages for callbacks in indirect communication (See clause 6.10.7).
This header should also be included in the HTTP POST message of any event notification request for direct communications.
If the header is included in received HTTP request, the SEPP or SCP shall include this header in the HTTP request forwarded to next hop. (NOTE 1)
3gpp-Sbi-Target-apiRootClause 5.2.3.2.4 This header is used by an HTTP client to indicate the apiRoot of the target URI when communicating indirectly with the HTTP server via an SCP. This header is also used by SCP to indicate the apiRoot of the target URI, if a new HTTP server is selected or reselected and there is no Location header included in the response.
This header may also be used by an HTTP client towards its local SEPP to indicate the apiRoot of the target URI towards HTTP server in another PLMN.
This header may also be used between SEPPs to indicate the apiRoot of the target URI towards HTTP server in another PLMN, when TLS security with the 3gpp-Sbi-Target-apiRoot header is used between the SEPPs.
3gpp-Sbi-Scp-apiRootClause 5.2.3.2.23 This header is used by an SCP in a source PLMN to indicate the apiRoot of an SCP in a target PLMN when using indirect communication with or without delegated discovery between different PLMNs with possible NF selection at target PLMN (see clause 6.10.12).
3gpp-Sbi-Routing-BindingClause 5.2.3.2.5 This header is used in a service request to signal binding information to direct the service request to an HTTP server which has the targeted NF Service Resource context (see clause 6.12).
3gpp-Sbi-BindingClause 5.2.3.2.6 This header is used to signal binding information related to an NF Service Resource to a future consumer (HTTP client) of that resource (see clause 6.12).
3gpp-Sbi-Discovery-*Clause 5.2.3.2.7 Headers beginning with the prefix 3gpp-Sbi-Discovery- are used in indirect communication mode to allow the discovery and selection of a suitable NF service producer (e.g. in case of service requests) or NF service consumer (e.g. in case of notifications or callbacks) by the SCP, as specified in clause 5.2.3.2.7, clause 6.5.3 and clause 6.10. Such headers may be included in any SBI message and include information allowing an SCP to find a suitable NF service producer or NF service consumer, as per the discovery and selection parameters provided respectively by the NF service consumer or the NF service producer.
3gpp-Sbi-Producer-IdClause 5.2.3.2.8 This header is used in a service response from the SCP to the NF Service Consumer, when using indirect communication, to identify the NF service producer. See clause 6.10.3.4.
This header may also be used in a resource creation response from the NF Service Producer to the NF consumer (or SCP), when the resource is created in a different NF Service Producer (e.g. UE Context Create with AMF relocation during inter-PLMN N2 handover procedure).
3gpp-Sbi-OciClause 5.2.3.2.9 This header may be used by an overloaded NF Service Producer in a service response, or in a notification request to signal Overload Control Information (OCI) to the NF Service Consumer.
This header may also be used by an overloaded NF Service Consumer in a notification response or in a service request to signal Overload Control Information (OCI) to the NF Service Producer.
3gpp-Sbi-LciClause 5.2.3.2.10 This header may be used by a NF Service Producer to send Load Control Information (LCI) to the NF Service Consumer.
3gpp-Sbi-Client-CredentialsClause 5.2.3.2.11 This header may be used by an NF Service Consumer to send Client Credentials Assertion to the NRF or to the NF Service Producer. See clause 6.7.5.
3gpp-Sbi-Source-NF-Client-CredentialsClause 5.2.3.2.22 This header may be used by an NF Service Consumer (e.g., DCCF, NWDAF containing MTLF) to send Client Credentials Assertion of the source NF (e.g. NWDAF, NWDAF containing AnLF) to the NF Service Producer (e.g. AMF, SMF, NWDAF containing MTLF).
The purpose is one of the followings:
  • to enable the authorization of NF service consumers for data access via DCCF as specified in Annex X of TS 33.501;
  • to enable the authorization of the ML model consumer when the NF service consumer requests ML models on behalf of the ML model consumer as specified in Annex X.10 of TS 33.501.
See clause 6.7.5.
3gpp-Sbi-Nrf-UriClause 5.2.3.2.12 This header may be used to indicate the NRF API URIs to be used for a given service request, e.g. in indirect communication with delegated discovery as a result of an NSSF query. It may also indicate whether OAuth2 based authorization is required for accessing the NRF services.
This header may also be used to indicate the NRF API URI to be used for a given notification request, e.g. if the NF service producer has received NRF API URI from the NF service consumer and the NF producer delegates NF consumer reselection to the SCP in indirect communication,
3gpp-Sbi-Target-Nf-IdClause 5.2.3.2.13 This header is used in a 307 Temporary Redirect or 308 Permanent Redirect response, to identify the target NF (service) instance towards which the request is redirected. See clause 6.10.9.1.
3gpp-Sbi-Max-Forward-HopsClause 5.2.3.2.14 This header may be used to indicate the maximum number of allowed hops with specified node type to relay the request message to the target HTTP server.
If node type is "scp", its value indicates the maximum number of allowed SCP hops to relay the request message to the target NF as HTTP server when indirect communication is used.
3gpp-Sbi-Originating-Network-IdClause 5.2.3.2.15 This header shall be inserted by an NF service consumer or an NF service producer originating an HTTP request message towards a different PLMN or SNPN.
It should be inserted by the sending SCP in SBI HTTP request messages towards the SEPP, only if the header is not present in the SBI HTTP request message and the SCP can determine which PLMN-ID value should be included in the header.
It shall be inserted by the sending SEPP or the receiving SEPP in SBI HTTP request messages towards the target PLMN or SNPN, only if the header is not present in the SBI HTTP request message and the sending SEPP or the receiving SEPP (respectively) can determine the PLMN ID or SNPN ID of the source PLMN or SNPN.
If the SEPP cannot uniquely determine the PLMN-ID or SNPN-ID, it is a configuration/deployment aspect to determine which PLMN-ID or SNPN-ID value should be included in the header by these entities. In such case, the message should either be rejected, or the SEPP shall indicate to the peer that the header is derived based on configuration.
It shall indicate the PLMN-ID or the SNPN-ID of the source PLMN or SNPN of the HTTP request message (i.e., the PLMN ID or the SNPN ID of the NF Service Consumer or NF Service Producer).
See clause 5.9.3.2 of TS 33.501 for the handling of this header by the sending NF, the sending SCP, the sending SEPP and the receiving SEPP. (NOTE 2)
3gpp-Sbi-Access-ScopeClause 5.2.3.2.16 This header is used in a service request for Indirect Communication to indicate the access scope of the service request for NF service access authorization. See clauses 6.7.3 and 6.10.11.
3gpp-Sbi-Access-TokenClause 5.2.3.2.17 This header is used in a service response forwarded by the SCP to an NF service consumer to provide an access token for possible re-use in subsequent service requests. See clause 6.10.1.
3gpp-Sbi-Target-Nf-Group-IdClause 5.2.3.2.19 This header is used in a service response from the SCP to the NF Service Consumer, when using indirect communication with delegated discovery, to indicate the NF Group ID of the NF service producer selected by the SCP. See clause 6.10.3.4.
3gpp-Sbi-Nrf-Uri-CallbackClause 5.2.3.2.20 This header may be included in service request (e.g. subscription creation request) from the NF service consumer to the NF service producer, to indicate:
  • the NRF NFDiscovery API URI to be used to discover an alternative NF service consumer for callback, e.g. during NF service consumer reselection for callback when the original NF service consumer is no longer available; and
  • if available, the NRF NFManagement API URI to be used to subscribe to NF status change of the NF service consumer.
For indirect communication, if the NF service producer delegates NF service consumer reselection to the SCP, the NF service producer should include 3gpp-Sbi-Nrf-Uri header with received NRF API URI (which was received in the 3gpp-Sbi-Nrf-Uri-Callback from the NF service consumer) in the notification requests to the NF service consumer.
3gpp-Sbi-NF-Peer-InfoClause 5.2.3.2.21 This header is used in HTTP requests and responses to indicate the sender and receiver of the message.
The HTTP client and server should include this header in every HTTP request and response messages.
HTTP intermediaries (e.g. SCP) should forward this header, when relaying HTTP messages to next hop, and may update the destination in the header if the receiver NF of the message is (re)selected. The parameters defined for the source and destination of SCPs or SEPPs (as defined in clause 5.2.3.2.21) may also need to be updated according to the source and destination of the HTTP message.
NOTE 1:
The callback URI for event subscription may receive event notifications from different NF producers, e.g. UDM may subscribe to AMF/SMF on behalf of NEF with directly reporting mode for certain UDM events in the subscription, which should be inspected with corresponding OpenAPI schema where the notification is defined. For both direct and indirect communications, to include this header in all event notification requests can help NF consumer to identify the type of event notification and select corresponding schema to perform OpenAPI inspection.
NOTE 2:
The value of this header shall be verified by the sending SEPP and receiving SEPP (see clause 5.9.3.2 of TS 33.501). If the PLMN ID or SNPN ID in this header does not match with any of the PLMN IDs that the sending SEPP represents, the sending SEPP or the receiving SEPP shall reject the received signalling message using the error cause "ORIGINATING_NETWORK_ID_MISMATCH".
Up
5.2.3.2.2  3gpp-Sbi-Message-Priorityp. 24
The header contains the HTTP/2 message priority value from 0 to 31, as defined in clause 6.8.4.
The encoding of the header follows the ABNF as defined in RFC 9110.
A message with 3gpp-Sbi-Message-Priority "0" has the highest priority.
EXAMPLE:
3gpp-Sbi-Message-Priority: 10
Up
5.2.3.2.3  3gpp-Sbi-Callbackp. 24
The header contains the type of notification. The value for the notification type is a string used identifying a particular type of callback (e.g. a notification, typically the name of the notify service operation).
The encoding of the header follows the ABNF as defined in RFC 9110.
EXAMPLE 1:
3gpp-Sbi-Callback: Nnrf_NFManagement_NFStatusNotify
EXAMPLE 2:
3gpp-Sbi-Callback: Nudm_SDM_Notification; apiversion=2
The list of valid values for the cbtype is specified in Annex B.
The apiversion parameter should be present if the major version is higher than 1.
Up
5.2.3.2.4  3gpp-Sbi-Target-apiRoot |R16|p. 25
The header contains the apiRoot of the target URI (see clause 4.4 of TS 29.501) in a request sent to an SCP when using Indirect Communication. This header contains the apiRoot of the selected or changed target URI in a response sent to an HTTP client, when the SCP selected or reselected a new HTTP server to route the request (or when the SCP sends the request to an alternative HTTP Server upon receiving a 3xx redirect message, see clause 6.10.9.1) and no Location HTTP header is included in the HTTP response. It may also be used in a request sent to a SEPP and in a request between SEPPs (see clause 6.1.4.3.2).
The encoding of the header follows the ABNF as defined in RFC 9110.
EXAMPLE:
3gpp-Sbi-Target-apiRoot: https://example.com/a/b/c
Up
5.2.3.2.5  3gpp-Sbi-Routing-Binding |R16|p. 25
This header contains a Routing Binding Indication used to direct a service request to an HTTP server which has the targeted NF service resource context (see clause 6.12).
The encoding of the header follows the ABNF as defined in RFC 9110.
The following parameters are defined:
  • bl (binding level): the value of this parameter (blvalue) indicates a preferred binding to a binding entity, i.e. either to an NF Instance, an NF set, an NF Service Instance or an NF Service Set. If the binding level is set to an NF Service Instance (nfservice-instance), then either NF Service Set ID or NF Instance ID shall also be present to unambiguously identify the NF Service Instance.
  • nfinst (NF instance): indicates an NF Instance ID, as defined in clause 5.2.2.2.2 in TS 29.510. This parameter shall be present if the binding level is set to "nf-instance", or if the binding level is set to "nfservice-instance" and the nfserviceset parameter is not included.
  • nfset (NF set): indicates an NF Set ID, as defined in clause 28.12 in TS 23.003. This parameter shall be present if the binding level is set to "nf-set". It may be present otherwise (see clause 6.12.1).
  • nfservinst (NF service instance): indicates an NF Service Instance ID. This parameter shall be present if the binding level is set to "nfservice-instance".
  • nfserviceset (NF service set): indicates an NF Service Set ID as defined in clause 28.13 of TS 23.003. This parameter shall be present if the binding level is set to "nfservice-set". It shall also be present if the binding level is set to "nfservice-instance" and the NF service instance indicated by the nfservinst parameter is part of an NF service set (see clause 6.12.1).
  • servname (service name): indicates the name of a service, as defined in TS 29.510, or a custom service that handles a notification or a callback request. It may be present in a Routing Binding Indication in a notification or a callback request.
  • backupamfinst (backup NF Instance): indicates the NF Instance ID (as defined in clause 5.2.2.2.2 of TS 29.510) of the backup NF, i.e. the backup AMF as specified in TS 23.501. The backupamfinst may be present only when the binding level is nf-instance or nfservice-instance or nfservice-set. When backupamfinst is present, no binding entity corresponding to NF set shall be present. When the binding level is nf-set, backupamfinst shall not be present.
  • for the definition and encoding of the backupnf see clause 5.2.3.2.6.
  • for the definition and encoding of the callback-uri-prefix see clause 5.2.3.2.6. The ABNF is defined in clause 5.2.3.3.7.
See Section 5.6.2 of RFC 9110 for the "token" type definition. A token's value is a string, which contains a binding entity ID or a service name.
EXAMPLE 1:
Binding to SMF set 1 of MCC 345 and MNC 012:
3gpp-Sbi-Routing-Binding: bl=nf-set; nfset=set1.smfset.5gc.mnc012.mcc345
EXAMPLE 2:
Binding to an SMF instance within SMF set of Example 1:
3gpp-Sbi-Routing-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfset=set1.smfset.5gc.mnc012.mcc345
EXAMPLE 3:
Binding to a SMF Service Set "xyz" within an SMF instance within SMF set of Example 1:
3gpp-Sbi-Routing-Binding: bl=nfservice-set; nfserviceset=setxyz.snnsmf-pdusession.nfi54804518-4191-46b3-955c-ac631f953ed8.5gc.mnc012.mcc345; nfset=set1.smfset.5gc.mnc012.mcc345
EXAMPLE 4:
Binding to AMF set 1 within AMF region 48 (hexadecimal):
3gpp-Sbi-Routing-Binding: bl=nf-set; nfset=set1-region48.amfset.5gc.mnc012.mcc345
EXAMPLE 5:
Binding for a subscription (i.e. notification requests) to AMF set 1 within AMF region 48 (hexadecimal) and Namf_Communication service:
3gpp-Sbi-Routing-Binding: bl=nf-set; nfset= set1-region48.amfset.5gc.mnc012.mcc345; servname=namf-comm
EXAMPLE 6:
Binding to the AMF Instance in addition with backup AMF, where the nfinst carries the Identity of the AMF to which the resource is bound and whose backup AMF is indicated in backupamfinst:
3gpp-Sbi-Routing-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed7; backupamfinst=54804518-4191-46b3-955c-ac631f953ed8
Up
5.2.3.2.6  3gpp-Sbi-Binding |R16|p. 26
This header contains a comma-delimited list of Binding Indications from an HTTP server for storage and subsequent use by an HTTP client (see clause 6.12).
The encoding of the header follows the ABNF as defined in RFC 9110.
The following parameters are defined:
  • scope: indicates the applicability of a Binding Indication in a service request other than a notification request, or in a notification or callback response. This may take one of the following values:
    • "other-service": the binding information applies to other service(s) that the NF Service Consumer may later on provide as an NF Service Producer (see clause 6.12.3);
    • "subscription-events": the binding information applies to subscription change event notifications (see clause 6.12.4);
    • "callback": the binding information applies to notification or callback requests (see clause 6.12.4 and clause 6.12.5).
    The absence of this parameter in a Binding Indication in a service request other than a notification request, or in a notification or callback response, shall be interpreted as "callback".
    Two scope parameters may be present in a Binding Indication if the binding information applies to notification/callback requests and to other services.
  • servname (service name): indicates the name of a service, as defined in TS 29.510, or a custom service, i.e.:
    • the name of the service that handles a notification or a callback request, when present in a Binding Indication for a subscription or a callback, i.e. with a scope parameter absent or set to "callback"; or
    • the name of the other service(s) for which the binding applies, when present in a Binding Indication in a service request for the other services the NF Service Consumer can provide later on as an NF Service Producer, i.e. with the scope parameter set to "other-service". More than one servname parameter may be present to represent multiple such services. The absence of this parameter in a Binding Indication with the scope parameter set to "other-service" shall be interpreted as binding information that applies to all the services that the NF Service Consumer may provide later as an NF Service Producer.
  • recoverytime: indicates the recovery timestamp of the entity corresponding to the highest resiliency level supported for the resource, that is, the higher level binding entity indicated in the Binding Indication. See Table 6.3.1.0-1 of TS 23.501, and clause 6.1 of TS 23.527. The date-time type is specified in RFC 5322 and Section 5.6.7 of RFC 9110.
  • nr: indicates the URI of the notification endpoint when this binding information is applicable; it applies to callback requests (see clause 6.12.4); if the notification URI does not contain a correlationID in the path (i.e. it is a common notification URI for multiple subscriptions), the correlationID shall be added as a fragment component of the URI (i.e. following the "#" character) at the end of the URI.
  • for the definition and encoding of the blvalue, nfinst, backupamfinst, nfset, nfservinst and nfserviceset see clause 5.2.3.2.5.
  • backupnf: indicates the backup NF service instance identifier and/or the backup NF identifier as defined in clause 5.2.2.2.2 in TS 29.510, which shall be used when preferred binding entity is not reachable if supported.
  • group: it is a boolean indicating if the binding indication is for a group of resource/session contexts.
  • groupid (group id): indicates the group identifier allocated by the NF (service) instance, one ore more resource/session contexts are sharing the same groupid. The groupid is optional and it may be allocated when the resource/session context is created and then be updated afterwards. The groupid is global unique and it may be encoded using the same mechnaism for the NfInstanceId as specificed in TS 29.571.
  • oldgroupid (old group id): indicates the group identifier allocated by the NF (service) instance previously and to be replaced by the groupid, hence it shall only be present when to update a Binding Indication for multiple contexts. When the if the oldgroupid is present, the groupid shall also be present to indicate the new groupid allocated.
  • uribase: identify the apiroot and path segments part in the resource URI or notification/callback URI which is common to multiple contexts. This parameter may only be present when to update a Binding Indication for multiple contexts and when the "group" is set to "true". When included, it indicates that all resources or notification contexts with this uribase will use the updated Binding Indication subsequently. More than one uribase may be present.
  • oldnfinst: indicates the NF Instance ID of the NF instance where the group of resource/session contexts are currently served (i.e. the Binding Indication allocated previously for the group of resource/session contexts includes the information of the NF instance), as defined in clause 5.2.2.2.2 in TS 29.510. When included, it indicates that all the resource/session contexts served by this NF instance will use the updated Binding Indication subsequently.
  • oldservset: indicates the NF Service Set ID of the NF Service Set where the group of resource/session contexts are currently served (i.e. the Binding Indication allocated previously for the group of resource/session contexts includes the information of the NF Service Set), as defined in clause 5.2.2.2.2 in TS 29.510. When included, it indicates that all the resource/session contexts served by this NF Service Set will use the updated Binding Indication subsequently.
  • oldservinst: indicates the NF Service Instance ID of the NF service instance where the group of resource/session contexts are currently served (i.e. the Binding Indication allocated previously for the group of resource/session contexts includes the information of the NF service instance), as defined in clause 5.2.2.2.2 in TS 29.510. When included, it indicates that all the resource/session contexts served by this NF service instance will use the updated Binding Indication subsequently.
  • guami (GUAMI): indicates the GUAMI of the AMF currently serving UE contexts, as defined in clause 5.3.4.1 of TS 29.571. When included, it indicates that all the UE contexts associated with the GUMAI will use the updated Binding Indication subsequently.
  • no-redundancy: it is a boolean set to true indicating that the resource is exclusively bound to the NF service instance identified in the binding indication. It may be present in a binding with any scope, i.e. "other-service", "subscription-events" or "callback", or with no scope parameter. When this parameter is present, the blvalue shall be set to "nfservice-instance", the nfservinst parameter shall be present and either the nfserviceset parameter or the nfinst parameter shall be present. The nfserviceset or nfinst parameter included in the binding indication shall only be used to identify the NF service instance and shall not be considered as a binding entity for reselection. The no-redundancy parameter shall only be signaled if the receiver of this information is known to support this parameter (see clause 6.12.1). Subsequently, when sending further requests targeting a resource with no-redundancy, the HTTP client shall not include any routing binding indication in the request message (to prevent the SCP from performing any reselection).
  • callback-uri-prefix: The NF service consumer may include this parameter when providing a Callback URI when the Callback URI contains a prefix. When present, the "callback-uri-prefix" shall be a path-absolute as specified RFC 3986 (i.e. the first path segment(s) after the authority) which is part of the Callback URI provided by a NF service consumer in the corresponding service request message sent to a NF service producer. The authority and "callback-uri-prefix" in the Callback URI shall uniquely identify a consumer service instance. This parameter is relevant when the "scope" parameter is either "subscription-events" or "callback". See clauses 6.12.4 and 6.12.5 for the usage of this parameter. The ABNF is defined in clause 5.2.3.3.7.
EXAMPLES 1 to 5:
Same as EXAMPLES 1 to 5 defined in clause 5.2.3.2.5, with the header name "3gpp-Sbi-Binding" instead of "3gpp-Sbi-Routing-Binding".
EXAMPLE 6:
Subscription request from one NF on behalf of another NF, with 2 binding indications:
3gpp-Sbi-Binding: bl=nf-set; nfset=set1.udmset.5gc.mnc012.mcc345; servname=nudm-ee;scope=subscription-events
3gpp-Sbi-Binding: bl=nf-set; nfset=set1.nefset.5gc.mnc012.mcc345; servname=nnef-event-exposure
EXAMPLE 7:
Service request with 2 binding indications, for callback requests and for other services the NF Service Consumer may provide later as an NF Service Producer:
3gpp-Sbi-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfset=set1.smfset.5gc.mnc012.mcc345; servname=nsmf-pdusession
3gpp-Sbi-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfset=set1.smfset.5gc.mnc012.mcc345; scope=other-service; servname=nsmf-event-exposure
EXAMPLE 8:
Service request with one binding indication applying to notification/callback requests and to any other services the NF Service Consumer may provide later as an NF Service Producer:
3gpp-Sbi-Binding: bl=nf-set; nfset=set1-region48.amfset.5gc.mnc012.mcc345; scope=callback; scope=other-service
EXAMPLE 9:
Service request with one binding indication applying to notification/callback requests together with a recovery time stamp associated with the NF Set indicated in the binding indication and with the binding level set to "nfset":
3gpp-Sbi-Binding: bl=nf-set; nfset=set1-region48.amfset.5gc.mnc012.mcc345; scope=callback; recoverytime= "Tue, 04 Feb 2020 08:49:37 GMT"
EXAMPLE 10:
Service response with one binding indication applying to the session context with a recovery time stamp associated with the NF Set indicated in "nfset" in the binding indication and with the binding level set to "nfinstance":
3gpp-Sbi-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfset=set1.smfset.5gc.mnc012.mcc345; recoverytime= "Tue, 04 Feb 2020 08:49:37 GMT"
EXAMPLE 11:
Service response with one binding indication applying to the session context with a recovery time stamp associated with the NF Instance included the binding indication and with the binding level set to nfserviceinstance:
3gpp-Sbi-Binding: bl=nfservice-instance; nfservinst=xyz; nfinst=54804518-4191-46b3-955c-ac631f953ed8; recoverytime= "Tue, 04 Feb 2020 08:49:37 GMT"
EXAMPLE 12:
Service response with one binding indication applying to the resource context pertaining to a group identified by "54804518-4191-46b3-955c-ac631f953ed1" together with a backup nf:
3gpp-Sbi-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed0; nfset=set1.smfset.5gc.mnc012.mcc345; backupnf=54804519-4191-46b3-955c-ac631f953ed2; groupid=54804518-4191-46b3-955c-ac631f953ed1
EXAMPLE 13:
A notification request message with one binding indication applying to the resource contexts with the oldgroup identifier "54804518-4191-46b3-955c-ac631f953ed1", where the preferred binding entity is changed to "nfinst=54804519-4191-46b3-955c-ac631f953ed0" together with a new group identifier "54804519-4191-46b3-955c-ac631f953ed3" allocated.
3gpp-Sbi-Binding: bl=nf-instance; nfinst=54804519-4191-46b3-955c-ac631f953ed0; nfset=set1.smfset.5gc.mnc012.mcc345; group=true; oldgroupid=54804518-4191-46b3-955c-ac631f953ed1; groupid=54804519-4191-46b3-955c-ac631f953ed3
EXAMPLE 14:
A notification request message with one binding indication applying to the resource contexts identified by an uribase, where the preferred binding entity is changed to "nfinst=54804519-4191-46b3-955c-ac631f953ed0":
3gpp-Sbi-Binding: bl=nf-instance; nfinst=54804519-4191-46b3-955c-ac631f953ed0; nfset=set1.smfset.5gc.mnc012.mcc345; group=true; uribase= http%3A%2F%2F10.10.10.10%2Fstringxyz
EXAMPLE 15:
A notification request message with one binding indication applying to the resource contexts served by the NF instance identified by "64804518-4191-46b3-955c-ac631f953ed8" where the preferred binding entity is changed to "nfinst=74804519-4191-46b3-955c-ac631f953ed0".
3gpp-Sbi-Binding: bl=nf-instance; nfinst=74804519-4191-46b3-955c-ac631f953ed0; nfset=set1.smfset.5gc.mnc012.mcc345; group=true; oldnfinst=64804518-4191-46b3-955c-ac631f953ed8
EXAMPLE 16:
Service request message with an updated binding indication applying to the UE contexts for GUAMI <mnc(012)><mcc(345)><AmfId("abcd12")> where the backupamfinst is changed.
3gpp-Sbi-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed7; backupamfinst=54804520-4191-46b3-955c-ac631f953ed8; scope=other-service; group=true; guami=%7B%22plmnId%22%3A%7B%22mnc%22%3A%22012%22%2C%22­mcc%22%3A%22345%22%7D%2C%22amfId%22%3A%22abcd12%22%7D
EXAMPLE 17:
Service response with a binding indication applying to the resource context which is exclusively bound to a specific NF service instance.
3gpp-Sbi-Binding: bl=nfservice-instance; nfservinst=xyz; nfinst=54804518-4191-46b3-955c-ac631f953ed8; no-redundancy= true
EXAMPLE 18:
Subscription request with a Callback URI containing a prefix "/abc":
3gpp-Sbi-Binding: bl=nf-set; nfset=set1.nefset.5gc.mnc012.mcc345; servname=nnef-event-exposure; callback-uri-prefix="/abc"
Up
5.2.3.2.7  3gpp-Sbi-Discovery |R16|p. 30
These headers shall be used to convey NF service discovery factors to the SCP in indirect communication models. They contain discovery parameters to be conveyed by an NF service consumer or an NF service producer to the SCP or by an SCP to the next hop SCP and they shall be used by the SCP to select or reselect a suitable NF service producer instance to create or update a (existing) resource context, or a suitable NF service consumer instance towards which to send a notification or a callback request, e.g. by performing the NF service discovery procedure with the NRF on behalf of the NF consumer in case of indirect communication with delegated discovery model.
The name of each NF service discovery factors header shall be constructed by concatenating the string "3gpp-Sbi-Discovery-" with the name of the conveyed discovery parameter, i.e. "3gpp-Sbi-Discovery-<discovery parameter>".
The discovery headers shall be used to include any of the discovery query parameters listed in TS 29.510, Table 6.2.3.2.3.1-1. The value of each NF service discovery header shall be encoded in the same way as the corresponding discovery parameter (i.e. with the same data type, cardinality and format). Thus, the values of these headers may be validated with the same data model as that of the corresponding discovery parameters. The discovery headers shall comply with the condition of presence of the discovery parameters defined in Table 6.2.3.2.3.1-1 of TS 29.510, e.g. discovery headers shall be included for discovery parameters defined as mandatory in this table. Table 5.2.3.2.7-1 lists examples of NF service discovery headers.
Header name Discovery parameter Header value Data Model
3gpp-Sbi-Discovery-target-nf-typetarget-nf-type (TS 29.510, Table 6.2.3.2.3.1-1)AMFNFType: Enumeration as of TS 29.510, Table 6.1.6.3.3-1.
3gpp-Sbi-Discovery-snssaissnssais (TS 29.510, Table 6.2.3.2.3.1-1) [{"sst": 1, "sd": "A08923"}, {"sst": 1, "sd": "0023F1"}] array(Snssai), where Snssai is a structured data type as of TS 29.571, Table 5.4.4.2-1
3gpp-Sbi-Discovery-target-nf-instance-idtarget-nf-instance-id (TS 29.510, Table 6.2.3.2.3.1-1)e553cf50-f32b-4638-8a7e-0d416cc60952NfInstanceId: simple data type as of TS 29.571, Table 5.3.2-1
3gpp-Sbi-Discovery-pdu-session-typespdu-session-types (TS 29.510, Table 6.2.3.2.3.1-1)IPV6,IPV4V6array(PduSessionType), where PduSessionType is a simple data type as of TS 29.571, Table 5.4.3.3-1.
 
The 3gpp-Sbi-Discovery-* header is not documented in OpenAPI specification files. It shall comply with the following OpenAPI definition:
  • for parameters defined with a "content:" block and specifying the "application/json" media type in clause A.3 of TS 29.510:
  • for other parameters:
3gpp-Sbi-Discovery-* headers corresponding to query parameters defined with the "style" keyword set to "form" and the "explode" keyword set to false in clause A.3 of TS 29.510 shall be formatted using the style "simple", i.e. as comma-separated values.
Up
5.2.3.2.8  3gpp-Sbi-Producer-Id |R16|p. 31
This header contains the NF Service Producer Instance ID (see clause 6.10.3.4).
The encoding of the header follows the ABNF as defined in RFC 9110.
The following parameters are defined:
EXAMPLE 1:
3gpp-Sbi-Producer-Id: nfinst=54804518-4191-46b3-955c-ac631f953ed8
EXAMPLE 2:
3gpp-Sbi-Producer-Id: nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfservinst=xyz
EXAMPLE 3:
3gpp-Sbi-Producer-Id: nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfservinst=xyz; nfset=set1.smfset.5gc.mnc012.mcc345
Up
5.2.3.2.9  3gpp-Sbi-Oci |R16|p. 32
The header contains a comma-delimited list of Overload Control Information (OCI). See clause 6.4.3.
The encoding of the header follows the ABNF as defined in RFC 9110.
"Timestamp" (Mandatory parameter): The date-time type is specified in RFC 5322 and Section 5.6.7 of RFC 9110. It indicates the timestamp at which the overload control information was generated.
"Period-of-Validity" (Mandatory parameter): Period of validity is a timer that is measured in seconds. Once the timer expires, the OCI becomes invalid.
"Overload-Reduction-Metric" (Mandatory parameter): Overload-Reduction-Metric up to 3 digits long decimal string and the value range shall be from 0 to 100.
The Overload Control Scope is a mandatory header component, and it shall contain one of the parameters: "NF-Instance", "NF-Set", "NF-Service-Instance" or "NF-Service-Set" (for NF consumers or NF producers), "Callback-URI" (for NF consumers), "SCP-FQDN" (for SCP), or "SEPP-FQDN" (for SEPP).
See clause 6.4.3.4.5. The nfinst, nfset, nfservinst, nfserviceset and servname parameters are defined in clause 5.2.3.2.8. fqdn shall encode an FQDN. URI is defined in Section 3 of RFC 3986.
When signaling overload control information of an NF service instance, the "NF-Inst" parameter shall be present to identify the NF service instance unambiguously. If the "NF-Inst" parameter is absent, the receiving NF should assume the last known NF instance ID of NF service producer or consumer, if available.
"DNN" (Optional parameter): Used for S-NSSAI/DNN based overload control by SMF, see clause 6.4.3.4.5.2.2, that refers to one or more specific DNN(s). DNN format is defined in TS 23.003.
"S-NSSAI" (Optional parameter): Used for S-NSSAI/DNN based overload control by SMF, see clause 6.4.3.4.5.2.2, that refers to one or more specific S-NSSAI(s).
S-NSSAI format is defined in clause 5.4.4.2 of TS 29.571. It shall be encoded as the object format (i.e. not converted to the string pattern defined in clause 5.4.4.2 of TS 29.571).
EXAMPLE 1:
Overload Control Information for an NF Instance:
3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 75s; Overload-Reduction-Metric: 50%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8
EXAMPLE 2:
Overload Control Information for an NF Service Set:
3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 120s; Overload-Reduction-Metric: 50%; NF-Service-Set: setxyz.snnsmf-pdusession.nfi54804518-4191-46b3-955c-ac631f953ed8.5gc.mnc012.mcc345
EXAMPLE 3:
Overload Control Information for an SMF instance related to a particular DNN of an S-NSSAI:
3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 600s; Overload-Reduction-Metric: 50%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8; S-NSSAI: %7B%22sst%22%3A%201%2C%20%22sd%22%3A%20%22A08923%22%7D; DNN: internet.mnc012.mcc345.gprs
EXAMPLE 4:
Overload Control Information for an SMF instance related to a particular DNN shared by two S-NSSAIs:
3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 240s; Overload-Reduction-Metric: 50%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8; S-NSSAI: %7B%22sst%22%3A%201%2C%20%22sd%22%3A%20%22A08923%22%7D & %7B%22sst%22%3A%201%2C%20%22sd%22%3A%20%22A08924%22%7D; DNN: internet.mnc012.mcc345.gprs
EXAMPLE 5:
Overload Control Information sent by a NF service consumer with a scope set to a Callback-Uri:
3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 120s; Overload-Reduction-Metric: 25%; Callback-Uri: "https://pcf12.operator.com/serviceY"
EXAMPLE 6:
Overload Control Information sent by a NF service consumer with a scope set to a specific NF Instance and service:
3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 120s; Overload-Reduction-Metric: 25%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8; Service-Name: nsmf-pdusession
EXAMPLE 7:
Overload Control Information sent by an SCP:
3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 120s; Overload-Reduction-Metric: 25%; SCP-FQDN: scp1.example.com
EXAMPLE 8:
Example with two OCI values, one for an SMF Instance and another one for a specific DNN of an S-NSSAI for the same SMF Instance:
3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 75s; Overload-Reduction-Metric: 50%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8
3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 600s; Overload-Reduction-Metric: 40%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8; S-NSSAI: %7B%22sst%22%3A%201%2C%20%22sd%22%3A%20%22A08923%22%7D; DNN: internet.mnc012.mcc345.gprs
EXAMPLE 9:
Overload Control Information sent by an SEPP:
3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 120s; Overload-Reduction-Metric: 25%; SEPP-FQDN: sepp1.example.com
EXAMPLE 10:
Overload Control Information for an NF Service Instance:
3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 75s; Overload-Reduction-Metric: 50%; NF-Service-Instance: xyz; NF-Inst: 54804518-4191-46b3-955c-ac631f953ed8
Up
5.2.3.2.10  3gpp-Sbi-Lci |R16|p. 34
The header contains a comma-delimited list (see RFC 9110) of Load Control Information (LCI). See clause 6.3.3.
The encoding of the header follows the ABNF as defined in RFC 9110.
"Timestamp" (Mandatory parameter): The date-time type is specified in RFC 5322 and Section 5.6.7 of RFC 9110. It indicates the timestamp associated with the load control information.
"Load-Metric" (Mandatory parameter): Load-Metric is up to 3 digits long decimal string and the value range shall be from 0 to 100.
The Load Control Scope is a mandatory header component, and it shall contain one of the parameters: "NF-Instance", "NF-Set", "NF-Service-Instance" or "NF-Service-Set" (for NF producers), "SCP-FQDN" (for SCP), or "SEPP-FQDN" (for SEPP).
See clause 6.3.3.4.4. The nfinst, nfset, nfservinst and nfserviceset parameters are defined in clause 5.2.3.2.5. fqdn shall encode an FQDN.
When signaling load control information of an NF service instance, the NF-Inst parameter shall be present to identify the NF service instance unambiguously. If the NF-Inst parameter is absent, the receiving NF should assume the last known NF instance ID of the NF service producer, if available.
"DNN" (Optional parameter): Used for S-NSSAI/DNN based load control by SMF, see clause 6.3.3.4.4.2.2, that refers to one or more specific DNN(s). DNN format is defined in TS 23.003.
"S-NSSAI" (Optional parameter): Used for S-NSSAI/DNN based load control by SMF, see clause 6.3.3.4.4.2.2, that refers to one or more specific S-NSSAI(s).
S-NSSAI format is defined in clause 5.4.4.2 of TS 29.571. It shall be encoded as the object format (i.e. not converted to the string pattern defined in clause 5.4.4.2 of TS 29.571).
"Relative-Capacity" (Optional parameter): Used for S-NSSAI/DNN based load control by SMF, see clause 6.3.3.4.5. Up to 3 digits long decimal string with value range from 0 to 100. The value applies to all combinations of S-NSSAIs and DNNs indicated in the LCI.
EXAMPLE 1:
Load Control Information for an NF Instance:
3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 25%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8
EXAMPLE 2:
Load Control Information for an NF Service Set:
3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 25%; NF-Service-Set: setxyz.snnsmf-pdusession.nfi54804518-4191-46b3-955c-ac631f953ed8.5gc.mnc012.mcc345
EXAMPLE 3:
Load Control Information for an SMF instance related to a particular DNN of an S-NSSAI (SST=1, SD="A08923"):
3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 25%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8; S-NSSAI: %7B%22sst%22%3A%201%2C%20%22sd%22%3A%20%22A08923%22%7D; DNN: internet.mnc012.mcc345.gprs; Relative-Capacity: 20%
EXAMPLE 4:
Load Control Information for an SMF instance related to a particular S-NSSAI (SST=1, SD="A08923"):
3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 25%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8; S-NSSAI: %7B%22sst%22%3A%201%2C%20%22sd%22%3A%20%22A08923%22%7D; DNN: internet.mnc012.mcc345.gprs; Relative-Capacity: 20%
EXAMPLE 5:
Load Control Information for SCP:
3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 25%; SCP-FQDN: scp1.example.com
EXAMPLE 6:
Example with two LCI values, for different DNNs of a same S-NSSAI (SST=1, SD="A08923"):
3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 40%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8; S-NSSAI: %7B%22sst%22%3A%201%2C%20%22sd%22%3A%20%22A08923%22%7D; DNN: internet.mnc012.mcc345.gprs; Relative-Capacity: 30%
3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 70%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8; S-NSSAI: %7B%22sst%22%3A%201%2C%20%22sd%22%3A%20%22A08923%22%7D; DNN: ciot.mnc012.mcc345.gprs; Relative-Capacity: 20%
EXAMPLE 7:
Load Control Information for SEPP:
3gpp-Sbi-Lci: Timestamp: "Tue, 04 Apr 2021 08:36:42 GMT"; Load-Metric: 25%; SEPP-FQDN: sepp1.example.com
EXAMPLE 8:
Load Control Information for an NF Service Instance:
3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 25%; NF-Service-Instance: xyz; NF-Inst: 54804518-4191-46b3-955c-ac631f953ed8
Up
5.2.3.2.11  3gpp-Sbi-Client-Credentials |R16|p. 36
3The header contains client credentials assertion (see clause 13.3.8.1 of TS 33.501).
The encoding of the header follows the ABNF as defined in RFC 9110.
The client credentials assertion shall be a JSON Web Token (JWT) as specified in RFC 7519, digitally signed using JWS as specified in RFC 7515 and in clause 13.3.8.1 of TS 33.501. It shall include:
  • the claims defined in Table 5.2.3.2.11-1 encoded as a JSON object; and
  • one of the following JOSE headers:
    • the X.509 URL (x5u) header (see Section 4.1.5 of RFC 7515) referring to a resource for the X.509 public key certificate or certificate chain used for signing the client authentication assertion, or
    • the X.509 Certificate Chain (x5c) header (see Section 4.1.5 of RFC 7515) including the X.509 public key certificate or certificate chain used for signing the client authentication assertion.
The digitally signed client credentials assertion shall be converted to the JWS Compact Serialization encoding as a string as specified in Section 7.1 of RFC 7515.
Attribute name Data type P Cardinality Description
subNfInstanceIdM1 This IE shall contain the NF instance ID of the NF service consumer, corresponding to the standard "Subject" claim described in Section 4.1.2 of RFC 7519.
iatintegerM1 This IE shall indicate the time at which the JWT was issued, corresponding to the standard "Issued At" claim described in Section 4.1.6 of RFC 7519. This claim may be used to determine the age of the JWT.
expintegerM1 This IE shall contain the expiration time after which the client credentials assertion is considered to be expired, corresponding to the standard "Expiration Time" claim described in Section 4.1.4 of RFC 7519.
audarray(NFType)M1..N This IE shall contain the NF type of the NF service producer and/or "NRF", for which the claim is applicable, corresponding to the standard "Audience" claim described in Section 4.1.3 of RFC 7519.
 
The JSON object containing the client credentials assertion shall comply with the following OpenAPI definition:
ClientCredentialsAssertion:
description: The data structure for the client credentials assertion
type: object
required:
- sub
- iat
- exp
- aud
properties:
sub:
$ref: 'TS29571_CommonData.yaml#/components/schemas/NfInstanceId'
iat:
type: integer
exp:
type: integer
aud:
type: array
items:
$ref: 'TS29510_Nnrf_NFManagement.yaml#/components/schemas/NFType'
minItems: 1
Up
5.2.3.2.12  3gpp-Sbi-Nrf-Uri |R16|p. 37
The header contains a list of NRF API URIs. See clause 6.10.3.2 and clause 6.10.5.1.
The encoding of the header follows the ABNF as defined in RFC 9110.
  • for the nnrf-disc, nnrf-nfm and nnrf-oauth2 parameters:
    URI shall comply with the URI definition in RFC 3986.
  • for the oauth2-requested-services parameter:
    nrfServiceName shall encode an NRF API name, e.g. "nnrf-disc" or "nnrf-nfm".
    When present, the oauth2-requested-services parameter shall indicate the list of NRF services for which OAuth2 based authorization is required for accessing the respective NRF services.
    If OAuth2 based authorization is required for accessing the respective NRF services, the nnrf-oauth2 parameter shall be present and shall be used to request access token for NRF services.
    The absence of the oauth2-requested-services parameter means that no indication is provided about the potential usage of Oauth2 for authorization.
EXAMPLE 1:
Header with NRF NF Discovery, NF Management and Access Token API URIs, without indication on whether OAuth2-based authorization is required to access the NRF services:
3gpp-Sbi-Nrf-Uri: nnrf-disc: "https://nrf1.operator.com/nnrf-disc/v1"; nnrf-nfm: "https://nrf1.operator.com/nnrf-nfm/v1"; nnrf-oauth2: "https://nrf1.operator.com/oauth2"
EXAMPLE 2:
Header with NRF NF Discovery, NF Management and Access Token API URIs, indication on whether OAuth2-based authorization is required to access the NRF services:
3gpp-Sbi-Nrf-Uri: nnrf-disc: "https://nrf1.operator.com/nnrf-disc/v1"; nnrf-nfm: "https://nrf1.operator.com/nnrf-nfm/v1"; nnrf-oauth2: "https://nrf1.operator.com/oauth2"; oauth2-requested-services: nnrf-disc & nnrf-nfm
Up
5.2.3.2.13  3gpp-Sbi-Target-Nf-Id |R16|p. 38
This header contains the target NF (Service) Instance ID in an HTTP 307/308 response (see clause 6.10.9).
The encoding of the header follows the ABNF as defined in RFC 9110.
The following parameters are defined:
EXAMPLE:
3gpp-Sbi-Target-Nf-Id: nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfservinst=xyz
Up
5.2.3.2.14  3gpp-Sbi-Max-Forward-Hops |R17|p. 38
The header contains the value of maximum number of allowed hops with specified node type to relay the request message to the target NF.
The encoding of the header follows the ABNF as defined in RFC 9110.
EXAMPLE:
Allowed up to 5 SCP hops to relay the request:
3gpp-Sbi-Max-Forward-Hops: 5; nodetype=scp
Up
5.2.3.2.15  3gpp-Sbi-Originating-Network-Id |R17|p. 39
The header contains the PLMN Identity (MCC-MNC) of the source PLMN or the SNPN ID (MCC-MNC-NID) of the source SNPN of the received HTTP messages.
The encoding of the header follows the ABNF as defined in RFC 9110.
The srcinfo shall only be present when SCP or SEPP was unable to uniquely determine the value, i.e. PLMN ID, and has decided to insert the header with the value derived by configuration as described in Table 5.2.3.2.1-1.
The srcfqdn shall indicate FQDN of SCP or SEPP that inserted the header when srcinfo is present.
EXAMPLE 1:
For a source PLMN:
3gpp-Sbi-Originating-Network-Id: 123-45
EXAMPLE 2:
For a source PLMN and the header included by SEPP under the condition when the value of the header is derived based on the configuration and inserted by the SEPP:
3gpp-Sbi-Originating-Network-Id: 123-45; src: SEPP-sepp001.sepp.5gc.mnc045.mcc123.3gppnetwork.org
EXAMPLE 3:
For a source SNPN:
3gpp-Sbi-Originating-Network-Id: 123-45-000007ed9d5
Up
5.2.3.2.16  3gpp-Sbi-Access-Scope |R16|p. 39
The header indicates the access scope of the service request for NF service access authorization, as defined in clauses 6.7.3 and 6.10.11.
The encoding of the header follows the ABNF as defined in RFC 9110.
Scope-token shall consist of a list of space-delimited, case-sensitive strings, containing the NF service name of the NF service producer corresponding to the service request and, if defined for the specific resource/operation in the corresponding API, the additional resource/operation-level scope.
NQCHAR is defined in Appendix A of IETF RFC 6749.
EXAMPLE:
3gpp-Sbi-Access-Scope: nhss-ims-uecm nhss-ims-uecm:authorize:invoke
Up
5.2.3.2.17  3gpp-Sbi-Access-Token |R16|p. 40
The header contains an Access Token in a service response, for possible re-use in subsequent service requests, as defined in clause 6.10.11.
The encoding of the header follows the ABNF as defined in RFC 9110.
See Section 11.4 of RFC 9110 for the definition of "credentials".
Up
5.2.3.2.18Void
5.2.3.2.19  3gpp-Sbi-Target-Nf-Group-Id |R17|p. 40
This header contains the NF Group ID (e.g. UDM, HSS, AUSF, UDR, CHF, PCF Group ID) of the NF service producer.
The encoding of the header follows the ABNF as defined in RFC 9110.
The following parameter is defined:
  • nfgid (NF Group ID): indicates a NF Group ID, as defined in TS 29.571.
EXAMPLE:
3gpp-Sbi-Target-Nf-Group-Id: nfgid="udm-group-15"
Up
5.2.3.2.20  3gpp-Sbi-Nrf-Uri-Callback |R17|p. 40
The header contains the NRF API URI of the NF discovery service and may contain the NRF API URI of the NF management service. See clauses 6.5.3.2.
The encoding of the header follows the ABNF as defined in RFC 9110.
URI shall comply with the URI definition in RFC 3986.
EXAMPLE 1:
Header with NRF NF Discovery Service:
3gpp-Sbi-Nrf-Uri-Callback: nnrf-disc: "https://nrf1.operator.com/nnrf-disc/v1"
EXAMPLE 2:
Header with NRF NF Discovery and NF Management Services:
3gpp-Sbi-Nrf-Uri-Callback: nnrf-disc: "https://nrf1.operator.com/nnrf-disc/v1"; nnrf-nfm: "https://nrf1.operator.com/nnrf-nfm/v1"
Up
5.2.3.2.21  3gpp-Sbi-NF-Peer-Info |R17|p. 41
This header contains the IDs of the NF (service) instance as HTTP client and the NF (service) instance as HTTP server.
The encoding of the header follows the ABNF as defined in RFC 9110.
The following peertype are defined:
  • srcinst (Source NF instance): indicates the Source NF Instance ID, as defined in TS 29.510;
  • srcservinst (Source NF service instance): indicates the Source NF Service Instance ID, as defined in TS 29.510; if this parameter is present, srcinst shall also be present;
  • srcscp (Source SCP): indicates the FQDN of the Source SCP, the format is "SCP-<SCP FQDN>"; this parameter shall only be included by an SCP, i.e. when the HTTP request or response message is originated or relayed by an SCP;
  • srcsepp (Source SEPP): indicates the FQDN of the Source SEPP, the format is "SEPP-<SEPP FQDN>"; this parameter shall only be included by a SEPP, i.e. when the HTTP request or response message is originated or relayed by a SEPP;
  • dstinst (Destination NF instance): indicates the Destination NF Instance ID, as defined in TS 29.510;
  • dstservinst (Destination NF service instance): indicates the Destination NF Service Instance ID, as defined in TS 29.510; if this parameter is present, dstinst shall also be present;
  • dstscp (Destination SCP): indicates the FQDN of the Destination SCP, the format is "SCP-<SCP FQDN>"; this parameter shall contain the next-hop SCP of the HTTP request or response message to be included by an SCP or SEPP or by clients/servers sending requests/responses to an SCP;
  • dstsepp (Destination SEPP): indicates the FQDN of the Destination SEPP, the format is "SEPP-<SEPP FQDN>"; this parameter shall be included by an SCP or by clients/servers sending requests/responses to a SEPP; it may also be included by a SEPP, based on operator's policy.
The header shall contain the source peer information, and should contain the destination peer information if available.
EXAMPLE:
3gpp-Sbi-NF-Peer-Info: srcinst=54804518-4191-46b3-955c-ac631f953ed8; dstinst=54804518-4191-4453-569c-ac631f74765cd
Up
5.2.3.2.22  3gpp-Sbi-Source-NF-Client-Credentials |R17|p. 41
The header contains client credentials assertion of a source NF instance (e.g. NWDAF, NWDAF containing AnLF) in a service request that is sent from an NF Service Consumer (e.g., DCCF, NWDAF containing MTLF) to an NF Service Producer (e.g. AMF, SMF, NWDAF containing MTLF). The purpose is to enable the authorization of NF service consumers for data access via DCCF or NWDAF containing MTLF (see clause 13.3.8.1 and Annex X of TS 33.501).
The encoding of the header follows the ABNF as defined in RFC 9110.
The client credentials assertion shall be a JSON Web Token (JWT) as defined in clause 5.2.3.2.11, with the sub claim identifying the source NF instance, i.e. corresponding to the sourceNfInstanceId claim specified in Table 6.3.5.2.4-1 of TS 29.510.
The ABNF of the JSON Web Token (JWT) is defined in clause 5.2.3.2.11.
Up
5.2.3.2.23  3gpp-Sbi-Scp-apiRoot |R19|p. 42
The header contains the apiRoot of an SCP in the target PLMN (see clause 4.4 of TS 29.501) in a request sent from a source PLMN to a target PLMN when using indirect communication with or without delegated discovery between different PLMNs with possible NF selection at target PLMN and the apiRoot of the SCP in the target PLMN is known by the source PLMN (see clause 6.10.12).
The encoding of the header follows the ABNF as defined in RFC 9110.
The ABNF of sbi-scheme, sbi-authority and prefix is defined in clause 5.2.3.2.4.
EXAMPLE:
3gpp-Sbi-Scp-apiRoot: https://scp12.operator.com/a/b/c
Up

Up   Top   ToC