Patent Description:
Identification is needed in various communication networks to ensure that users and network entities can be identified properly. For example, in core networks of cellular communication systems, such as in <NUM> core networks developed by the 3rd Generation Partnership Project, 3GPP, Network Functions, NFs, and NF instances need to be identified. The 3GPP still develops <NUM> core networks and there is a need to provide improved methods, apparatuses and computer programs for enhancing identification in <NUM> core networks, and in other networks in the future as well.

<CIT> relates to a network function profile management method and apparatus, and more particularly, to registration / update/ deregistration of a network function profile. <CIT> presents service discovery extension in a <NUM> mobile communication network.

According to some aspects, there is provided the subject-matter of the independent claims. Some example embodiments are defined in the dependent claims.

The scope of protection sought for various example embodiments of the invention is set out by the independent claims. The example embodiments and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various example embodiments of the invention.

Identification may be enhanced by the procedures described herein for example for Network Functions, NFs, in communication networks, such as in <NUM> core networks or other core networks. At least in the case of <NUM> core networks, flexibility would be beneficial and hence, a flexible framework for identification is provided. NFs may be identified by a NF instance Identity, ID, (NFInstanceID). The NFInstanceID may be defined as a combination of a string associated with the NFInstanceID and a type of the NFInstanceID. For a certain NFInstanceID, the type may be selected from a set of possible NFInstanceID types. For example, the set of possible NFInstance types may comprise at least Universally Unique Identifier, UUID, and Secure Production Identity Framework for Everyone, SPIFFE, identity types. Then, the NFInstanceID may be determined based on the string associated with the
NFInstanceID and the type of the NFInstanceID, thereby providing a flexible scheme for identification.

<FIG> illustrates an example system in accordance with at least some example embodiments of the present invention. The example system of <FIG> comprises NF <NUM>, which may refer to an operational and/or a physical entity. NF <NUM> may be a specific network node or element, or a specific function or set of functions carried out by one or more entities, such as Virtualized Network Functions, VNFs. At least some embodiments of the present invention may be applied in containerized deployments as well. One physical node may be configured to perform plural NFs. Examples of such network functions include a (radio) access or resource control or management function, session management or control function, interworking, data management or storage function, authentication function or a combination of one or more of these functions. In general, in accordance with embodiments of the present invention, NF <NUM> may also refer to a Service Communication Proxy, SCP, having a delegated role on behalf of a NF consumer,NFc, or NF producer,NFp. That is to say, the SCP may be configured to perform at least some actions of an NF and hence considered as NF <NUM>.

In case of a <NUM>rd Generation Partnership Project, 3GPP, Service-Based Architecture, SBA, of <NUM> core networks, NF <NUM> may comprise at least some of an Access and Mobility Function, AMF, a Session Management Function, SMF, a Network Slice Selection Function, NSSF, a Network Exposure Function, NEF, an Network Repository Function, NRF, a Unified Data Management, UDM, an Authentication Server Function, AUSF, a Policy Control Function, PCF, an Application Function, AF, Operations Administration and Maintenance, OAM, and Network Data Analysis Function, NWDAF.

NF <NUM> or instances of NF <NUM> may offer services to other NFs or NF instances. In order for a requested NF type, NF service or NF service instance to be discovered via NRF <NUM>, the NF instance needs to be registered in NRF <NUM>. After registration, NRF <NUM> maintains NF profiles of available NF instances and their supported services.

NF <NUM> may be identified by an instance identity of NF <NUM>, i.e., NFinstanceID of NF <NUM>. An information element NFInstanceID may be, along with other information elements, included in the profile of NF <NUM> at NRF <NUM>. The information element NFInstanceID and other IEs included in the NF profile maintained at NRF <NUM> may be specified for example in the 3GPP standard specification TS <NUM> (clauses <NUM>. <NUM> and <NUM>. <NUM>) and in the 3GPP standard specification TS <NUM>.

Embodiments of the present invention provide improvements concerning identification in communication networks, such as NFInstanceIDs in <NUM> core networks for example. More specifically, flexibility of such networks is enhanced. For instance, flexibility of service meshes and other similar cloud-native deployments can be improved. Service mesh describes a network of microservices, in which applications are shared and interaction between the applications is possible. To gain operational control over such distributed microservice architecture, a service needs to be identified. Embodiments of the present invention therefore improve flexibility that a service mesh or other similar cloud-native deployments could offer by enhancing identification. So in general the challenge is how to improve flexibility of communication networks, e.g., <NUM> core networks, and provide flexible identification in such networks.

For example, the NFInstanceID format currently defined in 3GPP standard specifications TS <NUM> (clause <NUM>) and TS <NUM> (clause <NUM>. <NUM>) is limited to be a string uniquely identifying a NF instance to one specific type, which is the UUID version <NUM>, as described in IETF RFC <NUM>. Alternatively, UUID version <NUM> may be used when randomly or pseudo-randomly generated v4 UUIDs cannot be used but manual configuration is preferred instead. However, currently 3GPP standard specifications TS <NUM>, TS <NUM> and TS <NUM> define only the UUID v4 to be used. The UUID (a string without any inbuilt structure or hierarchy related to single or multiple trust domains does) not tell anything about the NF type though which might be desirable in the identifier as well. Due to these limitations, the flexibility that a service mesh or other similar cloud-native deployments could offer by integrating different types of services across heterogeneous environments (and in case of <NUM> across different operator domains) is limited. Hence there is a need to provide flexible scheme for identifying NFs and instances of NFs.

In order to allow flexible service identification via the NFInstanceID, the NFInstanceID may be enhanced to support multiple identity types without bounding it to Istio service mesh but can also be realized with AWS, Azure or similar. In order to make this path easier, e.g., for 3GPP 5GC eSBA, the available NF identity related concepts may be enhanced to better fit into the service mesh and cloud-native worlds.

In some embodiments, a set of supported, possible identity types may comprise the UUID identity type. Alternatively, or in addition, the set of identity types may comprise the SPIFFE identity type, for example as defined on the website "https://github. com/spiffe/spiffe/blob/master/standards/SPIFFE-ID. md" (retrieved on July <NUM>, <NUM>). The set of identity types may be defined in the 3GPP standards. So the SPIFFE identity type may be integrated into the 3GPP standards for example. NF <NUM> may use the supported identity types for identifying NF instances of NF services or an NF service set. In some embodiments, a structured data type is defined instead of a simple data type string, thereby allowing usage of other NF identity types / alternatives in the future as well.

<FIG> illustrates signalling in accordance with at least some example embodiments. On the vertical axes are disposed, from the left to the right, NF <NUM> and NRF <NUM>. Time advances from the top towards the bottom.

At Step <NUM>, NF <NUM> may determine a string associated with the NFInstanceID of NF <NUM>. In addition, NF <NUM> may determine a type of the NFInstanceID of NF <NUM> from a set of instance ID types. The type of the NFInstanceID of NF <NUM> may define an identity type, such as UUID or SPIFFE ID, to be used for interpreting the string associated with the NFInstanceID of NF <NUM>. The NFInstanceID of NF <NUM> may be defined as a combination of the string associated with the NFInstanceID and the type of the NFInstanceID of NF <NUM>. Thus, various instance identity types may be supported. The set of instance ID types may comprise for example UUID and SPIFFE ID types. In some embodiments, the set of instance ID types may comprise for example {UUID, SPIFFE ID, OTHERS}. For example, in URI format the UUID may be defined as "urn:uuid:<uuid-v4-or-v5>" and the SPIFFE ID may be defined as SPIFFE-ID: "spiffe://<trust domain>/<workload identifier>".

NF <NUM> may get the NFInstanceID of NF <NUM>, e.g., in the format of UUID for backward compatibility or in the format of SPIFFE ID. The SPIFFE ID may cover e.g., trust domain (or locality), UUIDv4/v5, NF Type, and potentially also service names as part of the SPIFFE workload identity in SPIFFE Verifiable Identity Document, SVID. This brings enough uniqueness for the SPIFFE IDs in a single HPLMN for instance. For instance, a certificate of NF <NUM> may include the assigned NFInstanceID of NF <NUM> or multiple NFInstanceIDs of NF <NUM> if applicable for a target deployment architecture. In some embodiments, one NF instance may have multiple SPIFFE IDs. In case that there are multiple different NF instances (of different NF types) behind a HTTP/<NUM> reverse proxy, there may be multiple NFInstanceIDs as well, but not in the certificates (as that may cause rather complex certificates life-cycle management for NFs).

At step <NUM>, NF <NUM> may transmit a request to NRF <NUM>, wherein the request may comprise the string associated with the NFInstanceID of NF <NUM>. In some embodiments, there may be one or more intermediate forwarding or redirecting NRF nodes which proxy the requests, such as Nnrf Service API requests, to the target NRF managing the NFProfile data for the requester. For example, if NF <NUM> is an NF producer instance, the request may be related to NF instance registration, NF profile complete replacement, NF profile partial update, NF heartbeat, NF instance deregistration. Alternatively, the request may be an access token request. NRF <NUM> may thus receive the request from NF <NUM> at step <NUM>. For requests of NF consumers with NFDiscover, a SCP may handle all NRF related operations for NFp and NFc, e.g., for indirect communication model with Option D.

In some embodiments, NF <NUM> may indicate the type of the NFInstanceID of NF <NUM> implicitly. For instance, NF <NUM> may determine that the type of the NFInstanceID of NF <NUM> is the UUID identity type and in such a case transmit the request without the type of the NFInstanceID of NF <NUM>. However, if NF <NUM> determines that the type of the NFInstanceID of NF <NUM> is the SPIFFE identity type, NF <NUM> may add an indication about the type to the request. That is to say, in such a case the request may comprise an indication indicating that the type of the NFInstanceID of NF <NUM> is the SPIFFE identity type, i.e., an explicit indication. Also for NRF_NFDiscovery requests, URI query parameters (see TS <NUM>, clause <NUM>. <NUM> for details) and/or 3gpp-Sbi-Discovery and other custom headers (see TS <NUM>, clause <NUM>. <NUM>) may be extended to cover structured NFInstanceID (e.g., SPIFFE ID based) based NFDiscovery requests as well. Such extension may be used also for 3gpp-Sbi-Binding, 3gpp-Sbi-Producer-Id, 3gpp-Sbi-Oci and 3gpp-Sbi-Lci etc..

At step <NUM>, NRF <NUM> may determine the type of the NFInstanceID of NF <NUM> from the set of instance identity types, possibly based on the received request for example. NRF <NUM> may also determine the NFInstanceID of NF <NUM> based on the string associated with the NFInstanceID of NF <NUM> and the type of the NFInstanceID of NF <NUM>. That is to say, NRF <NUM> may interpret the string using the type. For example, if the type of the NFInstanceID of NF <NUM> is the UUID, NRF <NUM> may interpret the string by assuming that the string is in the form of the UUID, as defined in IETF RFC <NUM> for example. Similarly, if the type of the NFInstanceID of NF <NUM> is the SPIFFE identity type, NRF <NUM> may interpret the string by assuming that the string is in the form of the SPIFFE identity type, see the website "https://github. com/spiffe/spiffe/blob/master/standards/SPIFFE-ID. md" (retrieved on July <NUM>, <NUM>) for example. In some embodiments, depending on how the SPIFFE IDs are allocated (structured), the SPIFFE ID may contain some additional information from the NFProfile or NFProfile. nfServices[n] as defined in TS <NUM>; e.g., apiRoot for NF producer can be a part of the SPIFFE ID.

In some embodiments, NRF <NUM> may determine the type of the NFInstanceID of NF <NUM> based on an implicit indication from NF <NUM>. NRF <NUM> may receive the request and determine that the request does not comprise an indication about the type of the NFInstanceID of NF <NUM>. Based on such determination, NRF <NUM> may determine that the type of the NFInstanceID is the UUID identity type. In some embodiments, NRF <NUM> may receive the request comprising an indication indicating that the type of the NFInstanceID of NF <NUM> is the SPIFFE identity type and then use the explicit indication.

NRF <NUM> may use the determined NFInstanceID of NF <NUM> for various actions, depending on the request of NF <NUM>. For example, if the request is an access token request, NRF <NUM> may perform validation procedures using the determined NFInstanceID of NF <NUM>. For instance, NRF <NUM> may check that NFInstanceID of NF <NUM> is in a list of NF instances registered at NRF <NUM>. After completing the validation procedures successfully, NRF <NUM> may for example create an access token and include the string associated with the NFInstanceID of NF <NUM> to an access token response. In some embodiments, NF <NUM>, such as an NF consumer requesting access tokens, may not be registered to NRF <NUM> (only NF producers register their NF services) but the NFc needs to be trusted by NRF <NUM> in order to be able to grant the access tokens. For example with R16 Option D, service authorization may be delegated to SCP, so in such a case NF <NUM> can also be SCP for a specific NFc instance. The SPIFFE ID may be used for access tokens for the SCP or for the requester NF consumer (instance), or both.

At step <NUM>, NRF <NUM> may transmit a response to NF <NUM>. The response may depend on whether the NFInstanceID of NF <NUM> was found in the list of NF instances registered at NRF <NUM>. The response may indicate that the request is accepted if the NFInstanceID of NF <NUM> was found in the list of NF instances registered at NRF <NUM> but if the NFInstanceID of NF <NUM> was not found in the list of NF instances registered at NRF <NUM>, the response may indicate that the request is denied.

In some embodiments, NFs operating in accordance with Rel-<NUM> or Rel-<NUM>3GPP standard specifications may use UUID v4 as the type of the NFInstanceID. However, in some embodiments UUID v5 may be used as well, e.g., for implementations.

In some embodiments, for backward compatibility, NRF <NUM> may be able to determine a release of a target NF producer, or a requester NF consumer / SCP, and encode an access token appropriately. If an indication about the type of the NFInstanceID of NF <NUM> is missing, implicitly it means it is given in UUID type. For NF producers, if they support the SPIFFE ID as NFInstanceID, then an indication about that may be included in NFProfile. nfInstanceId, but for backwards compatibility both UUID and SPIFFE may be needed. For NF consumers, if they indicated the UUID as NFInstanceID (of the NF consumer) and/or requested specific UUID instead of the SPIFFE ID for the targetNfInstanceId in an access token request, or used UUIDs in "sub" for Subject, "aud" for Audience in access token claims, then those are most likely not using the SPIFFE concepts.

In some embodiments, the NFInstanceID of NF <NUM>, which may be based on the string associated with the NFInstanceID of NF <NUM> and the type of the NFInstanceID of NF <NUM>, may be exploited in an identity of a NF service set. For example, NFServiceSetId with "set<Set ID>. sn<Service Name>. nfi<NF Instance ID>. mcc<MCC>" may be defined in the 3GPP standard specification TS <NUM> (clause <NUM>. <NUM>) and TS <NUM> (clause <NUM>) may be updated to allow other identity types, i.e., the set of instance identity types, to be used as well. If type of the NFInstanceID of NF <NUM> in "nfi<NF Instance ID>" is missing, it may implicitly mean that the UUID type is used.

According to some embodiments of the present invention, some changes may be made to 3GPP standard specifications. For instance, NfInstanceId (String uniquely identifying a NF instance. The type of the NF Instance ID shall be a Universally Unique Identifier (UUID) version <NUM>, as described in IETF RFC <NUM> [<NUM>]) may be absent in the 3GPP TS <NUM> standard specification, Table <NUM>. <NUM>-<NUM> "Simple Data Types" in section <NUM>.

Alternatively, or in addition, section <NUM>. <NUM> (Enumerations) in the 3GPP TS <NUM> standard specification may comprise Enumeration: NFInstanceType and the following table:.

Alternatively, or in addition, section <NUM>. <NUM> (Structured Data Types) in the 3GPP TS <NUM> standard specification may comprise Enumeration: NFInstanceType and the following table:.

<FIG> illustrates an example apparatus capable of supporting at least some example embodiments. Illustrated is device <NUM>, which may comprise, for example, NF <NUM> or NRF <NUM>, or a device controlling functioning thereof. Comprised in device <NUM> is processor <NUM>, which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core. Processor <NUM> may comprise, in general, a control device. Processor <NUM> may comprise more than one processor. Processor <NUM> may be a control device. Processor <NUM> may comprise at least one Application-Specific Integrated Circuit, ASIC. Processor <NUM> may comprise at least one Field-Programmable Gate Array, FPGA. Processor <NUM> may comprise an Intel Xeon processor for example. Processor <NUM> may be means for performing method steps in device <NUM>, such as determining, causing transmitting and causing receiving. Processor <NUM> may be configured, at least in part by computer instructions, to perform actions.

A processor may comprise circuitry, or be constituted as circuitry or circuitries, the circuitry or circuitries being configured to perform phases of methods in accordance with example embodiments described herein. As used in this application, the term "circuitry" may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of hardware circuits and software, such as, as applicable: (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a network function, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

Device <NUM> may comprise a transmitter <NUM>. Device <NUM> may comprise a receiver <NUM>. Transmitter <NUM> and receiver <NUM> may be configured to transmit and receive, respectively, information in accordance with at least one cellular standard, such as a standard defined by the 3GPP. Transmitter <NUM> may comprise more than one transmitter. Receiver <NUM> may comprise more than one receiver. Transmitter <NUM> and/or receiver <NUM> may be configured to operate in accordance with a suitable communication standard.

Device <NUM> may comprise User Interface, UI, <NUM>. UI <NUM> may comprise at least one of a display, a keyboard, a touchscreen, a vibrator arranged to signal to a user by causing device <NUM> to vibrate, a speaker and a microphone. A user may be able to operate device <NUM> via UI <NUM>, for example to configure device <NUM> and/or functions it runs.

Device <NUM> may comprise further devices not illustrated in <FIG>. In some example embodiments, device <NUM> lacks at least one device described above. For example, device <NUM> may not have UI <NUM>.

Processor <NUM>, memory <NUM>, transmitter <NUM>, receiver <NUM> and/or UI <NUM> may be interconnected by electrical leads internal to device <NUM> in a multitude of different ways. For example, each of the aforementioned devices may be separately connected to a master bus internal to device <NUM>, to allow for the devices to exchange information. However, as the skilled person will appreciate, this is only one example and depending on the embodiment various ways of interconnecting at least two of the aforementioned devices may be selected without departing from the scope of the present invention.

<FIG> is a flow graph of a first method in accordance with at least some example embodiments. The phases of the illustrated first method may be performed by NRF <NUM>, or by a control device configured to control the functioning thereof, possibly when installed therein.

The first method may comprise, at step <NUM>, receiving, by a network repository function, a request from a network function, wherein the request comprises a string associated with an instance identity of the network function. The first method may also comprise, at step <NUM>, determining, by the network repository function, a type of the instance identity of the network function from a set of instance identity types. Moreover, the first method may comprise, at step <NUM>, determining, by the network repository function, the instance identity of the network function based on the string associated with the instance identity of the network function and the type of the instance identity of the network function. Finally, the first method may comprise, at step <NUM>, transmitting, by the network repository function, a response to the network function, wherein the response depends on whether the instance identity of the network function was found in a list of network function instances registered at the network repository function.

<FIG> is a flow graph of a second method in accordance with at least some example embodiments. The phases of the illustrated second method may be performed by NF <NUM>, or by a control device configured to control the functioning thereof, possibly when installed therein.

The second method may comprise, at step <NUM>, determining, by a network function, a string associated with an instance identity of the network function. The second method may also comprise, at step <NUM>, determining, by the network function, a type of the instance identity of the network function from a set of instance identity types. Finally, the second method may comprise, at step <NUM>, transmitting a request to a network repository function, wherein the request comprises the string associated with the instance identity of the network function.

It is to be understood that the embodiments disclosed are not limited to the particular structures, process steps, or materials disclosed herein, but are extended to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular example embodiments only and is not intended to be limiting.

Reference throughout this specification to one example embodiment or an example embodiment means that a particular feature, structure, or characteristic described in connection with the example embodiment is included in at least one example embodiment. Thus, appearances of the phrases "in one example embodiment" or "in an example embodiment" in various places throughout this specification are not necessarily all referring to the same example embodiment.

In addition, various example embodiments and examples may be referred to herein along with alternatives for the various components thereof. It is understood that such example embodiments, examples, and alternatives are not to be construed as de facto equivalents of one another, but are to be considered as separate and autonomous representations.

In an example embodiment, an apparatus, such as, for example, NF <NUM> or NRF <NUM>, or a device controlling functioning thereof, may comprise means for carrying out the example embodiments described above and any combination thereof.

In an example embodiment, a computer program may be configured to cause a method in accordance with the example embodiments described above and any combination thereof. In an example embodiment, a computer program product, embodied on a non-transitory computer readable medium, may be configured to control a processor to perform a process comprising the example embodiments described above and any combination thereof.

In an example embodiment, an apparatus, such as, for example, NF <NUM> or NRF <NUM>, or a device controlling functioning thereof, may comprise at least one processor, and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform the example embodiments described above and any combination thereof.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more example embodiments. In the preceding description, numerous specific details are provided, such as examples of lengths, widths, shapes, etc., to provide a thorough understanding of example embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.

It is not intended that the invention be limited, except as by the claims set forth below.

At least some example embodiments find industrial application at least in <NUM> core networks, wherein it is desirable to enhance identification, and possibly in other core networks in the future as well.

Claim 1:
An apparatus comprising means for performing:
- receiving, by a network repository function (<NUM>), a request from a network function (<NUM>), characterized in that the request comprises a string associated with an instance identity of the network function (<NUM>) and indicates a type of the instance identity of the network function (<NUM>);
- determining, by the network repository function (<NUM>), the type of the instance identity of the network function (<NUM>) from a set of instance identity types based on the request;
- determining, by the network repository function (<NUM>), the instance identity of the network function (<NUM>) based on the string associated with the instance identity of the network function (<NUM>) and the type of the instance identity of the network function (<NUM>); and
- transmitting, by the network repository function (<NUM>), a response to the network function (<NUM>), wherein the response depends on whether the instance identity of the network function (<NUM>) was found in a list of network function instances registered at the network repository function (<NUM>); .
wherein the set of instance identity types comprises an identity type for service mesh technologies, and
wherein the identity type for service mesh technologies comprises a Secure Production Identity Framework for Everyone, SPIFFE, identity type,
wherein the network function includes an NFInstanceID of the network function in the format of UUID for backward compatibility or in the format of SPIFFE ID, wherein the SPIFFE ID covers trust domain and locality, UUIDv4/v5, NF Type, and service names as part of the SPIFFE workload identity in SPIFFE Verifiable Identity Document, SVID,
wherein a certificate of the network function includes the assigned NFInstanceID of the network function or multiple NFInstanceIDs of the network function if applicable for a target deployment architecture, and wherein the network function instance includes multiple SPIFFE IDs.