Method and system for providing information about supported features - Patents.com

Abstract

TS 29.500. Feature negotiation is performed when a subscription is created by an NF consumer. P: For a default notification subscription, the NF consumer registers a default subscription with the NRF and the NF producer sends notifications directly to the callback URI without using the subscription creation procedure. S: NF: Register the supported features with the default subscription. The NF producer knows the supported features of the NF consumer and adjusts the notifications accordingly. TS 29.510, API versioning and feature negotiation between NF producer and NF consumer. In 5GC, an NF producer can subscribe to and directly report to another NF producer on behalf of the NF consumer. P: There is no way for an NF consumer to indicate the supported API versions and features of the second NF producer that it reports directly to the NF consumer. S: A new header that allows an NF consumer to indicate the API versions and features it supports.

Description

[Technical field]

[0001] The present disclosure relates to a service consumer providing information about features supported by the service consumer for services offered by a service producer. [Background technology]

[0002] The 3rd Generation Partnership Project (3GPP®) 5G Application Programming Interface (API) provides mechanisms that allow network function (NF) producers (aka “service providers”) and NF consumers (aka “service consumers”) to negotiate optional features (e.g., backward-compatible changes that may affect information transmitted or received via API operations). 3GPP® TS 29.500 V17.2.0 (“TS 39.500”) specifies, among other things, the extensibility mechanisms supported in the service-based architecture in 3GPP®’s 5G Core (5GC). These extensibility mechanisms include “feature negotiation” as described in TS 29.500 in section 6.6.2. Network functions can register default notification subscriptions in NF profiles, which indicate which event types are of interest to the NF as an NF consumer, at the NF profile level or at the service level. When an NF producer selects an NF consumer to receive notification messages for default notifications, the NF producer uses the Nnrf_NFDiscovery service API with GET as specified in 3GPP TS 29.510 V16.7.0 ("TS 29.510"), which specifies that "this operation retrieves a list of NF instances and their offered services currently registered with the NRF that meet some filter criteria, such as NF instances offering a particular service name or NF instances of a given NF type (e.g., AMF)."

[0003] Feature negotiation is exchanged during the first communication between NF consumer / producer. In case of feature negotiation for Subscription / Notify pattern, NF consumer usually provides its supported features in Subscription Creation Request and NF producer indicates its supported features in Subscription Creation Response. The result of capability negotiation is also applied to notifications in subscription. Summary of the Invention

[0004] Currently, several challenges exist. For example, in the case of default subscription, there is no step for creating a subscription between the NF producer and the NF consumer. Rather, the NF producer is supposed to explore and discover the NF consumer via the Network Repository Function (NRF) and deliver notifications directly to the NF consumer using a registered callback uniform resource identifier (URI). Without the exchange of subscription creation messages, the NF producer cannot know which optional features are supported by the NF consumer. Thus, in such a scenario, when the NF producer sends a notification to the NF consumer, the NF producer does not know whether a particular information element (IE) should not be included in the notification due to the fact that the particular information element (IE) is not supported by the NF consumer. The present disclosure aims to overcome these difficulties.

[0005] Thus, in one aspect, a method is provided that is executed by a service consumer. According to one embodiment, the method includes invoking an administration service provided by a network repository function. Invoking the administration service includes generating an administration message including a profile for the service consumer and sending the administration message including the profile to the network repository function. The profile includes first default notification subscription information. The first default notification subscription information includes: a first notification type identifier that identifies a first notification type to which the service consumer subscribes by default, where notifications of the first notification type are provided by a service producer that provides a service for providing notifications; and ii) first feature support information that identifies one or more features that the service consumer supports for a service provided by the service producer for providing notifications.

[0006] According to another embodiment, a method performed by a service consumer includes receiving from a service producer a first message (e.g., a first Hypertext Transfer Protocol (HTTP) message) related to a service provided by the service producer. The first message comprises a header and a body. The body comprises a message for the service consumer, and the header comprises service producer supported feature information identifying one or more features of the service supported by the service producer. The method also includes sending a second message (e.g., a second HTTP message) to the service producer in response to the first message. The second message comprises a header comprising service consumer supported feature information identifying one or more features of the service supported by the service consumer.

[0007] In another aspect, a method is provided that is performed by a service producer. According to one embodiment, the method includes invoking a discover service to discover service consumers. Invoking the discovery service includes generating a discovery message including query parameters and sending the discovery message including the query parameters to a network repository function. The query parameters include i) a notification type identifier that identifies a type of notification provided by the service producer, and ii) a consumer supported features parameter that identifies one or more features desired to be supported by a service consumer that subscribes to notifications of the identified type by default.

[0008] According to another embodiment, the method includes receiving, from a network repository function, a profile for the service consumer. The profile includes a default notification subscription including supported feature information indicating at least a set of information elements supported by the service consumer. The method also includes determining the information elements supported by the service consumer from the supported feature information. The method also includes generating a notification for the service consumer based on the determined information elements. The method also includes sending the notification to an address specified in the default notification subscription (e.g., an address included in or identified by a Uniform Resource Identifier (URI) specified in the default notification subscription).

[0009] According to another embodiment, the method includes providing a service to a service consumer. Providing the service includes sending a first message (e.g., a first HTTP message) to the service consumer, the first message including a header and a body. The body comprises a message for the service consumer, and the header comprises service producer supported feature information identifying one or more features of the service supported by the service producer. The method also includes receiving a second message (e.g., a second HTTP message) sent by the service consumer in response to the first message. The second message comprises a header having service consumer supported feature information identifying one or more features of the service supported by the service consumer. The method also includes storing the service consumer supported feature information. The method also includes utilizing the stored service consumer supported feature information when subsequently providing the service to the service consumer.

[0010] In another aspect, a method is provided that is performed by a Network Repository Function (NRF), the method including receiving a management message as described above and / or receiving a discovery message as described above.

[0011] In another aspect, a computer program is provided that includes instructions that, when executed by a processing circuit of the network node, cause the network node to perform any one of the methods disclosed herein. In another aspect, a carrier is provided that includes the computer program, the carrier being one of an electrical signal, an optical signal, a wireless signal, and a computer-readable storage medium. In another aspect, a network node is provided, the network node being configured to perform any one of the methods disclosed herein. According to some embodiments, the network node includes a processing circuit and a memory that includes instructions executable by the processing circuit, whereby the network node is configured to perform any one of the methods disclosed herein.

[0012] The aspects and embodiments disclosed herein are advantageous for many reasons. For example, embodiments enable an NF, as a consumer, to register supported optional features with a default event subscription(s) and an NF producer to obtain information of the supported optional features of the NF consumer, so that the NF producer can adjust the content of notifications accordingly. [Brief description of the drawings]

[0013] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate various embodiments.

[0014] [Figure 1] 1 illustrates an exemplary wireless communication system.

[0015] [Diagram 2] 1 is a message flow diagram illustrating message flow according to one embodiment.

[0016] [Diagram 3] 1 is a flowchart showing a process according to an embodiment.

[0017] [Figure 4] 1 is a flowchart showing a process according to an embodiment.

[0018] [Diagram 5] 1 is a flowchart showing a process according to an embodiment.

[0019] [Figure 6] 1 is a flowchart showing a process according to an embodiment.

[0020] [Figure 7] 1 is a flowchart showing a process according to an embodiment.

[0021] [Figure 8] 1 is a flowchart showing a process according to an embodiment.

[0022] [Figure 9] 1 illustrates a network node according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0023] FIG. 1 illustrates an exemplary wireless communication system 100, which is represented as a 5G network architecture using a service-based interface (SBI). The communication system 100 comprises an access network (AN) (e.g., a 5G access network (5G-AN), which is an access network comprising a next-generation (NG) radio access network (NG-RAN) and / or a non-3GPP access network that connects to a 5G core network) and a core network (CN) comprising network entities (NEs) in the form of network functions (NFs). Typically, the AN comprises base stations, such as evolved node Bs (eNBs) or 5G base stations (gNBs). As illustrated in FIG. 1, user equipment (UE) connects to the AN and the access and mobility management function (AMF). As further shown in FIG. 1, the 5G CN NF includes a Network Slice Selection Function (NSSF), an Authentication Server Function (AUSF), a Unified Data Management (UDM), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Policy Control Function (PCF), an Application Function (AF), a Network Publication Function (NEF), a Location Management Function (LMF), and a Network Repository Function (NRF).

[0024] The NFs in the 5G core network architecture are independent and modular functions, enabling independent evolution and scaling. The modular function design makes the 5G core network flexible to enable different services. Each NF in the core network directly interacts with another NF, but can use intermediate functions to route messages from one NF to another.

[0025] The services that an NF provides to other authorized NFs can be published to the authorized NFs via an SBI. In Figure 1, an SBI is denoted by the letter "N" followed by the name of the NF, e.g., Namf for the AMF for SBI, Nsmf for the SMF for SBI, etc.

[0026] Some characteristics of the NFs shown in FIG. 1 can be described in the following way: The AMF provides UE-based authentication, authorization, mobility management, etc. Since the AMF is independent of the radio access technology, even when using multiple access technologies, the UE is usually connected to a single AMF. However, if the UE is connected to two different PLMNs using distinct types of access networks (e.g., the UE is connected to a first PLMN via a 3GPP access network and the UE is also connected to a second PLMN via a non-3GPP access network), the UE may be connected to, for example, two AMFs. The SMF is responsible for session management, assigns an IP address to the UE, and selects and controls a UPF for data forwarding for the UE. If the UE has multiple PDU sessions, a different SMF can be assigned to each PDU session to manage them separately and possibly provide different functions for each PDU session. The AF provides information about the packet flow to the PCF, which is responsible for policy control, to support QoS. Based on this information, the PCF determines policies regarding mobility and session management in order to make the AMF and SMF work properly. The AUSF supports the authentication function of the UE and therefore stores data for the authentication of the UE or similar, while the UDM stores subscription data of the UE. The Data Network (DN) is not part of the 5G core network and provides Internet access, operator services, etc. The LMF receives measurements and assistance information from the NG-RAN and the UE via the AMF in order to calculate the UE's location.

[0027] The NRF supports the following functions: 1) maintaining NF profiles of available NF instances and their supported services, 2) enabling other NF instances to subscribe to and be notified of new NF instances of a given type in the NRF, and 3) supporting a discovery function. It receives NF discovery requests from NF instances and provides information of available NF instances that meet certain search criteria. The characteristics of the NRF are specified in 3GPP® Technical Specification (TS) 29.501 (see, e.g., 3GPP® TS 29.501 v16.0.0).

[0028] A number of 5G core network NFs of various types are typically instantiated in a 5G core network by default, such as, for example, AMF, NRF, PCF, and SMF. Other 5G core network NFs may be instantiated as needed, and several NFs of the same type may also be instantiated as needed, for example, to distribute load to additional NFs of the same type. Thus, an NF instance may be considered an example or sample of a particular NF. In this specification, the terms NF and NF instance are used interchangeably unless expressly stated otherwise or clear from the context in which the terms are used. An NF instance exposes one or more NF service instances.

[0029] The NRF is one of the main components of the 5G service-based architecture. The NRF maintains an updated repository of all 5G elements available in the operator's network, along with the services provided by each of the elements in the 5G core that are expected to be instantiated, scaled, and terminated, without or with minimal manual intervention. The NRF supports discovery mechanisms that allow 5G components to discover each other and obtain the updated state of desired components. The NRF supports the following functions: maintaining profiles of available NF instances and the services supported by them in the 5G core network, enabling consumer NF instances to discover other provider NF instances in the 5G core network, enabling NF instances to track the state of other NF instances. The NRF interacts with all other components in the 5G core network and supports the above functions through management and discovery services.

[0030] 2 is a message flow diagram illustrating a message flow according to one embodiment. The message flow may begin with the service consumer 201 sending a management message 251 (e.g., a registration message) to the NRF 204. The management message includes a profile for the service consumer 201. For example, the service consumer may invoke an NRFRegister operation as described in TS 29.510. That is, sending the management message 251 to the NRF may consist of the service consumer 201 sending a HyperText Transfer Protocol (HTTP) PUT message to the NRF 204 that includes an NFProfile for the service consumer.

[0031] According to one embodiment, the profile included in the management message 251 comprises first default notification subscription information including: i) a first notification type identifier identifying a first notification type to which the service consumer subscribes by default, where notifications of the first notification type are provided by a service producer that provides a service for providing the notifications; and ii) first feature support information identifying one or more features that the service consumer supports for the service provided by the service producer providing the notification.

[0032] According to one embodiment, the default notification subscription information is of a type that is an extension of the DefaultNotificationSubscription type defined in TS 29.510. For example, the default notification subscription information may include the following information elements (IEs) (e.g., attribute-value pairs): ┌──────────┬──────┬─────────────────────┐ │ Attribute Name │ Data Type │ Description │ ├──────────┼──────┼───────────────────┤ │notification type │A corresponding callback URI is provided │ │Notification type │ │Notification type │ ├──────────┼──────┼───────────────────┤ │callbackUri │Uri │This attribute is used to │ │Callback Uri │ │You can explicitly register a callback URI in │ │ │Not yet (e.g. implicit subscription │ │ │ │ to the NF service consumer as a result of │ │ │ by NF service producers │ │ │ │The default notification end that should be used │ │ │ │Including points. │ ├──────────┼──────┼───────────────────┤ │n1MessageClass │N1 Message │If the notification type is N1_MESSAGES, │ │n1 message class │Class │This IE exists and should be notified │ │ │ │Identify the class of the N1 message. │ ├──────────┼──────┼───────────────────┤ │n2InformationClass │N2 information class │If the notification type is N2_INFORMATION, │ │n2 information class │ │This IE exists and the N2 information to be notified │ │ │Identify the class. │ ├──────────┼──────┼───────────────────┤ │versions │array(string) │Supported by default notification type │ │ version │ array (string) │ the API version (e.g. "v1"). │ ├──────────┼──────┼───────────────────┤ │nfConsumerSupported │If this IE is present, it is │ │-FeaturescallbackUri │Features │Default notification subscription │ │nf consumer │ │Supported as NF consumer for │ │Supported Features │ │Indicates the features that are supported. │ │Callback Uri │ │(Note 1, Note 2) │ ├──────────┼──────┼───────────────────┤ │binding │string │If present, this IE specifies the binding │Binding │ │As specified in Section 6.12.4 of │ │ │ │ Vine for subscription notifications │ │ │ │The value of the ding indication (i.e. │ │ │ │"3gpp-Sbi-Binding" header value part) │ │ │ │Includes. │ ├──────────┴──────┴───────────────────┤ │Note 1: Supported IE features are related to the subscription service API│ For example, a subscription to the Namf_Communication service │For the generated notification type "N1_MESSAGE", the supported IE features are: │ │Features specified by Namf_Communication (3GPP TS 29.518, section 6.1.8)│ │ │Note 2: NF producers take into account the supported features of NF consumers │ │ and then send the notification to the default subscription. │For example, if the NF consumer supports this feature, it may │Only IEs controlled by features are included. │ └──────────────────────────────────────┘

[0033] Therefore, according to one embodiment, a new Information Element (IE), preferably called "nfConsumerSupportedFeatures", is added to the default notification subscription message, allowing an NF consumer to indicate the supported features of the corresponding API for that notification. In this way, an NF producer can determine the supported features of the NF consumer and adjust the content of the notification accordingly.

[0034] The message flow may also include the service producer 202 sending a discovery message 253 to the NRF 204, where the discovery message 253 includes the query parameters. For example, the service producer 202 may invoke an NFDiscover operation (NFDiscovery operation) described in TS 29.510. That is, sending the discovery message 253 to the NRF may consist of the service producer 202 sending a HyperText Transfer Protocol (HTTP) GET message with the query parameters to the NRF 204. The query parameters that may be included in the GET message (discovery message) are specified in Table 6.2.3.2.3.1-1 of TS 29.510, which is reproduced in part below: ┌──────────┬──────┬─────────────────────┐ │ Name │ Data Type │ Description │ ├──────────┼──────┼───────────────────┤ │target-nf-type │NF type │This IE specifies the │ │ │ │NF type included. │ ├──────────┼──────┼───────────────────┤ │requester-nf-type │NF type │This IE is for the Nnrf_NFDiscovery service │ │ │ │NF type of the requester NF calling │ │ │ │Includes │ ├──────────┼──────┼───────────────────┤ │requester-nf- │NfInstanceId│If included, this IE identifies the │ │instance-id │NF instance │Contains the NF instance id. │ │ │Chest of Drawers ID │ │ ├──────────┼──────┼───────────────────┤ │service-names │array(Servi-│If included, this IE specifies the NF profile │ │ceName) │ │ │ │Contains an array of service names that can be │ │ │Matches an NF service name in this list │ │ │ │Has at least one NF service │ │ │ │Returns the NF profile. │ │ │ │The NF service name returned by the NRF is │ │ │ │Requested NF service name and NF pro │ │ │ │NF service name registered in the file │ │ │ │It is interclose. │ │ │ │If not included, NRF will use the NF profile │ │ │ │ All NF service names registered in │ │ │ │Returns unique items. │ ├──────────┼──────┼───────────────────┤ │requester-nf- │Fdqh │This IE is used for NF discovery in the same PLMN as the NRF. │instance-fqdn │ │May be present for valid requests. │ │ │ │If included, this IE is Nnrf_NF- │ │ │ │Calling the Discovery service │ │ │ │Includes the FQDN of the requester NF. │ │ │ │NRF is the "allowedNfDomains" list │ │ │ │(see Section 6.1.6.2.3) in the requester │ │ │ │Contains entries that match the domain of NF │ │ │ │Contains at least one NF service │ │ │ │To return only NF profiles, │ │ │ │Use this. │ │ │ │This IE belongs to a different PLMN │ │ │ │When received from a requester NF, │ │ │ │Ignored by NRF. │ │ │ │(Note 12) │ ├──────────┼──────┼───────────────────┤ │target-plmn-list │array(Plmn- │This IE identifies NF services in different PLMNs, │ │ │Id) │or within the same PLMN containing multiple PLMN IDs │ │ │ │NF service for a specific PLMN ID is discovered │ │ │Included when necessary. │ │ │ │If included, this IE is │ │ │ │Includes PLMN ID. │ │ │ │If more than one PLMN ID is included, │ │ │ │The NF of any PLMN ID present in the list is │ │ │ │Matches the query parameters. │ │ │ │For inter-PLMN service discovery, │ │ │ │At most one PLMN ID is included in the list │ │ │ │ and sent to the NRF in the same PLMN │ │ │ │Service Disconnect from NF in source PLMN │ │ │ │coverage, whereas │ │ │ │Sent from source NRF to target NRF │ │ │ │Service discovery requests │ │ │ │ can be assumed not to exist in │ │ │ │In such cases, the NRF is greater than 1 │ │ │ │When receiving a PLMN ID, the NRF │ │ │Only consider the first element and ignore the rest │ ├──────────┼──────┼───────────────────┤ │requester-plmn-list │array(Plmn- │This IE is used to indicate whether NF services in different PLMNs │ │Id) │Included when it needs to be discovered. │ │ │ │If included, this IE shall be │ │ │Shall include PLMN ID. (Note 12) │ ├──────────┼──────┼───────────────────┤ │requester-snpn-list │array(Plmn- │This IE contains one or more requester NFs │ │ │IdNid) │Belongs to some SNPN and NF service of a specific SNPN │ │ │included when a problem needs to be discovered│ │ │ │If present, this IE is │ │ │ │Includes SNPN ID. NRF supports NF profiles and │ │ │ │NF service "allowedSnpns" list (6. │ │ │ │see subsections 1.6.2.2 and 6.1.6.2.3) │ │ │ │ DI from the SNPN identified by this IE │ │ │NF instance that enables scavenge │ │ │ │ to return only NF profiles for │ │ │ │Use this. │ ├──────────┼──────┼───────────────────┤ │target-nf-instance- │NfInstanceId│Identifier of the NF instance being discovered│ │id │ │ │ ├──────────┼──────┼───────────────────┤ │target-nf-fqdn │Fdqh │Target NF instance during discovery│ │ │ │FQDN of the ├──────────┼──────┼───────────────────┤ │hnrf-uri │Uri │If included, this IE specifies the │ │ │ │NFDiscovery service (see section 6.2.1) │ │ │ │Contains the API URI, which is used by the requester │ │ │ │For service discovery (e.g., │ │ │ │Should be used from NSSF in the home PLMN │ │ │ │ You have received such an API URI before │ │ │ │In some cases, it is included. │ ├──────────┼──────┼───────────────────┤ │snssais │array(Snssai│If included, this IE will │ │) │by the NF (service) instance │ │ │ │Contains a list of S-NSSAIs to be served. │ │ │ │NRF has selected │ │ │ │NF(service)in with at least one │ │ │ │Stance NF Profile / NF Services │ │ │ │Return NF(service) returned by NRF │ │ │ │NF profile / NF service of the instance │ │ │ │The S-NSSAI included in the │ │ │NSSAI and its NF (service) │ │ │ │S-NSSAI supported by │ │ │ │ is an interclose of (Note 10) │ │ │ │ NF instances being discovered │ │ │ │'s NF profile is "perPlmnSnssai │ │ │ │S- │ supported in "List" │ │ │If you have defined a list of NSSAis, │ │ │ │The discovered NF instances are │ │ │ │Included in the "target-plmn-list" attribute │ │ │ │This "snssais" parameter is │ │ │ │Select one of the S-NSSAI included in the meter. │ │ │to have and exist │ │ │ │If "target-plmn-list" is included, │ │ │ │If not, NRF will │ │ │ EST supports the PLMNs that it supports. │ │ │Assuming it is for either │ ├──────────┼──────┼───────────────────┤ │requester-snssais │array(Snssai │If included, this IE is the │ │ │) │Contains a list of S-NSSAI. This IE is different │ │ │ │Included in service discovery within the PLMN│ │ │ │If NF is a requester, NF's S-│ │ │ │S- of target PLMN corresponding to NSSAI value │ │ │ │NSSAI values ​​are provided. NRF provides NF profiles. │ │ │"allowedNssais" for le and NF services │ │ │ │List (see clauses 6.1.6.2.2 and 6.1.6.2.3) │ │ │see │ │ │ │At least one network slice │ │ │ │ to be discovered by NF In│ │ │ │To return only the NF profile of the stance│ │ │ │Use this for (Note 12) │ ├──────────┼──────┼───────────────────┤ │plmn-specific-snssai│array(Plmn- │If included, this IE will │-list │Snssai) │NFs to be discovered for the PLMN │ │ │ │Services served by S-NSSAI │ │ │ │ list. NRF uses this to │ │ │S-NSSAI for a given corresponding PLMN │ │ │ │ Identify the NF service that has registered support for │ │ │ │. NRF will consider the PLMNs provided in this list. │ │ │ at least one of the following is supported │ │ │NF profile with one S-NSSAI│ │ │ │ Returns the NF profile returned by the NRF. │ │ │List of S-NSSAI per PLMN included in the file │ │ │ │The request list and NF profile │ │ │ │Interclosing with registered lists│ │ │ │It is. (Note 10) │ ├──────────┼──────┼───────────────────┤ │requester-plmn- │array(Plmn- │if included, this IE will |specific-snssai-list|Snssai) |For each PLMN to which | │ │ │Contains a list of S-NSSAI. NRF is a NF profile │ │ │In file and NF services │ │ │ │"allowedNssais" and "allowedPlmns │ │ │ │" attribute is identified by this IE │ │ │At least one network slice │ │ │ │NF Instagram allows you to be discovered by │ │ │ to return only the NF profile of the │ │ │Use (see clauses 6.1.6.2.2 and 6.1.6.2.│ │ │ │see section 3). (note 12) │ ├──────────┼──────┼───────────────────┤ │nsi-list │array(string │If included, this IE will be discovered │ │) │NSI ID served by the service│ │ │ │Contains a list of │ ├──────────┼──────┼───────────────────┤ │dnn │Dnn │If included, this IE contains a DNN │ │ │ │An NF service that serves that DNN was discovered. │ │ │ │If the target NF type is, for example, │ │ │ │"BSF", "SMF", "PCF", "PCSCF", │ │ │ │or "UPF", it may contain DNN│ │ │ │. A DNN contains a network identifier. │ │ │ and then add the operator identifier │ │ │ │It may include │ │ │. (Note 11) SNSAI (compound │ │ │If it also contains a number of NFs, the NF serves the DNN. │ │ │The service is identified by SNSAI(s)│ │ │ │in the network slice(s) │ │ │and available. │ ├──────────┼──────┼───────────────────┤ │smf-serving-area │String │If included, this IE is the SMF serving area. │ │ │Including the target NF type│ │ │ │If it is "UPF", it may be included. │ ├──────────┼──────┼───────────────────┤ │tai │Tai │Tracking Area Identifier │ ├──────────┼──────┼───────────────────┤ │amf-region-id │AmfRegionId │AMF region identifier │ ├──────────┼──────┼───────────────────┤ │amf-set-id │AmfSetId │AMF Set Identifier │ ├──────────┼──────┼───────────────────┤ │guami │Guami │Used to search for appropriate AMF │ │ │ │Guami(Note 1) │ ├──────────┼──────┼───────────────────┤ │supi │Supi │If included, this IE searches for the appropriate NF │ │ │ │Contains the SUPI of the requester UE to │ │ │SUPI supports target NF types, e.g. │ │ │"PCF", "CHF", "AUSF", "UDM" │ │ │ │or "UDR", it may be included. │ ├──────────┼──────┼───────────────────┤ │ue-ipv4-address │Ipv4Addr │BSF or P-CSCF needs to be discovered │ │ │ │ UE IPv4 address │ ├──────────┼──────┼───────────────────┤ │ip-domain │string │IPv4 address of the UE for which the BSF needs to be discovered │ │ │ │less domain │ ├──────────┼──────┼───────────────────┤ │ue-ipv6-prefix │Ipv6Prefix │BSF or P-CSCF needs to be discovered │ │ │ │The IPv6 prefix of the UE. │ ├──────────┼──────┼───────────────────┤ │pgw-ind │Boolean │If present, this IE is the combined SMF / │ │ │ │PGW-C or independent SMF needs to be found│ │ │ │Indicates whether there is a true SMF │ │ │ / PGW-C is required to be discovered. │ │ │ │false: Requires that a standalone SMF be discovered│ │ │ │will be. (See Note 2) │ ├──────────┼──────┼───────────────────┤ │pgw │Fqdn │If included, this IE is the combined SMF / │ │ │ │By AMF from MME to discover PGW │ │ │ │Contains the received PGW FQDN. │ ├──────────┼──────┼───────────────────┤ │gpsi │Gpsi │If included, this IE shall │ │ │Requester UE's GPSI for scouting│ │ │ │Includes. Target NF type is "CHF", │ │ │ │"PCF", "UDM", or "UDR" │ │ │ │In some cases, GPSI may be included. │ ├──────────┼──────┼───────────────────┤ │external-group- │ExtGroupId │If included, this IE is used to │identity │ │To search, external │ │ │ │Contains a group identifier. This is │ │ │The NF type is "UDM" or "UDR"│ │ │ │It may be included in the following cases. │ ├──────────┼──────┼───────────────────┤ │pfd-data │PfdData │If present, this IE is used for PFD management. │ │ │Application Identifier and / or │ │ │ │Application Functions │ │ │ │Identifier. This is the target NF type. │ │ │May be included if the group is "NEF". │ ├──────────┼──────┼───────────────────┤ │data-set │DataSetId │Supported by the NF to be discovered │ │ │ │Shows the data set. Target NF type│ │ │ │ can be included if is "UDR". │ ├──────────┼──────┼───────────────────┤ │routing-indicator │string │using SUCI (see 3GPP 23.003

[12] ) │ │ │ │Network signaling to subscribers │ │ │ AUSF and UDM instances that can be used │ │ │Make it possible to route to a chest of drawers │ │ │ │Routing indicator information. │ │ │Get NF type is "AUSF" or "UDM" │ │ │ │ can be included if │ │ │ │Pattern: "^[0-9]{1,4}$" │ ├──────────┼──────┼───────────────────┤ │group-id-list │array(NfGro │Target NF type to be discovered│ │ │upId) │Identifier of the group of NFs. Target NF │ │ │Types are "UDR", "UDM", "HSS", and "PCF │ │ │, "AUSF" or "CHF" │ │ │ │Can be included. │ ├──────────┼──────┼───────────────────┤ │dnai-list │array(Dnai) │If included, this IE is a datanet │ │ │ │Contains a work access identifier. Target │ │ │ │If the NF type is "UPF", it includes │ │ │It can be. │ ├──────────┼──────┼───────────────────┤ │upf-iwk-eps-ind │Boolean │If present, this IE will interface with EPS. │ │ │ │ A UPF that supports │ │ │ │ Indicates whether EPS│ │ │ │Supports interworking with │ │ │ │UPF is requested to be discovered; │ │ │ │false: Supports interworking with EPS │ │ │ │Request to discover unsupported UPF │ │ │ │do. (Note 3) │ ├──────────┼──────┼───────────────────┤ │chf-supported-plmn │PlmnId │If included, this IE indicates that CHF supports │ │ │ │includes the PLMN ID to be │ │ │ in the ChfInfo attribute PlmnRange. │ │ │ has a target NF type of "CHF" │ │ │ │It can sometimes be included. │ ├──────────┼──────┼───────────────────┤ │preferred-locality │string │Preferred target NF location (e.g. │ │ │ │For example, geographic location, data center). │ │ │If │ │, the NRF matches the preferred locality. │ │ │NF profile with locality attribute │ │ │It is preferable. NRF, for example, is preferable │ │ │Matches the new target NF location│ │ │ │If no NF profile is found, the preferred │ │ │Does not match the new target NF location │ │ │If the response does not include the NF, an additional NF is returned. │ │ │ can be achieved. NRF is a preferred target │ │ │Responses that do not match the NF location│ │ │ │For any additional NF in the │ │ │Matches the new target NF location│ │ │ │should be given lower priority than │ │ │ │. (Note 6) │ ├──────────┼──────┼───────────────────┤ │access-type │Access │If included, this IE specifies the │ │Type │Subnetwork function (i.e. SMF) │ │ │Access that needs to be ported│ │ │ │Includes type. │ ├──────────┼──────┼───────────────────┤ │supported-features │Supported │Supported by target network features │ │ │Features │List of features that need to be done│ │ │Supported │ . This IE supports │ │ │ │and it contains a single service name │ │ │ │ can exist. │ │ │If this is the case, it will be ignored by the NRF. (Note 4) │ ├──────────┼──────┼───────────────────┤ │required-features │array(Support│Defined in the supportedFeatures attribute of NFService│ │ │tedFeatures)│Target network features│ │ │ │ of features that need to be supported by │ │ │ │List (see clauses 6.1.6.2.3 and 6.2.6.2.4) │ │ │See │ ... │ │ │It can only exist if it exists. │ │ │ then the required-features attribute is │ │ │The same number of entries as there are in the ames attribute. │ │ │Includes an entry in the required-features attribute. │ │ │The th entry is the nth entry in the service-names attribute. │ │ │th entry. A particular feature is │ │ │ │Entities that handle services that are not needed│ │ │ │ is coded as "0". │ ├──────────┼──────┼───────────────────┤ │complex-query │ComplexQuery│This query parameter is a query parameter│ │ │Combined queries│Override the default logical relationship of │ │ │used to ├──────────┼──────┼───────────────────┤ │limit │integer │NF profile to be returned in the response│ │ │ │Maximum number of files. │ │ │ │Minimum: 1 │ ├──────────┼──────┼───────────────────┤ │max-payload-size │Integer │Maximum payload size of response (compressed │ │ │ │before, if present). Expressed in kilo-octets │ │ │ │If present, the NRF is │ │ │so as not to exceed the maximum payload size│ │ │ │NF profile returned in response│ │ │ │Limit the number of rules. Default: 124. │ │ │ │Maximum: 2000 (i.e. 2 Mo). │ ├──────────┼──────┼───────────────────┤ │max-payload-size-ext│ Integer │ Maximum payload size of response (compressed │ │ │ │before, if present). Expressed in kilo-octets │ │ │ │If present, the NRF is │ │ │so as not to exceed the maximum payload size│ │ │ │NF profile returned in response│ │ │ │Limit the number of rules. This query parameter │ │ │The data is generated when the consumer │ │ │Supports larger payload sizes than │ │ │Used when. │ │ │ │Default: 124 │ ├──────────┼──────┼───────────────────┤ │pdu-session-types │array(PduSes│Target network capabilities (i.e., │ │ │sionType) │UPF) is required to be supported │ │ │ of the selected PDU session type(s) │ │ │ │List │ ├──────────┼──────┼───────────────────┤ │event-id-list │array(Event │If present, this attribute is │ │Id) │Supported by the ticsInfo service│ │ │ │Contains a list of events that are required │ │ │NRF will send all requested events to │ │ │ │Returns the supported NF. │ ├──────────┼──────┼───────────────────┤ │nwdaf-event-list │array(Nwdaf │If present, this attribute is │ │Event) │Supported by the Subscription service│ │ │ │List of events requested to be │ │ │Including, NRF will provide all requested events │ │ │ │Returns an NF that supports the ├──────────┼──────┼───────────────────┤ │atsss-capability │AtsssCapabil│If present, this IE indicates that the target UPF │ │ity │ATSS capabilities need to be supported │ │ │ indicates that. │ ├──────────┼──────┼───────────────────┤ │upf-ue-ip-addr-ind │Boolean │If present, this IE indicates the UE IP destination / pre │ │ │UPF supports fix allocation │ │ │ │ indicates whether │ needs to be discovered. │ │ │true: UE IP destination / prefix allocation │ │ │ │It is possible to discover a UPF that supports │ │ │required; │ │ │ │false:UE IP address / prefix allocation│ │ │ │ A UPF that does not support targeting has been discovered. │ │ │is required. │ ├──────────┼──────┼───────────────────┤ │client-type │External │If present, this IE will │ │ClientType │Serving dedicated to client type │ │ │ │show that NF needs to be found│ │ │ │This IE's target NF type is "LMF" │ │ │ │ and "GMLC". │ │ │ │ Dedicated support for the requested client type │ │ │If no NF profile can be found to scan, │ │ │In that case, the NRF will return the request │ │ │ │Serves client types exclusively │ │ │ │You can return NF that does not. │ ├──────────┼──────┼───────────────────┤ │lmf-id │LMFIdentifi-│If present, this IE identifies the LMF to be discovered. │ │ │cation │includes information about the target NF type. │ │ │May be included if the group is "LMF". │ ├──────────┼──────┼───────────────────┤ │an-node-type │AnNodeType │If included, this IE will │ │ │to network function (i.e., LMF) │ │ │Therefore, AN nodes that need to be supported│ │ │ │Includes type. │ ├──────────┼──────┼───────────────────┤ │rat-type │RatType │If included, this IE will │ │ │Network function (i.e., LMF) │ │ │RAT types that need to be ported │ │ │ │Including. │ ├──────────┼──────┼───────────────────┤ │target-snpn │PlmnIdNid │This IE is used to identify the NF service of a particular SNPN.│ │ │ │Included when it is necessary to │ │ │ │If included, this IE │ │ │Contains the PLMN ID and NID of the target NF. │ ├──────────┼──────┼───────────────────┤ │af-ee-data │AfEventExpo-│If present, this is the application │ │sureData │Events, and optionally, AF apps │ │ │Application function identifier and application│ | | | NF identifier. This is the target NF | │ │ │May be included if type is "NEF" │ ├──────────┼──────┼───────────────────┤ │w-agf-info │WAgfInfo │If included, this IE specifies the │ │ │Received by SMF to find F / UPF │ │ │W-AGF identifier of N3 termination to be │ │ │Includes. │ ├──────────┼──────┼───────────────────┤ │tngf-info │TngfInfo │If included, this IE indicates the │ │ │ / UPF received by SMF to find │ │ │ │TNGF identifier of the N3 termination to be │ │ │Includes. │ ├──────────┼──────┼───────────────────┤ │twif-info │TwifInfo │If included, this IE will │ │ │ / UPF received by SMF to find │ │ │ │The TWIF identifier of the N3 termination to be │ │ │Includes. │ ├──────────┼──────┼───────────────────┤ │target-nf-set-id │NfSetId │If present, this IE specifies the NF │ │ │Target NF Set ID of the instance (3GPP │ │ │ │As defined in section 28.12 of TS 23.003

[12] │ │ │ │Including. │ ├──────────┼──────┼───────────────────┤ │target-nf-service- │NfService- │If present, this IE will be discovered │ │set-id │SetId │Target NF of the NF service instance │ │ │ │Service Set ID (as defined in │ │ │ │As defined in Section 28.13. │ ├──────────┼──────┼───────────────────┤ │preferred-tai │Tai │If present, NRF should support TAI│ │ │ │ you prefer an NF profile that allows │ │ │NRF finds NF profile that matches TAI│ │ │ │If not found, NF pro that does not match TAI │ │ │ │Return the file. (Note 5) │ ├──────────┼──────┼───────────────────┤ │nef-id │NefId │If present, this IE should be discovered│ │ │ │Contains the NEF ID of the NEF. This is the target │ │ │ │Included when NF type is "NEF" │ │ │ │obtain. (Note 7) │ ├──────────┼──────┼───────────────────┤ │preferred-nf- │array(NfInst│If present, this IE lists the preferred candidate NFs│ │instances │anceId) │Contains a list of instance IDs. (Note 8) │ ├──────────┼──────┼───────────────────┤ │notification-type │Notification│If included, this IE is used to notify the NF that is discovered. │Type │ │NFProfile or NFService of the instance│ │ │ │ Default notification subscriptions to be registered │ │ ... │ │ │The NF profile returned is the notification type. │ │ │All including those that correspond to the parameters│ │ │ │Registered default notification subscriptions for │ │ │ │Including │ │ │ (Note 9) │ ├──────────┼──────┼───────────────────┤ │n1-msg-class │N1Message- │This IE is "notification-type" IE is │ │ │Class │If present with value "N1_MESSAGES", it will be included │ │ │ │is found. │ │ │NFProfile of the NF instance or │ │ │ │The default message to be registered in NFService │ │ │ │N1 Message Class of Chi Subscription│ │ │ │ Contains the NF profile returned by the NRF. │ │ │The file corresponds to the n1-msg-class parameter│ │ │ │All registered │ │ │ │Includes fault notification subscriptions. │ │ │ │(Note 9) │ ├──────────┼──────┼───────────────────┤ │n2-info-class │N2Informa- │This IE is "notification-type" IE is │ │ │tionClass │Included if present with value "N2_INFORMATION"│ │ │ │is found. │ │ │NFProfile of the NF instance or │ │ │ │The default message to be registered in NFService │ │ │ │ Contains the notification type of the subscription │ │ │ │. The NF profile returned by the NRF is │ │ │ │Corresponding to the n2-info-class parameter │ │ │ │ All registered defaults, including │ │ │ │Including notification subscriptions. (Note 9) │ ├──────────┼──────┼───────────────────┤ │serving-scope │array(string │If present, this attribute should be discovered│ │ │) │is provided by the NF instance│ │ │ │Contains a list of areas where │ │ │ │All requested in the query parameters│ │ │ │NF profile that can handle the range │ │ │Return. │ ├──────────┼──────┼───────────────────┤ │imsi │String │If included, this IE searches for the appropriate NF │ │ │ │Includes the IMSI of the requester UE to │ │ │IMSI is target NF type "HSS" │ │ │ │If there is, it may be included. │ │ │ │Pattern: "[0-9]{5,15}" │ ├──────────┼──────┼───────────────────┤ │ims-private-identity│ String │If included, this IE searches for the appropriate NF │ │ │ │to do this, the requester UE's IMS private │ │ │ Includes the port identifier. IMS Private Identity │ │ │ │The target NF type of the child is "HSS" │ │ │ │It may be included if │ ├──────────┼──────┼───────────────────┤ │ims-public-identity │String │If included, this IE searches for the appropriate NF │ │ │ │to do this, the requester UE's IMS │ │ │ │IMS public identifiers are │ │ │ │If the target NF type is "HSS" │ │ │ │It can be included. │ ├──────────┼──────┼───────────────────┤ │msisdn │string │If included, this IE searches for the appropriate NF│ │ │ │contains the MSISDN of the requester UE to │ │ │The IMS public identifier is the │ │ │ │If the type is "HSS", it may be included. │ ├──────────┼──────┼───────────────────┤ │internal-group- │GroupId │If included, this IE is used to search for the appropriate NF │ │identity │ │Contains the UE's internal group identifier to │ │ │. This is because the target NF type is "UDM" │ │ │ │ may be included when │ ├──────────┼──────┼───────────────────┤ │redundant-transport │Boolean │If present, this IE indicates that the corresponding │ │ │on the transport layer in a work slice│ │ │ │Supports redundant transport paths │ │ │ │Indicates whether UPF needs to be discovered │ │ │ │Yes. │ │ │ │ │ │ │ │true: Redundant transformer on the transport layer│ │ │ │Discover UPFs that support port paths │ │ │ │request to burr; │ │ │ │false:Redundant transformer on the transport layer│ │ │ │ Issued a UPF that does not support port paths │ │ │ │Request to see. │ │ │ │ │ │ │ │If SNSAI is also included, transport │ │ │ │Supports redundant transport paths on layers│ │ │ │The UPF is identified by SNSAI │ │ │ │Available in network slices│ │ │ │Yes. │ ├──────────┼──────┼───────────────────┤ │ipups │Boolean │If present, this IE is configured to │ │ │A configured UPF is required to be discovered │ │ │ │Indicates whether or not │ │ │ │ │ │ │true: Disables UPF configured for IPUPS. │ │ │Request to scavenge; │ │ │ │false: IPUPS is not configured for UPF. │ │ │Request discovery. │ ├──────────┼──────┼───────────────────┤ │scp-domain-list │array(string │If present, this IE is used to list the domains in the target │ │ │) │or the SCP domain to which the SCP belongs. │ │ │ │NRF endorses all products offered in this list. │ │ │NF or SCP process belonging to all SCP domains │ │ │Return the file. │ ├──────────┼──────┼───────────────────┤ │address-domain │Fqdn │If included, this IE is used to │ │ │Includes address domains that should be reachable│ │ │ │This IE has a target NF type of "SCP" │ │ │ │ can be included when │ ├──────────┼──────┼───────────────────┤ │ipv4-addr │Ipv4Addr │If included, this IE is the │ │ │ │Contains reachable IPv4 addresses. │ │ │ │This IE has a target NF type of "SCP" │ │ │ │ can be included when │ ├──────────┼──────┼───────────────────┤ │ipv6-prefix │Ipv6Prefix │If included, this IE is passed through the SCP │ │ │Contains reachable IPv6 prefixes│ │ │ │This IE has a target NF type of "SCP" │ │ │ │ can be included when │ ├──────────┼──────┼───────────────────┤ │served-nf-set-id │NfSetId │If present, this IE is the │ │ │ │Contains the NF set ID that should be reachable. │ │ │ │This IE has a target NF type of "SCP" │ │ │ │ can be included when │ ├──────────┼──────┼───────────────────┤ │remote-plmn-id │PlmnId │If included, this IE is the │ │ │ │Contains the remote PLMN IDs that are reachable. │ │ │ │This IE has a target NF type of "SCP" │ │ │ │ can be included when │ ├──────────┼──────┼───────────────────┤ │data-forwarding │Boolean │This is for target NF type "UPF" │ │ │ │May be included in some cases. (Note 13) │ │ │ │ │ │ │ │If present, IE will use │ │ │ │Does the configured UPF need to be discovered? │ │ │ │Indicates whether or not │ │ │ │ │ │ │true: Disables the UPF setting for data transfer. │ │ │Request to scavenge; │ │ │ │false: Not configured for data transfer │ │ │ │Request to discover UPF. │ ├──────────┼──────┼───────────────────┤ │preferred-api- │map(string) │If present, this IE is used to │versions │ │The services supported by the instance│ │ │ │Indicates the preferred API version of the service. │ │ │ │The key of the map is the service name (6.1.6.3.11 │ │ │ │see section │ │ │ │The preferred API version is indicated. │ │ │ │Each element is represented by a key│ │ │ │API version indicator for the service │ │ │ │ conveys the desired │ │ │ │NF profile that matches the new API version │ │ │ │If no rule is found, the preferred API version │ │ │ │In responses that do not match John │ │ │ │Additional NF can be returned. API version │ │ │ │The indication is {operator}+ │ │ │ │Formatted as {API version} │ │ │ │It is a string. The following operators are supported│ │ │ │shall: │ │ │ │ │ │ │ │"="Specified version value and version │ │ │ │ matches. │ │ │ │">" is greater than the version value displayed│ │ │ │It matches the new version. │ │ │ │">="Version equal to or greater than the indicated version value │ │ │ │ matches the │ │ │ │"<" Less than the version value shown │ │ │ │Matches the version. │ │ │ │"<="Any version value less than or equal to the specified version │ │ │ │ matches the version. │ │ │ │"^" indicates a version compatible with the specified version. │ │ │A version, i.e., a specified version │ │ │ has the same major version as the version │ │ │ │Matches the version. │ │ │ │ │ │ │ │The priority between versions is major, │ │ │ │Minor and patch versions │ │ │ │Compare fields numerically from left to right│ │ │ │It is identified by. │ │ │ │ │ │ │ │Operator or unknown operator is API version │ │ │ │If not specified in the indication│ │ │ │If so, the "=" operator is applied. │ │ │ │ │ │ │ │Example of API version indication: │ │ │ │ │ │ │ │Case1: 「=1.2.4.operator-ext」 or │ │ │ │"1.2.4.operator-ext" is a service │ │ │API version "1.2.4.operator-ext" and │ │ │ │means it matches │ │ │ │Case2: ">1.2.4" is an API version │ │ │ │Matches services greater than "1.2.4" │ │ │ │means │ │ │ │Case3: "^2.3.0" or "^2" is the major │ │ │ │All API versions from version "2" and │ │ │ │This means that the service matches. │ ├──────────┼──────┼───────────────────┤ │v2x-support-ind │Boolean │If present, this IE indicates whether V2X policy / pair support is enabled. │ │ │Supports parameter provisioning│ │ │ │Whether PCF needs to be discovered │ │ │ │Show. │ │ │ │ │ │ │ │true: V2X policy / parameter provisioning│ │ │ │A PCF that supports │ │ │ │ be required to; │ │ │ │false: V2X policy / parameter provisioning │ │ │ │You can use a PCF that does not support │ │ │ │Request to scavenge. │ ├──────────┼──────┼───────────────────┤ │redundant-gtpu │Boolean │If present, this IE indicates that redundant GTP-U │ │ │A UPF that supports the route needs to be discovered. │ │ │Indicates whether it exists. │ │ │ │ │ │ │ │true: Supports redundant GTP-U routes │ │ │ │Request to discover UPF; │ │ │ │false: Redundant GTP-U paths are not supported. │ │ │Request to discover a UPF that does not exist │ ├──────────┼──────┼───────────────────┤ │preferred-full-plmn │Boolean │If present, NRF will offer full PLMN │ │ │ │ can be used (i.e., any │ │ │NF Pro can provide you with the TAI of your choice. │ │ │Prefer file or complete PLMN │ │ │ │No NF profile found that provides │ │ │ │If │, the NRF returns another NF profile:│ │ │ │ │ │ │ │- true: NF instance providing complete PLMN │ │ │ │Chest of drawers takes precedence; │ │ │ │- false: NF instance that provides a complete PLMN │ │ │ │Chests of drawers are not recommended. │ │ │ │(Note 14) │ ├──────────┼──────┼───────────────────┤ │requester-features │Supported- │The Nnrf_NFDiscovery service is being called. │ │Features │Supported by the requester NF │ │ │ │Nnrf_NFDiscovery Features. │ │ │ │At least one feature is provided to the requester │ │ │ │ Therefore, if supported, this IE │ │ │ │Included. │ ├──────────┼──────┼───────────────────┤ │realm-id │String type │Included when the target NF type is "UDSF"│ │ │ │if included, this IE │ │ │It contains the realm-id and the UDSF for it │ │ │It should be discovered. │ ├──────────┼──────┼───────────────────┤ │storage-id │string type │The target NF type is "UDSF", │ │ │ │Included if realm-id is included. │ │ │ │If included, this IE indicates that UDSF is discovered │ │ │should be indicated in the realm-id IE │ │ │ │Includes the storage-id for the realm-id. │ ├──────────┼──────┼───────────────────┤ │vsmf-support-ind │Boolean │If included, this IE indicates V-SMF capability. │ │ │Supporting target SMF is preferred │ │ │ │ indicates │ │ │ │ │ │ │ │This IE's target NF type is "SMF" │ │ │ │ can be included when │ │ │ │(Note 15) │ └──────────┴──────┴───────────────────┘

[0035] According to one embodiment, in addition to including one or more of the above query parameters, the query parameters include: i) a notification type identifier that identifies the type of notification provided by the service producer; and ii) a consumer supported features parameter that identifies one or more features that are desired to be supported by a service consumer subscribing to the notification of the identified type by default. In this way, it is possible for an NF producer to indicate the required supported features of an NF consumer for a particular default subscription. For example, according to one embodiment, along with the existing query parameter "NotificationType", a new query parameter (e.g., "nfConsumerSupportedFeatures") is provided that indicates the to-be-supported features required for a candidate NF that is a candidate as a consumer when performing the selection of an NF consumer to receive notifications for the default notification subscription.

[0036] In response to the discovery message 253, the NRF 204 sends a discovery response message 255 to the service producer 202, which may include one or more service consumer profiles that match the query parameters.

[0037] After receiving the discovery response message 255, the service producer 202 can send a notification message 257 to the service consumer 201 due to the fact that the service producer 202 has determined, based on the service consumer's 201 profile, that the service consumer 201 subscribes to this notification by default. Sending the notification message may consist of the service producer 202 sending an HTTP message comprising a set of one or more headers and a body, where the body comprises the notification message 257.

[0038] According to one embodiment, as new HTTP headers are introduced (e.g., 3gpp-Sbi supported features) or existing HTTP customer headers are reused when appropriate, the service producer 202 can include a header indicating its supported features in the HTTP message and the service consumer 201 can include the supported features in the notification response message 259.

[0039] 3 is a flow chart illustrating a process 300 according to one embodiment. The process 300 may be performed by the service consumer 201 and may begin at step s302.

[0040] Step s302 includes invoking a management service provided by a network repository function (e.g., NRF 204). Invoking the management service includes generating a management message (e.g., message 251) including a profile for the service consumer (step s304) and sending the management message including the profile to the network repository function (step s306). The profile includes first default notification subscription information. The first default notification subscription information includes: a first notification type identifier that identifies a first notification type to which the service consumer subscribes by default, where notifications of the first notification type are provided by a service producer that provides a service for providing notifications; and ii) first feature support information that identifies one or more features supported by the service consumer for a service provided by the service producer for providing notifications.

[0041] According to some embodiments, the management message is an HTTP PUT message including the profile. According to some embodiments, the management message is sent for i) an initial service registration or ii) an update of a service registration. According to some embodiments, the service is a communication service (e.g., Namf_Communication service) provided by an instance of an Access and Mobility Management Function (AMF). According to some embodiments, the service consumer is at least an instance of a Location Management Function (LMF) or an Access and Mobility Management Function (AMF). According to some embodiments, the first feature support information is a string including a bitmask indicating the supported features.

[0042] 4 is a flow chart illustrating a process 400 according to one embodiment. The process 400 may be performed by the service producer 202 and may begin at step s402. Step s402 includes invoking a discovery service to discover service consumers. Invoking the discovery service includes generating a discovery message including query parameters (step s404) and sending the discovery message including the query parameters to a network repository function (step s406). The query parameters include i) a notification type identifier that identifies the type of notification provided by the service producer, and ii) a consumer supported features parameter that identifies one or more features desired to be supported by service consumers that subscribe to notifications of the identified type by default.

[0043] According to some embodiments, the discovery message comprises an indicator indicating that one or more features identified by the consumer-supported features parameter are required to be supported by the service consumer. According to some embodiments, the discovery message comprises an indicator indicating that one or more features identified by the consumer-supported features parameter are preferably supported by the service consumer. According to some embodiments, the discovery message is an HTTP GET message including a query parameter. According to some embodiments, the service producer is at least one instance of an Access and Mobility Management Function (AMF). According to some embodiments, the service consumer is at least an instance of a Location Management Function (LMF) or an Access and Mobility Management Function (AMF). According to some embodiments, the consumer-supported features parameter is a string including a bitmask identifying one or more features.

[0044] 5 is a flow chart illustrating a process 500 according to one embodiment. Process 500 may be performed by the NRF 204 and may begin at step s502. Step s502 includes the NRF receiving a management message 251 and / or a discovery message 253. According to some embodiments, the NRF receives a management message as defined in claim A1 and stores a profile in a data repository. According to some embodiments, the NRF receives a discovery message as defined in claim B1 and the NRF determines whether the profile matches the query parameters.

[0045] According to some embodiments, the NRF sends a response to the discovery message, where the response includes the profile only if the NRF determines that the profile indicates that the service consumer supports the desired feature.

[0046] According to some embodiments, the NRF sends a response to the discovery message, where the response includes the profile, even if the NRF determines that the profile indicates that the service consumer does not support the desired feature.

[0047] According to some embodiments, determining whether the profile matches the query parameters includes determining whether the features identified by the consumer-supported features parameter are also identified by first feature support information included in the first default notification subscription information.

[0048] FIG. 6 is a flow chart illustrating a process 600 according to one embodiment. The process 600 may be performed by the service producer 202 and may begin at step s602. Step s602 includes receiving a profile for the service consumer from a network repository function, the profile including a default notification subscription including supported feature information indicating at least a set of information elements supported by the service consumer. Step s604 includes determining information elements supported by the service consumer from the supported feature information. Step s606 includes generating a notification for the service consumer based on the determined information elements. Step s608 includes sending the notification to an address specified in the default notification subscription (e.g., an address included in or identified by a Uniform Resource Identifier (URI) specified in the default notification subscription). According to some embodiments, generating the notification based on the determined information elements includes generating the notification such that the notification includes only information elements supported by the service consumer.

[0049] FIG. 7 is a flow chart illustrating a process 700 according to one embodiment. The process 700 may be performed by the service consumer 201 and may begin at step s702. Step s702 includes receiving a first message (e.g., a first HTTP message) from a service producer related to a service provided by the service producer. The first message comprises a header and a body. The body comprises a message for the service consumer, and the header comprises service producer supported feature information identifying one or more features of the service supported by the service producer. Step s704 includes sending a second message (e.g., a second HTTP message) to the service producer in response to the first message. The second message comprises a header comprising service consumer supported feature information identifying one or more features of the service supported by the service consumer.

[0050] According to some embodiments, the first message includes a notification and the second message is a notification response message. According to some embodiments, the service producer is at least an instance of an Access and Mobility Management Function (AMF) and the service is at least a communication service (e.g., a Namf_Communication service). According to some embodiments, the service consumer is at least an instance of a Location Management Function (LMF) or an Access and Mobility Management Function (AMF). According to some embodiments, the service consumer supported features information is a string including a bitmask that identifies one or more features of the service supported by the service consumer.

[0051] FIG. 8 is a flow chart illustrating a process 800 according to one embodiment. The process 800 may be performed by the service producer 202 and may begin at step s802. Step s802 includes providing a service to a service consumer. Providing the service includes sending a first message (e.g., an HTTP message) including a header and a body to the service consumer (step s804). The body comprises a message for the service consumer, and the header comprises service producer supported feature information identifying one or more features of the service supported by the service producer. Step s804 includes receiving a second message (e.g., a second HTTP message) sent by the service consumer in response to the first message. The second message comprises a header comprising service consumer supported feature information identifying one or more features of the service supported by the service consumer. Step s806 includes storing the service consumer supported feature information. Step s808 includes utilizing the stored service consumer supported feature information when subsequently providing the service to the service consumer.

[0052] According to some embodiments, the first message includes a notification and the second message is a notification response message. According to some embodiments, the service producer is at least an instance of an Access and Mobility Management Function (AMF) and the service is at least a communication service (e.g., a Namf_Communication service). According to some embodiments, the service consumer is at least an instance of a Location Management Function (LMF) or an Access and Mobility Management Function (AMF). According to some embodiments, the service consumer supported features information is a string including a bitmask that identifies one or more features of the service supported by the service consumer.

[0053] 9 is a block diagram of a network node 900 that may be used to implement a service consumer 201, a service producer 202, and / or an NRF 204, according to some embodiments. For example, according to an embodiment in which the service consumer 201, the service producer 202, and / or the NRF 204 are comprised of software, the network node 900 may execute (or execute a virtual machine that executes) the service consumer 201, the service producer 202, and / or the NRF 204. As shown in FIG. 9 , the network node 900 may comprise a processing circuit (PC) 902, which may include one or more processors (P) 955 (e.g., a general-purpose microprocessor and / or one or more other processors, such as an application specific integrated circuit (ASIC), field programmable gate array (FPGA), etc.), which may be co-located in a single housing, or co-located in a single data center, or geographically distributed (i.e., the network node 900 may be a distributed computing device), and a network interface 948, which comprises a transmitter (Tx) 945 and a receiver (Rx) 947 to enable the network node 900 to transmit and receive data to and from other machines connected to the network 110 (e.g., an Internet Protocol (IP) network) to which the network interface 948 is connected (directly or indirectly), where the network interface 948 may be wirelessly connected to the network 110. The interface 948 is connected to an antenna device and a local storage unit (also referred to as a “data storage system”) 908, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. According to an embodiment in which the PC 902 includes a programmable processor, a computer program product (CPP) 941 may be provided. The CPP 941 includes a computer readable storage medium (CRSM) 942 that stores a computer program (CP) 943 that includes computer readable instructions (CRI) 944.The CRSM 942 may be a non-transitory computer readable medium, such as a magnetic medium (e.g., hard disk), an optical medium, a memory device (e.g., random access memory, flash memory), etc. According to some embodiments, the CRI 944 of the computer program 943, when executed by the PC 902, is configured to cause the network node 900 to perform the steps described herein (e.g., steps described herein with respect to flowcharts). According to other embodiments, the network node 900 may be configured to perform the steps described herein without the need for code. That is, for example, the PC 902 may consist only of one or more ASICs. Thus, features of the embodiments described herein may be implemented in hardware and / or software.

[0054] While various embodiments are described herein, it should be understood that they are presented by way of example only, not limitation. Thus, the breadth and scope of the present disclosure should not be limited by any of the exemplary embodiments described above. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the present disclosure unless otherwise indicated herein or clearly contradicted by context.

[0055] Additionally, while the processes described above and illustrated in the Figures are shown as a series of steps, this is done for illustrative purposes only, and it is therefore contemplated that some steps may be added, some steps may be omitted, the order of the steps may be rearranged, and some steps may be performed in parallel.

Claims

1. A method (500) performed by a Network Repository Function (NRF) (204), the method comprising: Receiving (s502) a management message (251); Receiving (s504) a discovery message (253); Including, The management message (251) includes a profile relating to a service consumer; the profile for the service consumer includes first default notification subscription information; The first default notification subscription information includes: a first notification type identifier identifying a first notification type to which the service consumer subscribes by default, where notifications of the first notification type are provided by a service producer (202) that provides a service for providing the notifications; first feature support information identifying one or more features that the service consumer supports for the service provided by the service producer for providing the notification; Including, The discovery message (253) includes a query parameter; The query parameters are: a notification type identifier that identifies the type of notification provided by the service producer; a consumer-supported-feature parameter that specifies one or more features that are desired to be supported by service consumers (201) that subscribe to notifications of the specified type by default; The method further comprises: determining whether the profile matches the query parameters; transmitting a response to the discovery message; The method of claim 1, wherein the response includes the profile even if the NRF determines that the profile indicates that the service consumer does not support the desired feature.

2. The method of claim 1 , wherein the NRF receives the management message and stores the profile in a data repository.

3. 3. The method of claim 1 or 2, wherein determining whether the profile matches the query parameters comprises determining whether a feature identified by the consumer-supported features parameter is also identified by the first feature support information included in the first default notification subscription information.

4. A method (600) performed by a service producer (202), the method comprising: receiving (s602) a profile for a service consumer (201) from a network repository function (204), where the profile includes default notification subscriptions including supported feature information indicating at least a set of information elements supported by the service consumer; determining (s604) the information elements supported by the service consumer from the supported feature information; generating a notification for the service consumer based on the determined information element (s606); Sending the notification to an address specified in the default notification subscription (s608); and A method comprising:

5. 5. The method of claim 4, wherein generating the notification based on the determined information elements comprises generating the notification such that the notification includes only information elements supported by the service consumer.

6. A computer program (943) comprising instructions (944) which, when executed by a processing circuit (955) of a network node (900), causes said network node to perform the method according to any one of claims 1 to 5.

7. A computer readable storage medium (942) containing the computer program of claim 6.

8. A network node (900), said network node being configured to perform the method according to any one of claims 1 to 5.

9. A network node (900) comprising a processing circuit (955) and a memory (942) containing instructions (944) executable by said processing circuit, whereby said network node is configured to perform a method according to any one of claims 1 to 5.

Images