B Handling 3GPP Attributes

B.1 vsmf-support-ind

NRF supports vsmf-support-ind attribute in the NF Discover service operation query as per the 3GPP standards. For more information about the attribute, see NRF Compliance Matrix.

The discovery query is processed as follows:

  • If vsmf-support-ind attribute is present in the NFDiscover query and the value of targetNfType is other than SMF, NRF does not reject the discovery query. In this case, NF profiles are not returned.
  • When the requester-feature attribute is present or its value does not have any impact on the processing of vsmf-support-ind in the discovery query.
  • When SMF profile contains SMFInfoList attribute and if one of the SMFInfo element in it doesn’t have vsmf-support-ind, then NRF can consider such SMF profile as “V-SMF Capability Support of the SMF is not specified”.

B.2 nrfSupportedFeatures

As per 3GPP TS 29.510, nrfSupportedFeatures attribute indicates the features supported by NRF for the NFDiscovery service. This attribute is included in the discovery response if at least one feature is supported by NRF. From release 23.4.0, the value of this attribute is 172 (in hexadecimal and 101110010 in binary), by reading the bits from left to right it indicates that it supports the 2, 5, 6, 7, and 9 Feature Number as per the following table:

Table B-1 nrfSupportedFeatures List

Feature Number Feature Details nrfSupportedFeatures by NRF
1 Complex-Query

This is an optional parameter.

Support of Complex Query expression (see clause 6.2.3.2.3.1)

 NRF does not support this feature.
2 Query-Params-Ext1

This is an optional parameter.

Support of the following query parameters:

- limit

- max-payload-size

- required-features

- pdu-session-types

NRF supports the following query parameters:

  • limit
  • max-payload-size
  • required-features
  • pdu-session-types
3 Query-Param-Analytics

This is an optional parameter.

Support of the query parameters for Analytics identifier:

- event-id-list

- nwdaf-event-list

 NRF does not support this feature.
4 MAPDU

This is an optional parameter.

This feature indicates whether the NRF supports selection of UPF with Access Traffic Steering, Switching and Splitting (ATSSS) capability.

NRF does not support this feature.
5 Query-Params-Ext2

This is an optional parameter.

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

NRF supports the following query parameters:

  • target-nf-set-id
  • preferred-tai
  • notification-type
  • serving-scope
6 Service-Map

This is a mandatory parameter.

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

 NRF supports the nfServiceList attribute in NFProfile.
7 Query-Params-Ext3

This is an optional parameter.

Support of the following query parameters:

- ims-private-identity

- ims-public-identity

- msisdn

- requester-plmn-specific-snssai-list

- n1-msg-class

- n2-info-class

NRF supports the following query parameters:

  • n1-msg-class
  • n2-info-class
8 Query-Params-Ext4

This is an optional parameter.

Support of the following query parameters:

- realm-id

- storage-id

 NRF does not support this feature.
9 Query-Param-vSmf-Capability

This is an optional parameter.

Support of the query parameters for V-SMF capability:

- vsmf-support-ind

 NRF supports vsmf-support-ind query parameter for V-SMF capability.

The value of nrfSupportedFeatures attribute in the discovery response varies based on the value of the requester-features attribute sent by the Consumer NF. The requester-features attribute indicates the features that are supported by the Consumer NF.

The value of the nrfSupportedFeatures attribute is calculated based on the following scenarios:

  • value of nrfSupportedFeatures attribute when there are common supported features between consumer NF and NRF

    If the requester-features attribute has the value of 12 (this is hexadecimal value) in the discovery search query, the corresponding binary value is 00010010. It indicates that the 2nd and 5th bit are enabled and Consumer NF supports the Feature Number 2 and 5. As per the current support at NRF, the common supported features between Consumer NF and NRF are 2 and 5. Hence, the value of nrfSupportedFeatures attribute in the discovery response is 12.

  • value of nrfSupportedFeatures attribute when there are partial common supported features between consumer NF and NRF

    If the requester-features attribute has the value of 6 (this is hexadecimal value) in the discovery search query, the corresponding binary value is 0110. It indicates that the 2nd and 3rd bit are enabled and Consumer NF supports Feature Number 2 and 3. As per the current support at NRF, the common supported feature between Consumer NF and NRF is 2. Hence, the value of the nrfSupportedFeatures attribute in the discovery response is 2.

  • value of nrfSupportedFeatures attribute when there is no common supported features between consumer NF and NRF

    If the requester-features attribute has the value of 8 (this is hexadecimal value) in the discovery search query, the corresponding binary value is 1000. It indicates that no common features are available between the Consumer NF and NRF. Hence, the value of the nrfSupportedFeatures attribute in the discovery response is 0.

  • value of nrfSupportedFeatures attribute is 172

    When the requester-features attribute is unavailable in the discovery search query of Consumer NF, the value of the nrfSupportedFeatures attribute in the discovery response is 172.

B.3 DataSetId Enhancements

As per 3GPP TS 29.510 v17.7, NRF supports the following enumeration (ENUM) values within DataSetId enumeration.

Table B-2 Additional DataSetId Enumerations

ENUM Value Description
"A_PFD" ApplicationData subset: Packet Flow Descriptions
"A_AFTI" ApplicationData subset: AF Traffic Influence Data
"A_IPTV" ApplicationData subset: IPTV Config Data
"A_BDT" ApplicationData subset: Background Data Transfer
"A_SPD" ApplicationData subset: Service Parameter Data
"A_EASD" ApplicationData subset: EAS Deployment Information
"A_AMI" ApplicationData subset: AM Influence Data
"P_UE" PolicyData subset: UE Specific Data
"P_SCD" PolicyData subset: Sponsored Connectivity Data
"P_BDT" PolicyData subset: Background Data Transfer
"P_PLMNUE" PolicyData subset: PLMN-specific UE policy data
"P_NSSCD" PolicyData subset: Network Slice Specific Control Data
"P_MBSCD" PolicyData subset: MBS Session Policy Control Data

NRF supports the additional ENUM values added in the DataSetId attribute in the following service operations as per the 3GPP TS 29.510 v17 standards:

  • NFRegister
  • NFProfileRetrieval
  • NFUpdate (Partial/Complete)
  • NFStatusNotify
  • NFDiscover
If UDR registers with DataSetId attribute, only the following enums are allowed:
  • SUBSCRIPTION
  • POLICY
  • EXPOSURE
  • APPLICATION
  • A_PFD
  • A_AFTI
  • A_IPTV
  • A_BDT
  • A_SPD
  • A_EASD
  • A_AMI
  • P_UE
  • P_SCD
  • P_BDT
  • P_PLMNUE
  • P_NSSCD
  • P_MBSCD

However, in case of NFRegister service operation, the following validations are not supported:

  • If UDR registers with DataSetId attribute with "APPLICATION", it is required to register with all A_*** enumerations in addition.
  • If UDR registers with all the above defined A_*** enumerations, it should register with "APPLICATION" enumeration in addition.
  • If UDR registers with DataSetId attribute with "POLICY", it is required to register with all P_*** enumerations in addition.
  • If UDR registers with all the above defined P_*** enumerations, it should register with "POLICY" enumeration in addition.

For more information about the attribute, see NRF Compliance Matrix.

Note:

The DataSetId parameter is ignored in the following scenarios for the NF Profiles (if the discovery query contains the DataSetId parameter):
  • supportedDataSets attribute is missing: If the UdrInfo profile does not contain the supportedDataSets attribute, the data-set parameter in the discovery request should be ignored.
  • UdrInfo JSON object is empty: If the UdrInfo JSON object is provided and it is empty, the data-set parameter should be ignored.
  • UdrInfo JSON object is missing: If the entire UdrInfo JSON object is not included in the request, the data-set parameter should be ignored.

B.4 Support for servingClientTypes in LmfInfo and GmlcInfo

As per 3GPP TS 29.510 v16.7, NRF supports servingClientTypes attribute in NF Profiles for Location Management Function (LMF) (LmfInfo) and Gateway Mobile Location Center (GMLC) (GmlcInfo). NRF supports client-type discovery query parameter to discover NFs based on servingClientTypes attribute. servingclientTypes attribute is supported for GMLC and LMF NF Types. If the above mentioned attribute is present in the NF Profile then the GMLC and LMF NFs are dedicated to serve the listed external client type. The listed external client types are mentioned in 3GPP TS 29.572 v16.7. If this attribute is not present in the NF Profile for the mentioned NFTypes then NFs are not dedicated to serve any external client type.

Possible values for servingClientTypes for both LmfInfo and GmlcInfo are as follows:

Table B-3 Possible Values for servingClientTypes

Enumeration value Description
"EMERGENCY_SERVICES" External client for emergency services
"VALUE_ADDED_SERVICES" External client for value added services
"PLMN_OPERATOR_SERVICES" External client for PLMN operator services
"LAWFUL_INTERCEPT_SERVICES" External client for Lawful Intercept services
"PLMN_OPERATOR_BROADCAST_SERVICES" External client for PLMN Operator Broadcast services
"PLMN_OPERATOR_OM" External client for PLMN Operator O&M
"PLMN_OPERATOR_ANONYMOUS_STATISTICS" External client for PLMN Operator anonymous statistics
"PLMN_OPERATOR_TARGET_MS_SERVICE_SUPPORT" External client for PLMN Operator target MS service support

Note:

If the servingClientTypes attribute is present in the respective LmfInfo or GmlcInfo attributes indicates NF are dedicated to serve the mentioned external client type. Hence absence of the respective LmfInfo or GmlcInfo attribute is also considered as NFs are not dedicated to serve any external client type.

If servingClientTypes attribute is present in LmfInfo or GmlcInfo attributes, it indicates that LMF or GMLC is dedicated to serve the listed external client type(s), For example, EMERGENCY_SERVICES.

If servingClientTypes attribute is not present in LmfInfo or GmlcInfo attributes or if LmfInfo and GmlcInfo attributes are absent, it indicates that the LMF or GMLC is not dedicated to serve the listed external client type.

For NFManagement service operations, NRF checks the servingClientTypes value matches with the supported values for servingClientTypes as mentioned in 3GPP TS 29.572 v16.7. If this value matches then NRF processes the requests. If the value does not match, NRF rejects the request.

For NFDiscover service operation, the client-type query parameter is received in the incoming NFDiscovery query. NRF checks the client-type value with the supported values for servingClientTypes as mentioned in 3GPP TS 29.572 v16.7.

  • If the servingClientTypes value matches with the supported servingClientTypes values as mentioned in 3GPP TS 29.572 v16.7:
    • NRF checks the value of client-type query parameter with the values in the servingClientTypes list from the corresponding NfInfo of the registered NFProfiles.
      • If these values matches, that NFProfile is considered for the discovery response.
      • If the value does not match, NRF does not include that NFProfile in the response.
  • If the servingClientTypes value is not matching with the supported values for servingClientTypes as mentioned in 3GPP TS 29.572 v16.7, NRF rejects the request.

Note:

  • In case, there are no NFProfiles of GMLC and LMF types registered in NRF with the matching servingClientTypes, it means none of the NF Profiles are dedicated to serve the servingClientTypes. Hence, NFProfiles which are not dedicated (where servingClientTypes attribute is absent or the respective NfInfo attribute is absent) are returned in the NFDiscovery response.
  • In case, in any NRF deployment, nfdiscovery.searchQueryIgnoreList (Helm parameter) is configured with value client-type, searchQueryIgnoreList parameter shall not contain the client-type. So that NRF can process this attribute in the NFDiscover service operation.

Examples

  • One instance of LMF is registered with NRF with LMFInfo present with servingClientTypes value as EMERGENCY_SERVICES and another instance of LMF is registered with NRF with LmfInfo present with servingClientTypes value as VALUE_ADDED_SERVICES.

    NFDiscover service operation query is received withclient-type query parameter as EMERGENCY_SERVICES. In this scenario, first instance of LMF is returned by NRF in NFDiscover service operation response.

  • One instance of LMF is registered with NRF with LmfInfo present with servingClientTypes value as EMERGENCY_SERVICES and another instance of LMF is registered with NRF with LmfInfo present with servingClientTypes value as VALUE_ADDED_SERVICES.

    NFDiscover service operation query is received with client-type query parameter as PLMN_OPERATOR_SERVICES. In this scenario, none of the LMF NF profiles are returned by NRF in NFDiscover service operation response.

  • One instance of LMF is registered with NRF with LmfInfo present with servingClientTypes attribute is absent and another instance of LMF is registered with NRF with LmfInfo present with servingClientTypes value as VALUE_ADDED_SERVICES.

    NFDiscover service operation query is received with client-type query parameter as PLMN_OPERATOR_SERVICES. In this scenario, as there is no matching NFProfile with dedicated servingClientTypes value, hence NFProfile with non-dedicated servingClientTypes, that is the first instance of LMF is returned by NRF in NFDiscover service operation response.

  • One instance of LMF is registered with NRF with LmfInfo present with servingClientTypes attribute is absent and another instance of LMF is registered with NRF with LmfInfo present with servingClientTypes value as PLMN_OPERATOR_SERVICES.

    NFDiscover service operation query is received with client-type query parameter as PLMN_OPERATOR_SERVICES. In this scenario, second instance of LMF is returned by NRF in NFDiscover service operation response.

  • One instance of LMF is registered with NRF with LmfInfo is absent and another instance of LMF is registered with NRF with LmfInfo present with servingClientTypes value as VALUE_ADDED_SERVICES.

    NFDiscover service operation query is received with client-type query parameter as PLMN_OPERATOR_SERVICES. In this scenario, as there is no matching NFProfile with dedicated servingClientTypes value, hence NFProfile with non-dedicated servingClientTypes, that is the first instance of LMF is returned by NRF in NFDiscover service operation response.

  • One instance of LMF is registered with NRFF with LmfInfo is absent and another instance of LMF is registered with NRF with LmfInfo present with servingClientTypes value as VALUE_ADDED_SERVICES.

    NFDiscover service operation query is received with client-type query parameter as VALUE_ADDED_SERVICES. In this scenario, second instance of LMF is returned by NRF in NFDiscover service operation response.

All these examples are also applicable to GMLC NF Type.

B.5 Enhancements for dnn NFProfile Attribute and Discovery Query Parameter

NRF supports dnn attribute that represents the Data Network Name (DNN). DNN comprises of the Network Identifier and Operator Identifier.

Until 24.2.x release, when dnn attribute was provided during NFManagement and NFDiscover service operations, NRF performed validations for null or empty values. NRF also supported exact matching of dnn query attribute value with the dnn attribute present in the registered NFProfile for NFDiscover service operations.

From 24.3.x releases, NRF performs the validations for the dnn attribute, as per 3GPP TS 29.571 v16.7. These validations are added for the NF Types SMF, UPF, PCF, and BSF (that is, smfInfo,smfInfoList, upfInfo, pcfInfo, and bsfInfo).

Note:

The attributes for upfInfoList, pcfInfoList, and bsfInfoList are not supported by NRF.
  • Maximum length of DNN is 100 Octets.
  • DNN Structure = <Label>.<Label>.<Label>. Label should only contain (A-Z), (a-z), (0-9), '-'.
  • Network Identifier structure is mandatory in DNN.

    Validations for Network Identifier:

    • maximum length can be 63 Octets
    • cannot start with {"rac","lac","sgsn","rnc"}
    • cannot end with {"gprs"}
    • cannot take value {"*"}
  • Operator Identifier structure is optional in DNN.

    Validations for Operator Identifier:

    • The Access Point Name (APN) Operator Identifier is composed of three labels. The last label (= domain) shall be "gprs".
    • The first and second labels together identifies the PLMN.

      Format: "mnc<MNC>.mcc<MCC>.gprs", <MNC> of 3 digits , <MCC> of 3 digits.

      • The format should be strictly followed. Any change in the formatted value will result in considering the whole dnn value as Network Identifier.
      • Any other value of mcc and mnc comprising of anything else like alphabets, negative value, or hyphen(-) will be rejected.

        Consumer NF should send the MNC in 3 digits to NRF.

        Note: If there are only 2 significant digits in the MNC, one "0" digit must be added at the left side by Consumer NF to fill the 3 digits coding of MNC in the APN Operator Identifier.

        For example: If the APN Operator Identifier for MCC 345 and MNC 12, then Consumer NF sends MNC as 012 in the DNS "mnc012.mcc345.gprs" to NRF.

Examples:

  • Following are the examples of valid dnn values:
    • province1.mnc012.mcc345.gprs

      Here, province1 is Network Identifier and mnc012.mcc345.gprs is Operator Identifier.

    • ggsn-cluster-A.provinceB.mnc012.mcc345.gprs

      Here, ggsn-cluster-A.provinceB is Network Identifier and mnc012.mcc345.gprs is Operator Identifier.

  • Following are the examples of invalid dnn values along with their rejection reasons:
    • province_A, provinc*A.mnc012.mcc345.gprs

      Here, these would be rejected as both the values contain a label having a character ( _ and * respectively ) that is not in permissible list of characters (A-Z), (a-z), (0-9), '-'.

    • province1.gprs, province-A.gprs.mnc012.mcc345.gprs

      Here, these would be rejected as all the values have their network identifier part ending with gprs.

    • lac.province.mnc012.mcc345.gprs, race-province, rncabc.provinceA.mnc012.mcc345.gprs, and sgsn

      Here, these would be rejected as all of the values have their network identifier starting with one of the following {"rac","lac","sgsn","rnc"}.

As per 3GPP TS 29.510 v16.7, the dnn attribute present in the discovery query is considered as a match with a dnn attribute present in the registered NFProfile during the following scenarios:
  • Both the dnn attributes contain the same Network Identifier and Operator Identifier.
  • Both the dnn attributes contain the same Network Identifier and none contains an Operator Identifier.
  • The dnn attribute in the discovery query contains only the Network Identifier and the DNN value in the registered NF Profile contains both the Network Identifier and Operator Identifier, and both contain the same Network Identifier.
  • The dnn attribute in the discovery query contains both the Network Identifier and Operator Identifier, the dnn value in the NF Profile contains the Network Identifier only, both contain the same Network Identifier and the Operator Identifier matches one PLMN of the NF (that is, plmnList of the NF Profile).

Note:

Prior to 24.3.0 release, NRF was not performing dnn validations. From 24.3.0 release, dnn validations are added for NFManagement and NFDiscover service operations as per 3GPP defined format. The following points should be considered while performing the validations:

  • Prior upgrading NRF to 24.3.x, in case NRF database contains NFProfiles with dnn attribute and dnn attribute value is not as per 3GPP defined format, NFs should update their NFProfiles with correct dnn format (as defined in 3GPP TS 23.003 v16.8 Section 9A). NFProfiles can be updated using NFRegister or NFUpdate (PUT or PATCH) service operations.
  • Post upgrading NRF to release 24.3.x, in case there are still NFProfiles with dnn attribute value not as per 3GPP defined format, then NFProfile processing is performed for NRF service operations as follows:
    • NFRegister (PUT): NFs are allowed to re-register with dnn attribute value as per 3GPP defined format.
    • NFUpdate (PUT): NFs are allowed to update the dnn attribute value as per 3GPP defined format.
    • NFUpdate (PATCH): NFs are not allowed to update the dnn attribute value. NRF rejects the request with status code as 400 bad request.
    • NFUpdate (Heartbeat): NFs are allowed to do heartbeat for such NFProfiles as per 3GPP specifications.
    • NFDiscover:
      • NFDiscover query with dnn attribute value if not as per 3GPP defined format, is rejected by NRF.
      • The NFProfiles in the database having invalid dnn value format will be ignored while filtering NFProfiles based on dnn query attribute.
      • The NFProfiles in the database having invalid dnn value format will be included in the NFDiscover response if dnn is not present in the discovery query if other attributes present in the query matches as per 3GPP NRF specifications.
      • The NFProfiles in the database having invalid dnn value format for Operator Identifier but Network Identifier value is in correct format. dnn attribute is present in the discovery query with matching network identifier and no operator identifier. In this case, such NFProfiles will be included in the NFDiscover response.
    • NFStatusNotify: NRF sends notifications for NFUpdate and NFRegister PUT service operations with the updated NFProfiles. As NFUpdate (Patch) request is rejected, NRF does not send notifications for the service operation.

B.6 Content-Encoding Header

NRF does not accept incoming request messages in gzipped format for NFManagement service operations such as NFRegister, NFUpdate (Complete/Patch Replacement, Heartbeat), and NFStatusSubscribe (both New and Update Subscriptions).

If the Content-Encoding header is present and has an unsupported value, NRF rejects the HTTP request with 415 Unsupported Media Type error, NRF only accepts the Content-Encoding header value set to “identity”. In such error cases, NRF will include an Accept-Encoding header with the value set to “identity.”

If the Content-Encoding header is missing but the payload is still compressed, NRF rejects the HTTP request with a 400 Bad Request error due to the invalid message.

However, NRF supports gzipped encoding for response messages for JSON body in NFManagement service operations such as NFRegister, NFUpdate (Complete/Patch Replacement, Heartbeat), NFListRetrieval, and NFProfileRetrieval, provided that the client (NF) specifies the gzip format in the Accept-Encoding header when requesting response.