WO2022062920A1

WO2022062920A1 - Method and apparatus for service registration and service discovery

Info

Publication number: WO2022062920A1
Application number: PCT/CN2021/117759
Authority: WO
Inventors: Xinyu Zhang; Maria Cruz Bartolome RODRIGO
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2020-09-25
Filing date: 2021-09-10
Publication date: 2022-03-31

Abstract

The present disclosure relates to a scenario where two or more Network Repository Functions, NRFs, are deployed in a communication network. The present disclosure provides a method for service registration performed by a NRF, which may comprise the steps of: receiving a register request from a Network Function, NF, instance and locally registering a profile of the NF instance, wherein the profile indicates one or more NF services offered by the NF instance; determining that a particular service of the NF services is accessible from at least one other NRF in the communication network; and interacting with said other NRF to share registration information related to the particular service. The present disclosure also provides some solutions for service discovery and inter-NRF synchronization.

Description

METHOD AND APPARATUS FOR SERVICE REGISTRATION AND SERVICE DISCOVERY

TECHNICAL FIELD

The present disclosure generally relates to the field of communication, and more particularly to methods and apparatuses for service registration and service discovery in a communication network, and related network nodes or entities or functions.

BACKGROUND

This section is intended to provide a background to the technologies described in this disclosure. Unless otherwise indicated herein, what is described in this section should not be regarded as prior art and are not admitted to be prior art by inclusion in this section.

The Fifth Generation (5G) Core Network (5GC) of a communication system is an example of a Service Based Architecture (SBA) including a plurality of Network Functions, where each Network Function (NF) acting as NF service producer can provide one or multiple well-defined services to whatever other NF acting as NF service consumer by means of service-based interface (SBI) . Moreover, a new Network Function named Network Repository Function (NRF) has been defined to provide NF service discovery capabilities in 5GC, allowing NF service producers to register their offered NF services in the NRF, so that later NF service consumers can discover these services.

Fig. 1 schematically illustrates non-roaming reference architecture of a 5G communication system 100. The architecture may comprise various types of Network Functions (NFs) , such as Authentication Server Function (AUSF) , Access and Mobility Management Function (AMF) , Data Network (DN) , Network Exposure Function (NEF) , Network Repository Function (NRF) , Policy Control Function (PCF) , Session Management Function (SMF) , Unified Data Management (UDM) , User Plane Function (UPF) , Application Function (AF) , User Equipment (UE) , (Radio) Access Network ( (R) AN) , Network Slice Specific Authentication and Authorization Function (NSSAAF) , Network Slice Selection Function (NSSF) , and so on. The architecture may further comprise some network entities, for example, Service Communication Proxy (SCP) . These Network Functions (NFs) may interact with each other within 5GC control plane via service-based interfaces (SBIs) , such as Namf, Nsmf, Nnef, Npcf, Nudm, Naf, Nnrf, Nnssf, Nausf, and Nnssaaf being exhibited respectively by AMF, SMF, NEF, PCF, UDM, AF, NRF, NSSF, AUSF, and NSSAAF. Fig. 1 also shows some reference points, such as reference point N1 between the UE and the AMF, reference point N2 between the (R) AN and the AMF, reference point N3 between the (R) AN and the UPF, reference point N4 between the SMF and the UPF, reference point N6 between the UPF and the DN, and reference point N9 between two Core UPFs.

Each NF can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g. on a cloud infrastructure. An identifiable instance of a NF is defined as "NF instance" . A NF may be deployed in a NF set which includes a group of interchangeable NF instances of the same NF type, supporting the same services and the same network slice (s) . The NF instances in the same NF set may be geographically distributed but have access to the same context data. Moreover, within an NF instance, a service may be deployed in a NF service set which includes a group of interchangeable NF service instances of the same service type. The NF service instances in the same NF service set have access to the same context data. The actual mapping of instances to a given set is up to deployment.

In 5G Core Network (5GC) , a NRF may be implemented as a network entity supporting the following functionalities: (i) maintaining the NF profile of available NF instances and their supported services; (ii) allowing other NF instances to subscribe to, and get notified about, the registration in NRF of new NF instances of a given type; and (iii) supporting service discovery function, by receiving NF discovery requests from NF instances, and providing the information of the available NF instances fulfilling certain criteria (e.g., supporting a given service) .

The details regarding NF, NF instance, NF service, NF service instance, and various interfaces and reference points can be found from some technical specifications proposed by the 3rd Generation Partnership Project (3GPP) , for example, 3GPP TS 23.501 V16.5.0 (2020-07) , "Services and System Aspects; System architecture for the 5G System (5GS) " , and 3GPP TS 29.510 V16.3.0 (2020-03) , "Core Network and Terminals; 5G System; Network Function Repository Services" , the contents of which are incorporated herein by reference.

It is possible to deploy multiple NRFs in one communication network, for example, Public Lands Mobile Network (PLMN) . This deployment has the benefit of minimizing the requirement on storage capacity and complexity of each NRF, as long as a NF service producer (NFp) would register in only one NRF. With the deployment, a NF Instance can subscribe to changes of NF Instances registered in an NRF to which it is not directly interacting, by means of forwarding or redirecting a subscription message. Moreover, one NRF may query the "nf-instances" resource in another NRF so as to fulfil the service discovery request from a NF service consumer. Two mechanisms are defined for service discovery, as shown in Fig. 2a and Fig. 2b.

Fig. 2a schematically illustrates a service discovery procedure 200a with intermediate redirecting NRF. The procedure 200a may comprise the following steps:

1. One NRF, NRF-1, receives a service discovery request, e.g. a Hypertext Transfer Protocol (HTTP) GET request, from a NF service consumer, but cannot fulfil the request. Then, NRF-1 sends the request to a pre-configured NRF, NRF-2.

2a. NRF-2 identifies another NRF, NRF-3, and redirects the request by returning "307 Temporary Redirect" response containing an identifier of NRF-3.

2b. Otherwise, NRF-2 responds with "404 Not Found" , and the procedure 200a stops.

3. Upon receiving "307 Temporary Redirect" response, NRF-1 sends the service discovery request to NRF-3.

4a. Upon success, NRF-3 returns "200 OK" success response with search result to NRF-1.

4b. Otherwise, NRF-3 returns "4xx/5xx" error response to NRF-1.

Fig. 2b schematically illustrates a service discovery procedure 200b with intermediate forwarding NRF. The procedure 200b may comprise the following steps:

1. One NRF, NRF-1, receives a service discovery request from a NF service consumer, but cannot fulfil the request. Then, NRF-1 sends the request to a pre-configured NRF, NRF-2.

2a. NRF-2 identifies another NRF, NRF-3, and forwards the request to NRF-3 (NRF-3 possibly goes on to forward the request to a further NRF) .

2b. Otherwise, NRF-2 responds with "404 Not Found" , and the procedure 200b stops.

3a. Upon success, NRF-3 returns "200 OK" success response with search result to NRF-2.

3b. Otherwise, NRF-3 returns "4xx/5xx" error response to NRF-2.

4a. NRF-2 forwards the success response to NRF-1.

4b. NRF-2 forwards the error response to NRF-1.

According to any of the above procedures, NRF-1 initially needs to check if it has local resource offering the requested service; and if so, exposes its local resource to the NF service consumer and the procedure ends. Only when the local resource cannot fulfil the request, the NF service consumer may have a chance to find resource from other NRF based on a new service discovery. However, either the initial service discovery or the new service discovery may return a non-optimal resource to the NF service consumer.

At present, no mechanism is defined for a NRF to judge whether it is suitable to just locally handle either subscription request or discovery request. Moreover, no mechanism is standardized for a NRF to find and expose optimal resource to a NF service consumer.

SUMMARY

It is therefore an object of the present disclosure to improve the procedures for service registration and service discovery, especially in a scenario where multiple Network Repository Functions (NRFs) are deployed in one communication network. Another object of the present disclosure is to provide several schemes for inter-NRF synchronization in such a scenario.

According to one aspect of the present disclosure, there is provided a method performed by a NRF in a communication network. The method may comprise: receiving a register request from a Network Function (NF) instance and locally registering a profile of the NF instance, wherein the profile indicates one or more NF services offered by the NF instance; determining that a particular service of the NF services is accessible from at least one other NRF in the communication network; and interacting with the other NRF to share registration information related to the particular service.

In an exemplary embodiment of the above method, the NRF may be initially configured with one or more service types each deployed at multiple NRFs in the communication network. The NRF may check the profile to identify the particular service matching one of the service types; and forward the register request to the other NRF to register the profile of the NF instance in the other NRF.

In an exemplary embodiment of the above method, the NRF may check the profile to find a set identifier, SetId, indicative of a NF set including NF instances supporting the same services; discover other NRF in which other NF instance (s) of the NF set is registered, based on the SetId; and obtain from said other NRF and storing locally profile of the other NF instance (s) .

In an exemplary embodiment of the above method, the NRF may be configured with a contact point to a central NRF for centrally managing NRF Areas service information that includes NRF service information of each NRF in the communication network. The NRF may check the profile to find a particular service is a new service not yet registered before; and request the central NRF to update the NRF service information of the NRF related to the particular service.

According to another aspect of the present disclosure, there is provided a method performed by a central NRF in a communication network. The central NRF may be configured for centrally managing NRF Areas service information that includes NRF service information of each local NRF in the communication network and the central NRF, wherein each local NRF may be configured with a contact point to the central NRF. The central NRF may receive an update request from a local NRF, the update request indicating that a particular service offered by a NF instance is newly registered in the local NRF; and update the NRF service information of the local NRF related to the particular service.

According to further aspect of the present disclosure, two optional schemes are provided for service discovery. In response to a discovery request, one scheme is to expose all NF instances offering the desired service, and another scheme is to only expose the locally registered NF instance (s) offering the desired service, and then expose additional NF instances when necessary.

The present disclosure also provides some embodiments for network nodes, apparatuses and communication systems which may be deployed in 5th Generation Core Network, 5GC.

The present disclosure also provides a computer program, a carrier, and a computer program product which may be used in conjunction with the above aspects.

The embodiments as provided in the present disclosure can overcome or at least mitigate at least one of the disadvantages in the prior art, which will be described in details with reference to the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects, features and advantages of the present disclosure will become apparent from the following detailed description about the non-limited embodiments of the present disclosure taken in conjunction with the accompanied drawings, in which:

Fig. 1 schematically illustrates non-roaming reference architecture of a 5G communication system;

Fig. 2a is a signalling diagram for schematically illustrating a service discovery procedure with intermediate redirecting NRF;

Fig. 2b is a signalling diagram for schematically illustrating a service discovery procedure with intermediate forwarding NRF;

Fig. 3a schematically depicts an exemplary scenario where multiple NRFs are deployed in one communication network;

Fig. 3b is a signalling diagram for schematically illustrating a conventional service discovery procedure performed in the scenario as shown in Fig. 3a;

Fig. 4 is a flowchart for schematically illustrating a service registration procedure and a service discovery procedure according to an embodiment of the present disclosure;

Fig. 5a is a flowchart for schematically illustrating a service registration procedure according to a first embodiment of the present disclosure;

Figs. 5b, 5c and 5d are flowcharts for schematically illustrating various inter-NRF synchronization procedures according to the first embodiment of the present disclosure;

Figs. 6 and 7 are signalling diagrams for schematically illustrating service registration and inter-NRF synchronization procedures according to the first embodiment of the present disclosure;

Fig. 8a is a flowchart for schematically illustrating a service registration procedure according to a second embodiment of the present disclosure;

Fig. 8b is a flowchart for schematically illustrating an inter-NRF synchronization procedure according to the second embodiment of the present disclosure;

Fig. 9 is a signalling diagram for schematically illustrating a service registration and inter-NRF synchronization procedure according to the second embodiment of the present disclosure;

Figs. 10a, 10b and 10c are flowcharts for schematically illustrating automatic management of multiple NRF areas according to a third embodiment of the present disclosure;

Fig. 10d is a flowchart for schematically illustrating a service discovery procedure according to the third embodiment of the present disclosure;

Fig. 11 is a signalling diagram for schematically illustrating automatic management of multiple NRF areas according to the third embodiment of the present disclosure;

Fig. 12 is a signalling diagram for schematically illustrating a service discovery procedure according to the third embodiment of the present disclosure;

Fig. 13 is a block diagram for schematically illustrating a first network node according to some embodiments of the present disclosure;

Fig. 14 is a block diagram for schematically illustrating a second network node according to some embodiments of the present disclosure;

Fig. 15 is a block diagrams for schematically illustrating a first apparatus according to some embodiments of the present disclosure; and

Fig. 16 is a block diagrams for schematically illustrating a second apparatus according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth in embodiments. It will be appreciated, however, by persons skilled in the art that the embodiments as disclosed herein may be practiced without such specific details, and that other changes may be made, without departing from the spirit or scope of the subject matters presented here. In other instances, well-known circuits, structures, protocols, and techniques have not been shown in detail in order not to obscure the understanding of the present disclosure.

References to the phrases "one embodiment" , "an embodiment" , "an exemplary embodiment" , "one example" , "an example" and the like throughout the disclosure indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment or example. In practice, the elements in one embodiment may be split into several implementations; or otherwise, the elements in several embodiments may be combined into one implementation. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa.

Hereinafter, some embodiments of the present disclosure are discussed in the context of 5G Core Network (5GC) . However, persons skilled in the art would understand these embodiments may be applicable to other similar systems.

In 5GC, it is possible to deploy more than one NRF in one communication network. Fig. 3a schematically depicts an exemplary scenario where two NRFs, NRF1 and NRF2, are deployed in one PLMN, as if the NRF functionality configured in the PLMN is logically divided into two NRF areas, NRF Area 1 and NRF Area 2. In an example, NRF1 and NRF2 may be located in different geographical areas, Geo Area 1 and Geo Area 2, and NRF Area 1 and NRF Area 2 may correspond to Geo Area 1 and Geo Area 2, respectively. In another example, several NRFs may be located in the same geographical area (e.g. in a relatively larger area) , and hence several NRF areas may correspond to one geographical area. The specific deployment and number of the NRFs may depend on actual needs of a telecommunication operator.

In the exemplary scenario of Fig. 3a, a NF acting as NF service consumer (NFc) may have an instance registered in NRF1, for example, "NFc" in NRF Area 1. Moreover, a NF acting as NF service producer (NFp) may have multiple instances registered in several NRFs (or possibly some instances registered in the same NRF) , for example, NFp#1 registered in NRF1 and NFp#2 registered in NRF2. NFp#1 and NFp#2 may be deployed in a set (e.g. "NFp Set" ) ; that is, they are interchangeable NF instances of the same NF type, supporting the same services. Alternatively, NFp#1 and NFp#2 may be individually deployed (i.e., not in a set) , although they are instances of the same NF type (e.g. two instances of PCF) supporting the same services. In other scenario, several instances of different NF types (e.g. an instance of PCF and an instance of AMF) being registered in multiple NRFs may possibly support the same service (s) .

Fig. 3b is a signalling diagram for schematically illustrating a conventional service discovery procedure 300b which may be performed in the scenario as shown in Fig. 3a. The procedure 300b may comprise the following steps:

1. A NF service consumer (NFc) sends a service discovery request to its local NRF (i.e. NRF1) in which it has registered, in order to find at least one NF service provider (NFp) instance offering a NF service, e.g. Service B. The request may include some query parameters, for example, service name (e.g. "servB" ) . The NFc itself can offer one or more other NF services, e.g. Service A.

2. NRF1 identifies one or more NFp instances (e.g. represented by NFp#1) locally registered for Service B.

3. NRF1 sends a service discovery response indicating NFp#1 offering Service B.

4. NFc sends a status subscription request for any status change and/or new registration/de-registration of NFp#1 to NRF1.

5. NRF1 sends a status subscription response to NFc, upon success.

6. NFc sends an operation request towards NFp#1.

7. NFc receives a successful operation response from NFp#1.

8. NFc sends another operation request towards NFp#1.

9. NFc receives a failure operation response (error or lack of response) , if the request fails for some reason, for example, if NFp#1 becomes invalid.

10. NFc will need to reselect another equivalent NFp instance, but it cannot find any other NFp instance in a different NRF Area (e.g. NFp#2 in NRF Area 2) , since it only has the status subscription with NRF1 for NFp#1.

The above procedure cannot continue if NFc does not have any available NFp instance. NFc may have to reinitiate a service discovery procedure. If all of the NFp instances locally registered for Service B are not available, NRF1 cannot fulfil the service discovery request from NFc. The request may be redirected or forwarded according to the conventional procedure of Fig. 2a or Fig. 2b. Finally, the resource (e.g. NFp#2) in another NRF area (e.g. NRF Area 2) may be provided to NFc.

No matter what procedure is used, NFc will only have access to the resource from a single NRF area during each service discovery procedure. The selection/reselection of the resource will be performed within the single NRF area, which limits the amount of resource to be used by NFc. It is also disadvantageous for load balancing among NF set or NF service set (at initial set selection) , or load re-balancing, since NFc cannot find all NFp instances offering the same service (s) in the scope of the entire network.

Moreover, if a NRF area matches a geographical area, NRF Area 1 and NRF Area 2 may correspond to Geo Area 1 and Geo Area 2, respectively. As such, if the NFp instances (e.g. NFp#1 and NFp#2) in the same set are deployed in NRF Area 1 and NRF Area 2, these NFp instances are geographically distributed in Geo Area 1 and Geo Area 2, as shown in Fig. 3a. If any NFp instance can be replaced by any alternative NFp instance within the same set, it is possible to implement geo-redundancy. However, according to the existing procedures, the selection/reselection of NFp instance can only be performed within single NRF area, which makes geo-redundancy impossible. In case of failure in a geographical area for example due to geographical disasters such as flooding and earthquakes, lack of geo-redundancy may become a challenge.

In view of the above deficiencies, the present disclosure provides some improvements on the existing service registration procedure and service discovery procedure, and accordingly provides some schemes for inter-NRF synchronization, as set forth in details hereinafter.

Fig. 4 schematically illustrates a service registration procedure and a service discovery procedure performed by a Network Repository Function (NRF) in a communication network (e.g. PLMN) , according to an embodiment of the present disclosure. The service registration procedure and the service discovery procedure may be separately applied to different situations, although they are combined into one procedure 400 as shown in Fig. 4.

During the service registration procedure, in step S402, the NRF may receive a register request from a Network Function (NF) instance and locally register a profile of the NF instance, wherein the profile may include many parameters, for example, "service name" for indicating one or more NF services offered by the NF instance. In step S404, the NRF may determine whether a particular service of the NF services offered by the NF instance is accessible from at least one other NRF in the communication network. If so, then in step S406, the NRF may interact with the other NRF (s) to share registration information related to the particular service; and if not, the service registration procedure may end (such a negative branch is not shown in Fig. 4 and other figures, and may be omitted in the following description, just for simplicity) .

It is to be noted that the term "a particular service" throughout the disclosure is to represent any service to be concerned, without implying any restriction on service type or quantity. The concept of this disclosure is applicable to two or more particular services.

It is also to be noted that the term "registration information related to the particular service" may refer to any information regarding registration of the particular service, such as a complete or partial profile of the registered NF instance offering the particular service, information derived from the profile, information related to the registered NF instance, information related to the particular service, or information related to the NRF handling the registration, and so on.

The service discovery procedure may start with step S408, in which the NRF may receive a discovery request for the particular service from a service consumer. In response to the request, the NRF may fully or partially expose the NF instances, depending on specific configuration.

In one example, upon receipt of the discovery request in step S408, the NRF may expose all NF instances offering the particular service which are registered in the NRF and the other NRF (s) , towards the service consumer, in step S410.

In another example, upon receipt of the discovery request in step S408, the NRF may initially expose one or more NF instances offering the particular service which are registered locally, towards the service consumer, in step S412. Then in step S414, the NRF may supervise which service consumers have sent the discovery request that similarly results in the NF instances offering the particular service. Alternatively or additionally, the NRF may supervise availability and/or load of said one or more NF instances having been exposed to the service consumer. When said one or more NF instances are not sufficient to satisfy the service consumer, the NRF may expose one or more additional NF instances offering said particular service which are registered in the other NRF (s) , towards the service consumer, in step S416.

With the above embodiment, the service consumer NFc is able to select, as much as possible, NFp instances from the NRF area where NFc is located, or closest to its location, which will minimize network resources and signalling latency, for example. Moreover, NFc is also able to select other proper NFp instances from other NRF areas while taking into account NFp instance failure, NFp instance overload protection, traffic demands, geographical redundancy and other factors.

Fig. 5a schematically illustrates a service registration procedure 500a according to a first embodiment of the present disclosure. The first embodiment may require initial configuration in each NRF in a communication network.

The procedure 500a may start with step S502, in which each NRF may be initially configured with one or more service types, one service represented by each service type being deployed at multiple NRFs in the network. As an example, each NRF may store a list of service name (s) representing said one or more service types. As anther example, each NRF may store a set of service code (s) or service identifier (s) representing said one or more service types. In step S504, being similar to step S402, the NRF may receive a register request from a NF instance and locally register a profile of the NF instance, wherein the profile may include many parameters, for example, "service name" for indicating one or more NF services offered by the NF instance. Hereinafter, the NRF in which the NF instance has registered may be called "local NRF" for this NF instance. In step S506, the local NRF may check the service names in the profile to identify a particular service matching one of the initially configured service types. Hence, the local NRF may derive that the particular service is accessible from other NRF (s) in the network. In step S508, the local NRF may forward the register request to the other NRF (s) to register the profile of the NF instance also in the other NRF (s) . Hence, this interaction between these NRFs can implement sharing of the registration information related to the particular service.

In an example of the procedure 500a, the forwarded register request may include an identifier of the NRF, or Internet Protocol (IP) address of the NRF, for indicating origin of the forwarded register request.

Figs. 5b, 5c and 5d schematically illustrate various inter-NRF synchronization procedures according to the first embodiment of the present disclosure. These procedures may be performed after the NF instance has registered in the local NRF and in the other NRF (s) according to the procedure 500a.

In one example, the local NRF may perform the procedure 500b as shown in Fig. 5b. The local NRF may receive a status subscription request for the NF instance from the other NRF (s) , in step S510; and send a status notification for the NF instance to the other NRF (s) , in step S512.

In another example, the local NRF may perform the procedure 500c as shown in Fig. 5c. The local NRF may receive an update request from an NF instance and locally update the profile of the NF instance, in step S514; determine that the updating relates to said particular service, in step S516; and forward the update request to the other NRF (s) to update the profile of the NF instance in the other NRF (s) , in step S518.

In still another example, the local NRF may perform the procedure 500d as shown in Fig. 5d. The local NRF may receive a deregister request from the NF instance and locally deregister the profile of the NF instance, in step S520; and forward the deregister request to the other NRF (s) to deregister the profile of the NF instance in the other NRF (s) , in step S522.

These

procedures

500b, 500c and 500d may be used individually or in combination to implement status update in the other NRF (s) . As a result, the status of the NF instance offering the particular service could be synchronized between the local NRF and the other NRF (s) .

Fig. 6 and Fig. 7 are signalling diagrams for schematically illustrating service registration and inter-NRF synchronization procedures according to the first embodiment of the present disclosure. Both Fig. 6 and Fig. 7 depict an exemplary scenario where two NRFs (NRF1, NRF2) are deployed in one communication network, forming two NRF areas (NRF Area 1, NRF Area 2) , and where an instance of NF service consumer (NFc) is registered in NRF Area 1, and two NFp instances (NFp#1, NFp#2) offering the same service (s) (e.g. Service B) are registered in NRF Area 1 and NRF Area 2, respectively.

The procedures in Fig. 6 and Fig. 7 may require initial configuration in each NRF in the network. For example, NRF1 and NRF2, in different NRF areas, may be initially configured with one or more service types, each of which represents a particular service being deployed in multiple NRF areas, for example in a form of service name of the particular service. In one example, each NRF may obtain a list of service name (s) representing the particular service (s) by initial configuration. In another example, each NRF may additionally obtain the information regarding specific NRF area (s) where each of the service types is defined, or a simple indication that each of the service types is defined in other NRF areas. Depending on different configuration, service registration could be forwarded to each specific NRF area, or to all the other NRF areas (the number of them is normally very small) .

After the initial configuration is completed, the exemplary procedure shown in Fig. 6 may comprise the following steps:

1. NFp#1 may send a Nnrf_NFMng_Register request to NRF1. The request may include an identifier of NFp#1, and service name (s) (e.g. "servB" ) representing one or more services (e.g. Service B) offered by NFp#1.

2. The profile of NFp#1 may be locally registered (or stored) in NRF1, wherein the profile may include many parameters, for example, "service name" for indicating one or more NF services offered by NFp#1. Moreover, NRF1 may mark NFp#1 as available to be discovered by other NFs.

3. NRF1 may send a Nnrf_NFMng_Register response to indicate registration success. The response may include the similar information elements as those in the request.

4. NRF1 may check the service names in the profile of NFp#1 to identify a particular service (e.g. Service B represented by "servB" ) matching one of the initially configured service types. In particular, NRF1 may check NRF Area configuration for Service B, to identify one or more specific NRF areas (e.g. NRF Area 2) having other NFp instance (s) (e.g. NFp#2) offering Service B. Hence, NRF1 may derive that Service B is accessible from other NRF (s) in the network.

5. NRF1 may forward the Nnrf_NFMng_Register request to the other NRF (s) in the specific NRF area (s) identified in step 4, for example, NRF2 in NRF Area 2.

6. NRF2 may locally register (or store) the profile of NFp#1.

7. NRF2 may send a Nnrf_NFMng_Register response indicating registration success to NRF1.

In a preferable embodiment, the forwarded request from NRF1 to NRF2 (in step 5) may include a new parameter (e.g. an identifier of NRF1) , for indicating that the origin of the request is a NRF rather than a NFp. This may require standardization in 3GPP. As an alternative, the forwarded request from NRF1 to NRF2 may include Internet Protocol (IP) address of NRF1. Moreover, each NRF has configured the IP addresses of other NRFs, so that it can identify whether the origin of the request is another NRF. Accordingly, the procedure of Fig. 6 may further comprise step 8, where NRF2 may identify the origin of the request is another NRF (i.e. NRF1) , so it will recognize that it does not have to forward this request to other NRFs.

The above interaction between NRF1 and NRF2 can implement sharing of the registration information related to the particular service (e.g. Service B) . Moreover, for the purpose of inter-NRF synchronization between NRF1 and NRF2, the procedure of Fig. 6 may further comprise the following steps:

9. NRF2 may send a Nnrf_NFStatusSubs request to NRF1 to subscribe to changes on the status of the NFp instance (s) (e.g. NFp#1) offering Service B.

10. NRF2 may receive a Nnrf_NFStatusSubs response from NRF1. As a result, if the status of NFp#1 is changed, or the profile of NFp#1 is modified for any reason, NRF2 will receive the status notification for NFp#1 from NRF1, and accordingly update the locally stored profile of NFp#1.

In another example for inter-NRF synchronization, NRF1 may receive a deregister request from the NFp instance (e.g. NFp#1) and locally deregister the profile of NFp#1; and forward the deregister request to NRF2 to deregister the profile of NFp#1 in NRF2. As a result, the profile of NFp#1 may be deleted from both NRF1 and NRF2.

Another exemplary procedure of Fig. 7 may require the same initial configuration as discussed above, and may comprise a part or all of steps 1-8 as shown in Fig. 6 (which are omitted from Fig. 7) . Moreover, for the purpose of inter-NRF synchronization between NRF1 and NRF2, the procedure of Fig. 7 may comprise the following steps:

1. NFp#1 may send a Nnrf_NFMng_Update request to NRF1. The request may include an identifier of NFp#1, and service name (s) (e.g. "servB" ) representing one or more services (e.g. Service B) offered by NFp#1.

2. The profile of NFp#1 may be locally updated in NRF1.

3. NRF1 may send a Nnrf_NFMng_Update response to indicate update success. The response may include the similar information elements as those in the request.

4. NRF1 may determine whether the updating relates to a particular service (e.g. Service B represented by "servB" ) . If so, then NRF1 may further check NRF Area configuration for Service B, to identify one or more specific NRF areas (e.g. NRF Area 2) having other NFp instance (s) (e.g. NFp#2) offering Service B.

5. NRF1 may forward the Nnrf_NFMng_Update request to the other NRF (s) in the specific NRF area (s) identified in step 4, for example, NRF2 in NRF Area 2.

6. NRF2 may locally update the profile of NFp#1.

7. NRF2 may send a Nnrf_NFMng_Update response indicating update success to NRF1.

8. NRF2 may identify the origin of the request is another NRF (i.e. NRF1) , so it will recognize that it does not have to forward this request to other NRFs, which is similar to step 8 of Fig. 6.

Fig. 8a schematically illustrates a service registration procedure 800a according to a second embodiment of the present disclosure. The second embodiment does not require initial configuration in each NRF in a communication network.

The procedure 800a may start with step S802, in which a NRF may receive a register request from a NF instance and locally register a profile of the NF instance, wherein the profile may include many parameters, for example, "service name" for indicating one or more NF services offered by the NF instance. Hereinafter, the NRF in which the NF instance has registered may be called "local NRF" for this NF instance. In step S804, the local NRF may check the profile of the NF instance to find a set identifier, SetId, indicative of a NF set including NF instances supporting the same service (s) , which may imply the presence of at least one other NF instance offering the same service (s) . Hence, the local NRF may derive that the same service (s) may be accessible from other NRF in the network. In step S806, the local NRF may discover other NRF in which at least one other NF instance of the NF set is registered, based on the SetId. In step S808, the local NRF may obtain from the other NRF and store locally the profile of said at least one other NF instance. Hence, this interaction between these NRFs can implement sharing of the registration information related to the same service (s) . If other NF instances of the NF set are registered in multiple other NRFs, then the local NRF may perform steps S806 and S808 for each of the other NRFs.

Fig. 8b schematically illustrates an inter-NRF synchronization procedure 800b according to the second embodiment of the present disclosure. The procedure 800b may be performed after the procedure 800a. The local NRF may send a status subscription request associated with the SetId to the other NRF (s) , in step S810, and receive a status notification associated with the SetId from the other NRF (s) , in step S812. The status notification associated with the SetId may include change to the profile of said other NF instance, deregistration of said other NF instance, or registration of one or more new NF instances added into the NF set.

In an example, the profile of the locally registered NF instance may include multiple SetIds. The local NRF may perform the same steps S806, S808, S810 and S812 for each of the multiple SetIds.

Fig. 9 is a signalling diagram for schematically illustrating a service registration and inter-NRF synchronization procedure according to the second embodiment of the present disclosure. Fig. 9 depicts an exemplary scenario where two NRFs (NRF1, NRF2) are deployed in one communication network, forming two NRF areas (NRF Area 1, NRF Area 2) , and where an instance of NF service consumer (NFc) is registered in NRF Area 1, and two NFp instances (NFp#1, NFp#2) in a NF set offering the same service (s) (e.g. Service B) are registered in NRF Area 1 and NRF Area 2, respectively.

The exemplary procedure shown in Fig. 9 may comprise the following steps:

1. NFp#1 may send a Nnrf_NFMng_Register request to NRF1. The request may include an identifier of NFp#1 and at least one service name (e.g. "servB" ) representing at least one service (e.g. Service B) offered by NFp#1.

2. The profile of NFp#1 may be locally registered (or stored) in NRF1, wherein the profile may include the at least one service name, and possibly include at least one set identifier, SetId.

3. NRF1 may send a Nnrf_NFMng_Register response to NFp#1.

4. NRF1 may check whether the profile of NFp#1 includes at least one SetId, SetId-X. If the SetId-X is found, it may imply that there is a NF set including NFp#1 and at least one other NF instance offering the same service (s) . Hence, NRF1 may derive that the same service (s) may be accessible from other NRF (s) in the network.

5. NRF1 may send a Nnrf_NFMng_Discovery request to the other NRF (s) , for example, NRF2 in NRF Area 2, in order to discover other NF instance (s) of the NF set, based on the SetId-X.

6. NRF2 may find the profile of at least one other NF instance (e.g. NFp#2) including the SetId-X is locally registered (or stored) .

7. NRF2 may send a Nnrf_NFMng_Discovery response including the found profile (s) to NRF1.

8. NRF1 may locally store the profile (s) received from NRF2.

This interaction between these NRFs can implement sharing of the registration information related to the same service (s) . As a result, NRF1 may locally store the profiles of almost all NF instances in the NF set with the SetId-X.

For inter-NRF synchronization, the procedure of Fig. 9 may further comprise the following steps:

9. NRF1 may send a Nnrf_NFStatusSubs request associated with the SetId-X to the other NRF (s) including NRF2.

10. NRF1 may receive a Nnrf_NFStatusSubs response from the other NRF (s) . As a result, NRF1 may receive the status notification associated with the SetId-X, which may include change to the profile of the other NF instance (s) in the NF set, deregistration of the other NF instance (s) , or registration of one or more new NF instances added into the NF set.

Figs. 10a, 10b and 10c schematically illustrate automatic management of multiple NRF areas according to a third embodiment of the present disclosure. This embodiment depicts an exemplary scenario where a central NRF and at least one local NRF are deployed in different NRF areas in one communication network, and where the central NRF is configured for centrally managing NRF Areas service information that includes NRF service information of each NRF (including the central NRF per se) in the network, and each local NRF is configured with a contact point to the central NRF.

Fig. 10a schematically illustrates a procedure 1000a performed by a local NRF according to the third embodiment.

In step S1006, a local NRF may receive a register request from a NF instance and locally register a profile of the NF instance, wherein the profile may include many parameters, for example, "service name" for indicating one or more NF services offered by the NF instance. In step S1008, the local NRF may check the profile to find a particular service is a new service not yet registered before. In step S1010, the local NRF may request the central NRF to update the NRF service information of the local NRF related to the particular service. In an example, the NRF service information of the local NRF may include at least an identifier of the local NRF, service name of said particular service, and an identifier of the NF instance offering said particular service (or SetId of a NF set, if the NF set offers said particular service) .

When multiple local NRFs are deployed in the network, each of the local NRFs may perform the similar steps as discussed above for its new service. As a result, the NRF Areas service information centrally managed by the central NRF will include an array of the NRF service information of the local NRFs.

Moreover, the procedure 1000a provides two exemplary modes for inter-NRF synchronization. According to the first mode, during initial set-up, the local NRF may send a subscription request for the NRF Areas service information to the central NRF, in step S1002; and receive a subscription response from the central NRF, in step S1004. According to the second mode, the local NRF may read the NRF Areas service information from the central NRF in response to an event requiring this information, in step S1012; and subscribe for update of the NRF Areas service information from the central NRF, in step S1014. These modes can be used individually or in combination.

Fig. 10b schematically illustrates a procedure 1000b performed by the central NRF according to the third embodiment, which may correspond to the procedure 1000a discussed above.

In step S1020, the central NRF for centrally managing NRF Areas service information may receive an update request from a local NRF, the update request indicating that a particular service offered by a NF instance is newly registered in the local NRF. In step S1022, the central NRF may update the NRF service information of the local NRF related to the particular service.

Moreover, the procedure 1000b provides three exemplary modes for inter-NRF synchronization. According to the first mode, the central NRF may check whether any other local NRF is managed centrally for said particular service, and if so, send a notification of updating the NRF Areas service information to the other local NRF, in step S1028. According to the second mode, during initial set-up, the central NRF may receive a subscription request for the NRF Areas service information from the local NRF, in step S1016; and send a subscription response to the local NRF, in step S1018. According to the third mode, the central NRF may allow the local NRF to read the NRF Areas service information in response to an event requiring this information, in step S1024; and notify update of the NRF Areas service information to the local NRF having subscribed for said update, in step S1026. These modes can be used individually or in combination.

Fig. 10c schematically illustrates a procedure 1000c performed by the central NRF according to the third embodiment. During the procedure 1000c, the central NRF may also act as a local NRF for local registration of a NF instance.

In step S1030, the central NRF may receive a register request from a NF instance and locally register the NF instance which offers a new service. In step S1032, the central NRF may update the NRF service information of the central NRF related to this new service.

Moreover, for inter-NRF synchronization, the central NRF may check whether any other local NRF is managed centrally for said new service, and if so, sending a notification of updating the NRF Areas service information to the other local NRF, in step S1034.

As a result of the automatic management of multiple NRF areas as discussed above, any local NRF being managed centrally by a central NRF will obtain at least a part of the NRF Areas service information as stored in the central NRF.

Fig. 10d schematically illustrates a service discovery procedure 1000d performed by a NRF (either a local NRF, or a central NRF) , based on the obtained NRF Areas service information.

In step S1036, the NRF may receive a discovery request for one service from a service consumer. In step S1038, the NRF may expose one or more locally registered NF instances or NF sets offering said one service, towards the service consumer. In step S1040, the NRF may supervise which service consumers have sent the discovery request that results in NF instances of NF sets offering said one service. Alternatively or additionally, the NRF may supervise the availability and/or load of the locally registered NF instances or NF sets. In step S1042, the NRF may check the NRF Areas service information to find other NRF (s) where said one service is available, when the locally registered NF instances or NF sets are not sufficient to satisfy the service consumer. In step S1044, the NRF may initiate inter-NRF discovery to the other NRF (s) to find further NF instance (s) or NF set (s) offering said one service. In step S1046, the NRF may notify the further NF instance (s) or NF set (s) to the service consumer having subscribed to be notified.

Fig. 11 is a signalling diagram for schematically illustrating automatic management of multiple NRF areas according to the third embodiment of the present disclosure.

In the exemplary scenario of Fig. 11, NRF1 deployed in NRF Area 1 may act as a central NRF, while NRF2 deployed in NRF Area 2 may act as a local NRF. Although only one local NRF is shown for clarity, any number of local NRFs can be involved, depending on specific deployment of a telecommunication operator. Each local NRF (e.g. NRF2) may be initially configured with a contact point to the central NRF1 during an initial set-up process, and each local NRF may perform the same steps as discussed below for NRF2.

NRF Areas service information may be centrally managed by the central NRF1, in order to keep track of each local NRF in terms of NF services registered in the local NRF, and the NF instance or NF set that each of the services belongs to. As an example, the NRF Areas service information may contain an array of NRF service information which may include: an identifier of a NRF, i.e. NRFid, and an array of service name of a particular service together with an identifier/SetId of the NF instance/NF set offering the particular service.

Initially, the NRF Areas service information in the central NRF1 may be empty. NRF-to-NRF interaction between the central NRF1 and each local NRF will update the NRF Areas service information. The present disclosure proposes a new service, Nnrf_NrfAreasMng, to be implemented by NRF to keep the NRF Areas service information updated in the central NRF.

The exemplary procedure 1100 shown in Fig. 11 may comprise the following steps:

1. NRF2 may send a Nnrf_NrfAreasMng_Subs request to NRF1, to subscribe for any update of the NRF Areas service information. This step may be performed when NRF2 is set-up initially, prior to registration of any NF instance (e.g. NFp#2) .

2. NRF2 may receive a Nnrf_NrfAreasMng_Subs response indicating subscription success from NRF1.

3. NFp#2 (offering e.g. Service B) may send a Nnrf_NFMng_Register request to NRF2, wherein the request may contain an identifier of NFp#2 and at least one service name (e.g. "servB" ) , for example.

4. The profile of NFp#2 may be registered (or stored) locally in NRF2.

5. NRF2 may send back to NFp#2 a Nnrf_NFMng_Register response indicating registration success.

6. NRF2 may check if Service B was already registered. If Service B is a new service not yet registered, then steps 7-8 would be performed; otherwise, steps 7-8 are unnecessary.

7. NRF2 may send a Nnrf_NrfAreasMng_Update request to NRF1 acting as the central NRF, wherein the request may include an identifier of NRF2 and at least one service name (e.g. "ServB" ) , for example.

8. NRF2 may receive a Nnrf_NrfAreasMng_Update response from NRF1.

9. NRF1 may update the NRF Areas service information, in particular, update the NRF service information of NRF2 related to Service B. Thus, it can be derived from the NRF Areas service information whether each local NRF (e.g. NRF2) has a local registration for a service, based on a service name, e.g. "ServX" .

10. NRF1 may check if notifications to other local NRFs (if any) are required. In the exemplary scenario of Fig. 11, NRF2 is the first local NRF having registered Service B, so there is not yet other local NRF to be notified.

In an example, as an alternative to steps 1-2, NRF2 may read the NRF Areas service information from NRF1 in response to an event requiring this information, and then, subscribe for update of the NRF Areas service information from NRF1. The present disclosure proposes a new operation, Nnrf_NrfAreasMng_Get, for this purpose.

In an example, the central NRF (NRF1) may also act as a local NRF for local registration of a NF instance (e.g. NFp#1) . The exemplary procedure 1100 of Fig. 11 may further comprise the following steps:

11. NRF1 may receive a Nnrf_NFMng_Register request from NFp#1 which can offer at least one NF service (e.g. Service B) . This request may contain an identifier of NFp#1 and at least one service name, e.g. "servB" .

12. NRF1 may locally register (or store) the profile of NFp#1.

13. NRF1 may send a Nnrf_NFMng_Register response indicating registration success to NFp#1.

14. NRF1 (acting as a central NRF from now on) may update the NRF Areas service information, in particular, the NRF service information of NRF1 related to Service B.

15. NRF1 may check if notifications to other local NRFs (if any) are required, since the NRF Areas service information has been updated. NRF1 may derive from the NRF Areas service information that the same service (Service B in this example) was registered locally in other local NRFs (e.g. NRF2) , and thus NRF2 needs to be notified.

16. NRF1 may send a Nnrf_NrfAreasMng_Notif request to NRF2, wherein this request may contain any update of the NRF Areas service information centrally managed in NRF1. In this example, the update may refer to the NRF service information of NRF1 related to Service B.

17. NRF2 may send a Nnrf_NrfAreasMng_Notif response to NRF1.

After the aforesaid NRF-to-NRF interaction between the central NRF and each local NRF, the central NRF may have stored and centrally managed the NRF service information for all NRF areas as well as its own area. Each local NRF being managed centrally by the central NRF may obtain at least a part of the NRF Areas service information as stored in the central NRF. In other words, each local NRF would have an up-to-date information relevant to the locally registered services in its local area. If all service types involved in the network have been locally registered in a local NRF, this local NRF may obtain the same NRF Areas service information as that of the central NRF.

Fig. 12 is a signalling diagram for schematically illustrating a service discovery procedure according to the third embodiment of the present disclosure. The exemplary procedure 1200 of Fig. 12 may be divided into two phases: (1) local NRF discovery phase, which is limited to a local NRF area; and (2) inter-NRF Area (s) discovery phase, which is extended to other NRF area (s) than the local NRF area.

The exemplary procedure 1200 shown in Fig. 12 may comprise the following steps:

1. An instance of NF service consumer (NFc) deployed in NRF Area 1 may send a Nnrf_NFMng_Discovery request to its local NRF (NRF1) , seeking for NFp instance (s) offering a service, e.g. Service B (represented by its service name "ServB" ) .

2. NRF1 may send a Nnrf_NFMng_Discovery response to NFc, exposing one or more locally registered NFp instances or NF sets offering Service B, towards NFc. The response may contain SetX (s) identifying the NF set (s) said Service B belongs to.

3. NRF1 may supervise which service consumers have sent the similar discovery requests that would result in the NFp instances or NF sets offering Service B.

4. NRF1 may further supervise the availability and/or load of the locally registered NFp instances or NF sets as exposed towards NFc in step 2. The ultimate goal of steps 3-4 is that the local NRF is able to identify when NFc may not have any NFp instance offering Service B to properly deal with its traffic, based on the supervising results.

5. NRF1 may check the NRF Areas service information to find other NRF (s) where said one service is available, when the locally registered NFp instances or NF sets are not sufficient to satisfy NFc. As an example, NRF2 in NRF Area 2 is found to have one or more locally registered NFp instances or NF sets offering Service B.

6. NRF1 may initiate an inter-NRF Area (s) discovery toward NRF2, by sending a Nnrf_NFMng_NFDiscovery request which may contain some parameters such as "servB" and "SetX (s) " .

7. NRF2 may send a Nnrf_NFMng_NFDiscovery response to NRF1, which may contain the profiles of the NFp instances (e.g. NFp#2) discovered based on the parameters in the discovery request.

8. NRF1 may send a Nnrf_NFMng_StatusNotify request to NFc.

9. NRF1 may receive a Nnrf_NFMng_StatusNotify response from NFc. As a result of steps 8-9, NRF1 may automatically notify NFc that new NFp instance (s) (e.g. NFp#2) offering Service B are discovered in other NRF area (s) . Otherwise, without steps 8-9, NFc may need to frequently perform new discoveries in order to find the new NFp instance (s) .

In an example, NRF1 may find multiple NRFs where Service B is available, based on the NRF Areas service information. However, NRF1 may initiate the inter-NRF Area (s) discovery toward only one of, a part of, or all of the multiple NRFs, depending on actual demands.

It is to be noted that any NRF in a communication network may be configured to act as a local NRF or a central NRF. Terms "local NRF" and "central NRF" are used throughout this disclosure to represent relatively different roles. As compared with the role of the local NRF, the role of the central NRF may additionally comprise centrally managing NRF Areas service information for all NRFs, and providing relevant information to any of the other NRFs. However, there is no substantive difference between a local NRF and a central NRF in many aspects, for example, in terms of interaction with one or more service consumers and access to the profiles of one or more service producers registered in other NRF areas.

Persons skilled in the art will appreciate that the steps, operations or functions of each NRF, NFc and NFp disclosed herein may be implemented in one or more nodes using hardware and/or software and/or firmware. The one or more nodes may have one or more suitable interfaces to interact with each other.

For example, hardware implementation may include, without limitation, an electronic circuit, a logic circuit, a processor, a microprocessor, a controller, a microcontroller, an integrated circuit such as an application specific integrated circuit (ASIC) or general purpose integrated circuit, a field-programmable gate array (FPGA) , a programmable logic device (PLD) , a system on chip (SoC) , a computing device, a computing platform, etc., that are configured to provide the described functionality. In addition, the hardware implementation may include, without limitation, one or more memories such as read only memory (ROM) , random access memory (RAM) , cache memory, flash memory and the like, as well as one or more storage devices (e.g. optical storage device, or mass storage device) . The term “processor” may refer to a central processing unit (CPU) , a digital signal processor (DSP) , a single-core processor, a multiple-core processor, and/or any other processing device capable of executing computer-executable instructions, such as program code, software modules, and/or functional processes.

Where software implementation is appropriate, the techniques disclosed herein can be considered to be embodied entirely within any form of computer-readable storage medium, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques.

Moreover, any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules included in one or more virtual apparatuses. These virtual apparatuses may be implemented via hardware (s) which is configured to execute software program stored in one or more memories. The software program may include program instructions for carrying out one or more of the embodiments disclosed herein, as well as program instructions for executing one or more communication protocols.

Fig. 13 schematically illustrates a first network node 1300 adapted to provide a Network Repository Function (NRF) in a communication network, according to some embodiments of the present disclosure. The first network node 1300 may comprise a processor 1302 and a memory 1304 coupled to the processor, wherein the memory 1304 may contain instructions that when executed by the processor 1302, may cause the first network node 1300 to act as a local NRF in the various procedures discussed above. Moreover, the first network node 1300 may be configured with a network interface 1306 coupled to the processor, to enable communication with other network nodes or entities or modules or functions. According to other embodiments, the processor may include an internal memory so that a separate memory is not required.

Fig. 14 schematically illustrates a second network node 1400 adapted to provide a Network Repository Function (NRF) in a communication network, according to some embodiments of the present disclosure. The second network node 1400 may comprise a processor 1402 and a memory 1404 coupled to the processor, wherein the memory 1404 may contain instructions that when executed by the processor 1402, may cause the second network node 1400 to act as a central NRF in the various procedures discussed above. Moreover, the second network node 1400 may be configured with a network interface 1406 coupled to the processor, to enable communication with other network nodes or entities or modules or functions. According to other embodiments, the processor may include an internal memory so that a separate memory is not required.

Fig. 15 schematically illustrates a first apparatus 1500 for implementing a local NRF in a communication network according to some embodiments of the present disclosure. The first apparatus 1500 may comprise: a receiving module 1502 for receiving a register request from a NF instance and locally registering a profile of the NF instance, wherein the profile indicates one or more NF services offered by the NF instance; a determining module 1504 for determining that a particular service of the NF services is accessible from other NRF (s) in the communication network; and an interacting module 1506 for interacting with the other NRF (s) to share registration information related to the particular service. In other example, the first apparatus 1500 may comprise one or more additional modules for performing other operations of the local NRF as discussed hereinabove. It is to be noted that the modules may be implemented by software, hardware, firmware, or any combination thereof.

Fig. 16 schematically illustrates a second apparatus 1600 for implementing a central NRF in a communication network, according to some embodiments of the present disclosure. The second apparatus 1600 may be configured for centrally managing NRF Areas service information that includes NRF service information of each local NRF in the communication network and the central NRF, wherein each local NRF is configured with a contact point to the central NRF. The second apparatus 1600 may comprise: a receiving module 1602 for receiving an update request from a local NRF, the update request indicating that a particular service offered by a NF instance is newly registered in the local NRF; and an updating module 1604 for updating the NRF service information of the local NRF related to the particular service. In other example, the second apparatus 1600 may comprise one or more additional modules for performing other operations of the central NRF as discussed hereinabove. It is to be noted that the modules may be implemented by software, hardware, firmware, or any combination thereof.

According to an exemplary embodiment, there is provided a communication system comprising: at least one NF instance acting as a service producer; at least one NF instance acting as a service consumer; and at least one of the first network node, the second network node, the first apparatus and the second apparatus as discussed in the present disclosure. As a non-limiting example, the communication system may be deployed in 5th Generation Core Network, 5GC.

According to an exemplary embodiment, there is provided a computer program comprising computer-executable instructions configured to cause a device to perform the procedures or methods as discussed in the present disclosure, when the computer-executable instructions are executed on a processor comprised in the device.

According to an exemplary embodiment, there is provided a carrier containing the computer program as discussed in the present disclosure. As a non-limiting example, the carrier may be selected from an electronic signal, optical signal, radio signal, and computer-readable storage medium.

According to an exemplary embodiment, there is provided a computer program product comprising a computer-readable storage medium, the computer-readable storage medium having computer-executable instructions configured to cause a device to perform the procedures or methods as discussed in the present disclosure, when the computer-executable instructions are executed on a processor comprised in the device.

Hereinabove, some embodiments have been presented in a form of flowchart, signalling diagram or block diagram. It is to be noted that the orders of the steps or operations as shown in these diagrams are only intended for illustrative purpose rather than for limitation of the present invention. Steps in the procedures or methods disclosed herein may be carried out in any order unless expressly otherwise stated. Any reference signs shall not be construed so as to limit their scope. In practice, various procedures disclosed herein may be divided or combined according to actual demands. Persons skilled in the art would recognize that some variations can be made to these flowcharts or diagrams within the broadest spirit and scope of the present disclosure.

Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. Where the terms, "first" , "second" etc. are used, they are to be understood merely as labels for the convenient identification of a particular feature. In particular, they are not to be interpreted as describing the first or the second feature of a plurality of such features to occur in time or space, unless explicitly stated otherwise.

In the claims, the word "comprising" , "comprise" , "including" or "include" does not exclude other elements or steps and the indefinite article "a" or "an" does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Throughout the description, the embodiments of the present disclosure have been described with reference to some specific details. It will be evident that various modifications may be made thereto without departing from the broadest spirit and scope as claimed in the appended claims. Accordingly, the description and the drawings shall be interpreted in an illustrative sense rather than a restrictive sense.

Claims

A method performed by a Network Repository Function, NRF, in a communication network, comprising:

receiving (S402) a register request from a Network Function, NF, instance and locally registering a profile of the NF instance, wherein the profile indicates one or more NF services offered by the NF instance;

determining (S404) that a particular service of the NF services is accessible from at least one other NRF in the communication network; and

interacting (S406) with said other NRF to share registration information related to said particular service.
The method according to claim 1, wherein the NRF is initially configured (S502) with one or more service types each deployed at multiple NRFs in the communication network, and

wherein:

the determining (S404) comprises checking (S506) the profile to identify said particular service matching one of the service types; and

the interacting (S406) comprises forwarding (S508) the register request to said other NRF to register the profile of the NF instance in said other NRF.
The method according to claim 2, wherein the forwarded register request includes an identifier of the NRF, or Internet Protocol, IP, address of the NRF, for indicating origin of the forwarded register request.
The method according to claim 2, further comprising:

receiving (S510) a status subscription request for the NF instance from said other NRF; and

sending (S512) a status notification for the NF instance to said other NRF.
The method according to claim 2, further comprising:

receiving (S514) an update request from the NF instance and updating the profile of the NF instance;

determining (S516) that said updating relates to said particular service; and

forwarding (S518) the update request to said other NRF to update the profile of the NF instance in said other NRF.
The method according to claim 2, further comprising:

receiving (S520) a deregister request from the NF instance and deregistering the profile of the NF instance; and

forwarding (S522) the deregister request to said other NRF to deregister the profile of the NF instance in said other NRF.
The method according to claim 1, wherein:

the determining (S404) comprises checking (S804) the profile to find a set identifier, SetId, indicative of a NF set including NF instances supporting the same services; and

the interacting (S406) comprises discovering (S806) other NRF in which at least one other NF instance of the NF set is registered, based on the SetId, and obtaining (S808) from said other NRF and storing locally profile of said other NF instance.
The method according to claim 7, further comprising:

sending (S810) a status subscription request associated with the SetId to said other NRF; and

receiving (S812) a status notification associated with the SetId from said other NRF.
The method according to claim 8, wherein the status notification associated with the SetId includes change to the profile of said other NF instance, deregistration of said other NF instance, or registration of one or more new NF instances added into the NF set.
The method according to any of claims 7 to 9, wherein the profile includes multiple SetIds, and the method comprises performing the same operations for each of the multiple SetIds.
The method according to claim 1, wherein the NRF is configured with a contact point to a central NRF for centrally managing NRF Areas service information that includes NRF service information of each NRF in the communication network, and wherein:

the determining (S404) comprises checking (S1008) the profile to find said particular service is a new service not yet registered before; and

the interacting (S406) comprises requesting (S1010) the central NRF to update the NRF service information of the NRF related to said particular service.
The method according to claim 11, wherein the NRF service information of the NRF includes at least an identifier of the NRF, service name of said particular service, and an identifier of the NF instance offering said particular service.
The method according to claim 11 or 12, further comprising:

during initial set-up,

sending (S1002) a subscription request for the NRF Areas service information to the central NRF; and

receiving (S1004) a subscription response from the central NRF.
The method according to claim 11 or 12, further comprising:

reading (S1012) the NRF Areas service information from the central NRF in response to an event requiring the NRF Areas service information; and

subscribing (S1014) for update of the NRF Areas service information from the central NRF.
The method according to any of claims 1 to 14, further comprising:

receiving (S408) a discovery request for said particular service from a service consumer; and

exposing (S410) all NF instances offering said particular service which are registered in the NRF and said other NRF, towards the service consumer.
The method according to any of claims 1 to 14, further comprising:

receiving (S408) a discovery request for said particular service from a service consumer;

exposing (S412) one or more NF instances offering said particular service which are registered locally, towards the service consumer;

supervising (S414) which service consumers have sent the discovery request that results in NF instances offering said particular service, and/or availability and/or load of said one or more NF instances; and

exposing (S416) one or more additional NF instances offering said particular service which are registered in said other NRF, towards the service consumer, when said one or more NF instances are not sufficient to satisfy the service consumer.
The method according to any of claims 1 to 16, wherein the NRF and the at least other NRF are deployed at different geographical areas.
A method performed by a central Network Repository Function, NRF, in a communication network, the central NRF being configured for centrally managing NRF Areas service information that includes NRF service information of each local NRF in the communication network and the central NRF, wherein each local NRF is configured with a contact point to said central NRF, the method comprising:

receiving (S1020) an update request from a local NRF, the update request indicating that a particular service offered by a Network Function, NF, instance is newly registered in the local NRF; and

updating (S1022) the NRF service information of the local NRF related to said particular service.
The method according to claim 18, wherein the NRF service information of the local NRF includes at least an identifier of the local NRF, service name of said particular service, and an identifier of the NF instance offering said particular service.
The method according to claim 18 or 19, further comprising:

during initial set-up,

receiving (S1016) a subscription request for the NRF Areas service information from the local NRF; and

sending (S1018) a subscription response to the local NRF.
The method according to claim 18 or 19, further comprising:

allowing (S1024) the local NRF to read the NRF Areas service information in response to an event requiring the NRF Areas service information; and

notifying (S1026) update of the NRF Areas service information to the local NRF having subscribed for said update.
The method according to claim 18 or 19, further comprising:

checking (S1028) whether any other local NRF is managed centrally for said particular service, and if so, sending a notification of updating the NRF Areas service information to the other local NRF.
The method according to claim 18 or 19, further comprising:

receiving (S1030) a register request from another NF instance and locally registering the another NF instance which offers another service; and

updating (S1032) the NRF service information of the central NRF related to the another service.
The method according to claim 23, further comprising:

checking (S1034) whether any other local NRF is managed centrally for said another service, and if so, sending a notification of updating the NRF Areas service information to the other local NRF.
The method according to any of claims 18 to 24, further comprising:

receiving (S1036) a discovery request for one service from a service consumer;

exposing (S1038) one or more NF instances or NF sets offering said one service which are locally registered in the central NRF, towards the service consumer;

supervising (S1040) which service consumers have sent the discovery request that results in NF instances or NF sets offering said one service, and/or availability and/or load of said one or more NF instances or NF sets; and

checking (S1042) said NRF Areas service information to find one or more local NRFs where said one service is available, when said one or more NF instances or NF sets are not sufficient to satisfy the service consumer.
The method according to claim 25, further comprising:

initiating (S1044) inter-NRF discovery to at least one of the local NRFs to find one or more additional NF instances or NF sets offering said one service; and

notifying (S1046) the one or more additional NF instances or NF sets to the service consumer having subscribed to be notified.
The method according to any of claims 18 to 26, wherein at least two of the NRFs are deployed at different geographical areas.
A network node (1300) for providing a Network Repository Function, NRF, in a communication network, comprising:

a processor (1302) ; and

a memory (1304) coupled to the processor, wherein the memory contains instructions that when executed by the processor, cause the network node to perform the method according to any of claims 1 to 17.
A network node (1400) for providing a central Network Repository Function, NRF, in a communication network, comprising:

a processor (1402) ; and

a memory (1404) coupled to the processor, wherein the memory contains instructions that when executed by the processor, cause the network node to perform the method according to any of claims 18-27.
An apparatus (1500) for implementing a Network Repository Function, NRF, in a communication network, comprising:

receiving module (1502) for receiving a register request from a Network Function, NF, instance and locally registering a profile of the NF instance, wherein the profile exposes one or more NF services offered by the NF instance;

determining module (1504) for determining that a particular service of the NF services should be accessible from at least one other NRF in the communication network; and

interacting module (1506) for interacting with said other NRF to share registration information related to said particular service.
The apparatus according to claim 30, further comprising modules for performing each step in the method according to any of claims 2 to 17.
An apparatus (1600) for implementing a central Network Repository Function, NRF, in a communication network, the apparatus being configured for centrally managing NRF Areas service information that includes NRF service information of each local NRF in the communication network and the central NRF, wherein each local NRF is configured with a contact point to said central NRF, the apparatus comprising:

receiving module (1602) for receiving an update request from a local NRF, the update request indicating that a particular service offered by a Network Function, NF, instance is newly registered in the local NRF; and

updating module (1604) for updating the NRF service information of the local NRF related to said particular service.
The apparatus according to claim 32, further comprising modules for performing each step in the method according to any of claims 19 to 27.
A communication system comprising:

at least one Network Function, NF, instance acting as a service producer;

at least NF instance acting as a service consumer; and

at least one of the following:

the network node according to claim 28,

the network node according to claim 29, and

the apparatus according to any of claims 30 to 33.
The communication system according to claim 34, being deployed in 5th Generation Core Network, 5GC.
A computer program comprising computer-executable instructions configured to cause a device to perform the method according to any of claims 1 to 27, when the computer-executable instructions are executed on a processor comprised in the device.
A carrier containing the computer program of claim 35, wherein the carrier is one of an electronic signal, optical signal, radio signal, and computer-readable storage medium.
A computer program product comprising a computer-readable storage medium, the computer-readable storage medium having computer-executable instructions configured to cause a device to perform the method according to any of claims 1 to 27, when the computer-executable instructions are executed on a processor comprised in the device.