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; |
|
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; |
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; |
|
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"}, "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; |
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; |
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; |
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; 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; |
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; |
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: 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: 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 |
preferredFullPlmnMatchInd |
boolean |
O |
0..1 |
Indicates whether all the returned NFProfiles match or do not match the query parameter preferred-full-plmn. true: 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 |
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 |
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 |
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 |
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 |
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 |
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 |
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. |
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. |