Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 29.500  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   5…   5.2.3…   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.11…   A   B   C   D…

 

5.2.3.3  Optional to support custom headers |R16|p. 41

5.2.3.3.1  Generalp. 41
The 3GPP NF Services may support the HTTP custom headers specified in Table 5.2.3.3-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.3-1.
Name Reference Description
3gpp-Sbi-Sender-TimestampClause 5.2.3.3.2 This header may be used to indicate the date and time (with a millisecond granularity) at which an HTTP request or response is originated. This may be used e.g. for measuring signalling delays between different NF service instances.
3gpp-Sbi-Max-Rsp-TimeClause 5.2.3.3.3 This header may be used in a HTTP request to indicate the duration during which the HTTP client waits for a response. See clause 6.11.2.
3gpp-Sbi-Correlation-InfoClause 5.2.3.3.4 This header may be used to contain correlation information (e.g. UE identity), that may be used by an operator in various offline network management, performance analysis and troubleshooting tools/applications to identify messages (requests, responses, subscriptions, notifications) related to a particular subscriber. See clause 6.13.
3gpp-Sbi-Alternate-Chf-IdClause 5.2.3.3.5 This header may be used to indicate a primary or secondary CHF instance, e.g. when using indirect communication with delegated discovery. See clause 6.10.3.5.
3gpp-Sbi-Request-InfoClause 5.2.3.3.12 This header may be used to indicate additional information related to a HTTP request, e.g. if the request is involving a reselection towards an alternative NF, and/or if the request is a retransmission of a request towards an (alternative) NF.
This header may be used in a non-idempotent HTTP request message to include an idempotency key to enable the receiver to detect possible duplicated request messages. See clause 5.2.8.
This header may also be used in notification requests to indicate to the SCP a prefix of the Callback URI when binding procedures are not supported.
3gpp-Sbi-Notif-Accepted-EncodingClause 5.2.3.3.6 This header may be used to indicate the content encodings supported by the NF service Consumer when receiving notifications related to the subscriptions data conveyed by the HTTP request in which the header is included. See clause 6.9.2.1.
3gpp-Sbi-Consumer-InfoClause 5.2.3.3.7 This header is used in a service request to create a subscription to indicate the API version(s) and feature(s) of the corresponding NF service(s) for the subscribed event(s) and the accepted encodings for notifications of the subscribed event(s), which are supported by the NF consumer.
The NF consumer may include this header when subscribing to an intermediate NF for event(s) which may be detected and reported directly by a target NF, e.g. subscribe to Location Reporting event at AMF via UDM with AMF directly reporting the notifications to the NF consumer. See clause 6.2.2.
The NF service consumer may include this header when providing a Callback URI when the authority part of the Callback URI is shared by several NF service consumer instances. See clause 6.12.1 for the usage of this parameter. The NF service consumer may also include this header when providing a Callback URI including a prefix, for use during NF service consumer reselection, when binding procedures are not supported.
3gpp-Sbi-Response-InfoClause 5.2.3.3.8 This header may be used to provide additional information related to an HTTP response, e.g. in a 4xx or 5xx response sent:
  • by an SCP to indicate whether it attempted to retransmit the request to alternative HTTP server instances (see clause 6.10.8.1); or
  • by an alternative HTTP server instance to indicate whether the resource/context has been transferred to the instance sending the response, or by an HTTP server instance to indicate that the failed request shall not be retried (see clause 6.10.3.4, 6.10.5.1 and 6.10.8.1).
3gpp-Sbi-Selection-InfoClause 5.2.3.3.10 This header may be included in a HTTP request message for indirect communication and may be used by the SCP when performing the (re)selection of the target NF.
See clauses 6.10.3.2 and 6.10.5.1.
3gpp-Sbi-Interplmn-PurposeClause 5.2.3.3.11 This header is used in HTTP request to indicate the intended purpose for inter-PLMN signaling.
The HTTP client may include this header in HTTP request when the target NF is in a different PLMN, and if included shall set the intended purpose of the HTTP request.
SEPP shall evaluate the contents of this header against the local policy and continue or reject the request if received. (see clause 6.14.3)
3gpp-Sbi-Retry-InfoClause 5.2.3.3.13 This header may be included in a HTTP request message for indirect communication to indicate that the request shall only be sent once and shall not be retried.
3gpp-Sbi-Other-Access-ScopesClause 5.2.3.3.14 This header may be included in a service request for Indirect communication with delegated discovery to indicate other access scopes that are desired to be obtained for the access token, in addition to the scopes indicated in the 3gpp-Sbi-Access-Scope, that are not required for the service request itself but that may be required for further service requests. See clauses 5.2.3.3.14 and 6.10.11.
Up
5.2.3.3.2  3gpp-Sbi-Sender-Timestampp. 44
The header contains the date and time (with a millisecond granularity) at which an HTTP request or response is originated.
The encoding of the header follows the ABNF as defined in RFC 9110.
day-name, date1, time-of-day shall comply with the definition in Section 5.6.7 of RFC 9110.
When a 3gpp-Sbi-Sender-Timestamp header field is generated, the sender should generate its field value as the best available approximation of the date and time of message generation.
EXAMPLE:
3gpp-Sbi-Sender-Timestamp: Sun, 04 Aug 2019 08:49:37.845 GMT
Up
5.2.3.3.3  3gpp-Sbi-Max-Rsp-Timep. 44
The header indicates the duration, expressed in milliseconds since the request was originated, during which the HTTP client waits for a response. See clause 6.11.2.
The encoding of the header follows the ABNF as defined in RFC 9110.
EXAMPLE:
3gpp-Sbi-Max-Rsp-Time: 10000
Up
5.2.3.3.4  3gpp-Sbi-Correlation-Info |R17|p. 44
The header contains correlation information e.g. UE identifier related to the HTTP request or response.
The encoding of the header follows the ABNF as defined in RFC 9110.
The format of cvalue shall comply with the data type description provided in Table 5.2.3.3.4-1.
ctype Description
imsi VarUeId format defined in Table 5.2.2-1 of TS 29.571 for IMSI and starting after the string "imsi-"
impi imsUeId format defined in Table 6.1.3.2.2-1 of TS 29.562 for IMPI and starting after the string "impi-"
suci SupiOrSuci format defined in Table 5.3.2-1 of TS 29.571 for SUCI and starting after the string "suci-"
nai VarUeId format defined in Table 5.2.2-1 of TS 29.571 for NAI and starting after the string "nai-"
gci VarUeId format defined in Table 5.2.2-1 of TS 29.571 for GCI and starting after the string "gci-"
gli VarUeId format defined in Table 5.2.2-1 of TS 29.571 for GLI and starting after the string "gli-"
impu imsUeId format defined in Table 6.1.3.2.2-1 of TS 29.562 for IMPU and starting after the string "impu-". Depending on whether the IMPU contains a SIP URI or a TEL URI, the corresponding pattern from the definition of imsUeId in Table 6.1.3.2.2-1 of TS 29.562 shall be used.
msisdn VarUeId format defined in Table 5.2.2-1 of TS 29.571 for MSISDN and starting after the string "msisdn-"
extid VarUeId format defined in Table 5.2.2-1 of TS 29.571 for External Identifier and starting after the string "extid-"
imei Pei format defined in Table 5.3.2-1 of TS 29.571 for IMEI and starting after the string "imei-"
imeisv Pei format defined in Table 5.3.2-1 of TS 29.571 for IMEISV and starting after the string "imeisv-"
mac Pei format defined in Table 5.3.2-1 of TS 29.571 for MAC address and starting after the string "mac-"
eui Pei format defined in Table 5.3.2-1 of TS 29.571 for IEEE Extended Unique Identifier (EUI-64) and starting after the string "eui-"
EXAMPLE 1:
When UE identifier used is SUPI and SUPI type is an IMSI:
3gpp-Sbi-Correlation-Info: imsi-345012123123123
EXAMPLE 2:
When UE identifier used is PEI and PEI type is an IMEISV:
3gpp-Sbi-Correlation-Info: imeisv-3550121231231230
EXAMPLE 3:
When UE identifier used is PEI and PEI type is a MAC address:
3gpp-Sbi-Correlation-Info: mac-00-00-5E-00-53-00
EXAMPLE 4:
When UE identifier used is GPSI and GPSI type is an MSISDN:
3gpp-Sbi-Correlation-Info: msisdn-1234567890
EXAMPLE 5:
When UE identifier used is GPSI and GPSI type is an External Identifier:
3gpp-Sbi-Correlation-Info: extid-123456789@domain.com
EXAMPLE 6:
When UE identifiers used are SUPI and GPSI where SUPI type is an IMSI and GPSI type is an MSISDN:
3gpp-Sbi-Correlation-Info: imsi-345012123123123; msisdn-1234567890
Up
5.2.3.3.5  3gpp-Sbi-Alternate-Chf-Idp. 46
The header indicates a primary or a secondary CHF Instance ID. See clause 6.10.3.5.
The encoding of the header follows the ABNF as defined in RFC 9110.
Parameter "nfinst" shall indicate an NF Instance ID, as defined in clause 5.2.2.2.2 in TS 29.510; the ABNF is defined in clause 5.2.3.2.8.
EXAMPLE 1:
Service response from a primary CHF instance signalling a secondary CHF instance Id:
3gpp-Sbi-Alternate-Chf-Id: nfinst=54804518-4191-46b3-955c-ac631f953ed8; secondary
EXAMPLE 2:
Service response from a secondary CHF instance signalling a primary CHF instance Id:
3gpp-Sbi-Alternate-Chf-Id: nfinst=54804518-4191-46b3-955c-ac631f953ed8; primary
Up
5.2.3.3.6  3gpp-Sbi-Notif-Accepted-Encoding |R17|p. 46
The header indicates the content encodings supported when receiving notifications related to the subscriptions data conveyed by the HTTP request in which the header is included.
This header shall be compliant with Accept-Encoding header defined in Section 12.5.3 of RFC 9110.
Example:
3gpp-Sbi-Notif-Accepted-Encoding: gzip;q=1.0, identity;q=0.5, *;q=0
5.2.3.3.7  3gpp-Sbi-Consumer-Info |R17|p. 46
This header contains a comma-delimited list of NF service consumer information from an HTTP client (as NF service consumer).
The encoding of the header follows the ABNF as defined in RFC 9110.
"service" (Mandatory parameter): Supported Service parameter indicates the name of a service, as defined in TS 29.510, which is supported by the sender as NF service consumer.
"apiversion" (Mandatory parameter): Supported Versions parameter indicates the major version(s) of the service API that are supported by the sender as NF service consumer.
"supportedfeatures" (Optional parameter): Supported Features parameter carries a string containing a bitmask in hexadecimal representation, as specified for SupportedFeatures data type in TS 29.571, to indicate the feature(s) of the service API that are supported by the sender as NF service consumer.
"acceptencoding" (Optional parameter): Accept Encoding carries a string indicating the accepted content encodings supported by the sender as NF service consumer, when receiving notifications defined by the service. In the ABNF definition, "codings" and "weight" are defined in Section 12.5.3 of RFC 9110 and Section 12.4.2 of RFC 9110.
"intraPlmnCallbackRoot", "interPlmnCallbackRoot" (Optional parameters): intra plmn callback root and inter plmn callback root supported by the sender as NF service consumer, for the indicated service.
"callback-uri-prefix" (Optional parameter): The NF service consumer may include this parameter when providing a Callback URI when the authority part of the Callback URI is shared by several NF service consumer instances. The NF service consumer may also include this header when providing a Callback URI including a prefix, for use during NF service consumer reselection, when binding procedures are not supported. 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. See clause 6.12.1 for the usage of this parameter
EXAMPLE 1:
The NF consumer supports Namf_EventExposure OpenAPI "v1" without any optional feature:
3gpp-Sbi-Consumer-Info: service=namf-evts; apiversion=(1)
EXAMPLE 2:
The NF consumer supports Nsmf_EventExposure OpenAPI "v1" and "v2" with optional feature number 1 and accepted encoding "gzip":
3gpp-Sbi-Consumer-Info: service=nsmf-event-exposure; apiversion=(1 2); supportedfeatures=01; acceptencoding="gzip; q=1.0, *;q=0.5"
EXAMPLE 3:
The NF consumer supports both Namf_EventExposure OpenAPI "v1" and Nsmf_EventExposure OpenAPI "v2":
3gpp-Sbi-Consumer-Info: service=namf-evts; apiversion=(1), service=nsmf-event-exposure; apiversion=(2)
EXAMPLE 4:
An AMF service instance supports Nsmf_PDUSession OpenAPI "v1", provides the callback URI https://amf45.operator.com/servinst123/pdusession, whereby the authority is shared by more than one AMF service instance, while the prefix "/servinst123" uniquely identifies a specific AMF service instance:
3gpp-Sbi-Consumer-Info: service=nsmf-pdusession; apiversion=(1); callback-uri-prefix="/servinst123"
EXAMPLE 5:
The NF consumer supports Namf_EventExposure OpenAPI "v1" and sends intra PLMN callback root "https://operator.com" and inter PLMN callback root "https://5gc.mnc012.mcc345.3gppnetwork.org" in the header:
3gpp-Sbi-Consumer-Info: service=namf-evts; apiversion=(1); intraPlmnCallbackRoot="https://operator.com"; interPlmnCallbackRoot="https://5gc.mnc012.mcc345.3gppnetwork.org"
Up
5.2.3.3.8  3gpp-Sbi-Response-Info |R17|p. 48
The header contains a list of additional information related to an HTTP response. It may be included e.g. in a 4xx or 5xx response sent:
  • by an SCP to indicate whether it attempted to retransmit the request to alternative HTTP server instances; or
  • by an alternative HTTP server instance to indicate whether the corresponding resource or context has been transferred to the alternative HTTP server instance, or by an HTTP server instance to indicate that the failed request shall not be retried.
The encoding of the header follows the ABNF as defined in RFC 9110.
The following parameters are defined:
  • "request-retransmitted": this parameter indicates, in an error response, whether the SCP attempted to (re)transmit the request to alternative HTTP server instances. When present, it shall be set to "true" if so, and to "false" otherwise. See clause 6.10.8.1.
  • "nfinst", "nfset", "nfservinst", "nfserviceset": one or more of these parameters may be present in an error response, when the request-retransmitted is set to "true". When present, it shall indicate the NF Instances, NF Sets, NF Service Instances or NF Service Sets that were attempted to serve the request. See clause 6.10.8.1. The value of the nfinst, nfset, nfservinst and nfserviceset parameters shall be encoded as defined for the corresponding parameters in clause 5.2.3.2.5.
  • "context-transferred": this parameter indicates, in an error response, whether the corresponding resource or context has been transferred to the HTTP server instance sending the response. When present, it shall be set to "true" if the request has been transferred, i.e. the subsequent requests towards the resource or context shall be sent to the HTTP server instance sending the response, and to "false" otherwise.
  • "no-retry": this parameter indicates, in an error response, whether the failed request can be retried at other alternative HTTP server instance or not. When present, it shall be set to "true" if the failed request shall not be retried at other alternative NF instances, and to "false" otherwise.
EXAMPLE 1:
3gpp-Sbi-Response-Info: request-retransmitted=true
EXAMPLE 2:
3gpp-Sbi-Response-Info: request-retransmitted=true; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfinst=54804518-4191-46b3-955c-ac631f953456; nfinst=54804518-4191-46b3-955c-ac631f953780
EXAMPLE 3:
3gpp-Sbi-Response-Info: context-transferred=false; no-retry=true
Up
5.2.3.3.9Void
5.2.3.3.10  3gpp-Sbi-Selection-Info |R17|p. 49
The header contains a comma-delimited list of additional (re)selection information for an HTTP request message. It may be included by a NF service consumer or a NF service producer in a HTTP request message for indirect communication. If the header is received by the SCP and the SCP supports the header, the SCP shall:
  • avoid forwarding the request message to the target NF as indicated in the 3gpp-Sbi-Target-apiRoot (if present in the request) or the request URI (otherwise) if reselection is set "true", i.e., the SCP shall perform a reselection; and
  • use the selection-criteria included in this header together with 3gpp-Sbi-Routing-Binding or 3gpp-Sbi-Discovery-* headers whichever available, when the SCP performs the (re)selection of the target NF.
The encoding of the header follows the ABNF as defined in RFC 9110.
  • reselection: it is a boolean and set to "false" by default. When it is set to "true", it indicates that the SCP shall perform a reselection, i.e., the SCP shall not forward the request message towards the target as indicated in the target uri or in the 3gpp-Sbi-Target-ApiRoot. When this parameter occurs multiple times in the comma-delimited list, all parameters shall have the same value.
  • not-select-nfservinst (the NF service instance(s) that shall not be selected): indicates an NF Service Instance ID. This parameter shall be present if the sender of the request message knows that the target NF or other potential target NF service instance that shall not be selected, e.g., when the target NF service instance is overloaded, or some NF service instances are out of service. (see also clause 6.4.3.4.5.2.1) When this parameter is present, one of not-select-nfserviceset or not-select-nfinst shall be present to enable the SCP to identify the nfservinst.
  • not-select-nfserviceset (the NF service instance pertaining to a NF service set in a NF instance that shall not be selected): indicates an NF Service Set ID as defined in clause 28.13 of TS 23.003. This parameter shall be present if the sender of the request message knows that all NF service instances in the NF service set shall not be selected, e.g., when target NF service instance has indicated its overload and the overload scope is NF service set level, in this case, not-select-nfservinst shall not be present. (see also clause 6.4.3.4.5.2.1)
  • not-select-nfinst (the NF instance(s) that shall not be selected): indicates an NF Instance ID, as defined in clause 5.2.2.2.2 of TS 29.510. This parameter shall be present if the sender of the request message knows the target NF instance or other potential target NF instance that shall not be selected, e.g., when the target NF instance is overloaded, or other NF instance(s) is out of service, in this case, not-select-nfservinst shall not be present. (see also clause 6.4.3.4.5.2.1)
  • not-select-nfset (the NF set that shall not be selected): indicates an NF Set ID, as defined in clause 28.12 in TS 23.003. This parameter may be present, e.g., during an initial resource creation with Delegated Discovery (Indirect Communication Mode D), the NF service consumer knows certain NF set shall not be selected.
EXAMPLE 1:
The SCP may or may not perform reselection, but when doing reselection, it shall not select NF instance as identified by 87654321-4191-46b3-955c-ac631f953ed8.
3gpp-Sbi-Selection-Info: not-select-nfinst=87654321-4191-46b3-955c-ac631f953ed8
EXAMPLE 2:
The SCP may or may not perform reselection, but when doing reselection, it shall not select NF service set in the NF instance (as identified in nfi87654321-4191-46b3-955c-ac631f953ed8).
3gpp-Sbi-Selection-Info: not-select-nfserviceset=setxyz.snnsmf-pdusession.nfi87654321-4191-46b3-955c-ac631f953ed8.5gc.mnc012.mcc345
EXAMPLE 3:
The SCP shall perform reselection; and when doing reselection, it shall not select NF instance as identified by 87654321-4191-46b3-955c-ac631f953ed8.
3gpp-Sbi-Selection-Info: reselection=true; not-select-nfinst=87654321-4191-46b3-955c-ac631f953ed8
EXAMPLE 4:
The SCP shall perform reselection; and when doing reselection, the SCP shall not select NF service instance xyz1 and xyz2 in the NF instance identified by 87654321-4191-46b3-955c-ac631f953ed8, and NF service instance abc1 and abc2 in the NF instance identified by 12345678-4191-46b3-955c-ac631f953ed8.
3gpp-Sbi-Selection-Info: reselection=true; not-select-nfservinst=xyz1; not-select-nfservinst=xyz2; not-select-nfinst=87654321-4191-46b3-955c-ac631f953ed8, reselection=true; not-select-nfservinst=abc1; not-select-nfservinst=abc2; not-select-nfinst=12345678-4191-46b3-955c-ac631f953ed8
Up
5.2.3.3.11  3gpp-Sbi-Interplmn-Purpose |R17|p. 50
The header contains the intended purpose for inter-PLMN signaling. See clauses 6.14.
The encoding of the header follows the ABNF as defined in RFC 9110.
  • N32Purpose: The parameter for N32Purpose indicates the intended purpose of inter-PLMN signaling, and values specified in clause 6.1.5.3.9 of TS 29.573 are used.
EXAMPLE:
3gpp-Sbi-Interplmn-Purpose: ROAMING: usecaseA
Up
5.2.3.3.12  3gpp-Sbi-Request-Info |R17|p. 50
The header contains a list of additional information related to a HTTP request which may be included by a NF or a SCP, to indicate e.g.:
  • whether the HTTP request message is involving a reselection of an alternative NF;
  • whether the HTTP request message is a retransmission of the message, i.e. the request message has been sent but being rejected with a temporary failure or timeout;
When the header is included by a NF acting as a HTTP client, an idempotency-key may be included for a non-idempotent request to enable the receiver to detect possible duplicated request messages as specified in clause 5.2.8.
The receiving NF may use the header, e.g. to determine whether to accept the request.
The encoding of the header follows the ABNF as defined in RFC 9110.
The following parameters are defined:
  • "reason": indicates the reason for which the NF resends or redirects the HTTP request message. This may take one of the following values:
    • "unreachable": indicates that the HTTP request is redirected to an alternative NF due to the request URI (e.g. the resource URI or Notification/callback URI) is not reachable;
    • "overloaded": indicates that the HTTP request is redirected to an alternative NF as result of overload control enforcement, by doing redirection towards an alternative NF (see clause 6.4.3.5.1);
    • "3xx-redirect": indicates that the HTTP request is redirected to an alternative NF as result of receiving a 3xx status code.
    • "temporary-rejection-cause": indicates the HTTP request is retransmitted towards the same or alternative NF due to a temporary rejection.
  • "receivedrejectioncause": indicates a temporary rejection application cause received from the NF or SCP (for last attempt) as defined in clause 5.2.7.2, when the "retrans" parameter is set to "true" and the reason is set to "temporary-rejection-cause". The cause data type is specified in clause 5.2.4.1 of TS 29.571.
  • "retrans": it is a boolean and shall be set to "true" to indicate that the request message has been retransmitted e.g. when the request didn't get any response or get a temporary failure cause, otherwise the "retrans" shall not be present.
  • "redirect": it is a boolean and shall be set to "true" to indicate that the request message has been redirected to an alternative NF.
  • "idempotency-key": it is a string and may be encoded using Universally Unique Identifier (UUID), as described in RFC 4122, to uniquely identify a request message (to be received) in the target NF. See clause 5.2.8.
  • "callback-uri-prefix": path-absolute as specified RFC 3986 (i.e. the first path segment(s) after the authority) which is part of the Callback URI. The ABNF is defined in clause 5.2.3.3.7.
EXAMPLE 1:
For a request retransmitted to an alternative NF due to the rejection by the original target NF with a temporary rejection cause:
3gpp-Sbi-Request-Info: retrans=true; redirect=true; reason=temporary-rejection-cause; receivedrejectioncause=INSUFFICIENT_RESOURCES
EXAMPLE 2:
For a request sent towards an alternative NF due to the original target NF not reachable:
3gpp-Sbi-Request-Info: redirect=true; reason=unreachable
EXAMPLE 3:
For a non-idempotent request:
3gpp-Sbi-Request-Info: idempotency-key=54804518-4191-46b3-955c-ac631f953ed8
EXAMPLE 4:
For a notification request with a callback URI containing the prefix "/abc":
3gpp-Sbi-Request-Info: callback-uri-prefix="/abc"
Up
5.2.3.3.13  3gpp-Sbi-Retry-Info |R18|p. 52
The header may be included in a HTTP request message for indirect communication to indicate that the request shall only be sent once and shall not be retried.
The encoding of the header follows the ABNF as defined in RFC 9110.
The following value is defined:
  • "no-retries" indicates that the request shall only be sent once and shall not be retried to the same nor alternative endpoints of the same target NF service instance nor towards another target NF service instance once the request has been forwarded once.
EXAMPLE 1:
NF service consumer instructing the SCP to not perform any retries:
3gpp-Sbi-Retry-Info: no-retries
EXAMPLE 2:
NF service consumer instructing the SCP to perform an NF reselection, not reselecting the NF instance identified by 87654321-4191-46b3-955c-ac631f953ed8, and to not perform any retries then if no successful response is received from the reselected NF instance.
3gpp-Sbi-Selection-Info: reselection=true; not-select-nfinst=87654321-4191-46b3-955c-ac631f953ed8
3gpp-Sbi-Retry-Info: no-retries
Up
5.2.3.3.14  3gpp-Sbi-Other-Access-Scopes |R18|p. 52
The header indicates other access scopes that are desired to be obtained for the access token, in addition to the scopes indicated in the 3gpp-Sbi-Access-Scope, that are not required for the service request itself but that may be required for further service requests. It enables the SCP to request access tokens that can be reused in further service requests, 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.
The following value is defined:
Scope-token shall consist of a list of space-delimited, case-sensitive strings, containing one or more NF service name(s) of the NF service producer and/or additional resource/operation-level scope(s) for these API(s) that are not already contained in the 3gpp-Sbi-Access-Scope header. The ABNF is defined in clause 5.2.3.2.16.
NQCHAR is defined in Appendix A of RFC 6749.
EXAMPLE 1:
3gpp-Sbi-Access-Scope: nudm-uecm nudm-uecm:amf-registration:write
3gpp-Sbi-Other-Access-Scopes: nudm-sdm nudm-sdm:am-data:read nudm-sdm:smf-select-data:read
EXAMPLE 2:
3gpp-Sbi-Access-Scope: namf-comm namf-comm:n1-n2-messages
3gpp-Sbi-Other-Access-Scopes: namf-comm:ue-contexts:assign-ebi
Up

Up   Top   ToC