6.2 Nnrf_NFDiscovery Service API

29.5103GPP5G SystemNetwork function repository servicesRelease 18Stage 3TS

6.2.1 API URI

The API URI of the Nnrf_NFDiscovery API shall be:

{apiRoot}/<apiName>/<apiVersion>

The request URIs used in HTTP requests from the NF service consumer towards the NF service producer shall have the Resource URI structure defined in clause 4.4.1 of 3GPP TS 29.501 [5], i.e.:

{apiRoot}/<apiName>/<apiVersion>/<apiSpecificResourceUriPart>

where:

– the {apiRoot} shall be set as defined in clause 4.4.1 of 3GPP TS 29.501 [5];

– the <apiName> shall be set to "nnrf-disc";

– the <apiVersion> shall be set to "v1" for the current version of this specification;

– the <apiSpecificResourceUriPart> shall be set as described in clause 6.2.3.

6.2.2 Usage of HTTP

6.2.2.1 General

HTTP/2, as defined in IETF RFC 7540 [9], shall be used as specified in clause 5 of 3GPP TS 29.500 [4].

HTTP/2 shall be transported as specified in clause 5.3 of 3GPP TS 29.500 [4].

HTTP messages and bodies for the Nnrf_NFDiscovery service shall comply with the OpenAPI [10] specification contained in Annex A.

6.2.2.2 HTTP standard headers

6.2.2.2.1 General

The mandatory standard HTTP headers as specified in clause 5.2.2.2 of 3GPP TS 29.500 [4] shall be supported.

6.2.2.2.2 Content type

The following content types shall be supported:

– The JSON format (IETF RFC 8259 [22]). The use of the JSON format shall be signalled by the content type "application/json". See also clause 5.4 of 3GPP TS 29.500 [4].

– The Problem Details JSON Object (IETF RFC 7807 [11]). The use of the Problem Details JSON object in a HTTP response body shall be signalled by the content type "application/problem+json".

6.2.2.2.3 Cache-Control

A "Cache-Control" header should be included in HTTP responses, as described in IETF RFC 7234 [20], clause 5.2. It shall contain a "max-age" value, indicating the amount of time in seconds after which the received response is considered stale; this value shall be the same as the content of the "validityPeriod" element described in clause 6.2.6.2.2.

6.2.2.2.4 ETag

An "ETag" (entity-tag) header should be included in HTTP responses, as described in IETF RFC 7232 [19], clause 2.3. It shall contain a server-generated strong validator, that allows further matching of this value (included in subsequent client requests) with a given resource representation stored in the server or in a cache.

6.2.2.2.5 If-None-Match

An NF Service Consumer should issue conditional GET request towards NRF, by including an If-None-Match header in HTTP requests, as described in IETF RFC 7232 [19], clause 3.2, containing one or several entity tags received in previous responses for the same resource.

6.2.2.3 HTTP custom headers

6.2.2.3.1 General

In this release of this specification, no custom headers specific to the Nnrf_NFDiscovery service are defined. For 3GPP specific HTTP custom headers used across all service-based interfaces, see clause 5.2.3 of 3GPP TS 29.500 [4].

6.2.3 Resources

6.2.3.1 Overview

The structure of the Resource URIs of the NFDiscovery service is shown in figure 6.2.3.1-1.

Figure 6.2.3.1-1: Resource URI structure of the NFDiscovery API

Table 6.2.3.1-1 provides an overview of the resources and applicable HTTP methods.

Table 6.2.3.1-1: Resources and methods overview

Resource name

Resource URI

HTTP method or custom operation

Description

nf-instances

(Store)

/nf-instances

GET

Retrieve a collection of NF Instances according to certain filter criteria.

Stored Search (Document)

/searches/{searchId}

GET

Retrieve a collection of NF Instances, previously stored by NRF as a consequence of a prior search result.

Complete Stored Search (Document)

/searches/{searchId}/complete

GET

Retrieve a collection of NF Instances, previously stored by NRF as a consequence of a prior search result, without applying any client restriction on the number of instances (e.g. "limit" or "max-payload-size" query parameters).

SCP Domain Routing Information (Document)

/scp-domain-routing-info

GET

Retrieve the SCP Domain Routing Information.

SCP Domain Routing Info Subscriptions

(Collection)

/scp-domain-routing-info-subs

POST

Subscribe to SCP Domain Routing Information change.

Individual SCP Domain Routing Info Subscription

(Document)

/scp-domain-routing-info-subs/{subscriptionID}

DELETE

Unsubscribe to SCP Domain Routing Information change.

6.2.3.2 Resource: nf-instances (Store)

6.2.3.2.1 Description

This resource represents a collection of the different NF instances registered in the NRF.

This resource is modelled as the Store resource archetype (see clause C.3 of 3GPP TS 29.501 [5]).

6.2.3.2.2 Resource Definition

Resource URI: {apiRoot}/nnrf-disc/v1/nf-instances

This resource shall support the resource URI variables defined in table 6.2.3.2.2-1.

Table 6.2.3.2.2-1: Resource URI variables for this resource

Name

Data type

Definition

apiRoot

string

See clause 6.1.1

6.2.3.2.3 Resource Standard Methods

6.2.3.2.3.1 GET

This operation retrieves a list of NF Instances, and their offered services, currently registered in the NRF, satisfying a number of filter criteria, such as those NF Instances offering a certain service name, or those NF Instances of a given NF type (e.g., AMF).

Table 6.2.3.2.3.1-1: URI query parameters supported by the GET method on this resource

Name

Data type

P

Cardinality

Description

Applicability

target-nf-type

NFType

M

1

This IE shall contain the NF type of the target NF being discovered.

requester-nf-type

NFType

M

1

This IE shall contain the NF type of the Requester NF that is invoking the Nnrf_NFDiscovery service.

preferred-collocated-nf-types

array(CollocatedNfType)

O

1..N

The IE may be present to indicate desired collocated NF type(s) when the NF service consumer wants to discover candidate NFs matching the target NF Type that are preferentially collocated with other NF types. (NOTE 19)

Collocated-NF-Selection

requester-nf-instance-id

NfInstanceId

O

0..1

If included, this IE shall contain the NF instance id of the Requester NF.

Query-Params-Ext2

service-names

array(ServiceName)

O

1..N

If included, this IE shall contain an array of service names for which the NRF is queried to provide the list of NF profiles.

The NRF shall return the NF profiles that have at least one NF service matching the NF service names in this list.

The NF services returned by the NRF (inside the nfServices or nfServiceList attributes) in each matching NFProfile shall be those services whose service name matches one of the service names included in this list.

If not included, the NRF shall not filter based on service name.

This array shall contain unique items.

Example:

NF1 supports services: A, B, C

NF2 supports services: C, D, E

NF3 supports services: A, C, E

NF4 supports services: B, C, D

Consumer asks for service-names = [A, E]

NRF returns:

NF1 containing service A

NF2 containing service E

NF3 containing services A, E

NF4 is not returned

requester-nf-instance-fqdn

Fqdn

O

0..1

This IE may be present for an NF discovery request within the same PLMN as the NRF.

If included, this IE shall contain the FQDN of the Requester NF that is invoking the Nnrf_NFDiscovery service.

The NRF shall use this to return only those NF profiles that include at least one NF service containing an entry in the "allowedNfDomains" list (see clause 6.1.6.2.3) that matches the domain of the requester NF.

This IE shall be ignored by the NRF if it is received from a requester NF belonging to a different PLMN.

(NOTE 12)

target-plmn-list

array(PlmnId)

C

1..N

This IE shall be included when NF services in a different PLMN, or NF services of specific PLMN ID(s) in a same PLMN comprising multiple PLMN IDs, need to be discovered. When included, this IE shall contain the PLMN ID of the target NF. If more than one PLMN ID is included, NFs from any PLMN ID present in the list matches the query parameter.

This IE shall also be included in SNPN scenarios, when the entity owning the subscription, the Credentials Holder (see clause 5.30.2.9 in 3GPP TS 23.501 [2]) is a PLMN.

For inter-PLMN service discovery, at most 1 PLMN ID shall be included in the list; it shall be included in the service discovery from the NF in the source PLMN sent to the NRF in the same PLMN, while it may be absent in the service discovery request sent from the source NRF to the target NRF. In such case, if the NRF receives more than 1 PLMN ID, it shall only consider the first element of the array, and ignore the rest.

requester-plmn-list

array(PlmnId)

C

1..N

This IE shall be included when NF services in a different PLMN need to be discovered. It may be present when NF services in the same PLMN need to be discovered. When included, this IE shall contain the PLMN ID(s) of the requester NF. (NOTE 12)

requester-snpn-list

array(PlmnIdNid)

C

1..N

This IE shall be included when the Requester NF belongs to one or several SNPNs, and NF services of a specific SNPN need to be discovered. The SNPN scenarios include use cases when CH/DCS is using AAA-S or when CH/DCS is using AUSF/UDM, see clauses 5.30.2.9.2, 5.30.2.9.3 and 5.30.2.10.2.2 in 3GPP TS 23.501 [2]).

When present, this IE shall contain the SNPN ID(s) of the requester NF.

The NRF shall use this to return only those NF profiles of NF Instances allowing to be discovered from the SNPNs identified by this IE, according to the "allowedSnpns" list in the NF Profile and NF Service (see clauses 6.1.6.2.2 and 6.1.6.2.3).

Query-Params-Ext2

target-nf-instance-id

NfInstanceId

O

0..1

Identity of the NF instance being discovered.

target-nf-fqdn

Fqdn

O

0..1

FQDN of the target NF instance being discovered.

hnrf-uri

Uri

C

0..1

If included, this IE shall contain the API URI of the NFDiscovery Service (see clause 6.2.1) of the home NRF. It shall be included if the Requester NF has previously received such API URI to be used for service discovery (e.g., from the NSSF in the home PLMN as specified in clause 6.1.6.2.11 of 3GPP TS 29.531 [42]).

snssais

array(Snssai)

O

1..N

If included, this IE shall contain the list of S-NSSAIs that are served by the NF (Service) Instances being discovered. The NRF shall return those NF profiles/NF services of NF (Service) Instances that have at least one of the S-NSSAIs in this list. The S-NSSAIs included in the NF profiles/NF services of NF (Service) Instances returned by the NRF shall be an interclause of the S-NSSAIs requested and the S-NSSAIs supported by those NF (Service) Instances. (NOTE 10)

When the NF Profile of the NF Instances being discovered has defined the list of supported S-NSSAIs in the "perPlmnSnssaiList", the discovered NF Instances shall be those having any of the S-NSSAIs included in this "snssais" parameter in any of the PLMNs included in the "target-plmn-list" attribute, if present; if the "target-plmn-list" is not included, the NRF shall assume that the discovery request is for any of the PLMNs it supports.

requester-snssais

array(ExtSnssai)

O

1..N

If included, this IE shall contain the list of S-NSSAI of the requester NF. If this IE is included in a service discovery in a different PLMN, the requester NF shall provide S-NSSAI values of the target PLMN, that correspond to the S-NSSAI values of the requester NF.

The NRF shall use this to return only those NF profiles of NF Instances allowing to be discovered from at least one network slice identified by this IE, according to the "allowedNssais" list in the NF Profile and NF Service (see clause 6.1.6.2.2 and 6.1.6.2.3). (NOTE 12)

plmn-specific-snssai-list

array(PlmnSnssai)

O

1..N

If included, this IE shall contain the list of S-NSSAI that are served by the NF service being discovered for the corresponding PLMN provided. The NRF shall use this to identify the NF services that have registered their support for the S-NSSAIs for the corresponding PLMN given. The NRF shall return the NF profiles that have at least one S-NSSAI supported in any of the PLMNs provided in this list. The per PLMN list of S-NSSAIs included in the NF profile returned by the NRF shall be an interclause of the list requested and the list registered in the NF profile. (NOTE 10).

requester-plmn-specific-snssai-list

array(PlmnSnssai)

O

1..N

If included, this IE shall contain the list of S-NSSAI of the requester NF, for each of the PLMNs it supports. The NRF shall use this to return only those NF profiles of NF Instances allowing to be discovered from at least one network slice identified by this IE, according to the "allowedNssais" and "allowedPlmns" attributes in the NF Profile and NF Service (see clause 6.1.6.2.2 and 6.1.6.2.3). (NOTE 12)

Query-Params-Ext3

nsi-list

array(string)

O

1..N

If included, this IE shall contain the list of NSI IDs that are served by the services being discovered.

dnn

Dnn

O

0..1

If included, this IE shall contain the DNN for which NF services serving that DNN is discovered. DNN may be included if the target NF type is e.g. "BSF", "SMF", "PCF", "PCSCF", "UPF", "EASDF", "TSCTSF", "MB-UPF" or "MB-SMF".

The DNN shall contain the Network Identifier and it may additionally contain an Operator Identifier. (NOTE 11).

If the Snssai(s) are also included, the NF services serving the DNN shall be available in the network slice(s) identified by the Snssai(s).

ipv4-index

IpIndex

O

0..1

This IE may be included if the target NF type is "UPF" and the dnn IE is included.

When included, this IE shall indicate the IPv4 index that is supported by the candidate UPF.

Query-Upf-IpIndex

ipv6-index

IpIndex

O

0..1

This IE may be included if the target NF type is "UPF" and the dnn IE is included.

When included, this IE shall indicate the IPv6 index that is supported by the candidate UPF.

Query-Upf-IpIndex

smf-serving-area

string

O

0..1

If included, this IE shall contain the serving area of the SMF. It may be included if the target NF type is "UPF".

mbsmf-serving-area

string

O

0..1

If included, this IE shall contain the serving area of the MB-SMF. It may be included if the target NF type is "MB-UPF".

Query-MBS

tai

Tai

O

0..1

Tracking Area Identity. (NOTE 22).

amf-region-id

AmfRegionId

O

0..1

AMF Region Identity.

amf-set-id

AmfSetId

O

0..1

AMF Set Identity.

guami

Guami

O

0..1

Guami used to search for an appropriate AMF.

(NOTE 1)

supi

Supi

O

0..1

If included, this IE shall contain the SUPI of the requester UE to search for an appropriate NF. SUPI may be included if the target NF type is e.g. "PCF", "CHF", "AUSF", "BSF", "UDM", "TSCTSF", "NSSAAF" or "UDR".

ue-ipv4-address

Ipv4Addr

O

0..1

The IPv4 address of the UE for which a BSF or P-CSCF needs to be discovered.

ip-domain

string

O

0..1

The IPv4 address domain of the UE for which a BSF needs to be discovered.

ue-ipv6-prefix

Ipv6Prefix

O

0..1

The IPv6 prefix of the UE for which a BSF or P-CSCF needs to be discovered.

pgw-ind

boolean

O

0..1

When present, this IE indicates whether a combined SMF/PGW-C or a standalone SMF needs to be discovered.

true: A combined SMF/PGW-C is requested to be discovered;
false: A standalone SMF is requested to be discovered.
(See NOTE 2, NOTE 21)

preferred-pgw-ind

boolean

O

0..1

When present, this IE indicates whether combined PGW-C+SMF(s) or standalone SMF(s) are preferred.

true: Combined PGW-C+SMF(s) are preferred to be discovered;
false: Standalone SMF(s) are preferred to be discovered.
(See NOTE 2, NOTE 20, NOTE 21)

Query-SBIProtoc17

pgw

Fqdn

O

0..1

If included, this IE shall contain the PGW FQDN which is used by the AMF to find the combined SMF/PGW-C.

pgw-ip

IpAddr

O

0..1

If included, this IE shall contain the PGW IP Address used by the AMF to find the combined SMF/PGW-C.

Query-SBIProtoc17

gpsi

Gpsi

O

0..1

If included, this IE shall contain the GPSI of the requester UE to search for an appropriate NF. GPSI may be included if the target NF type is "CHF", "PCF", "BSF", "UDM", "TSCTSF" or "UDR".

external-group-identity

ExtGroupId

O

0..1

If included, this IE shall contain the external group identifier of the requester UE to search for an appropriate NF. This may be included if the target NF type is "UDM", "UDR", "HSS" or "TSCTSF".

pfd-data

PfdData

O

0..1

When present, this IE shall contain the application identifiers and/or application function identifiers in PFD management. This may be included if the target NF type is "NEF".

The NRF shall return those NEF instances which can provide the PFDs for at least one of the provided application identifiers, or for at least one of the provided application function identifiers.

Query-Params-Ext2

data-set

DataSetId

O

0..1

Indicates the data set to be supported by the NF to be discovered. May be included if the target NF type is "UDR".

routing-indicator

string

O

0..1

Routing Indicator information that allows to route network signalling with SUCI (see 3GPP TS 23.003 [12]) to an AUSF, AAnF and UDM instance capable to serve the subscriber. May be included if the target NF type is "AUSF", "AANF" or "UDM".

Pattern: "^[0-9]{1,4}$"

group-id-list

array(NfGroupId)

O

1..N

Identity of the group(s) of the NFs of the target NF type to be discovered. May be included if the target NF type is "UDR", "UDM", "HSS", "PCF", "AUSF", "BSF" or "CHF".

dnai-list

array(Dnai)

O

1..N

If included, this IE shall contain the Data network access identifiers. It may be included if the target NF type is "UPF", "SMF", "EASDF" or "NEF".

upf-iwk-eps-ind

boolean

O

0..1

When present, this IE indicates whether a UPF supporting interworking with EPS needs to be discovered.

true: A UPF supporting interworking with EPS is requested to be discovered;
false: A UPF not supporting interworking with EPS is requested to be discovered.
(NOTE 3)

chf-supported-plmn

PlmnId

O

0..1

If included, this IE shall contain the PLMN ID that a CHF supports (i.e., in the PlmnRange of ChfInfo attribute in the NFProfile). This IE may be included when the target NF type is "CHF".

When an SMF discovers CHF(s) for a PDU session, the SMF shall set the value of this IE as specified in clause 5.1.9.2 of 3GPP TS 32.255 [46].

preferred-locality

string

O

0..1

Preferred target NF location (e.g. geographic location, data center).

When present, the NRF shall prefer NF profiles with a locality attribute that matches the preferred-locality.

The NRF may return additional NFs in the response not matching the preferred target NF location, e.g. if no NF profile is found matching the preferred target NF location.

The NRF should set a lower priority for any additional NFs on the response not matching the preferred target NF location than those matching the preferred target NF location. In addition, based on operator’s policy, the NRF may set different priorities based on the localities of the NFs.

(NOTE 6, NOTE 25)

ext-preferred-locality

map(array(LocalityDescription))

O

1..N(1..M)

Preferred target NF location (e.g. geographic location, data center).

The key of the map shall represent the relative priority, for the requester, of each locality description among the list of locality descriptions in this query parameter, encoded as "1" (highest priority"), "2", "3", …, "n" (lowest priority).

When present, the NRF shall prefer NF profiles with an extLocality attribute that matches at least one LocalityDescription of the ext-preferred-locality, with the highest possible priority.

The NRF may return additional NFs in the response not matching the preferred target NF location, e.g. if no NF profile is found matching the preferred target NF location.

The NRF should set the priority of each NF profile returned in the response based on the priority associated with the matching locality description of the ext-preferred-locality. The NRF should set a lower priority for any additional NFs in the response not matching the preferred target NF location than those matching the preferred target NF location. In addition, based on operator’s policy, the NRF may set different priorities based on the localities of the NFs.

(NOTE 6)

Example 1 indicating a preference to discover an NFp in the data center "dc-123" as a first choice, otherwise in the city of Los Angeles or San Diego as a second choice, otherwise in the state of California as a third choice.

{

"1": [{localityType: DATA_CENTER, localityValue: "dc-123"}],

"2": [{localityType: CITY, localityValue: "Los Angeles"},
{localityType: CITY, localityValue: "San Diego"}],

"3": [{localityType: STATE, localityValue: "California"}]

}

Example 2 indicating a preference to discover an NFp in the data center "dc-123" as a first choice, otherwise in the data center "dc-456" or "dc-789" as a second choice.

{

"1": [{localityType: DATA_CENTER, localityValue: "dc-123"}],

"2": [{localityType: DATA_CENTER, localityValue: "dc-456"},

{localityType: {DATA_CENTER, localityValue: "dc-789"}]

}

Example 3 indicating a preference to discover an NFp in the city of Bath and in the state of Virginia as a first choice, otherwise in the state of Virginia as a second choice.

{

"1": [{localityType: CITY, localityValue: "Bath",

addlLocDescrItems: [{localityType: STATE, localityValue:

"Virginia"}]],

"2": [{localityType: STATE, localityValue: "Virginia"}

}

(NOTE 25)

Query-SBIProtoc18

access-type

AccessType

C

0..1

If included, this IE shall contain the Access type which is required to be supported by the target Network Function (i.e. SMF).

supported-features

SupportedFeatures

O

0..1

List of features required to be supported by the target Network Function.

This IE may be present only if the service-names attribute is present and if it contains a single service-name. It shall be ignored by the NRF otherwise.

(NOTE 4)

required-features

array(SupportedFeatures)

O

1..N

List of features required to be supported by the target Network Function, as defined by the supportedFeatures attribute in NFService (see clauses 6.1.6.2.3 and 6.2.6.2.4).

This IE may be present only if the service-names attribute is present.

When present, the required-features attribute shall contain as many entries as the number of entries in the service-names attribute. The nth entry in the required-features attribute shall correspond to the nth entry in the service-names attribute. An entry corresponding to a service for which no specific feature is required shall be encoded as "0".

(NOTE 24)

Query-Params-Ext1

complex-query

ComplexQuery

O

0..1

This query parameter is used to override the default logical relationship of query parameters.

Complex-Query

limit

integer

O

0..1

Maximum number of NFProfiles to be returned in the response.

Minimum: 1

Query-Params-Ext1

max-payload-size

integer

O

0..1

Maximum payload size (before compression, if any) of the response, expressed in kilo octets.

When present, the NRF shall limit the number of NF profiles returned in the response such as to not exceed the maximum payload size indicated in the request.

Default: 124. Maximum: 2000 (i.e. 2 Mo).

Query-Params-Ext1

max-payload-size-ext

integer

O

0..1

Maximum payload size (before compression, if any) of the response, expressed in kilo octets.

When present, the NRF shall limit the number of NF profiles returned in the response such as to not exceed the maximum payload size indicated in the request.

This query parameter is used when the consumer supports payload size bigger than 2 million octets.

Default: 124

Query-Params-Ext2

pdu-session-types

array(PduSessionType)

O

1..N

List of the PDU session type (s) requested to be supported by the target Network Function (i.e UPF).

Query-Params-Ext1

event-id-list

array(EventId)

O

1..N

If present, this attribute shall contain the list of events requested to be supported by the Nnwdaf AnalyticsInfo Service, the NRF shall return NF which support all the requested events.

Query-Param-Analytics

nwdaf-event-list

array(NwdafEvent)

O

1..N

If present, this attribute shall contain the list of events requested to be supported by the Nnwdaf_EventsSubscription service, the NRF shall return NF which support all the requested events.

Query-Param-Analytics

atsss-capability

AtsssCapability

O

0..1

When present, this IE indicates the ATSSS capability of the target UPF needs to be supported.

MAPDU

upf-ue-ip-addr-ind

boolean

O

0..1

When present, this IE indicates whether a UPF supporting allocating UE IP addresses/prefixes needs to be discovered.

true: a UPF supporting UE IP addresses/prefixes allocation is requested to be discovered;
false: a UPF not supporting UE IP addresses/prefixes allocation is requested to be discovered.

Query-Params-Ext2

client-type

ExternalClientType

O

0..1

When present, this IE indicates that NF(s) dedicatedly serving the specified Client Type needs to be discovered. This IE may be included when target NF Type is "LMF" and "GMLC".

If no NF profile is found dedicately serving the requested client type, the NRF may return NF(s) not dedicatedly serving the request client type in the response.

Query-Params-Ext2

lmf-id

LMFIdentification

O

0..1

When present, this IE shall contain LMF identification to be discovered.This may be included if the target NF type is "LMF".

Query-Params-Ext2

an-node-type

AnNodeType

O

0..1

If included, this IE shall contain the AN Node type which is required to be supported by the target Network Function (i.e. LMF).

Query-Params-Ext2

rat-type

RatType

O

0..1

If included, this IE shall contain the RAT type which is required to be supported by the target Network Function (i.e. LMF).

Query-Params-Ext2

target-snpn

PlmnIdNid

C

0..1

This IE shall be included when NF services of a specific SNPN need to be discovered. When included, this IE shall contain the PLMN ID and NID of the target NF.

This IE shall also be included in SNPN scenarios, when the entity owning the subscription, the Credentials Holder (see clause 5.30.2.9 in 3GPP TS 23.501 [2]) is an SNPN.

Query-Params-Ext2

af-ee-data

AfEventExposureData

O

0..1

When present, this shall contain the application events, and optionally application function identifiers, application identifiers of the AF(s). This may be included if the target NF type is "NEF".

Query-Params-Ext2

w-agf-info

WAgfInfo

O

0..1

If included, this IE shall contain the W-AGF identifiers of N3 terminations which is received by the SMF to find the combined W-AGF/UPF.

Query-Params-Ext2

tngf-info

TngfInfo

O

0..1

If included, this IE shall contain the TNGF identifiers of N3 terminations which is received by the SMF to find the combined TNGF/UPF.

Query-Params-Ext2

twif-info

TwifInfo

O

0..1

If included, this IE shall contain the TWIF identifiers of N3 terminations which is received by the SMF to find the combined TWIF/UPF.

Query-Params-Ext2

target-nf-set-id

NfSetId

O

0..1

When present, this IE shall contain the target NF Set ID (as defined in clause 28.12 of 3GPP TS 23.003 [12]) of the NF instances being discovered.

Query-Params-Ext2

target-nf-service-set-id

NfServiceSetId

O

0..1

When present, this IE shall contain the target NF Service Set ID (as defined in clause 28.13 of 3GPP TS 23.003 [12]) of the NF service instances being discovered.

If this IE is provided together with the target-nf-set-id IE, the NRF shall return service instances of the NF Service Set indicated in the request and should additionally return equivalent ones, if any.

Query-Params-Ext2

preferred-tai

Tai

O

0..1

When present, the NRF shall prefer NF profiles that can serve the TAI, or the NRF shall return NF profiles not matching the TAI if no NF profile is found matching the TAI.

(NOTE 5)

Query-Params-Ext2

nef-id

NefId

O

0..1

When present, this IE shall contain the NEF ID of the NEF to be discovered. This may be included if the target NF type is "NEF". (NOTE 7)

Query-Params-Ext2

preferred-nf-instances

array(NfInstanceId)

O

1..N

When present, this IE shall contain a list of preferred candidate NF instance IDs. (NOTE 8)

Query-Params-Ext2

notification-type

NotificationType

O

0..1

If included, this IE shall contain the notification type of default notification subscriptions that shall be registered in the NFProfile or NFService of the NF Instances being discovered. The NF profiles returned by the NRF shall contain all the registered default notification subscriptions, including the one corresponding to the notification-type parameter.

(NOTE 9)

Query-Params-Ext2

n1-msg-class

N1MessageClass

O

0..1

This IE may be included when "notification-type" IE is present with value "N1_MESSAGES".

When included, this IE shall contain the N1 message class of default notification subscriptions that shall be registered in the NFProfile or NFService of the NF Instances being discovered. The NF profiles returned by the NRF shall contain all the registered default notification subscriptions, including the one corresponding to the n1-msg-class parameter.

(NOTE 9)

Query-Params-Ext3

n2-info-class

N2InformationClass

O

0..1

This IE may be included when "notification-type" IE is present with value "N2_INFORMATION".

If included, this IE shall contain the notification type of default notification subscriptions that shall be registered in the NFProfile or NFService of the NF Instances being discovered. The NF profiles returned by the NRF shall contain all the registered default notification subscriptions, including the one corresponding to the n2-info-class parameter.

(NOTE 9)

Query-Params-Ext3

serving-scope

array(string)

O

1..N

If present, this attribute shall contain the list of areas that can be served by the NF instances to be discovered. The NRF shall return NF profiles of NFs which can serve all the areas requested in this query parameter.

(NOTE 18)

Query-Params-Ext2

imsi

string

O

0..1

If included, this IE shall contain the IMSI of the requester UE to search for an appropriate NF. IMSI may be included if the target NF type is "HSS".

pattern: "^[0-9]{5,15}$"

Query-Params-Ext2

ims-private-identity

string

O

0..1

If included, this IE shall contain the IMS Private Identity of the requester UE to search for an appropriate NF. IMS Private Identity may be included if the target NF type is "HSS".

Query-Params-Ext3

ims-public-identity

string

O

0..1

If included, this IE shall contain the IMS Public Identity of the requester UE to search for an appropriate NF. IMS Public Identity may be included if the target NF type is "HSS".

Query-Params-Ext3

msisdn

string

O

0..1

If included, this IE shall contain the MSISDN of the requester UE to search for an appropriate NF. IMS Public Identity may be included if the target NF type is "HSS".

Query-Params-Ext3

internal-group-identity

GroupId

O

0..1

If included, this IE shall contain the internal group identifier of the UE to search for an appropriate NF. This may be included if the target NF type is "UDM", "NSSAAF" or "TSCTSF".

Query-Params-Ext2

preferred-api-versions

map(string)

O

1..N

When present, this IE indicates the preferred API version of the services that are supported by the target NF instances. The key of the map is the ServiceName (see clause 6.1.6.3.11) for which the preferred API version is indicated. Each element carries the API Version Indication for the service indicated by the key. The NRF may return additional NFs in the response not matching the preferred API versions, e.g. if no NF profile is found matching the preferred-api-versions.

An API Version Indication is a string formatted as {operator}+{API Version}.

The following operators shall be supported:

"=" match a version equals to the version value indicated.

">" match any version greater than the version value indicated

">=" match any version greater than or equal to the version value indicated

"<" match any version less than the version value indicated

"<=" match any version less than or equal to the version value indicated

"^" match any version compatible with the version indicated, i.e. any version with the same major version as the version indicated.

Precedence between versions is identified by comparing the Major, Minor, and Patch version fields numerically, from left to right.

If no operator or an unknown operator is provided in API Version Indication, "=" operator is applied.

Example of API Version Indication:

Case1: "=1.2.4.operator-ext" or "1.2.4.operator-ext" means matching the service with API version "1.2.4.operator-ext"

Case2: ">1.2.4" means matching the service with API versions greater than "1.2.4"

Case3: "^2.3.0" or "^2" means matching the service with all API versions with major version "2".

Query-Params-Ext2

v2x-support-ind

boolean

O

0..1

When present, this IE indicates whether a PCF supporting V2X Policy/Parameter provisioning needs to be discovered.

true: a PCF supporting V2X Policy/Parameter provisioning is requested to be discovered;
false: a PCF not supporting V2X Policy/Parameter provisioning is requested to be discovered.

Query-Params-Ext2

redundant-gtpu

boolean

O

0..1

When present, this IE indicates whether a UPF supporting redundant GTP-U path needs to be discovered.

true: a UPF supporting redundant GTP-U path is requested to be discovered;
false: a UPF not supporting redundant GTP-U path is requested to be discovered.

Query-Params-Ext2

redundant-transport

boolean

O

0..1

When present, this IE indicates whether a UPF supporting redundant transport path on the transport layer in the corresponding network slice needs to be discovered.

true: a UPF supporting redundant transport path on the transport layer is requested to be discovered;
false: a UPF not supporting redundant transport path on the transport layer is requested to be discovered.

If the Snssai(s) are also included, the UPF supporting redundant transport path on the transport layer shall be available in the network slice(s) identified by the Snssai(s).

Query-Params-Ext2

ipups

boolean

O

0..1

When present, this IE indicates whether a UPF which is configured for IPUPS is requested to be discovered.

true: a UPF which is configured for IPUPS is requested to be discovered;

false: a UPF which is not configured for IPUPS is requested to be discovered.

Query-Params-Ext2

sxa-ind

boolean

O

0..1

When present, this IE indicates whether a UPF which is configured to support Sxa interface is requested to be discovered.

true: a UPF which is configured to support Sxa interface is requested to be discovered;

false: a UPF which is not configured to support Sxa interface is requested to be discovered.

Query-SBIProtoc18

scp-domain-list

array(string)

O

1..N

When present, this IE shall contain the SCP domain(s) the target NF, SCP or SEPP belongs to. The NRF shall return NF, SCP or SEPP profiles that belong to all the SCP domains provided in this list.

Query-Params-Ext2

address-domain

Fqdn

O

0..1

If included, this IE shall contain the address domain that shall be reachable through the SCP. This IE may be included when the target NF type is "SCP".

Query-Params-Ext2

ipv4-addr

Ipv4Addr

O

0..1

If included, this IE shall contain the IPv4 address that shall be reachable through the SCP. This IE may be included when the target NF type is "SCP".

Query-Params-Ext2

ipv6-prefix

Ipv6Prefix

O

0..1

If included, this IE shall contain the IPv6 prefix that shall be reachable through the SCP. This IE may be included when the target NF type is "SCP".

Query-Params-Ext2

served-nf-set-id

NfSetId

O

0..1

When present, this IE shall contain the NF Set ID that shall be reachable through the SCP. This IE may be included when the target NF type is "SCP".

Query-Params-Ext2

remote-plmn-id

PlmnId

O

0..1

If included, this IE shall contain the remote PLMN ID that shall be reachable through the SCP or SEPP. This IE may be included when the target NF type is "SCP" or "SEPP".

Query-Params-Ext2

remote-snpn-id

PlmnIdNid

O

0..1

If included, this IE shall contain the remote SNPN ID that shall be reachable through the SCP or SEPP. This IE may be included when the target NF type is "SCP" or "SEPP".

Query-ENPN

data-forwarding

boolean

O

0..1

This may be included if the target NF type is "UPF". (NOTE 13)

When present, the IE indicates whether UPF(s) configured for data forwarding needs to be discovered.

true: UPF(s) configured for data forwarding is requested to be discovered;
false: UPF(s) not configured for data forwarding is requested to be discovered.

Query-Params-Ext2

preferred-full-plmn

boolean

O

0..1

When present, the NRF shall prefer NF profile(s) that can serve the full PLMN (i.e. can serve any TAI in the PLMN), or the NRF shall return other NF profiles if no NF profile serving the full PLMN is found:

– true: NF instance(s) serving the full PLMN is preferred;

– false: NF instance(s) serving the full PLMN is not preferred.

(NOTE 14)

Query-Params-Ext2

requester-features

SupportedFeatures

C

0..1

Nnrf_NFDiscovery features supported by the Requester NF that is invoking the Nnrf_NFDiscovery service.

This IE shall be included if at least one feature is supported by the Requester NF.

realm-id

string

O

0..1

May be included if the target NF type is "UDSF". If included, this IE shall contain the realm-id for which a UDSF shall be discovered.

Query-Params-Ext4

storage-id

string

O

0..1

May be included if the target NF type is "UDSF" and realm-id is included. If included, this IE shall contain the storage-id for the realm-id indicated in the realm-id IE for which a UDSF shall be discovered.

Query-Params-Ext4

vsmf-support-ind

boolean

O

0..1

If included, this IE shall indicate that target SMF(s) that support V-SMF Capability are preferred.

This IE may be included when the target NF type is "SMF".

(NOTE 15)

Query-Param-vSmf-Capability

ismf-support-ind

boolean

O

0..1

If included, this IE shall indicate that target SMF(s) that support I-SMF Capability are preferred.

This IE may be included when the target NF type is "SMF".

(NOTE 15)

Query-Param-iSmf-Capability

nrf-disc-uri

Uri

C

0..1

If included, this IE shall contain the API URI of the NFDiscovery Service (see clause 6.2.1) of the NRF holding the NF Profile.

It shall be included if:

– the target-nf-instance-id is present;

– the NF Service Consumer has previously received such API URI in an earlier NF service discovery, i.e. if the target NF instance was provided in the nfInstanceList attribute in SearchResult (see clause 6.2.6.2.2) and the nrfDiscApiUri attribute was present in the NfInstanceInfo (see clause 6.2.6.2.7); and

– the service discovery request is addressed to a different NRF than the NRF holding the NF profile.

Enh-NF-Discovery

preferred-vendor-specific-features

map(map(array(VendorSpecificFeature)))

O

1..N(1..M(1..L))

When present, this IE indicates the list of preferred vendor-specific features supported by the target Network Function, as defined by the supportedVendorSpecificFeatures attribute in NFService (see clauses 6.1.6.2.3 and 6.2.6.2.4). NF profiles that support all the preferred features, or by default, NF profiles that contain at least one service supporting the preferred features, should be preferentially returned in the response; NF profiles in the response may not support the preferred features.

The key of the external map is the ServiceName (see clause 6.1.6.3.11) for which the preferred vendor-specific features is indicated. Each element carries the preferred vendor-specific features for the service indicated by the key.

The key of the internal map is the IANA-assigned "SMI Network Management Private Enterprise Codes" [38]. The string used as key of the internal map shall contain 6 decimal digits; if the SMI code has less than 6 digits, it shall be padded with leading digits "0" to complete a 6-digit string value.

The value of each entry of the map shall be a list (array) of VendorSpecificFeature objects.

The NF profiles returned by the NRF shall include the full list of vendor-specific-features and not just the interclause of supported and preferred vendor-specific features.

Query-SBIProtoc17

preferred-vendor-specific-nf-features

map(array(VendorSpecificFeature))

O

1..N(1..M)

When present, this IE indicates the list of preferred vendor-specific features supported by the target Network Function, as defined by the supportedVendorSpecificFeatures attribute in NF profile (see clause 6.1.6.2.2 and 6.2.6.2.3). NF profiles that support all the preferred features should be preferentially returned in the response. NF profiles in the response may not support the preferred features.

The key of the map is the IANA-assigned "SMI Network Management Private Enterprise Codes" [38]. The value of each entry of the map shall be a list (array) of VendorSpecificFeature objects.

The NF profiles returned by the NRF shall include the full list of vendor-specific features and not just the interclause of supported and preferred vendor-specific features.

Query-SBIProtoc17

required-pfcp-features

string

O

0..1

List of features required to be supported by the target UPF or MB-UPF (when selecting a UPF or a MB-UPF), encoded as defined for the supportedPfcpFeatures attribute in UpfInfo (see clause 6.1.6.2.13).

(NOTE 16)

Query-Upf-Pfcp

home-pub-key-id

integer

O

0..1

When present, this IE shall indicate the Home Network Public Key ID which shall be able to be served by the NF instance.

May be included if the target NF type is "AUSF" or "UDM". This query parameter may only be present if the routing-indicator query parameter is also present.

(NOTE 17)

Query-SBIProtoc17

prose-support-ind

boolean

O

0..1

When present, this IE indicates whether supporting ProSe capability by PCF needs to be discovered.

true: a PCF supporting ProSe capability is requested to be discovered;
false: a PCF not ProSe capability is requested to be discovered.

Query-5G-ProSe

analytics-aggregation-ind

boolean

O

0..1

If included, this IE shall contain the analytics aggregation capability indication of the NF being discovered. This IE may be included when the target NF type is "NWDAF".

Query-eNA-PH2

analytics-metadata-prov-ind

boolean

O

0..1

If included, this IE shall contain the analytics metadata provisioning capability indication of the NF being discovered. This IE may be included when the target NF type is "NWDAF".

Query-eNA-PH2

serving-nf-set-id

NfSetId

O

0..1

When present, this IE shall contain the NF Set ID that is served by the DCCF, NWDAF or MFAF. This IE may be included when the target NF type is "DCCF" or "NWDAF" or "MFAF".

Query-eNA-PH2

serving-nf-type

NFType

O

0..1

When present, this IE shall contain the NF type that is served by the DCCF, NWDAF or MFAF. This IE may be included when the target NF type is "DCCF" or "NWDAF" or "MFAF".

Query-eNA-PH2

ml-analytics-info-list

array(MlAnalyticsInfo)

O

1..N

If present, this attribute shall contain the list of ML Analytics Filter information per Analytics ID(s) requested to be supported by the Nnwdaf_MLModelProvision Service. The NRF shall return NWDAF profiles that support at least one of the MlAnalyticsInfo in this list.

Query-eNA-PH2

nsacf-capability

NsacfCapability

O

0..1

When present, this IE indicates the service capability that the target NSACF needs to support.

NSAC

mbs-session-id-list

array(MbsSessionId)

O

0..1

This IE may be present if the target NF type is "MB-SMF".

When present, it shall contain the list of MBS Session ID(s) for which MB-SMF(s) are to be discovered.

When present, for each mbs-session-id in the list, the NRF shall determine whether an MB-SMF supporting the mbs-session-id and complying with the other query parameters (if any) exists. An MB-SMF shall be considered to support the mbs-session-id if:

– the mbs-session-id contains a TMGI that is part of a TMGI range (see tmgiRangeList attribute in clause 6.1.6.2.85) registered by the MB-SMF and, if the tai query parameter is present:

– if the TAI indicated in the tai query parameter can be served by the MB-SMF (see taiList and taiRangeList attributes in clause 6.1.6.2.85);

or

– the mbs-session-id contains a TMGI or an SSM address, that is part of the list of MBS sessions currently served by the MB-SMF (see mbsSessionList attribute in clause 6.1.6.2.85) and, if the tai query parameter is present and the MBS session is registered with an MBS Service Area (see mbsServiceArea in clause 6.1.6.2.90):

– if the TAI indicated in the tai query parameter is supported by the MBS Service Area of the MBS session.

If so, the NRF shall return the profile of this MB-SMF. If no MB-SMF supporting the mbs-session-id and complying with the other query parameters exists, the NRF shall return an empty response.

See clause 7.1.2 of 3GPP TS 23.247 [43].

Query-MBS

area-session-id

AreaSessionId

O

0..1

This IE may be present if the target NF type is "MB-SMF", the mbs-session-id-list IE is present and contains only one MBS Session ID.

When present, the IE shall contain the Area Session ID, for the MBS session indicated in the mbs-session-id-list IE, for which an MB-SMF is to be discovered.

When this IE is present, the NRF shall return an MB-SMF profile that currently serves the MBS Session ID and Area Session ID (see mbsSessionList attribute in clause 6.1.6.2.85).

If no MB-SMF supports the MBS Session ID and Area Session ID, the NRF shall return an empty response.

See clause 7.1.2 of 3GPP TS 23.247 [43].

Query-MBS

gmlc-number

string

O

0..1

If included, this IE shall contain the GMLC Number of which should supported by the target GMLC. It may be included if the target NF type is "GMLC".

Pattern: "^[0-9]{5,15}$"

Query-eLCS

upf-n6-ip

IpAddr

O

0..1

If included, this IE shall contain the N6 IP address of PSA UPF.

It may be included if the target NF type is "EASDF".

Query-eEDGE-5GC

tai-list

array(Tai)

O

1..N

If included, this IE shall contain the Tracking Area Identities requested to be supported by the NFs being discovered. The NRF shall return NFs which support all the TAIs in the list. It may be included if the target NF type is "NEF".

Query-eEDGE-5GC

preferences-precedence

array(string)

O

2..N

This IE may be present when multiple query parameters expressing a preference are included in the discovery request.

When present, this IE shall indicate the relative precedence of these query parameters (from higher precedence to lower precedence). The NRF shall use the indicated precedence to prioritize the candidate NFs in the search result, among the candidate NFs partially matching the different preference query parameters, candidate matching the higher precedence preference query parameter should have higher priority.

This IE may include any query parameter named "preferred-xxx" or "ext-preferred-xxx" (e.g. preferred-locality, preferred-tai).

Example:

preferences-precedence=[preferred-tai, preferred-vendor-specific-features]

The above value indicates that the "preferred-tai" parameter has higher precedence than the "preferred-vendor-specific-features" parameter.

Query-SBIProtoc17

support-onboarding-capability

boolean

O

0..1

If present, this attribute indicates the target AMF or SMF instances support SNPN Onboarding. If the target is an SMF, this indicates the SMF also supports User Plane Remote Provisioning. This is used for the case of Onboarding of UEs for SNPNs (see 3GPP TS 23.501 [2], clauses 5.30.2.10 and 6.2.6.2).

Query-ENPN

uas-nf-functionality-ind

boolean

O

0..1

If included, this IE shall contain the UAS NF functionality indication of the NF being discovered. This IE may be included when the target NF type is "NEF".

Query-ID_UAS

v2x-capability

V2xCapability

O

0..1

When present, this IE indicates the V2X capability that the target PCF needs to support.

When the v2x-capability is provided as the query parameter, NRF shall return the PCF instances which support all the V2X capabilities requested.

Query-SBIProtoc17

prose-capability

ProSeCapability

O

0..1

When present, this IE indicates the ProSe capability that the target PCF needs to support.

When the prose-capability is provided as the query parameter, NRF shall return the PCF instances which support all the ProSe capabilities requested.

Query-5G-ProSe

shared-data-id

SharedDataId

O

0..1

Identifies the shared data that is stored in the NF (UDR) to be discovered. May be included if the target NF type is "UDR"

Query-SBIProtoc17

target-hni

Fqdn

O

0..1

If included, this IE shall contain the Home Network Identifier.

If CH/DCS is using AAA Server or AUSF and UDM for primary authentication and authorization (see clauses 5.30.2.9.2, 5.30.2.9.3 and 5.30.2.10.2.2 in 3GPP TS 23.501 [2]), the sender (AMF or AUSF) populates this IE with CH/DCS ID. See also clauses 4.17.4a and 4.17.5a in TS 23.502 [3].

If the target NF is AUSF or NSSAAF and the HNI belongs to a CH/DCS with AAA Server in another domain, i.e. not in this SNPN, the NRF returns back the AUSF or NSSAAF in the same SNPN, based on the NF profile as specified in clause 6.2.6.2 in 3GPP TS 23.501 [2].

Query-ENPN

target-nw-resolution

boolean

O

0..1

If included and set to true, the NRF shall determine the identity of the target PLMN to which the NFDiscovery request shall be directed, based on the MSISDN of the UE included in the "gpsi" query parameter, as described in 3GPP TS 23.540 [48].

If included and set to false, this IE shall be ignored.

Query-Nw-Resolution

exclude-nfinst-list

array(NfInstanceId)

O

1..N

If included, this IE shall indicate the list of NF instances that should not be returned in the NF Discovery response.

(NOTE 23)

Query-SBIProtoc17-Ext1

exclude-nfservinst-list

array(NfServiceInstance)

O

1..N

If included, this IE shall indicate the list of NF service instances that should not be returned in the NF Discovery response.

(NOTE 23)

Query-SBIProtoc17-Ext1

exclude-nfserviceset-list

array(NfServiceSetId)

O

1..N

If included, this IE shall indicate the list of NF service sets of NF service instances that should not be returned in the NF Discovery response.

(NOTE 23)

Query-SBIProtoc17-Ext1

exclude-nfset-list

array(NfSetId)

O

1..N

If included, this IE shall indicate the list of NF sets of NF instances that should not be returned in the NF Discovery response.

(NOTE 23)

Query-SBIProtoc17-Ext1

preferred-analytics-delays

map(DurationSec)

O

1..N

If included, this IE shall contain the preferred Analytics Delay. The key of the map is the EventId or NwdafEvent (as defined in 3GPP TS 29.520 [33]) for which the preferred Analytics Delay is related to. Each element carries the preferred Analytics Delay for the Analytics ID indicated by the key.

The NRF shall return the NWDAFs supports the Analytics ID with a supported Analytics Delay that is less than or equal to the preferred Analytics Delay, as described in clause 6.3.13 of 3GPP TS 23.501 [2]. The NRF may return NWDAFs in the response not matching the preferred Analytics Delay, e.g. if no NWDAF profile is found matching the preferred Analytics Delay.

Query-eNA-PH2-Ext1

complete-profile

boolean

O

0..1

This IE may be included by an SCP with the value true to request to discover the complete profile of NF Instances (including authorization attributes such as the "allowedXXX" attributes of NFProfile and NFService data types) matching the query parameters. See clause 5.3.2.2.2.

Complete-Profile-Discovery

n32-purposes

array(N32Purpose)

O

1..N

This IE may be included when the target NF type is "SEPP".

When present, this IE shall indicate the requested N32 purposes to be supported by the SEPP. The NRF shall return SEPP profiles that support at least one requested N32 purpose.

Query-SBIProtoc18

preferred-features

map(SupportedFeatures)

O

1..N

List of features preferred to be supported by the target Network Function, as defined by the supportedFeatures attribute in NFService (see clauses 6.1.6.2.3 and 6.2.6.2.4).

The key of the map is the Service Name as specified in clause 6.1.6.3.11. Each element carries the preferred feature(s) to be supported by the target Network Function for the indicated service.

The NRF shall priorize the NF candidates supporting the preferred features in the search result.

(NOTE 24)

Query-SBIProtoc18

remote-plmn-id-roaming

PlmnId

O

0..1

If included, this IE shall indicate the remote PLMN that the target NF service producer can serve, i.e. the NF service producer can serve the roaming UEs which belong to the indicated remote PLMN. This IE may be included when the target NF type is "SMSF".

The NRF shall return the candidate NF service producer(s) in discovery result with the following order of preference:

– NF profiles explicitly indicated the support of roaming UE for the requested remote PLMN; then

– NF profiles indicated the support of roaming UE for any remote PLMN; then

– if none of above are available, NF profiles without indication of roaming UE support.

Query-SBIProtoc18

NOTE 1: If this parameter is present and no AMF supporting the requested GUAMI is available due to AMF Failure or planned AMF removal, the NRF shall return in the response AMF instances acting as a backup for AMF failure or planned AMF removal respectively for this GUAMI (see clause 6.1.6.2.11). The NRF can detect if an AMF has failed, using the Heartbeat procedure. The NRF will receive a de-registration request from an AMF performing a planned removal.

NOTE 2: If the combined SMF/PGW-C is requested to be discovered, the NRF shall return in the response the SMF instances registered with the SmfInfo containing pgwFqdn.

NOTE 3: If a UPF supporting interworking with EPS is requested to be discovered, the NRF shall return in the response the UPF instances registered with the upfInfo containing iwkEpsInd set to true.

NOTE 4: This attribute has a different semantic than what is defined in clause 6.6.2 of 3GPP TS 29.500 [4], i.e. it is not used to signal optional features of the Nnrf_NFDiscovery Service API supported by the requester NF.

NOTE 5: The AMF may perform the SMF discovery based on the dnn, snssais and preferred-tai during a PDU session establishment procedure, and the NRF shall return the SMF profiles matching all if possible, or the SMF profiles only matching dnn and snssais. If the SMF profiles only matching dnn and snssais are returned, the AMF shall insert an I-SMF. An SMF may also perform a UPF discovery using this parameter.

NOTE 6: The SMF may select the P-CSCF close to the UPF by setting the preferred-locality to the value of the locality of the UPF.

NOTE 7: During EPS to 5GS idle mobility procedure, the Requester NF (i.e. SMF) discovers the anchor NEF for NIDD using the SCEF ID received from EPS as the value of the NEF ID, as specified in clause 4.11.1.3.3 of 3GPP TS 23.502 [3].

NOTE 8: The service consumer may include a list of preferred-nf-instance-ids in the query. If so, the NRF shall first check if the NF profiles of the preferred NF instances match the other query parameters, and if so, then the NRF shall return the corresponding NF profiles; otherwise, the NRF shall return a list of candidate NF profiles matching the query parameters other than the preferred-nf-instance-ids. For example, the target AMF may set this query parameter to the SMF Instance ID and I-SMF Instance ID during an inter AMF mobility procedure to select an I-SMF.

NOTE 9: This parameter may be used by the SCP (with other query parameters) to discover and select a NF service consumer with a default notification subscription supporting the notification type of a notification request (see clause 6.10.3.3 of 3GPP TS 29.500 [4]).

NOTE 10: An S-NSSAI value used in discovery request query parameters shall be considered as matching the S-NSSAI value in the NF Profile or NF Service of a given NF Instance if both the SST and SD components are identical (i.e. an S-NSSAI value where SD is absent, shall not be considered as matching an S-NSSAI where SD is present, regardless if SST is equal in both).

NOTE 11: The dnn query parameter shall be considered as matching a DNN attribute in the NF Profile of a given NF Instance if:
– both contain the same Network Identifier and Operator Identifier;
– both contain the same Network Identifier and none contains an Operator Identifier;
– the dnn query parameter contains the Network Identifier only, the DNN value in the NF Profile contains both the Network Identifier and Operator Identifier, and both contain the same Network Identifier; or
– the dnn query parameter contains both the Network Identifier and Operator Identifier, the DNN value in the NF Profile contains the Network Identifier only, both contain the same Network Identifier and the Operator Identifier matches one PLMN of the NF (i.e. plmnList of the NF Profile).

NOTE 12: Based on operator’s policies, a discovery request not including the requester’s information necessary to validate the authorization parameters in NF Profiles may be rejected or accepted but with only returning in the discovery response NF Instances whose authorization parameters allow any NF Service Consumer to access their services. The authorization parameters in NF Profile are those used by NRF to determine whether a given NF Instance / NF Service Instance can be discovered by an NF Service Consumer in order to consume its offered services (e.g. "allowedNfTypes", "allowedNfDomains", etc.).

NOTE 13: Different UPF instances for data forwarding may be configured in the network e.g. for different serving areas. The SMF may use this query parameter together with others (like SMF Serving Area or TAI) in discovery to select the UPF candidate for data forwarding.

NOTE 14: For HR roaming, if the V-PLMN requires Deployments Topologies with specific SMF Service Areas (DTSSA) but no H-SMF can be selected supporting V-SMF change, AMF may use this query parameter to select a V-SMF serving the full VPLMN if available.

NOTE 15: The AMF may perform discovery with this parameter to find V-SMF(s)/I-SMF(s), and the NRF shall return the SMF profiles that explicitly indicated support of V-SMF/I-SMF(s) capability. When performing discovery, the AMF shall use other query parameters together with this IE to ensure the required configurations and/or features are supported by the V-SMF/I-SMF(s), e.g. required Slice for the PDU session, support of DTSSA feature if V-SMF change is required for PDU Session, etc. If no SMF instances that explicitly indicated support of V-SMF/I-SMF(s) capability can be matched for the discovery, the NRF shall return matched SMF instances not indicating support of V-SMF/I-SMF(s) capability explicitly, i.e. the SMF instances not registered vsmfSupportInd/ismfSupportInd IE in the NF profile but matched to the rest query parameters, if available.

NOTE 16: When required-pfcp-features is used as query parameter, the NRF shall return a list of candidate UPFs supporting all the required PFCP features. The NRF may also return UPF profiles not including the "SupportedPfcpFeatures" attribute (e.g. pre-Rel-17 UPFs) but matching the other query parameters. The NF Service Consumer, e.g. a SMF, when using required-pfcp-features as query parameter, shall also include the query parameter corresponding to the UPF features (atsss-capability, upf-ue-ip-addr-ind, redundant-gtpu) which correspond to the PFCP feature flags MPTCP and ATSSS_LL, UEIP, and RTTL respectively, if the corresponding PFCP feature is required. For example an SMF, that wishes to select a UPF supporting UE IP Address Allocation by the UP function, shall set the UEIP flag to "1" in the required-pfcp-features and also include the upf-ue-ip-addr-ind parameter set to "true".

NOTE 17: In this release, the usage of Home Network Public Key identifier for AUSF/UDM discovery is limited to the scenario where the AUSF/UDM NF consumers belong to the same PLMN as AUSF/UDM.

NOTE 18: The NF service consumer may derive the serving scope from e.g. the TAI of the UE, using local configuration. This parameter may be used to discover any NF that registers to the NRF, e.g. a 5GC NF or a P-CSCF.

NOTE 19: If the NRF supports the "Collocated-NF-Selection" feature and the NF service consumer has included the "preferred-collocated-nf-types" attribute, the NRF shall return a list of candidates NFs (for the target-nf-type) matching the discovery query parameters and preferentially supporting CollocatedNfType(s) as indicated in the preferred-collocated-nf-types.

NOTE 20: If the NRF supports this IE and the NF service consumer has included this IE with the value "true" in discovery request, the NRF shall look up and return PGW-C+SMF instances matching the other query parameters. If no matching is found, the NRF shall return a list of standalone SMF instances matching the other query parameters. If the NRF supports this IE and the NF service consumer has included this IE with the value "false" in discovery request, the NRF shall look up and return standalone SMF instances matching the other query parameters. If no matching is found, the NRF shall return a list of PGW-C+SMF instances matching the other query parameters.

NOTE 21: Either pgw-ind IE or preferred-pgw-ind IE may be included in the discovery request.

NOTE 22: MB-SMF may use an NRF to discover the AMF(s) serving an MBS service area (see clause 7.3.1 in 3GPP TS 23.247 [43]. For this purpose, the MB-SMF may use query parameters specified in this table, e.g. ‘tai’ and ‘service-names’, or ‘snssais’, or any other parameters.

NOTE 23: This parameter may be set by an NF service consumer or SCP to filter-out specific NF (service) instances or NF (service) sets from the NF Discovery response, e.g. when the NFc knows that an NF service producer is not responsive or overloaded. See the 3gpp-Sbi-Selection-Info header in clause 5.2.3.3.10 of 3GPP TS 29.500 [4].

NOTE 24: A feature shall not be included in both required-features IE and preferred-features IE in the same discovery request.

NOTE 25: When Locality is configured in NSACF(s), an NSACF consumer, e.g. AMF or SMF, may use a locally configured NSACF Locality to discover the candidate NSACF, or otherwise may use its own Locality to discover the candidate NSACF.

The default logical relationship among the query parameters is logical "AND", i.e. all the provided query parameters shall be matched, with the exception of the "preferred-locality", "ext-preferred-locality", "preferred-nf-instances", "preferred-tai", "preferred-api-versions", "preferred-full-plmn", "preferred-collocated-nf-types", "preferred-pgw-ind", "preferred-analytics-delays", "preferred-features" and "mbs-session-id" query parameters (see Table 6.2.3.2.3.1-1).

The NRF may support the Complex query expression as defined in 3GPP TS 29.501 [5] for the NF Discovery service. If the "complexQuery" query parameter is included, then the logical relationship among the query parameters contained in "complexQuery" query parameter is as defined in 3GPP TS 29.571 [7].

A NRF not supporting Complex query expression shall reject a NF service discovery request including a complexQuery parameter, with a ProblemDetails IE including the cause attribute set to INVALID_QUERY_PARAM and the invalidParams attribute indicating the complexQuery parameter.

This method shall support the request data structures specified in table 6.1.3.2.3.1-2 and the response data structures and response codes specified in table 6.1.3.2.3.1-3.

Table 6.2.3.2.3.1-2: Data structures supported by the GET Request Body on this resource

Data type

P

Cardinality

Description

n/a

Table 6.2.3.2.3.1-3: Data structures supported by the GET Response Body on this resource

Data type

P

Cardinality

Response

codes

Description

SearchResult

M

1

200 OK

The response body contains the result of the search over the list of registered NF Instances.

RedirectResponse

O

0..1

307 Temporary Redirect

The response shall be used when the intermediate NRF redirects the service discovery request.

The NRF shall include in this response a Location header field containing a URI pointing to the resource located on the redirect target NRF.

If an SCP redirects the message to another SCP then the location header field shall contain the same URI or a different URI pointing to the endpoint of the NF service producer to which the request should be sent.

ProblemDetails

O

0..1

400 Bad Request

The response body contains the error reason of the request message.

If the query parameter used to match the authorization parameter is required but not provided in the NF discovery request, the "cause" attribute shall be set to "MANDATORY_QUERY_PARAM_MISSING", and the missing query parameter shall be indicated.

ProblemDetails

O

0..1

403 Forbidden

This response shall be returned if the Requester NF is not allowed to discover the NF Service(s) being queried.

ProblemDetails

O

0..1

404 Not Found

This response shall be returned if the requested resource URI as defined in clause 6.2.3.2.2 (query parameter not considered) is not found in the server.

It may also be sent in hierarchical NRF deployments when the NRF needs to forward/redirect the request to another NRF but lacks information in the request to do so; similarly, the NRF shall return this response code when it is received from the upstream NRF.

ProblemDetails

O

0..1

500 Internal Server Error

The response body contains the error reason of the request message.

Table 6.2.3.2.3.1-4: Headers supported by the GET method on this endpoint

Name

Data type

P

Cardinality

Description

If-None-Match

string

C

0..1

Validator for conditional requests, as described in IETF RFC 7232 [19], clause 3.2

Table 6.2.3.2.3.1-5: Headers supported by the 200 Response Code on this endpoint

Name

Data type

P

Cardinality

Description

Cache-Control

string

C

0..1

Cache-Control containing max-age, described in IETF RFC 7234 [20], clause 5.2

ETag

string

C

0..1

Entity Tag containing a strong validator, described in IETF RFC 7232 [19], clause 2.3

Table 6.2.3.2.3.1-6: Headers supported by the 307 Response Code on this endpoint

Name

Data type

P

Cardinality

Description

Location

string

M

1

The URI pointing to the resource located on the redirect target NRF

Table 6.2.3.2.3.1-7: Links supported by the 200 Response Code on this endpoint

Name

Resource name

HTTP method or custom operation

Parameters table

Description

search

Stored Search (Document)

GET

6.2.3.2.3.1-8

The ‘searchId’ parameter returned in the response can be used as the ‘searchId’ parameter in the GET request to ‘/searches/{searchId}’

completeSearch

Complete Stored Search (Document)

GET

6.2.3.2.3.1-9

The ‘searchId’ parameter returned in the response can be used as the ‘searchId’ parameter in the GET request to ‘/searches/{searchId}/complete’

6.2.3.2.4 Resource Custom Operations

There are no resource custom operations for the Nnrf_NFDiscovery service in this release of the specification.

6.2.3.3 Resource: Stored Search (Document)

6.2.3.3.1 Description

This resource represents a search result (i.e. a number of discovered NF Instances), stored by NRF as a consequence of a prior search result.

This resource is modelled as the Document resource archetype (see clause C.3 of 3GPP TS 29.501 [5]).

6.2.3.3.2 Resource Definition

Resource URI: {apiRoot}/nnrf-disc/v1/searches/{searchId}

This resource shall support the resource URI variables defined in table 6.2.3.3.2-1.

Table 6.2.3.3.2-1: Resource URI variables for this resource

Name

Data type

Definition

apiRoot

string

See clause 6.1.1

searchId

string

Identifier of a stored search result, returned by NRF to the NF Consumer in the original response to the NF Discovery GET operation (see clause 6.2.6.2.2).

6.2.3.3.2.1 GET

This method retrieves the NF Instances corresponding to a given stored search result.

This method shall support the URI query parameters specified in table 6.2.3.3.2.1-1.

Table 6.2.3.3.2.1-1: URI query parameters supported by the GET method on this resource

Name

Data type

P

Cardinality

Description

n/a

This method shall support the request data structures specified in table 6.2.3.3.2.1-2 and the response data structures and response codes specified in table 6.2.3.3.2.1-3.

Table 6.2.3.3.2.1-2: Data structures supported by the GET Request Body on this resource

Data type

P

Cardinality

Description

n/a

Table 6.2.3.3.2.1-3: Data structures supported by the GET Response Body on this resource

Data type

P

Cardinality

Response

codes

Description

StoredSearchResult

M

1

200 OK

The response body contains the NF Instances corresponding to a given stored search result.

NOTE: The mandatory HTTP error status codes for the GET method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] other than those specified in the table above also apply, with a ProblemDetails data type (see clause 5.2.7 of 3GPP TS 29.500 [4]).

6.2.3.4 Resource: Complete Stored Search (Document)

6.2.3.4.1 Description

This resource represents a complete search result (i.e. a number of discovered NF Instances), stored by NRF as a consequence of a prior search result, but without applying any client restrictions in terms of the number of instances to be returned (i.e. "limit" or "max-payload-size" query parameters).

This resource is modelled as the Document resource archetype (see clause C.3 of 3GPP TS 29.501 [5]).

6.2.3.4.2 Resource Definition

Resource URI: {apiRoot}/nnrf-disc/v1/searches/{searchId}/complete

This resource shall support the resource URI variables defined in table 6.2.3.4.2-1.

Table 6.2.3.4.2-1: Resource URI variables for this resource

Name

Data type

Definition

apiRoot

string

See clause 6.1.1

searchId

string

Identifier of a stored search result, returned by NRF to the NF Consumer in the original response to the NF Discovery GET operation (see clause 6.2.6.2.2).

6.2.3.4.2.1 GET

This method retrieves the NF Instances corresponding to a given stored search result.

This method shall support the URI query parameters specified in table 6.2.3.4.2.1-1.

Table 6.2.3.4.2.1-1: URI query parameters supported by the GET method on this resource

Name

Data type

P

Cardinality

Description

n/a

This method shall support the request data structures specified in table 6.2.3.4.2.1-2 and the response data structures and response codes specified in table 6.2.3.4.3.1-3.

Table 6.2.3.4.2.1-2: Data structures supported by the GET Request Body on this resource

Data type

P

Cardinality

Description

n/a

Table 6.2.3.4.2.1-3: Data structures supported by the GET Response Body on this resource

Data type

P

Cardinality

Response

codes

Description

StoredSearchResult

M

1

200 OK

The response body contains the NF Instances corresponding to a given stored search result, but without applying any client restrictions in terms of the number of instances to be returned (i.e. "limit" or "max-payload-size" query parameters).

NOTE: The mandatory HTTP error status codes for the GET method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] other than those specified in the table above also apply, with a ProblemDetails data type (see clause 5.2.7 of 3GPP TS 29.500 [4]).

6.2.3.5 Resource: SCP Domain Routing Information (Document)

6.2.3.5.1 Description

This resource represents (local) SCP Domain Routing Information, calculated by NRF based on SCPs registered in the network (or in the producer NRF for local SCP Domain Routing Information).

This resource is modelled as the Document resource archetype (see clause C.3 of 3GPP TS 29.501 [5]).

6.2.3.5.2 Resource Definition

Resource URI: {apiRoot}/nnrf-disc/v1/scp-domain-routing-info

This resource shall support the resource URI variables defined in table 6.2.3.5.2-1.

Table 6.2.3.5.2-1: Resource URI variables for this resource

Name

Data type

Definition

apiRoot

string

See clause 6.2.1

6.2.3.5.2.1 GET

This method retrieves the (local) SCP Domain Routing Information.

This method shall support the URI query parameters specified in table 6.2.3.5.2.1-1.

Table 6.2.3.5.2.1-1: URI query parameters supported by the GET method on this resource

Name

Data type

P

Cardinality

Description

local

boolean

O

0..1

When present, this IE shall indicate whether local SCP Domain Routing Information is to be fetched:

– true: local SCP Domain Routing Information to be fetched.

– false (default): SCP Domain Routing Information to be fetched

This method shall support the request data structures specified in table 6.2.3.5.2.1-2 and the response data structure and response codes specified in table 6.2.3.5.2.1-3.

Table 6.2.3.5.2.1-2: Data structures supported by the GET Request Body on this resource

Data type

P

Cardinality

Description

n/a

Table 6.2.3.5.2.1-3: Data structures supported by the GET Response Body on this resource

Data type

P

Cardinality

Response

codes

Description

ScpDomainRoutingInfo

M

1

200 OK

The response body contains SCP Domain Routing Information.

NOTE: The mandatory HTTP error status codes for the GET method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] other than those specified in the table above also apply, with a ProblemDetails data type (see clause 5.2.7 of 3GPP TS 29.500 [4]).

6.2.3.6 Resource: SCP Domain Routing Information Subscriptions (Collection)

6.2.3.6.1 Description

This resource represents a collection of subscriptions of (local) SCP Domain Routing Information.

6.2.3.6.2 Resource Definition

Resource URI: {apiRoot}/nnrf-disc/v1/scp-domain-routing-info-subs

This resource shall support the resource URI variables defined in table 6.2.3.6.2-1.

Table 6.1.3.6.2-1: Resource URI variables for this resource

Name

Data type

Definition

apiRoot

string

See clause 6.2.1

6.2.3.6.3 Resource Standard Methods

6.2.3.6.3.1 POST

This method creates a new subscription. This method shall support the URI query parameters specified in table 6.2.3.6.3.1-1.

Table 6.2.3.6.3.1-1: URI query parameters supported by the POST method on this resource

Name

Data type

P

Cardinality

Description

n/a

This method shall support the request data structures specified in table 6.2.3.6.3.1-2 and the response data structure and response codes specified in table 6.2.3.6.3.1-3.

Table 6.2.3.6.3.1-2: Data structures supported by the POST Request Body on this resource

Data type

P

Cardinality

Description

ScpDomainRoutingInfoSubscription

M

1

The request body contains the input parameters for the subscription.

Table 6.2.3.6.3.1-3: Data structures supported by the POST Response Body on this resource

Data type

P

Cardinality

Response

codes

Description

ScpDomainRoutingInfoSubscription

M

1

201 Created

This case represents the successful creation of a subscription.

Upon success, the HTTP response shall include a "Location" HTTP header that contains the resource URI of the created resource.

NOTE: The mandatory HTTP error status codes for the POST method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] other than those specified in the table above also apply, with a ProblemDetails data type (see clause 5.2.7 of 3GPP TS 29.500 [4]).

Table 6.2.3.6.3.1-4: Headers supported by the 201 Response Code on this resource

Name

Data type

P

Cardinality

Description

Location

string

M

1

Contains the URI of the newly created resource, according to the structure: {apiRoot}/nnrf-disc/v1/scp-domain-routing-info-subs/{subscriptionId}

6.2.3.7 Resource: Individual SCP Domain Routing Information Subscription (Document)

6.2.3.7.1 Description

This resource represents an individual subscription of (local) SCP Domain Routing Information.

6.2.3.7.2 Resource Definition

Resource URI: {apiRoot}/nnrf-disc/v1/scp-domain-routing-info-subs/{subscriptionID}

This resource shall support the resource URI variables defined in table 6.2.3.7.2-1.

Table 6.2.3.7.2-1: Resource URI variables for this resource

Name

Data type

Definition

apiRoot

string

See clause 6.2.1

subscriptionID

string

Represents a specific subscription

6.2.3.7.3 Resource Standard Methods

6.2.3.7.3.1 DELETE

This method terminates an existing subscription. This method shall support the URI query parameters specified in table 6.2.3.7.3.1-1.

Table 6.2.3.7.3.1-1: URI query parameters supported by the DELETE method on this resource

Name

Data type

P

Cardinality

Description

n/a

This method shall support the request data structures specified in table 6.2.3.7.3.1-2 and the response data structure and response codes specified in table 6.2.3.7.3.1-3.

Table 6.2.3.7.3.1-2: Data structures supported by the DELETE Request Body on this resource

Data type

P

Cardinality

Description

n/a

Table 6.2.3.7.3.1-3: Data structures supported by the DELETE Response Body on this resource

Data type

P

Cardinality

Response

codes

Description

n/a

204 No Content

NOTE: The mandatory HTTP error status codes for the DELETE method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] other than those specified in the table above also apply, with a ProblemDetails data type (see clause 5.2.7 of 3GPP TS 29.500 [4]).

6.2.4 Custom Operations without associated resources

There are no custom operations defined without any associated resources for the Nnrf_NFDiscovery service in this release of this specification.

6.2.5 Notifications

6.2.5.1 General

This clause specifies the notifications provided by the Nnrf_NFDiscovery service.

The delivery of notifications shall be supported as specified in clause 6.2 of 3GPP TS 29.500 [4] for Server-initiated communication.

Table 6.2.5.1-1: Notifications overview

Notification

Resource URI

HTTP method or custom operation

Description

(service operation)

SCP Domain Routing Information Change Notification

{callbackUri}

(NF Service Consumer provided callback reference)

POST

Notify about change of SCP Domain Routing Information

6.2.5.2 SCP Domain Routing Information Change Notification

6.2.5.2.1 Description

The NF Service Consumer provides a callback URI for getting notified about change of (local) SCP Domain Routing Information, the NRF shall notify the NF Service Consumer, when the (local) SCP Domain Routing Information is updated.

6.2.5.2.2 Notification Definition

The POST method shall be used for SCP Domain Routing Information Change Notification and the URI shall be the callback reference provided by the NF Service Consumer during the subscription to this notification.

Resource URI: {callbackUri}

Support of URI query parameters are specified in table 6.2.5.2.2-1.

Table 6.2.5.2.2-1: URI query parameters supported by the POST method

Name

Data type

P

Cardinality

Description

n/a

Support of request data structures is specified in table 6.2.5.2.2-2, and support of response data structures and response codes is specified in table 6.2.5.2-3.

Table 6.2.5.2.2-2: Data structures supported by the POST Request Body

Data type

P

Cardinality

Description

ScpDomainRoutingInfoNotification

M

1

Representation of the SCP Domain Routing Information Change Notification.

Table 6.2.5.2.2-3: Data structures supported by the POST Response Body

Data type

P

Cardinality

Response

codes

Description

N/A

204 No Content

This case represents a successful notification of SCP Domain Routing Information Change.

NOTE: The mandatory HTTP error status codes for the POST method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] other than those specified in the table above also apply, with a ProblemDetails data type (see clause 5.2.7 of 3GPP TS 29.500 [4]).

6.2.6 Data Model

6.2.6.1 General

This clause specifies the application data model supported by the API.

Table 6.2.6.1-1 specifies the data types defined for the Nnrf service based interface protocol.

Table 6.2.6.1-1: Nnrf_NFDiscovery specific Data Types

Data type

Clause defined

Description

SearchResult

6.2.6.2.2

Contains the list of NF Profiles returned in a Discovery response.

NFProfile

6.2.6.2.3

Information of an NF Instance discovered by the NRF.

NFService

6.2.6.2.4

Information of a given NF Service Instance; it is part of the NFProfile of an NF Instance discovered by the NRF.

StoredSearchResult

6.2.6.2.5

Contains a complete search result (i.e. a number of discovered NF Instances), stored by NRF as a consequence of a prior search result.

PreferredSearch

6.2.6.2.6

Contains information on whether the returned NFProfiles match the preferred query parameters.

NfInstanceInfo

6.2.6.2.7

Contains information on an NF profile matching a discovery request.

ScpDomainRoutingInfo

6.2.6.2.8

SCP Domain Routing Information

ScpDomainConnectivity

6.2.6.2.9

SCP Domain Routing Information

ScpDomainRoutingInfoSubscription

6.2.6.2.10

SCP Domain Routing Information Subscription

ScpDomainRoutingInfoNotification

6.2.6.2.11

Notification for SCP Domain Routing Information Update

NfServiceInstance

6.2.6.2.12

NF service instance

NoProfileMatchInfo

6.2.6.2.13

No Profile Matching information

QueryParamCombination

6.2.6.2.14

Contains a list of query parameters

QueryParameter

6.2.6.2.15

Contains name and value of a query parameter

Table 6.2.6.1-2 specifies data types re-used by the Nnrf_NFDiscovery service-based interface protocol from other specifications, including a reference to their respective specifications and when needed, a short description of their use within the Nnrf_NFDiscovery service-based interface.

Table 6.2.6.1-2: Nnrf_NFDiscovery re-used Data Types

Data type

Reference

Comments

Snssai

3GPP TS 29.571 [7]

PlmnId

3GPP TS 29.571 [7]

Dnn

3GPP TS 29.571 [7]

Tai

3GPP TS 29.571 [7]

SupportedFeatures

3GPP TS 29.571 [7]

NfInstanceId

3GPP TS 29.571 [7]

Uri

3GPP TS 29.571 [7]

Gpsi

3GPP TS 29.571 [7]

GroupId

3GPP TS 29.571 [7]

Guami

3GPP TS 29.571 [7]

IPv4Addr

3GPP TS 29.571 [7]

IPv6Addr

3GPP TS 29.571 [7]

UriScheme

3GPP TS 29.571 [7]

Dnai

3GPP TS 29.571 [7]

NfGroupId

3GPP TS 29.571 [7]

Identifier of a NF Group

PduSessionType

3GPP TS 29.571 [7]

AtsssCapability

3GPP TS 29.571 [7]

PlmnIdNid

3GPP TS 29.571 [7]

NfSetId

3GPP TS 29.571 [7]

NfServiceSetId

3GPP TS 29.571 [7]

ExtSnssai

3GPP TS 29.571 [7]

DurationSec

3GPP TS 29.571 [7]

RedirectResponse

3GPP TS 29.571 [7]

Response body of the redirect response message.

MbsSessionId

3GPP TS 29.571 [7]

MBS Session Identifier

IpAddr

3GPP TS 29.571 [7]

IP Address

AreaSessionId

3GPP TS 29.571 [7]

Area Session Identifier used for an MBS session with location dependent content

Fqdn

3GPP TS 29.571 [7]

Fully Qualified Domain Name

EventId

3GPP TS 29.520 [32]

Defined in Nnwdaf_AnalyticsInfo API.

NwdafEvent

3GPP TS 29.520 [32]

Defined in Nnwdaf_EventsSubscription API.

ExtGroupId

3GPP TS 29.503 [36]

SharedDataId

3GPP TS 29.503 [36]

ExternalClientType

3GPP TS 29.572 [33]

SupportedGADShapes

3GPP TS 29.572 [33]

Supported GAD Shapes

DefaultNotificationSubscription

3GPP TS 29.510

See clause 6.1.6.2.4

IPEndPoint

3GPP TS 29.510

See clause 6.1.6.2.5

NFType

3GPP TS 29.510

See clause 6.1.6.3.3

UdrInfo

3GPP TS 29.510

See clause 6.1.6.2.6

UdmInfo

3GPP TS 29.510

See clause 6.1.6.2.7

AusfInfo

3GPP TS 29.510

See clause 6.1.6.2.8

SupiRange

3GPP TS 29.510

See clause 6.1.6.2.9

AmfInfo

3GPP TS 29.510

See clause 6.1.6.2.11

SmfInfo

3GPP TS 29.510

See clause 6.1.6.2.12

UpfInfo

3GPP TS 29.510

See clause 6.1.6.2.13

PcfInfo

3GPP TS 29.510

See clause 6.1.6.2.20

BsfInfo

3GPP TS 29.510

See clause 6.1.6.2.21

ChfInfo

3GPP TS 29.510

See clause 6.1.6.2.32

NFServiceVersion

3GPP TS 29.510

See clause 6.1.6.2.19

PlmnSnssai

3GPP TS 29.510

See clause 6.1.6.2.44

NwdafInfo

3GPP TS 29.510

See clause 6.1.6.2.45

NFStatus

3GPP TS 29.510

See clause 6.1.6.3.7

DataSetId

3GPP TS 29.510

See clause 6.1.6.3.8

ServiceName

3GPP TS 29.510

See clause 6.1.6.3.11

NFServiceStatus

3GPP TS 29.510

See clause 6.1.6.3.12

LmfInfo

3GPP TS 29.510

See clause 6.1.6.2.46

GmlcInfo

3GPP TS 29.510

See clause 6.1.6.2.47

NefInfo

3GPP TS 29.510

See clause 6.1.6.2.48

PfdData

3GPP TS 29.510

See clause 6.1.6.2.49

AfEventExposureData

3GPP TS 29.510

See clause 6.1.6.2.50

PcscfInfo

3GPP TS 29.510

See clause 6.1.6.2.53

HssInfo

3GPP TS 29.510

See clause 6.1.6.2.57

ImsiRange

3GPP TS 29.510

See clause 6.1.6.2.58

VendorSpecificFeature

3GPP TS 29.510

See clause 6.1.6.2.62

ScpInfo

3GPP TS 29.510

See clause 6.1.6.2.65

NefId

3GPP TS 29.510

See clause 6.1.6.3

VendorId

3GPP TS 29.510

See clause 6.1.6.3

AnNodeType

3GPP TS 29.510

See clause 6.1.6.3.13

SuciInfo

3GPP TS 29.510

See clause 6.1.6.2.71

SeppInfo

3GPP TS 29.510

See clause 6.1.6.2.72

NsacfInfo

3GPP TS 29.510

See clause 6.1.6.2.81

NsacfCapability

3GPP TS 29.510

See clause 6.1.6.2.82

MlAnalyticsInfo

3GPP TS 29.510

See clause 6.1.6.2.84

MbSmfInfo

3GPP TS 29.510

See clause 6.1.6.2.85

TsctsfInfo

3GPP TS 29.510

See clause 6.1.6.2.91

MbUpfInfo

3GPP TS 29.510

See clause 6.1.6.2.94

TrustAfInfo

3GPP TS 29.510

See clause 6.1.6.2.96

CollocatedNfInstance

3GPP TS 29.510

See clause 6.1.6.2.99

NssaafInfo

3GPP TS 29.510

See clause 6.1.6.2.104

IwmscInfo

3GPP TS 29.510

See clause 6.1.6.2.108

MnpfInfo

3GPP TS 29.510

See clause 6.1.6.2.109

LocalityDescriptionItem

3GPP TS 29.510

See clause 6.1.6.2.111

LocalityDescription

3GPP TS 29.510

See clause 6.1.6.2.112

LocalityType

3GPP TS 29.510

See clause 6.1.6.3.18

6.2.6.2 Structured data types

6.2.6.2.1 Introduction

This clause defines the structures to be used in resource representations.

6.2.6.2.2 Type: SearchResult

Table 6.2.6.2.2-1: Definition of type SearchResult

Attribute name

Data type

P

Cardinality

Description

validityPeriod

integer

M

1

It shall contain the time in seconds during which the discovery result is considered valid and can be cached by the NF Service Consumer. This value shall be the same as the value contained in the "max-age" parameter of the "Cache-Control" header field sent in the HTTP response.

nfInstances

array(NFProfile)

M

0..N

It shall contain an array of NF Instance profiles, matching the search criteria indicated by the query parameters of the discovery request. If the nfInstancesList IE is absent, an empty array means there is no NF instance that can match the search criteria.

NF instance profiles included in this IE shall not contain authorization attributes (such as the "allowedXXX" attributes of the NFProfile or NFService data types).

completeNfInstances

array(NFProfile)

C

1..N

When present, it shall contain an array of complete NF Instance profiles (including authorization attributes such as the "allowedXXX" attributes of the NFProfile or NFService data types), matching the search criteria indicated by the query parameters of the discovery request.

This IE shall only be present if the NRF supports the "Complete-Profile-Discovery" feature, the "complete-profile" query parameter is present and set to true in the request (see clause 6.2.3.2.3.1) and if the requesting entity is authorized to discover the complete profile of NF instances.

searchId

string

O

0..1

This IE may be present if the NRF stores the result of the current service discovery response in a given URL (server-side caching), to make it available in the future to NF Service Consumers without having to compute the whole search process again.

numNfInstComplete

Uint32

O

0..1

This IE may be present when the total number of NF Instances found by NRF, as the result of the service discovery process, is higher than the actual number of NF Instances included in the attribute nfInstances of the SearchResult object. This may happen due to the NF Service Consumer including in the discovery request parameters such as "limit" or "max-payload-size".

preferredSearch

PreferredSearch

C

0..1

This IE shall be present to indicate whether all the returned NFProfiles match the preferred query parameters, if the discovery request contains any of the query parameter defined in the PreferredSearch data type.

nrfSupportedFeatures

SupportedFeatures

C

0..1

Features supported by the NRF for the NFDiscovery service (see clause 6.2.9).

This IE should be present if the NRF supports at least one feature.

nfInstanceList

map(NfInstanceInfo)

O

1..N

This IE may be present if the NF Discovery request indicated support of the Enh-NF-Discovery feature.

When present, this IE shall contain a map of NfInstanceInfo of NF instance profiles matching the search criteria indicated by the query parameters of the discovery request. The key of the map shall be the NF instance ID.

(NOTE 2)

alteredPriorityInd

boolean

O

0..1

This IE shall indicate whether the NRF altered the priority values returned in the search result or not. (NOTE 1, NOTE 3)

When present, this IE shall be set as following:

– true: NF instances with NRF altered priority are returned in the search result.

– false: the NRF has not altered priority values in any NF instance returned in the search result

noProfileMatchInfo

NoProfileMatchInfo

O

0..1

This IE may be present if an empty array of nfInstances is conveyed and the nfInstancesList IE is absent; otherwise it shall be absent.

If present, it shall indicate the specific reason for not finding any NF instance that can match the search criteria.

NOTE 1: If NRF altered priority values are returned in the search result, when the NF consumer receives a different priority value in a subsequent NF Profile change notification for NF instance(s) returned in the search result, the NF consumer should not overwrite the NRF altered priority in the cached search result.

NOTE 2: If the alteredPriorityInd IE is present and set to true and the nrfAlteredPriorities IE is not included for a certain NF instance of the nfInstanceList, the NF consumer shall apply the priorities retrieved in the corresponding NF profile for this NF instance when selecting a NF service producer for the corresponding NF Discovery request.

NOTE 3: This IE shall be set if the NRF altered the priority values of one or more NF instances returned in the search result, regardless of whether the NF instances are returned in the nfInstances IE and/or nfInstanceList IE.

6.2.6.2.3 Type: NFProfile

Table 6.2.6.2.3-1: Definition of type NFProfile

Attribute name

Data type

P

Cardinality

Description

nfInstanceId

NfInstanceId

M

1

Unique identity of the NF Instance.

nfType

NFType

M

1

Type of Network Function

nfStatus

NFStatus

M

1

Status of the NF Instance

collocatedInstances

array(CollocatedNfInstance)

O

1..N

Information related collocated NF type(s) and corresponding NF Instance(s) when the NF is collocated with NFs supporting other NF types

nfInstanceName

string

O

0..1

Human readable name of the NF Instance

plmnList

array(PlmnId)

C

1..N

PLMN(s) of the Network Function (NOTE 5). This IE shall be present if this information is available for the NF. If this information was not provided by the NF during registration, the NRF should return the list of PLMN ID(s) of the PLMN of the NRF. If this IE is absent in the response, PLMN ID(s) of the PLMN of the NRF are assumed for the NF.

sNssais

array(ExtSnssai)

O

1..N

S-NSSAIs of the Network Function.

If not provided, and if the perPlmnSnssaiList attribute is not present, the NF can serve any S-NSSAI.

If the sNSSAIs attribute is provided in at least one NF Service, the sNssais attribute in the NF Profile shall be present and be the set or a superset of the sNSSAIs of the NFService(s).

perPlmnSnssaiList

array(PlmnSnssai)

O

1..N

The per-PLMN list of S-NSSAI(s) supported by the Network Function.

If the perPlmnSnssaiList attribute is provided in at least one NF Service, the perPlmnSnssaiList attribute in the NF Profile shall be present and be the set or a superset of the perPlmnSnssaiList of the NFService(s).

nsiList

array(string)

O

1..N

List of NSIs of the Network Function.

If not provided, the NF can serve any NSI.

fqdn

Fqdn

C

0..1

FQDN of the Network Function (NOTE 1, NOTE 3, NOTE 11)

interPlmnFqdn

Fqdn

C

0..1

If the requester-plmn-list query parameter is absent in the NF Discovery request, or if is present and the requester’s PLMN is the same as the PLMN of the discovered NF, then this attribute shall be included by the NRF and it shall contain the interPlmnFqdn value registered by the NF during NF registration (see clause 6.1.6.2.2), if the interPlmnFqdn attribute was registered in the NF profile.

This attribute shall be absent if the requester-plmn in the query parameter is different from the PLMN of the discovered NF.

(NOTE 3, NOTE 14)

ipv4Addresses

array(Ipv4Addr)

C

1..N

IPv4 address(es) of the Network Function (NOTE 1, NOTE 11)

ipv6Addresses

array(Ipv6Addr)

C

1..N

IPv6 address(es) of the Network Function (NOTE 1, NOTE 11)

allowedPlmns

array(PlmnId)

C

1..N

PLMNs allowed to access the NF instance.

This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise.

If not provided, any PLMN is allowed to access the NF.

allowedSnpns

array(PlmnIdNid)

C

1..N

SNPNs allowed to access the NF instance.

This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise.

If this attribute is present in the NFService and in the NF profile, the attribute from the NFService shall prevail.

The absence of this attribute in both the NFService and in the NF profile indicates that no SNPN, other than the SNPN(s) registered in the snpnList attribute of the NF Profile, is allowed to access the service instance.

allowedNfTypes

array(NFType)

C

1..N

Type of the NFs allowed to access the NF instance.

This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise.

If not provided, any NF type is allowed to access the NF.

allowedNfDomains

array(string)

C

1..N

Pattern (regular expression according to the ECMA-262 dialect [8]) representing the NF domain names within the PLMN of the NRF allowed to access the NF instance.

This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise.

If not provided, any NF domain is allowed to access the NF.

allowedNssais

array(ExtSnssai)

C

1..N

S-NSSAI of the allowed slices to access the NF instance.

This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise.

If not provided, any slice is allowed to access the NF.

capacity

integer

O

0..1

Static capacity information within the range 0 to 65535, expressed as a weight relative to other NF instances of the same type; if capacity is also present in the nfServiceList parameters, those will have precedence over this value. (See NOTE 2)

load

integer

O

0..1

Latest known load information of the NF within the range 0 to 100 in percentage (See NOTE 4)

loadTimeStamp

DateTime

O

0..1

It indicates the point in time in which the latest load information of the NF Instance was sent from the NF to the NRF.

locality

string

O

0..1

Operator defined information about the location of the NF instance (e.g. geographic location, data center)

extLocality

map(string)

O

1..N

Operator defined information about the location of the NF instance. (NOTE 3)

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters, representing a type of locality as defined in clause 6.1.6.3.x.

Example:

{

"DATA_CENTER": "dc-123",

"CITY": "Los Angeles",

"STATE": "California"

}

priority

integer

O

0..1

Priority (relative to other NFs of the same type) within the range 0 to 65535, to be used for NF selection; lower values indicate a higher priority. Priority may or may not be present in the nfServiceList parameters, xxxInfo parameters and in this attribute. Priority in the nfServiceList has precedence over the priority in this attribute.

(NOTE 2)

Priority in xxxInfo parameter shall only be used to determine the relative priority among NF instances with the same priority at NFProfile/NFService.

udrInfo

UdrInfo

O

0..1

Specific data for the UDR (ranges of SUPI, …)

udrInfoList

map(UdrInfo)

O

1..N

Multiple entries of UdrInfo. This attribute provides additional information to the udrInfo. udrInfoList may be present even if the udrInfo is absent.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

udmInfo

UdmInfo

O

0..1

Specific data for the UDM

udmInfoList

map(UdmInfo)

O

1..N

Multiple entries of UdmInfo. This attribute provides additional information to the udmInfo. udmInfoList may be present even if the udmInfo is absent.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

ausfInfo

AusfInfo

O

0..1

Specific data for the AUSF

ausfInfoList

map(AusfInfo)

O

1..N

Multiple entries of AusfInfo. This attribute provides additional information to the ausfInfo. ausfInfoList may be present even if the ausfInfo is absent.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

amfInfo

AmfInfo

O

0..1

Specific data for the AMF (AMF Set ID, …)

amfInfoList

map(AmfInfo)

O

1..N

Multiple entries of AmfInfo. This attribute provides additional information to the amfInfo. amfInfoList may be present even if the amfInfo is absent.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

smfInfo

SmfInfo

O

0..1

Specific data for the SMF (DNN’s, …).

(NOTE 8)

smfInfoList

map(SmfInfo)

O

1..N

Multiple entries of SmfInfo. This attribute provides additional information to the smfInfo. smfInfoList may be present even if the smfInfo is absent.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

(NOTE 8)

upfInfo

UpfInfo

O

0..1

Specific data for the UPF (S-NSSAI, DNN, SMF serving area, …)

upfInfoList

map(UpfInfo)

O

1..N

Multiple entries of UpfInfo. This attribute provides additional information to the upfInfo. upfInfoList may be present even if the upfInfo is absent.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

pcfInfo

PcfInfo

O

0..1

Specific data for the PCF

pcfInfoList

map(PcfInfo)

O

1..N

Multiple entries of PcfInfo. This attribute provides additional information to the pcfInfo. pcfInfoList may be present even if the pcfInfo is absent.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

bsfInfo

BsfInfo

O

0..1

Specific data for the BSF

bsfInfoList

map(BsfInfo)

O

1..N

Multiple entries of BsfInfo. This attribute provides additional information to the bsfInfo. bsfInfoList may be present even if the bsfInfo is absent.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

chfInfo

ChfInfo

O

0..1

Specific data for the CHF

chfInfoList

map(ChfInfo)

O

1..N

Multiple entries of ChfInfo. This attribute provides additional information to the chfInfo. chfInfoList may be present even if the chfInfo is absent.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

udsfInfo

UdsfInfo

O

0..1

Specific data for the UDSF

udsfInfoList

map(UdsfInfo)

O

1..N

Multiple entries of udsfInfo. This attribute provides additional information to the udsfInfo. udsfInfoList may be present even if the udsfInfo is absent.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

nefInfo

NefInfo

O

0..1

Specific data for the NEF

nwdafInfo

NwdafInfo

O

0..1

Specific data for the NWDAF

nwdafInfoList

map(NwdafInfo)

O

1..N

Multiple entries of nwdafInfo. This attribute provides additional information to the nwdafInfo. nwdafInfoList may be present even if the nwdafInfo is absent.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

pcscfInfoList

map(PcscfInfo)

O

1..N

Specific data for the P-CSCF.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

(NOTE 7)

hssInfoList

map(HssInfo)

O

1..N

Specific data for the HSS.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

customInfo

object

O

0..1

Specific data for custom Network Functions

recoveryTime

DateTime

O

0..1

Timestamp when the NF was (re)started

nfServicePersistence

boolean

O

0..1

– true: If present, and set to true, it indicates that the different service instances of a same NF Service in the NF instance, supporting a same API version, are capable to persist their resource state in shared storage and therefore these resources are available after a new NF service instance supporting the same API version is selected by a NF Service Consumer (see 3GPP TS 23.527 [27]).

– false (default): Otherwise, it indicates that the NF Service Instances of a same NF Service are not capable to share resource state inside the NF Instance.

nfServices

array(NFService)

O

1..N

List of NF Service Instances.

(NOTE 10)

This attribute is deprecated; the attribute "nfServiceList" should be used instead.

nfServiceList

map(NFService)

O

1..N

Map of NF Service Instances, where the "serviceInstanceId" attribute of the NFService object shall be used as the key of the map.

(NOTE 10)

defaultNotificationSubscriptions

array(DefaultNotificationSubscription)

O

1..N

Notification endpoints for different notification types.

(NOTE 6)

(See also NOTE 10 in clause 6.1.6.2.2)

lmfInfo

LmfInfo

O

0..1

Specific data for the LMF

gmlcInfo

GmlcInfo

O

0..1

Specific data for the GMLC

snpnList

array(PlmnIdNid)

C

1..N

SNPN(s) of the Network Function.

This IE shall be present if the NF pertains to one or more SNPNs.

nfSetIdList

array(NfSetId)

C

1..N

NF Set ID defined in clause 28.12 of 3GPP TS 23.003 [12].

At most one NF Set ID shall be indicated per PLMN-ID or SNPN of the NF.

This information shall be present if available.

servingScope

array(string)

O

1..N

The served area(s) of the NF instance.

The absence of this attribute does not imply the NF instance can serve every area.

lcHSupportInd

boolean

O

0..1

This IE indicates whether the NF supports Load Control based on LCI Header (see clause 6.3 of 3GPP TS 29.500 [4]).

– true: the NF supports the feature.

– false (default): the NF does not support the feature.

olcHSupportInd

boolean

O

0..1

This IE indicates whether the NF supports Overload Control based on OCI Header (see clause 6.4 of 3GPP TS 29.500 [4]).

– true: the NF supports the feature.

– false (default): the NF does not support the feature.

nfSetRecoveryTimeList

map(DateTime)

O

1..N

Map of recovery time, where the key of the map is the NfSetId of NF Set(s) that the NF instance belongs to.

When present, the value of each entry of the map shall be the recovery time of the NF Set indicated by the key.

serviceSetRecoveryTimeList

map(DateTime)

O

1..N

Map of recovery time, where the key of the map is the NfServiceSetId of the NF Service Set(s) configured in the NF instance.

When present, the value of each entry of the map shall be the recovery time of the NF Service Set indicated by the key.

scpDomains

array(string)

O

1..N

When present, this IE shall carry the list of SCP domains the SCP belongs to, or the SCP domain the NF (other than SCP) or the SEPP belongs to.

(NOTE 9)

scpInfo

ScpInfo

O

0..1

Specific data for the SCP.

seppInfo

SeppInfo

O

0..1

Specific data for the SEPP.

vendorId

VendorId

O

0..1

Vendor ID of the NF instance, according to the IANA-assigned "SMI Network Management Private Enterprise Codes" [38].

supportedVendorSpecificFeatures

map(array(VendorSpecificFeature))

O

1..N(1..M)

Map of Vendor-Specific features, where the key of the map is the IANA-assigned "SMI Network Management Private Enterprise Codes" [38]. The string used as key of the map shall contain 6 decimal digits; if the SMI code has less than 6 digits, it shall be padded with leading digits "0" to complete a 6-digit string value.

The value of each entry of the map shall be a list (array) of VendorSpecificFeature objects.

(NOTE 12)

aanfInfoList

map(AanfInfo)

O

1..N

Specific data for the AAnF.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

mfafInfo

MfafInfo

O

0..1

Specific data for the MFAF.

easdfInfoList

map(EasdfInfo)

O

1..N

Specific data for the EASDF.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

(NOTE 13)

dccfInfo

DccfInfo

O

0..1

Specific data for the DCCF.

nsacfInfoList

map(NsacfInfo)

O

1..N

Specific data for the NSACF.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

mbSmfInfoList

map(MbSmfInfo)

O

1..N

MB-SMF specific data.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

tsctsfInfoList

map(TsctsfInfo)

O

1..N

Specific data for the TSCTSF.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

mbUpfInfoList

map(MbUpfInfo)

O

1..N

MB-UPF specific data.

The key of the map shall be a (unique) valid JSON string per clause 7 of IETF RFC 8259 [22], with a maximum of 32 characters.

trustAfInfo

TrustAfInfo

O

0..1

Specific data for the trusted AF.

nssaafInfo

NssaafInfo

O

0..1

Specific data for the NSSAAF.

hniList

arrary(Fqdn)

C

1..N

Identifications of Credentials Holder or Default Credentials Server.

This IE shall be present if the NFs are available for the case of access to an SNPN using credentials owned by a Credentials Holder or for the case of SNPN Onboarding using a DCS.

iwmscInfo

IwmscInfo

O

0..1

Specific data for the SMS-IWMSC.

mnpfInfo

MnpfInfo

O

0..1

Specific data for the MNPF.

smsfInfo

SmsfInfo

O

0..1

Specific data for the SMSF.

NOTE 1: At least one of the addressing parameters (fqdn, ipv4address or ipv6adress) shall be included in the NF Profile. See NOTE 1 of Table 6.2.6.2.4-1 for the use of these parameters. If multiple ipv4 addresses and/or ipv6 addresses are included in the NF Profile, the NF Service Consumer shall select one of these addresses randomly, unless operator defined local policy of IP address selection, in order to avoid overload for a specific ipv4 address and/or ipv6 address.

NOTE 2: The capacity and priority parameters, if present, are used for NF selection and load balancing. The priority and capacity attributes shall be used for NF selection in the same way that priority and weight are used for server selection as defined in IETF RFC 2782 [23].

NOTE 3: If the requester-plmn in the query parameter is different from the PLMN of the discovered NF, then the fqdn attribute value shall contain the interPlmnFqdn value registered by the NF during NF registration (see clause 6.1.6.2.2). The requester-plmn is different from the PLMN of the discovered NF if it belongs to none of the PLMN ID(s) configured for the PLMN of the NRF.

NOTE 4: The usage of the load parameter by the NF service consumer is implementation specific, e.g. be used for NF selection and load balancing, together with other parameters.

NOTE 5: An NF may register multiple PLMN IDs in its profile within a PLMN comprising multiple PLMN IDs. If so, all the attributes of the NF Profile shall apply to each PLMN ID registered in the plmnList. As an exception, attributes including a PLMN ID, e.g. IMSI-based SUPI ranges, TAIs and GUAMIs, are specific to one PLMN ID and the NF may register in its profile multiple occurrences of such attributes for different PLMN IDs (e.g. the UDM may register in its profile SUPI ranges for different PLMN IDs).

NOTE 6: For notification types that may be associated with a specifc service of the NF Instance receiving the notification (see clause 6.1.6.3.4), if notification endpoints are present both in the profile of the NF instance (NFProfile) and in some of its NF Services (NFService) for a same notification type, the notification endpoint(s) of the NF Services shall be used for this notification type.

NOTE 7: The absence of the pcscfInfoList attribute in a P-CSCF profile indicates that the P-CSCF can be selected for any DNN and Access Type, and that the P-CSCF Gm addressing information is the same as the addressing information registered in the fqdn, ipv4Addresses and ipv4Addresses attributes of the NF profile.

NOTE 8: The absence of both the smfInfo and smfInfoList attributes in an SMF profile indicates that the SMF can be selected for any S-NSSAI listed in the sNssais and perPlmnSnssaiList IEs, or for any S-NSSAI if neither the sNssais IE nor the perPlmnSnssaiList IE are present, and for any DNN, TAI and access type.

NOTE 9: If an NF (other than a SCP or SEPP) includes this information in its profile, this indicates that the services produced by this NF should be accessed preferably via an SCP from the SCP domain the NF belongs to.

NOTE 10: If the NF Service Consumer that issued the discovery request indicated support for the "Service-Map" feature, the NRF shall return in the discovery response the list of NF Service Instances in the "nfServiceList" map attribute. Otherwise, the NRF shall return the list of NF Service Instances in the "nfServices" array attribute.

NOTE 11: For API URIs constructed with an FQDN, the NF Service Consumer may use the FQDN of the target URI to do a DNS query and obtain the IP address(es) to setup the TCP connection, and ignore the IP addresses that may be present in the NFProfile; alternatively, the NF Service Consumer may use those IP addresses to setup the TCP connection, if no service-specific FQDN or IP address is provided in the NFService data and if the NF Service Consumer supports to indicate specific IP address(es) to establish an HTTP/2 connection with an FQDN in the target URI.

NOTE 12: When present, this attribute allows an NF requesting NF Discovery (e.g. an NF Service Consumer) to determine which vendor-specific extensions are supported in a given NF (e.g. an NF Service Producer), so as to select an appropriate NF with specific capability, or to include or not the vendor-specific attributes (see 3GPP TS 29.500 [4] clause 6.6.3) required for a given feature in subsequent messages towards a certain NF. One given vendor-specific feature shall not appear in both NF Profile and NF Service Profile. If one vendor-specific feature is service related, it shall only be included in the NF Service Profile.

NOTE 13: The absence of the easdfnfoList attributes in an EASDF profile indicates that the EASDF can be selected for any S-NSSAI, DNN, DNAI or PSA UPF N6 IP address.

NOTE 14: This attribute may be used by the requester NF or SCP e.g. to build the authority of the Location header in 3xx response or to set the 3gpp-Sbi-apiRoot header in a response message (see clause 6.10.4 of 3GPP TS 29.500 [4]), when the NF redirects a request issued by a consumer from a different PLMN towards the discovered NF, or when the SCP has reselected the discovered NF for such a request.

6.2.6.2.4 Type: NFService

Table 6.2.6.2.4-1: Definition of type NFService

Attribute name

Data type

P

Cardinality

Description

serviceInstanceId

string

M

1

Unique ID of the service instance within a given NF Instance

serviceName

ServiceName

M

1

Name of the service instance (e.g. "udm-sdm")

versions

array(NFServiceVersion)

M

1..N

The API versions supported by the NF Service and if available, the corresponding retirement date of the NF Service.

The different array elements shall have distinct unique values for "apiVersionInUri", and consequently, the values of "apiFullVersion" shall have a unique first digit version number.

scheme

UriScheme

M

1

URI scheme (e.g. "http", "https")

nfServiceStatus

NFServiceStatus

M

1

Status of the NF Service Instance

fqdn

Fqdn

O

0..1

FQDN of the NF Service Instance (see NOTE 1, NOTE 3, NOTE 9).

The FQDN provided as part of the NFService information has precedence over the FQDN and IP addresses provided as part of the NFProfile information (see clause 6.1.6.2.2).

interPlmnFqdn

Fqdn

C

0..1

If the requester-plmn-list query parameter is absent in the NF Discovery request, or if is present and the requester’s PLMN is the same as the PLMN of the discovered NF Service, then this attribute shall be included by the NRF and it shall contain the interPlmnFqdn value registered for the NF Service during NF registration (see clause 6.1.6.2.3), if the interPlmnFqdn attribute was registered for the NF Service in the NF profile.

This attribute shall be absent if the requester-plmn in the query parameter is different from the PLMN of the discovered NF Service.

(NOTE 3, NOTE 10)

ipEndPoints

array(IpEndPoint)

O

1..N

IP address(es) and port information of the Network Function (including IPv4 and/or IPv6 address) where the service is listening for incoming service requests (see NOTE 1, NOTE 5, NOTE 6, NOTE 9).

IP addresses provided in ipEndPoints have precedence over IP addresses provided as part of the NFProfile information and, when using the HTTP scheme, over FQDN provided as part of the NFProfile information (see clause 6.2.6.2.3).

apiPrefix

string

O

0..1

Optional path segment(s) used to construct the {apiRoot} variable of the different API URIs, as described in 3GPP TS 29.501 [5], clause 4.4.1 (optional deployment-specific string that starts with a "/" character)

defaultNotificationSubscriptions

array(DefaultNotificationSubscription)

O

1..N

Notification endpoints for different notification types.

(See also NOTE 10 in clause 6.1.6.2.2)

allowedPlmns

array(PlmnId)

C

1..N

PLMNs allowed to access the service instance (NOTE 12).

This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise.

The absence of this attribute indicates that any PLMN is allowed to access the service instance.

When included, the allowedPlmns attribute needs not include the PLMN ID(s) registered in the plmnList attribute of the NF Profile, i.e. the PLMN ID(s) registered in the NF Profile shall be considered to be allowed to access the service instance.

allowedSnpns

array(PlmnIdNid)

C

1..N

SNPNs allowed to access the service instance.

This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise.

If this attribute is present in the NFService and in the NF profile, the attribute from the NFService shall prevail.

The absence of this attribute in both the NFService and in the NF profile indicates that no SNPN, other than the SNPN(s) registered in the snpnList attribute of the NF Profile, is allowed to access the service instance.

When included, the allowedSnpns attribute needs not include the PLMN ID/NID(s) registered in the snpnList attribute of the NF Profile, i.e. the SNPNs registered in the NF Profile shall be considered to be allowed to access the service instance.

allowedNfTypes

array(NFType)

C

1..N

Type of the NFs allowed to access the service instance (NOTE 12).

This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise.

The absence of this attribute indicates that any NF type is allowed to access the service instance.

allowedNfDomains

array(string)

C

1..N

Pattern (regular expression according to the ECMA-262 dialect [8]) representing the NF domain names within the PLMN of the NRF allowed to access the service instance (NOTE 12).

This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise.

The absence of this attribute indicates that any NF domain is allowed to access the service instance.

allowedNssais

array(ExtSnssai)

C

1..N

S-NSSAI of the allowed slices to access the service instance (NOTE 12).

This attribute may be present in a complete NF profile (i.e. in the completeNfInstances IE in the SearchResult or StoredSearchResult data types). It shall not be present otherwise.

The absence of this attribute indicates that any slice is allowed to access the service instance.

capacity

integer

O

0..1

Static capacity information within the range 0 to 65535, expressed as a weight relative to other services of the same type. (See NOTE 2)

load

integer

O

0..1

Latest known load information of the NF Service, within the range 0 to 100 in percentage. (See NOTE 4)

loadTimeStamp

DateTime

O

0..1

It indicates the point in time in which the latest load information of the NF Service Instance was sent from the NF to the NRF.

priority

integer

O

0..1

Priority (relative to other services of the same type) within the range 0 to 65535, to be used for NF Service selection; lower values indicate a higher priority. (See NOTE 2)

recoveryTime

DateTime

O

0..1

Timestamp when the NF service was (re)started

supportedFeatures

SupportedFeatures

O

0..1

Supported Features of the NF Service instance

nfServiceSetIdList

array(NfServiceSetId)

C

1..N

NF Service Set ID (see clause 28.13 of 3GPP TS 23.003 [12])

At most one NF Service Set ID shall be indicated per PLMN-ID or SNPN of the NF.

This information shall be present if available.

sNssais

array(ExtSnssai)

O

1..N

S-NSSAIs of the NF Service. This may be a subset of the S-NSSAIs supported by the NF (see sNssais attribute in NFProfile).

When present, this IE represents the list of S-NSSAIs supported by the NF Service in all the PLMNs listed in the plmnList IE.

perPlmnSnssaiList

array(PlmnSnssai)

O

1..N

S-NSSAIs of the NF Service per PLMN. This may be a subset of the S-NSSAIs supported per PLMN by the NF (see perPlmnSnssaiList attribute in NFProfile).

This IE may be included when the list of S-NSSAIs supported by the NF Service for each PLMN it is supporting is different. When present, this IE shall include the S-NSSAIs supported by the NF Service for each PLMN. When present, this IE shall override the sNssais IE.

vendorId

VendorId

O

0..1

Vendor ID of the NF Service instance, according to the IANA-assigned "SMI Network Management Private Enterprise Codes" [38].

supportedVendorSpecificFeatures

map(array(VendorSpecificFeature)

O

1..N(1..M)

Map of Vendor-Specific features, where the key of the map is the IANA-assigned "SMI Network Management Private Enterprise Codes" [38]. The string used as key of the map shall contain 6 decimal digits; if the SMI code has less than 6 digits, it shall be padded with leading digits "0" to complete a 6-digit string value.

The value of each entry of the map shall be a list (array) of VendorSpecificFeature objects.

(NOTE 7)

oauth2Required

boolean

O

0..1

It indicates whether the NF Instance requires Oauth2-based authorization.

Absence of this IE means that the NF Service Producer has not provided any indication about its usage of Oauth2 for authorization.

(See NOTE 11)

allowedOperationsPerNfType

map(array(string))

C

1..N(1..M)

Map of allowed operations on resources for each type of NF; the key of the map is the NF Type, and the value is an array of scopes.

The scopes shall be any of those defined in the API that defines the current service (identified by the "serviceName" attribute).

This IE should be present, if it is present in the registered NF service instance and if the map contains a key matching the requester’s NF type. When present, this IE should only contain the key-value pair of the map matching the requester’s NF type.

(NOTE 8)

allowedOperationsPerNfInstance

map(array(string))

C

1..N(1..M)

Map of allowed operations on resources for a given NF Instance; the key of the map is the NF Instance Id, and the value is an array of scopes.

The scopes shall be any of those defined in the API that defines the current service (identified by the "serviceName" attribute).

This IE should be present, if it is present in the registered NF service instance and if the map contains a key matching the requester’s NF instance ID. When present, this IE should only contain the key-value pair of the map matching the requester’s NF Instance ID.

(NOTE 8)

allowedOperationsPerNfInstanceOverrides

boolean

O

0..1

This IE, when present and set to true, indicates that the scopes defined in attribute "allowedOperationsPerNfInstance" for a given NF Instance ID take precedence over the scopes defined in attribute "allowedOperationsPerNfType" for the corresponding NF type of the NF Instance associated to such NF Instance ID.

If the IE is not present, or set to false (default), it indicates that the allowed scopes are any of the scopes present either in "allowedOperationsPerNfType" or in "allowedOperationsPerNfInstance".

NOTE 1: The NF Service Consumer shall construct the API URIs of the service using:
– For intra-PLMN signalling: If TLS is used, the FQDN present in the NF Service Profile, if any; otherwise, the FQDN present in the NF Profile. If TLS is not used, the FQDN should be used if the NF Service Consumer uses Indirect Communication via an SCP; the FQDN or the IP address in the ipEndPoints attribute may be used if the NF Service Consumer uses Direct Communication.
– For inter-PLMN signalling: the FQDN present in the NF Service Profile, if any; otherwise, the FQDN present in the NF Profile (see NOTE 3).

NOTE 2: The capacity and priority parameters, if present, are used for service selection and load balancing. The priority and capacity attributes shall be used for NF selection in the same way that priority and weight are used for server selection as defined in IETF RFC 2782 [23].

NOTE 3: If the requester-plmn in the query parameter is different from the PLMN of the discovered NF Service, then the fqdn attribute value, if included shall contain the interPlmnFqdn value registered by the NF Service during NF registration (see clause 6.1.6.2.3). The requester-plmn is different from the PLMN of the discovered NF Service if it belongs to none of the PLMN ID(s) configured for the PLMN of the NRF.

NOTE 4: The usage of the load parameter by the NF service consumer is implementation specific, e.g. be used for NF service selection and load balancing, together with other parameters.

NOTE 5: If the NF Service Consumer, based on the FQDN and IP address related attributes of the NFProfile and NFService, determines that it needs to use an FQDN to establish the HTTP connection with the NF Service Producer, it shall use such FQDN for DNS query and, in absence of any port information in the ipEndPoints attribute of the NF Service, it shall use the default HTTP port number, i.e. TCP port 80 for "http" URIs or TCP port 443 for "https" URIs as specified in IETF RFC 7540 [9] when invoking the service.

NOTE 6: If multiple ipv4 addresses and/or ipv6 addresses are included in the NF Service, the NF Service Consumer shall select one of these addresses randomly, unless operator defined local policy of IP address selection, in order to avoid overload for a specific ipv4 address and/or ipv6 address.

NOTE 7: When present, this attribute allows the NF requesting NF discovery (e.g. an NF Service Consumer) to determine which vendor-specific extensions are supported in a given NF (e.g. an Service Producer) in order to select an appropriate NF, or to include or not include the vendor-specific attributes (see 3GPP TS 29.500 [4] clause 6.6.3) required for a given feature in subsequent service requests towards a certain service instance of the NF Service Producer. One given vendor-specific feature shall not appear in both NF Profile and NF Service Profile. If one vendor-specific feature is service related, it shall only be included in the NF Service Profile.

NOTE 8: These attributes are used by the NF Service Consumer in order to discover the additional scopes (resource/operation-level scopes) that might be required to invoke a certain service operation, based on the authorization information registered in NRF by the NF Service Producer in its NF profile. See also NOTE 11 of Table 6.1.6.2.3-1.

NOTE 9: For API URIs constructed with an FQDN, the NF Service Consumer may use the FQDN in the target URI to do a DNS query and obtain the IP address(es) to setup the TCP connection, and ignore the IP addresses that may be present in the ipEndPoints attribute; alternatively, the NF Service Consumer may use those IP addresses to setup the TCP connection, if the NF Service Consumer supports to indicate specific IP address(es) to establish an HTTP/2 connection with an FQDN in the target URI.

NOTE 10: This attribute may be used by the requester NF or SCP e.g. to build the authority of the Location header in 3xx response or to set the 3gpp-Sbi-apiRoot header in a response message (see clause 6.10.4 of 3GPP TS 29.500 [4]), when the NF redirects a request issued by a consumer from a different PLMN towards the discovered NF service, or when the SCP has reselected the discovered NF service for such a request.

NOTE 11: If PLMN specific value is registered for the PLMN ID of the requester NF, the NRF shall set the oauth2Required attribute with the PLMN specific values (see description of perPlmnOauth2ReqList in clause 6.1.6.2.3).

NOTE 12: If this attribute is present in the NFService and in the NF profile, the attribute from the NFService shall prevail. The absence of this attribute in the NFService and in the NFProfile indicates that there is no corresponding restriction to access the service instance. If this attribute is absent in the NF Service, but it is present in the NF Profile, the attribute from the NF Profile shall be applied.

6.2.6.2.5 Type: StoredSearchResult

Table 6.2.6.2.5-1: Definition of type StoredSearchResult

Attribute name

Data type

P

Cardinality

Description

nfInstances

array(NFProfile)

M

0..N

An array of NF Instances corresponding to a given stored search result.

NF instance profiles included in this IE shall not contain authorization attributes (such as the "allowedXXX" attributes of the NFProfile or NFService data types).

completeNfInstances

array(NFProfile)

C

1..N

When present, it shall contain an array of complete NF Instance profiles (including authorization attributes such as the "allowedXXX" attributes of the NFProfile or NFService data types), matching the search criteria indicated by the query parameters of the discovery request.

.

This IE shall only be present if the NRF supports the "Complete-Profile-Discovery" feature, the "complete-profile" query parameter is present and set to true in the request (see clause 6.2.3.2.3.1), and if the requesting entity is authorized to discover the complete profile of NF instances.

6.2.6.2.6 Type: PreferredSearch

Table 6.2.6.2.6-1: Definition of type PreferredSearch

Attribute name

Data type

P

Cardinality

Description

preferredTaiMatchInd

boolean

C

0..1

Indicates whether all the returned NFProfiles match or do not match the query parameter preferred-tai.

true: Match
false (default): Not Match

preferredFullPlmnMatchInd

boolean

O

0..1

Indicates whether all the returned NFProfiles match or do not match the query parameter preferred-full-plmn.

true: Match
false (default): Not Match

preferredApiVersionsMatchInd

boolean

O

0..1

Indicates whether the search result includes at least one NF Profile that matches all the preferred API versions indicated in the query parameter preferred-api-versions.

true: Match
false: Not Match

otherApiVersionsInd

boolean

O

0..1

This IE may be present if the preferred-api-versions query parameter is provided in the discovery request.

When present, this IE indicates whether there is at least one NF Profile with other API versions, i.e. that does not match all the preferred API versions indicated in the preferred-api-versions, returned in the response or not.

true: Returned

false: Not returned

preferredLocalityMatchInd

boolean

O

0..1

Indicates whether the search result includes at least one NFProfile that match the query parameter preferred-locality or ext-preferred-locality.

true: Match
false (default): Not Match

otherLocalityInd

boolean

O

0..1

This IE may be present if the preferred-locality or ext-preferred-locality query parameter is provided in the discovery request.

When present, this IE indicates whether there is at least one NFProfile with another locality, i.e. not matching the preferred-locality or ext-preferred-locality, returned in the response or not.

true: Returned

false (default): Not returned

preferredVendorSpecificFeaturesInd

boolean

O

0..1

Indicates whether all the returned NFProfiles match (or do not match) the query parameter preferred-vendor-specific-features (i.e. whether they support all the preferred vendor-specific-features).

true: Match
false (default): Not Match

preferredCollocatedNfTypeInd

boolean

O

0..1

Indicates whether all the returned NFProfiles match (or do not match) the query parameter preferred-collocated-nf-types.

true: Match
false (default): Not Match

preferredPgwMatchInd

boolean

O

0..1

This IE may be present if preferred-pgw-ind query parameter is provided in the discovery request.

When present, this IE shall indicate whether all the returned NFProfiles match or do not match the query parameter preferred-pgw-ind.

true: Match
false: Not Match

preferredAnalyticsDelaysInd

boolean

C

0..1

This IE shall be present if preferred-analytics-delays query parameter is provided in the discovery request.

When present, this IE shall indicate whether all the returned NFProfiles match or do not match the query parameter preferred-analytics-delays.

true: Match
false: Not Match

preferredFeaturesMatchInd

boolean

O

0..1

Indicates whether the search result includes at least one NFProfile that supports all the preferred feature(s) indicated by the query parameter preferred-features.

true: Supported
false: Not supported

noPreferredFeaturesInd

boolean

O

0..1

Indicates whether the search result includes at least one NFProfile not supporting all the preferred feature(s) indicated by the query parameter preferred-features.

true: Returned

false: Not returned

NOTE: The PreferredSearch data type is used to encode the preferredSearch IE in SearchResult (see clause 6.2.6.2.2) and the preferredSearch IE in the NfInstanceInfo data type (see clause 6.2.6.2.7). The description of the IEs in the PreferredSearch data type is provided for the first case.
For the latter case, these IEs shall be interpreted as indicating whether the NF profile of the NF instance ID returned in the nfInstanceList IE of SearchResult matches the preference parameters, and the otherApiVersionsInd IE and the otherLocalityInd IE shall be absent.

6.2.6.2.7 Type: NfInstanceInfo

Table 6.2.6.2.7-1: Definition of type NfInstanceInfo

Attribute name

Data type

P

Cardinality

Description

nrfDiscApiUri

Uri

C

0..1

This IE shall be present if the NRF holding the NF profile is not the NRF that received the NFDiscover request. It may be present otherwise.

When present, this IE shall contain the API URI of the Nnrf_NFDiscovery service of the NRF holding the NF profile. The API URI shall be formatted as specified in clause 6.2.1

preferredSearch

PreferredSearch

O

0..1

This IE may be present to indicate whether the NF Profile matches the preferred query parameters, if the discovery request contains any of the query parameter defined in the PreferredSearch data type.

This IE shall take precedence over the preferredSearch IE in the SearchResult, if any.

nrfAlteredPriorities

map(integer)

O

1..N

This IE may be present if the NRF wishes to signal modified priorities for the NF instance.

The key of the map shall be the JSON Pointer (as specified in IETF RFC 6901 [14]) of the corresponding priority IE in the NFProfile data type defined in clause 6.2.6.2.3.

(NOTE)

NOTE: If this IE is present, the requester NF should apply the NRF altered priorities when selecting a NF service producer for the corresponding NF Discovery request, instead of the priorities retrieved in the corresponding NF profile.

EXAMPLE: The following JSON object would represent an NfInstanceInfo where the NRF signals modified priorities for the NF instance, two NF service instances and two smfInfo instances.

{

"nrfAlteredPriorities": {

"/priority": 1000,

"/nfServiceList/serviceinstance1/priority": 3000,

"/nfServiceList/serviceinstance2/priority": 5000,

"/smfInfo/priority": 20000,

"/smfInfoList/abcd/priority": 15000

}

}

6.2.6.2.8 Type: ScpDomainRoutingInformation

Table 6.1.6.2.8-1: Definition of type ScpDomainRoutingInformation

Attribute name

Data type

P

Cardinality

Description

scpDomainList

map(ScpDomainConnectivity)

M

0..N

This IE shall contain map of SCP domain interconnection information, where the key of the map is a SCP domain. The value of each entry shall be the interconnectivity information of the SCP domain indicated by the key.

An empty map indicates that there is no SCP domain currently registered in the NRF.

EXAMPLE: The SCP Domain Routing Information is derived from the SCP domains registered by SCPs, e.g. if SCP x, SCP y and SCP z have registered in NRF with following SCP domains:

SCP x Profile includes: { "scpDomains": [ "SCP_Domain_1", "SCP_Domain_2" ] }

SCP y Profile includes: { "scpDomains": [ "SCP_Domain_2", "SCP_Domain_3" ] }

SCP z Profile includes: { "scpDomains": [ "SCP_Domain_4" ] }

then the SCP Domain Routing Information should be as following:

{

"scpDomainList": {

"SCP_Domain_1": { "connectedScpDomainList": [ "SCP_Domain_2" ] },

"SCP_Domain_2": { "connectedScpDomainList": [ "SCP_Domain_1", "SCP_Domain_3" ] },

"SCP_Domain_3": { "connectedScpDomainList": [ "SCP_Domain_2" ] },

"SCP_Domain_4": { "connectedScpDomainList": [ ] }

}

}

6.2.6.2.9 Type: ScpDomainConnectivity

Table 6.2.6.2.9-1: Definition of type ScpDomainConnectivity

Attribute name

Data type

P

Cardinality

Description

connectedScpDomainList

array(string)

M

0..N

This IE shall contain the list of interconnected SCP domains.

An empty array indicates there is no SCP Domain currently interconnected.

6.2.6.2.10 Type: ScpDomainRoutingInfoSubscription

Table 6.2.6.2.10-1: Definition of type ScpDomainRoutingInfoSubscription

Attribute name

Data type

P

Cardinality

Description

callbackUri

Uri

M

1

Callback URI where the Service Consumer will receive the notifications from NRF.

validityTime

DateTime

C

0..1

Time instant after which the subscription becomes invalid. This parameter may be sent by the client, as a hint to the server, but it shall be always sent back by the server (regardless of the presence of the attribute in the request) in the response to the subscription creation request.

reqInstanceId

NfInstanceId

O

0..1

If present, this IE shall contain the NF instance id of the Service consumer.

localInd

boolean

O

0..1

When present, this IE shall indicate whether changes of local SCP Domain Routing Information to be notified:

– true: changes of local SCP Domain Routing Information to be notified.

– false (default): changes of SCP Domain Routing Information to be notified

6.2.6.2.11 Type: ScpDomainRoutingInfoNotification

Table 6.2.6.2.11-1: Definition of type ScpDomainRoutingInfoNotification

Attribute name

Data type

P

Cardinality

Description

routingInfo

ScpDomainRoutingInformation

M

1

This IE shall contain the SCP Domain Routing Information after the change.

localInd

boolean

O

0..1

When present, this IE shall indicate whether changes of local SCP Domain Routing Information is carried in the notification:

– true: changes of local SCP Domain Routing Information in the notification.

– false (default): changes of SCP Domain Routing Information in the notification.

6.2.6.2.12 Type: NfServiceInstance

Table 6.2.6.2.12-1: Definition of type NfServiceInstance

Attribute name

Data type

P

Cardinality

Description

serviceInstanceId

string

M

1

Unique ID of the service instance within a given NF Instance

nfInstanceId

NfInstanceId

C

0..1

NF Instance ID of the NF service instance

(NOTE)

nfServiceSetId

NfServiceSetId

C

0..1

NF Service Set ID of the NF Service instance

(NOTE)

NOTE: Either the nfInstanceId IE or the nfServiceSetId IE shall be present.

6.2.6.2.13 Type: NoProfileMatchInfo

Table 6.2.6.2.13-1: Definition of type NoProfileMatchInfo

Attribute name

Data type

P

Cardinality

Description

reason

NoProfileMatchReason

M

1

This IE shall indicate the specific reason for not finding any NF instance that can match the search criteria.

queryParamCombinationList

array(QueryParamCombination)

O

1..N

This IE may be present if the reason IE is set to "QUERY_PARAMS_COMBINATION_NO_MATCH".

If present each QueryParamCombination indicates that no NF Instance matching the QueryParamCombination has registered.

6.2.6.2.14 Type: QueryParamCombination

Table 6.2.6.2.14-1: Definition of type QueryParamCombination

Attribute name

Data type

P

Cardinality

Description

queryParams

array(QueryParameter)

M

1..N

This IE shall contain a list of query parameters.

6.2.6.2.15 Type: QueryParameter

Table 6.2.6.2.15-1: Definition of type QueryParameter

Attribute name

Data type

P

Cardinality

Description

name

string

M

1

name of the query parameter

value

string

M

1

value of the query parameter

6.2.6.3 Simple data types and enumerations

6.2.6.3.1 Introduction

This clause defines simple data types and enumerations that can be referenced from data structures defined in the previous clauses.

6.2.6.3.2 Simple data types

The simple data types defined in table 6.2.6.3.2-1 shall be supported.

Table 6.2.6.3.2-1: Simple data types

Type Name

Type Definition

Description

6.2.6.3.3 Enumeration: NoProfileMatchReason

The enumeration NoProfileMatchReason indicates the specific reason for not finding any NF instance that can match the search criteria.

Table 6.2.6.3.3-1: Enumeration NoProfileMatchReason

Enumeration value

Description

"REQUESTER_PLMN_NOT_ALLOWED"

NF profiles are not allowed to be discovered by the requester’s PLMN

"TARGET_NF_SUSPENDED"

Target NF exists with NFStatus or NFServiceStatus "SUSPENDED"

"TARGET_NF_UNDISCOVERABLE"

Target NF exists with NFStatus or NFServiceStatus "UNDISCOVERABLE"

"QUERY_PARAMS_COMBINATION_NO_MATCH"

No NF instance matching the Query Parameter Combination has registered

"UNSPECIFIED"

Other reasons

6.2.7 Error Handling

6.2.7.1 General

HTTP error handling shall be supported as specified in clause 5.2.4 of 3GPP TS 29.500 [4].

6.2.7.2 Protocol Errors

Protocol errors handling shall be supported as specified in clause 5.2.7 of 3GPP TS 29.500 [4].

6.2.7.3 Application Errors

The application errors defined for the Nnrf_NFDiscovery service are listed in Table 6.2.7.3-1.

Table 6.2.7.3-1: Application errors

Application Error

HTTP status code

Description

6.2.8 Security

As indicated in clause 13.3 of 3GPP TS 33.501 [15], when static authorization is not used, the access to the Nnrf_NFDiscovery API may be authorized by means of the OAuth2 protocol (see IETF RFC 6749 [16]), using the "Client Credentials" authorization grant, where the NRF plays the role of the authorization server.

If Oauth2 authorization is used on the Nnrf_NFDiscovery API, an NF Service Consumer, prior to consuming services offered by the Nnrf_NFDiscovery API, shall obtain a "token" from the authorization server, by invoking the Access Token Request service, as described in clause 5.4.2.2.

NOTE: When multiple NRFs are deployed in a network, the NRF used as authorization server is the same NRF where the Nnrf_NFDiscovery service is invoked by the NF Service Consumer.

The Nnrf_NFDiscovery API defines the following scopes for OAuth2 authorization:

Table 6.2.8-1: Oauth2 scopes defined in Nnrf_NFDiscovery API

Scope

Description

"nnrf-disc"

Access to the Nnrf_NFDiscovery API

"nnrf-disc:scp-domain:read"

Access to read the scp-domain-routing-info resource

"nnrf-disc:scp-domain-subs:write"

Access to create/delete a scp-domain subscription resource

"nnrf-disc:nf-instances:read-complete-profile"

Access to the Nnrf_NFDiscovery API enabling the discovery of the complete profile of NF instances

6.2.9 Features supported by the NFDiscovery service

The syntax of the supportedFeatures attribute is defined in clause 5.2.2 of 3GPP TS 29.571 [7].

The following features are defined for the Nnrf_NFDiscovery service.

Table 6.2.9-1: Features of supportedFeatures attribute used by Nnrf_NFDiscovery service

Feature Number

Feature

M/O

Description

1

Complex-Query

O

Support of Complex Query expression (see clause 6.2.3.2.3.1)

2

Query-Params-Ext1

O

Support of the following query parameters:

– limit

– max-payload-size

– required-features

– pdu-session-types

3

Query-Param-Analytics

O

Support of the query parameters for Analytics identifier:

– event-id-list

– nwdaf-event-list

4

MAPDU

O

This feature indicates whether the NRF supports selection of UPF with ATSSS capability.

5

Query-Params-Ext2

O

Support of the following query parameters:

– requester-nf-instance-id

– upf-ue-ip-addr-ind

– pfd-data

– target-snpn

– af-ee-data

– w-agf-info

– tngf-info

– twif-info

– target-nf-set-id

– target-nf-service-set-id

– preferred-tai

– nef-id

– preferred-nf-instances

– notification-type

– serving-scope

– internal-group-identity

– preferred-api-versions

– v2x-support-ind

– redundant-gtpu

– redundant-transport

– lmf-id

– an-node-type

– rat-type

– ipups

– scp-domain-list

– address-domain

– ipv4-addr

– ipv6-prefix

– served-nf-set-id

– remote-plmn-id

– data-forwarding

– preferred-full-plmn

– requester-snpn-list

– max-payload-size-ext

– client-type

6

Service-Map

M

This feature indicates whether it is supported to identify the list of NF Service Instances as a map (i.e. the "nfServiceList" attribute of NFProfile is supported).

7

Query-Params-Ext3

O

Support of the following query parameters:

– ims-private-identity

– ims-public-identity

– msisdn

– requester-plmn-specific-snssai-list

– n1-msg-class

– n2-info-class

8

Query-Params-Ext4

O

Support of the following query parameters:

– realm-id

– storage-id

9

Query-Param-vSmf-Capability

O

Support of the query parameters for V-SMF Capability:

– vsmf-support-ind

10

Enh-NF-Discovery

O

Enhanced NF Discovery

This feature indicates whether it is supported to return the nfInstanceList IE in the NF Discovery response.

11

Query-SBIProtoc17

O

Support of the following query parameters, for Service Based Interface Protocol Improvements defined in 3GPP Rel-17:

– preferred-vendor-specific-features

– preferred-vendor-specific-nf-features

– home-pub-key-id

– pgw-ip

– preferences-precedence

– preferred-pgw-ind

– v2x-capability

– shared-data-id

12

SCPDRI

O

SCP Domain Routing Information

An NRF supporting this feature shall allow a service consumer (i.e. a SCP) to get the SCP Domain Routing Information and subscribe/unsubscribe to the change of SCP Domain Routing Information with following service operations:

– SCPDomainRoutingInfoGet (see clause 5.3.2.3)

– SCPDomainRoutingInfoSubscribe (see clause 5.3.2.4)

– SCPDomainRoutingInfoUnsubscribe (see clause 5.3.2.6)

A service consumer (i.e. a SCP) supporting this feature shall be able to handle SCPDomainRoutingInfoNotify as specified in clause 5.3.2.5, if subscribed to the change of SCP Domain Routing Information in the NRF.

13

Query-Upf-Pfcp

O

This feature indicates whether the NRF supports selection of UPF with required UP function features as defined in 3GPP TS 29.244 [21].

14

Query-5G-ProSe

O

Support of the following query parameters, for Proximity based Services in 5GS defined in 3GPP Rel-17:

– prose-support-ind

– prose-capability

15

NSAC

O

This feature indicates the NSACF service capability.

Support of the following query parameters:

– nsacf-capability

16

Query-MBS

O

Support of the following query parameters, for Multicast and Broadcast Services defined in 3GPP Rel-17:

– mbs-session-id-list

– mbsmf-serving-area

– area-session-id

17

Query-eNA-PH2

O

Support of the following query parameters, for Enhanced Network Automation Phase 2 defined in 3GPP Rel-17:

– analytics-aggregation-ind

– serving-nf-set-id

– serving-nf-type

– ml-analytics-info-list

– analytics-metadata-prov-ind

18

Query-eLCS

O

Support of the following query parameters, for 5G LCS service:

– gmlc-number

19

Query-eEDGE-5GC

O

Support of the following query parameters, for enhancement of support for Edge Computing in 5GC defined in 3GPP Rel-17:

– upf-n6-ip

– tai-list

20

Collocated-NF-Selection

O

Support of selecting a collocated NF supporting multiple NF types.

21

Query-ENPN

O

Support of the following query parameter for the enhanced support of Non-Public Networks defined in 3GPP Rel-17:

– support-onboarding-capability

– target-hni

– remote-snpn-id

22

Query-ID_UAS

O

Support of the following query parameters, for remote Identification of Unmanned Aerial Systems defined in 3GPP Rel-17:

– uas-nf-functionality-ind

23

NRFSET

O

NRF Set feature

An NRF supporting this feature shall allow a NF Service Consumer to get the NRF Set Information and subscribe/unsubscribe to the change of NRF Set Information:

A NF Service Consumer supporting this feature shall be able to handle Notify of the NRF status change, if subscribed to the change of NRF set information.

24

Query-Nw-Resolution

O

Support for the following query parameters:

– target-nw-resolution

25

Query-Param-iSmf-Capability

O

Support of the query parameters for I-SMF Capability:

– ismf-support-ind

26

Query-SBIProtoc17-Ext1

O

Support of the following query parameters, for Service Based Interface Protocol Improvements defined in 3GPP Rel-17:

– exclude-nfinst-list

– exclude-nfservinst-list

– exclude-nfserviceset-list

– exclude-nfset-list

27

Query-Upf-IpIndex

O

Support of the query parameters for UPF selection with IpIndex:

– ipv4-index

– ipv6-index

28

Query-eNA-PH2-Ext1

O

Support of the following query parameters, for extension of Enhanced Network Automation Phase 2 defined in 3GPP Rel-17:

– preferred-analytics-delays

29

Query-SBIProtoc18

O

Support of the following query parameters, for Service Based Interface Protocol Improvements defined in 3GPP Rel-18:

– ext-preferred-locality

– n32-purposes

– preferred-features

– sxa-ind

– remote-plmn-id-roaming

30

Complete-Profile-Discovery

O

Support discovery of complete NF profiles (including authorization attributes such as the "allowedXXX" attributes of NFProfile and NFService data types) of NF instances matching the query parameters.

Feature number: The order number of the feature within the supportedFeatures attribute (starting with 1).

Feature: A short name that can be used to refer to the bit and to the feature.

M/O: Defines if the implementation of the feature is mandatory ("M") or optional ("O").

Description: A clear textual description of the feature.

NOTE 1: An NRF that advertises support of a given feature shall support all the query parameters associated with the feature. An NRF may support none or a subset of the query parameters of features that it does not advertise as supported.

NOTE 2: For a release under development, it is recommended to define new features for new query parameters by grouping them per 3GPP work item. Any definition of new query parameters in a frozen release requires a new feature definition.