Discovery of Which NEF or AF is Serving a UE

Abstract

There is provided mechanisms for discovering, for data collection, which NEF or AF is serving a UE. A method is performed by an NWDAF entity. The method comprises providing, to a 5GC network function entity, a query of which NEF or AF is serving the UE. The method comprises receiving, from the 5GC network function entity, a response comprising an ID of the NEF or the AF when there is a NEF or AF instance stored in the 5GC network function entity for the UE.

Claims

1-40. (canceled)

41. A method for discovering, for data collection, which network exposure function, NEF, or application function, AF, is serving a user equipment, UE, the method being performed by a network data analytics function, NWDAF, entity, the method comprising: providing, to a 5GC network function entity, a query of which NEF or AF is serving the UE; and receiving, from the 5GC network function entity, a response comprising an ID of the NEF or the AF when there is a NEF or AF instance stored in the 5GC network function entity for the UE.

42. The method according to claim 41, wherein the 5GC network function entity is one of: a network repository function, NRF; a binding support function, B SF; or a unified data management, UDM, entity.

43. The method according to claim 41, wherein the query invokes a discovery service in the 5GC network function entity.

44. The method according to claim 41, wherein the query comprises an ID of the UE.

45. The method according to claim 41, further comprising: receiving, from a network repository function, NRF, an address to the NEF or the AF.

46. The method according to claim 45, wherein, when the 5GC network function entity is the NRF, the address to the NEF or the AF is received in the response from the 5GC network function entity.

47. The method according to claim 45, wherein, when the 5GC network function entity is not the NRF, the address to the NEF or the AF is received in response to the NWDAF entity having provided a query to the NRF for a discovery service.

48. The method according to claim 41, wherein the address to the AF is received when the AF is in trusted mode, and wherein the address to the NEF is received when the AF is in untrusted mode.

49. The method according to claim 41, wherein an explicit indication of whether the AF is in trusted mode or in untrusted mode is received from the NRF.

50. The method according to claim 49, wherein, when the AF is in untrusted mode, the method further comprises: providing, to the NEF, a request for event subscription for the UE, the request comprising an ID of the UE and at least one identifier of metrics to be collect by the NWDAF for the UE; and receiving, from the NEF, an acknowledgement of the event subscription.

51. The method according to claim 49, wherein, when the AF is in trusted mode, the method further comprises: providing, to the AF, a request for event subscription for the UE, the request comprising an ID of the UE and at least one identifier of metrics to be collect by the NWDAF for the UE; and receiving, from the AF, an acknowledgement of the event subscription.

52. The method according to claim 41, wherein the response comprises an error indication in case there is no NEF or AF instance stored in the 5GC network function entity for the UE.

53. A method for enabling discovery, for data collection, which network exposure function, NEF, or application function, AF, is serving a user equipment, UE, the method being performed by a 5GC network function entity, the method comprising: receiving, from a network data analytics function, NWDAF, entity, a query of which NEF or AF is serving the UE; and providing, to the NWDAF entity, a response comprising an ID of the NEF or the AF when there is a NEF or AF instance stored in the 5GC network function entity for the UE.

54. The method according to claim 53, wherein the 5GC network function entity is one of: a network repository function, NRF; a binding support function, B SF; or a unified data management, UDM, entity.

55. The method according to claim 53, wherein the query invokes a discovery service in the 5GC network function entity.

56. The method according to claim 53, wherein, when the 5GC network function entity is a network repository function, NRF, an address to the NEF or the AF is provided in the response.

57. The method according to claim 56, wherein the address to the AF is provided when the AF is in trusted mode, and wherein the address to the NEF is provided when the AF is in untrusted mode.

58. The method according to claim 56, wherein an explicit indication of whether the AF is in trusted mode or in untrusted mode is provided to the NWDAF entity.

59. The method according to claim 53, further comprising: receiving, from the NEF when the AF is in untrusted mode, an AF profile for registration of the AF in the network function, the AF profile comprising an indication that the AF is in untrusted mode.

60. A network data analytics function, NWDAF, entity for discovering, for data collection, which network exposure function, NEF, or application function, AF, is serving a user equipment, UE, the NWDAF entity comprising processing circuitry, the processing circuitry being configured to cause the NWDAF entity to: provide, to a 5GC network function entity, a query of which NEF or AF is serving the UE; and receive, from the 5GC network function entity, a response comprising an ID of the NEF or the AF when there is a NEF or AF instance stored in the 5GC network function entity for the UE.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which:

[0025] FIG. 1 is a schematic diagram illustrating a communication network according to embodiments;

[0026] FIGS. 2 and 3 are flowcharts of methods according to embodiments;

[0027] FIGS. 4, 5, 6, and 7 are signaling diagrams according to embodiments;

[0028] FIG. 8 is a schematic diagram showing functional units of an NWDAF entity according to an embodiment;

[0029] FIG. 9 is a schematic diagram showing functional modules of an NWDAF entity according to an embodiment;

[0030] FIG. 10 is a schematic diagram showing functional units of a 5GC network function entity according to an embodiment;

[0031] FIG. 11 is a schematic diagram showing functional modules of a 5GC network function entity according to an embodiment; and

[0032] FIG. 12 shows one example of a computer program product comprising computer readable means according to an embodiment.

DETAILED DESCRIPTION

[0033] The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown. This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any action or feature illustrated by dashed lines should be regarded as optional.

[0034] FIG. 1 is a schematic diagram illustrating a communication network 100 where embodiments presented herein can be applied. The communication network 100 represents a reference architecture of a fifth generation telecommunication system (5GS) and comprises the following entities: and Authentication Server Function (AUSF), an Access and Mobility Management Function (AMF), a Data Network (DN), e.g. operator services, Internet access or 3rd party services, a Network Exposure Function (NEF), a Network Repository Function (NRF), a Network Slice Selection Function (NSSF), a Policy Control Function (PCF), a Session Management Function (SMF), a Unified Data Management (UDM), a Unified Data Repository (UDR), a User Plane Function (UPF), an Application Function (AF), a User Equipment (UE), a (Radio) Access Network ((R)AN), a Network Data Analytics Function (NWDAF), a Binding Support Function (BSF), and a Charging Function (CHF). Service based interfaces are represented by the format Nxyz (e.g., Nnssf, NNef, etc.) and point to point interfaces are represented by the format Nx (e.g. N1, N2, etc.).

[0035] As noted above how the NWDAF determines which NEF and AF instances are serving a UE is still undefined and hence, there is still a need for improved discovery mechanisms in communication networks, and especially, but not exclusively, in the fifth generation core network.

[0036] The embodiments disclosed herein therefore relate to mechanisms for discovering, for data collection, which NEF or AF is serving a UE and enabling discovery, for data collection, which NEF or AF is serving a UE. In order to obtain such mechanisms there is provided an NWDAF entity 200, a method performed by the NWDAF entity 200, a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the NWDAF entity 200, causes the NWDAF entity 200 to perform the method. In order to obtain such mechanisms there is further provided a 5GC network function entity 300a, 300b, 300c, a method performed by the 5GC network function entity 300a, 300b, 300c, and a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the 5GC network function entity 300a, 300b, 300c, causes the 5GC network function entity 300a, 300b, 300c to perform the method.

[0037] Reference is now made to FIG. 2 illustrating a method for discovering, for data collection, which NEF or AF is serving a UE as performed by the NWDAF entity 200 according to an embodiment.

[0038] S102: The NWDAF entity 200 provides, to a 5GC network function entity 300a, 300b, 300c, a query of which NEF or AF is serving the UE. There might be different examples of network function entities. According to a first example, the 5GC network function entity 300a, 300b, 300c is an NRF 300a. According to a second example, the 5GC network function entity 300a, 300b, 300c is a BSF 300b. According to a third example, the 5GC network function entity 300a, 300b, 300c is a UDM entity 300c.

[0039] S104: The NWDAF entity 200 receives, from the 5GC network function entity 300a, 300b, 300c, a response comprising an ID of the NEF or the AF when there is a NEF or AF instance stored in the 5GC network function entity 300a, 300b, 300c for the UE.

[0040] Embodiments relating to further details of discovering, for data collection, which NEF or AF is serving a UE as performed by the NWDAF entity 200 will now be disclosed.

[0041] There might be different examples of queries that are provided in action S102. According to some embodiments, the query invokes a discovery service in the 5GC network function entity 300a, 300b, 300c. According to some embodiments, the query comprises an ID of the UE.

[0042] As will be further disclosed below with reference to FIG. 7 the NRF might provide to the NWDAF entity 200 an address to the NEF or the AF. Hence, according to an embodiment, the NWDAF entity 200 is configured to perform action S106:

[0043] S106: The NWDAF entity 200 receives, from the NRF, an address to the NEF or the AF.

[0044] In some embodiments when the 5GC network function entity 300a, 300b, 300c is the NRF, the address to the NEF or the AF is received in the response from the 5GC network function entity 300a, 300b, 300c (i.e., in the response received by the NWDAF entity 200 in action S104). Action S102 might then be equal to action 5 in FIG. 7

[0045] In some embodiments when the 5GC network function entity 300a, 300b, 300c is not the NRF, the address to the NEF or the AF is received in response to the NWDAF entity 200 having provided a query to the NRF for a discovery service. The query in action S102 is then equal to either action 1 or action 3 in FIG. 7 and the query provided to the NRF for the discovery service is equal to action 5 in FIG. 7.

[0046] As will be further disclosed below, the AF might be in either trusted mode or untrusted mode. Different actions might be performed depending on whether the AF is in trusted mode or in untrusted mode. According to a first example, the address to the AF is received when the AF is in trusted mode, and the address to the NEF is received when the AF is in untrusted mode. This provides the NWDAF entity 200 with an indirect indication as to whether the AF is in trusted mode or in untrusted mode. According to a second example, an explicit indication of whether the AF is in trusted mode or in untrusted mode is by the NWDAF entity 200 received from the NRF.

[0047] As will be further disclosed below with reference to actions 7 and 8 of FIG. 7, when the AF is in untrusted mode, any request for event subscription for the UE is provided to the NEF. Thus, according to some embodiments, when the AF is in untrusted mode, the NWDAF entity 200 is configured to perform (optional) actions S108, S110:

[0048] S108: The NWDAF entity 200 provides, to the NEF, a request for event subscription for the UE. The request comprises an ID of the UE and at least one identifier of metrics to be collect by the NWDAF for the UE.

[0049] S110: The NWDAF entity 200 receives, from the NEF, an acknowledgement of the event subscription.

[0050] As will be further disclosed below with reference to actions 11 and 12 of FIG. 7, when the AF is in trusted mode, any request for event subscription for the UE is provided to the AF. Thus, according to some embodiments, when the AF is in trusted mode, the NWDAF entity 200 is configured to perform (optional) actions S112, S114:

[0051] S112: The NWDAF entity 200 provides, to the AF, a request for event subscription for the UE, the request comprising an ID of the UE and at least one identifier of metrics to be collect by the NWDAF for the UE.

[0052] S114: The NWDAF entity 200 receives, from the AF, an acknowledgement of the event subscription.

[0053] As disclosed above, a response is in action S104 received when there is a NEF or AF instance stored in the 5GC network function entity 300a, 300b, 300c for the UE. In some embodiments the response instead comprises an error indication in case there is no NEF or AF instance stored in the 5GC network function entity 300a, 300b, 300c for the UE.

[0054] Reference is now made to FIG. 3 illustrating a method for enabling discovery, for data collection, which NEF or AF is serving a UE as performed by the 5GC network function entity 300a, 300b, 300c according to an embodiment. As above, there might be different examples of network function entities. According to a first example, the 5GC network function entity 300a, 300b, 300c is an NRF 300a. According to a second example, the 5GC network function entity 300a, 300b, 300c is a BSF 300b. According to a third example, the 5GC network function entity 300a, 300b, 300c is a UDM entity 300c.

[0055] S218: The 5GC network function entity 300a, 300b, 300c receives, from the NWDAF entity 200, a query of which NEF or AF is serving the UE.

[0056] S220: The 5GC network function entity 300a, 300b, 300c provides, to the NWDAF entity 200, a response comprising an ID of the NEF or the AF when there is a NEF or AF instance stored in the 5GC network function entity 300a, 300b, 300c for the UE.

[0057] Embodiments relating to further details of enabling discovery, for data collection, which NEF or AF is serving a UE as performed by the 5GC network function entity 300a, 300b, 300c will now be disclosed.

[0058] As above, in some embodiments, the query invokes a discovery service in the 5GC network function entity 300a, 300b, 300c. As above, in some embodiments, the query comprises an ID of the UE.

[0059] As above, in some embodiments when the 5GC network function entity 300a, 300b, 300c is an NRF, an address to the NEF or the AF is provided in the response. As above, in some embodiments, the address to the AF is provided when the AF is in trusted mode, and wherein the address to the NEF is provided when the AF is in untrusted mode. As above, in some embodiments, an explicit indication of whether the AF is in trusted mode or in untrusted mode is provided to the NWDAF entity 200.

[0060] Aspects of possible actions that the 5GC network function entity 300a, 300b, 300c might perform before it receives, from the NWDAF entity 200, the query in action S118 of which NEF or AF is serving the UE will now be disclosed.

[0061] As will be further disclosed below with reference to action 1 of FIG. 4, the NEF might invoke the Nnrf_NFRegister service operation in the NRF, specifying that NFType=NEF, and the UE-ID range (i.e., the range of UE-IDs handled by this NEF instance). Thus, according to some embodiments, the 5GC network function entity 300a, 300b, 300c is configured to perform (optional) action S202:

[0062] S202: The 5GC network function entity 300a, 300b, 300c (such as the NRF) receives, from the NEF, an ID of the UE.

[0063] As will be further disclosed below with reference to action 6 of FIG. 4, the NEF might register the AF profile in the NRF, invoking the Nnrf_NFRegister service, and specifying that NFType=AF, the App-ID, and that trust=UNTRUSTED. Thus, according to some embodiments, when the AF is in untrusted mode, the 5GC network function entity 300a, 300b, 300c is configured to perform (optional) action S204:

[0064] S204: The 5GC network function entity 300a, 300b, 300c receives, from the NEF when the AF is in untrusted mode, an AF profile for registration of the AF in the network function (such as the NRF). The AF profile comprises an indication that the AF is in untrusted mode.

[0065] As will be further disclosed below with reference to action 8 of FIG. 4, the AF might register itself the AF profile in the NRF, invoking the Nnrf_NFRegister service, and specifying that NFType=AF, the App-ID, and that trust=TRUSTED (i.e., an indication that the AF is in trusted mode. Thus, according to some embodiments, when the AF is in trusted mode, the 5GC network function entity 300a, 300b, 300c is configured to perform (optional) action S208:

[0066] S208: The 5GC network function entity 300a, 300b, 300c receives, from the AF when the AF is in trusted mode, an AF profile for registration of the AF in the network function (such as the NRF). The AF profile comprising an indication that the AF is in trusted mode.

[0067] As will be further disclosed below with reference to actions 8, 10, 12 of FIG. 5, the NEF might register the mapping between the UE and the AF when the AF is in untrusted mode. Thus, according to some embodiments, when the AF is in untrusted mode, the 5GC network function entity 300a, 300b, 300c is configured to perform (optional) action S206:

[0068] S206: The 5GC network function entity 300a, 300b, 300c (such as NRF, BSF, or UDM) receives, from the NEF when the AF is in untrusted mode, registration of a mapping between the UE and the AF.

[0069] As will be further disclosed below with reference to actions 14, 16, 18 of FIG. 5, the AF might itself register the mapping between the UE and the AF when the AF is in trusted mode. Thus, according to some embodiments, when the AF is in trusted mode, the 5GC network function entity 300a, 300b, 300c is configured to perform (optional) action S210:

[0070] S210: The 5GC network function entity 300a, 300b, 300c (such as NRF, BSF, or UDM) receives, from the AF when the AF is in trusted mode, registration of a mapping between the UE and the AF.

[0071] As will be further disclosed below with reference to actions 7, 8, 10 of FIG. 6, the NRF might determine which NEF is serving the UE. Thus, according to some embodiments, when the 5GC network function entity 300a, 300b, 300c is the NRF, the 5GC network function entity 300a, 300b, 300c is configured to perform (optional) actions S212, S214:

[0072] S212: The 5GC network function entity 300a, 300b, 300c determines which NEF is serving the UE.

[0073] S214: The 5GC network function entity 300a, 300b, 300c provides, to the BSF and the UDM, an indication of the NEF that is serving the UE.

[0074] Alternatively, the NEF determines the mapping between the UE and the NEF and provides information of the mapping to the network function entity 300a, 300b, 300c (such as NRF, BSF, or UDM). Thus, according to some embodiments, the 5GC network function entity 300a, 300b, 300c is configured to perform (optional) action S216:

[0075] S216: The 5GC network function entity 300a, 300b, 300c receives registration of a mapping between the UE and the NEF from the NEF.

[0076] Next, three particular embodiments based on at least some of the above disclosed embodiments will be disclosed. In some of these embodiments, different alternatives are covered. In this respect, the notation Option 1, Option 2, and Option 3 is used to identify three different alternatives. Thus, when an action pertaining to Option 1 is performed, neither any action pertaining to Option 2 nor any action pertaining to Option 3 is performed, and vice versa. Thus, only the actions of one of Option 1, Option 2, and Option 3 are performed per alternative.

[0077] One particular embodiment for a registration procedure in the NRF of the NEF and the AF based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signaling diagram of FIG. 4.

[0078] According to this embodiment, the above disclosed 5GC network function entity 300a, 300b, 300c is an NRF 300a.

[0079] 1. The NEF invokes the Nnrf_NFRegister service operation in the NRF, specifying that NFType=NEF, and the UE-ID range (i.e., the range of UE-IDs handled by this NEF instance).

[0080] 2. The NRF acknowledges the registration.

[0081] 3. The AF sends an onboard request to NEF, specifying the AF-ID, and the App-ID.

[0082] 4. The NEF checks whether the AF is trusted or untrusted.

[0083] 5. The NEF acknowledges the onboarding request, including whether the AF is deemed as trusted or untrusted.

[0084] If the AF is in untrusted mode, actions 6 and 7 are performed.

[0085] 6. The NEF registers the AF profile in the NRF, invoking the Nnrf_NFRegister service, and specifying that NFType=AF, the App-ID, and that trust=UNTRUSTED (i.e., an indication that the AF is in untrusted mode).

[0086] 7. The NRF acknowledges the registration.

[0087] If the AF is in trusted mode, actions 8 and 9 are performed.

[0088] 8. The AF registers itself the AF profile in the NRF, invoking the Nnrf_NFRegister service, and specifying that NFType=AF, the App-ID, and that trust=TRUSTED (i.e., an indication that the AF is in trusted mode.

[0089] 9. The NRF acknowledges the registration.

[0090] One particular embodiment for when the mapping between UE and AF instance is stored either in the NRF, the BSF or the UDM, for the AF being in untrusted mode and in trusted mode, respectively, based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signaling diagram of FIG. 5.

[0091] According to this embodiment, Option 1 corresponds to that the above disclosed 5GC network function entity 300a, 300b, 300c is an NRF 300a, Option 2, corresponds to that the 5GC network function entity 300a, 300b, 300c is a BSF 300b, and Option 3 corresponds to that the 5GC network function entity 300a, 300b, 300c is a UDM entity 300c.

[0092] If the AF is in untrusted mode, actions 1 to 13 are performed.

[0093] 1. The AF invokes an API in the default or front-end NEF (e.g. Application QoS, etc.), specifying the AF-ID, the UE-ID, and (optionally) other parameters (e.g. App-ID, . . . ).

[0094] 2. The NEF verifies that the UE-ID is out of its UE-ID range.

[0095] 3. The NEF discovers the NEF (i.e., NEF A) that is serving the UE by invoking the Nnrf_NFDiscovery service in the NRF, specifying that NFtype=NEF, and the UE-ID.

[0096] 4. The NRF responds with the address of the NEF (i.e., of NEF A) whose UE-ID range includes the UE-ID.

[0097] 5. The NEF invokes the same API as in action 1 in the NEF serving the UE, specifying the AF-ID, the UE-ID, the AF Address so that the NEF serving the UE is enabled to communicate with this AF, and (optionally) other parameters (e.g. App-ID, . . . ).

[0098] 6. The NEF (i.e., NEF A) serving the UE responds to the default NEF (i.e., NEF B), specifying the address of the NEF serving the UE.

[0099] 7. The default NEF responds to the AF, specifying the address of the NEF serving the UE. For any subsequent request (on a per UE basis) to the NEF, the AF sends the subsequent request using the address of the NEF serving the UE.

[0100] 8. (Option 1) The NEF serving the UE registers the mapping between UE and AF instance in the NRF by invoking the Nnrf_NFUpdate service, and specifying the AF-ID and the UE-ID. Other parameters might optionally also be registered along the UE-ID, e.g. the App-ID, etc.

[0101] 9. (Option 1) The NRF acknowledges the registration.

[0102] 10. (Option 2) The NEF serving the UE registers the mapping between UE and AF instance in the BSF by invoking the Nbsf_Register service, and specifying that NFtype=AF, the AF-ID, and the UE-ID. Other parameters might optionally also be registered along the UE-ID, e.g. the App-ID, etc.

[0103] 11. (Option 2) The BSF acknowledges the registration.

[0104] 12. (Option 3) The NEF serving the UE registers the AF-UE mapping between UE and AF instance in the UDM by invoking the Nudm_AFRegister service, and specifying that NFtype=AF, the AF-ID, and the UE-ID. Other parameters might optionally also be registered along the UE-ID, e.g. the App-ID, etc.

[0105] 13. (Option 3) The UDM acknowledges the registration.

[0106] If the AF is in trusted mode, actions 14 to 18 are performed.

[0107] 14. (Option 1) The AF registers itself the mapping between UE and AF instance in the NRF by invoking the Nnrf_NFUpdate service, and specifying the AF-ID and the UE-ID. Other parameters might optionally also be registered along the UE-ID, e.g. the App-ID, etc.

[0108] 15. (Option 1) The NRF acknowledges the registration.

[0109] 16. (Option 2) The AF registers itself the mapping between UE and AF instance in the BSF by invoking the Nbsf_Register service, and specifying that NFtype=AF, the AF-ID, and the UE-ID. Other parameters might optionally also be registered along the UE-ID, e.g. the App-ID, etc.

[0110] 17. (Option 2) The BSF acknowledges the registration.

[0111] 18. (Option 3) The AF registers itself the mapping between UE and AF instance in the UDM by invoking the Nudm_AFRegister service, and specifying that NFtype=AF, the AF-ID, and the UE-ID. Other parameters might optionally also be registered along the UE-ID, e.g. the App-ID, etc.

[0112] 19. (Option 3) The UDM acknowledges the registration.

[0113] One particular embodiment for when the mapping between UE and NEF instance is stored either in the NRF, the BSF or the UDM based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signaling diagram of FIG. 6. This particular embodiment only applies when the AF is in untrusted mode.

[0114] According to this embodiment, Option 1 corresponds to that the above disclosed 5GC network function entity 300a, 300b, 300c is a BSF 300b, Option 2, corresponds to that the 5GC network function entity 300a, 300b, 300c is a UDM entity 300c, and Option 3 corresponds to that the 5GC network function entity 300a, 300b, 300c is an NRF 300a.

[0115] 1. The AF invokes an API in the default or front-end NEF (e.g. Application QoS, etc.), specifying the AF-ID, the UE-ID, and (optionally) other parameters (e.g. App-ID, . . . ).

[0116] 2. (Option 1) If the BSF is the entity storing the mapping between UE and NEF instance, the default NEF tries to discover the NEF serving the UE by invoking the Nbsf_Discovery service in the BSF, specifying that NFtype=NEF, and the UE-ID, and (optionally) other parameters (e.g. App-ID, . . . ).

[0117] 3. (Option 1) The BSF responds with the NEF-ID, or an error indication in case there is no NEF instance stored for the specified UE-ID.

[0118] 4. (Option 2) If the UDM is the entity storing the mapping between UE and NEF instance, the default NEF tries to discover the NEF serving the UE by invoking the Nudm_AFDiscovery service in UDM, specifying that NFtype=NEF, and the UE-ID, and (optionally) other parameters (e.g. App-ID, . . . ).

[0119] 5. (Option 2) The UDM responds with the NEF-ID, or an error indication in case there is no NEF instance stored for the specified UE-ID.

[0120] 6. The default NEF invokes the Nnrf_NFDiscovery service in the NRF, specifying that NFtype=NEF, the UE-ID, and (optionally) other parameters (e.g. App-ID, . . . ). (Option 1, Option 2) The default NEF specifies the NEF-ID in case the mapping between UE and NEF instance is stored in the BSF or the UDM. (Option 3) If the mapping between UE and NEF instance is stored in the NRF the field for the NEF-ID is either empty or not present.

[0121] 7. (Optional) If there is no NEF assigned to the UE-ID, the NRF decides which NEF instance is to be assigned to the UE based on the parameters received in the discovery request in action 6.

[0122] 8. (Option 1) If the NRF assigns a NEF to the UE in action 7 and the mapping between UE and NEF instance is stored in the BSF, the NRF registers the mapping between UE and NEF instance in the BSF by invoking the Nbsf_Register service, specifying that NFtype=NEF, the NEF-ID, and the UE-ID, and (optionally) other parameters (e.g. App-ID, . . . ).

[0123] 9. (Option 1) The BSF acknowledges the registration.

[0124] 10. (Option 2) If the NRF assigns a NEF to the UE in action 7 and the mapping between UE and NEF instance is stored in the UDM, the NRF registers the mapping between UE and NEF instance in the UDM by invoking the Nudm_NEFRegister service specifying that NFtype=NEF, the NEF-ID, and the UE-ID, and (optionally) other parameters (e.g. App-ID, . . . ).

[0125] 11. (Option 2) The UDM acknowledges the registration.

[0126] (Option 3) If the mapping between UE and NEF instance is stored in the NRF, the NRF stores internally the UE-ID in the NF Profile of the assigned NEF instance, and (optionally) other parameters (e.g. App-ID, . . . ).

[0127] 12. The NRF responds to the default NEF with the address of the NEF serving the UE.

[0128] 13. The default NEF invokes the same API as in action 1 in the NEF serving the UE, specifying the UE-ID, the AF Address so that the NEF serving the UE is enabled to communicate with this AF, and (optionally) other parameters (e.g. App-ID, . . . ).

[0129] 14. The NEF serving the UE responds to the default NEF.

[0130] 15. The default NEF responds to the AF, specifying the address of the NEF serving the UE. For any subsequent request (on a per UE basis) to the NEF, the AF sends the subsequent request using the address of the NEF serving the UE.

[0131] One particular embodiment for when the NWDAF entity discovers, for data collection, the NEF or AF serving the UE based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signaling diagram of FIG. 7.

[0132] According to this embodiment, Option 1 corresponds to that the above disclosed 5GC network function entity 300a, 300b, 300c is a BSF 300b, Option 2, corresponds to that the 5GC network function entity 300a, 300b, 300c is a UDM entity 300c, and Option 3 corresponds to that the 5GC network function entity 300a, 300b, 300c is an NRF 300a.

[0133] 1. (Option 1) If the BSF is the entity storing the mapping between UE and NEF or AF, the NWDAF tries to discover the NEF or AF serving the UE by invoking the Nbsf_Discovery service in the BSF, specifying that NFtype=NEF or AF, and the UE-ID, and (optionally) other parameters (e.g. App-ID, . . . ).

[0134] 2. (Option 1) The BSF responds with the AF-ID or NEF-ID, or an error indication in case there is no NEF or AF instance stored for the UE-ID.

[0135] 3. (Option 2) If the UDM is the entity storing the mapping between UE and NEF or AF, the NWDAF tries to discover the NEF or AF serving the UE by invoking the Nudm_AFDiscovery service in the UDM, specifying that NFtype=NEF or AF, and the UE-ID, and (optionally) other parameters (e.g. App-ID, . . . ).

[0136] 4. (Option 2) The UDM responds with the AF-ID or NEF-ID, or an error indication in case there is no NEF or AF instance stored for the UE-ID.

[0137] 5. The NWDAF invokes the Nnrf_NFDiscovery service in the NRF, specifying that NFtype=NEF or AF, and (optionally) other parameters (e.g. App-ID, . . . ). (Option 1, Option 2) The NWDAF specifies the AF-ID or NEF-ID in case the mapping between UE and NEF or AF is stored in the BSF or the UDM. (Option 3) If the mapping between UE and NEF or AF is stored in the NRF the field for the AF-ID or NEF-ID is either empty or not present. (Option 3) The NWDAF specifies the UE-ID in case the mapping between UE and NEF or AF is stored in the NRF.

[0138] 6. The NRF responds with the AF address or NEF address. In this respect, if the NWDAF wants to discover an untrusted AF, the NRF checks that the AF profile includes the indication trust=UNTRUSTED, and instead of responding with the AF address responds with the address of the NEF instance that handles the AF.

[0139] If the AF is in untrusted mode, actions 7 to 10 are performed.

[0140] 7. The NWDAF invokes the Nnef_EventsSubscription service in NEF, specifying the UE-ID, and the Event-ID of the metrics to collect, and (optionally), other parameters or filters for the data collection (e.g. App-ID, . . . ).

[0141] 8. The NEF acknowledges the subscription request.

[0142] 9. The NEF invokes the Naf_EventsSubscription service in the AF, specifying the UE-ID, and the Event-ID of the metrics to collect, and (optionally), other parameters or filters for the data collection (e.g. App-ID, . . . ). It is here assumed that the NEF knows the AF address in case it is untrusted.

[0143] 10. The AF acknowledges the subscription request.

[0144] If the AF is in trusted mode, actions 11 and 12 are performed.

[0145] 11. The NWDAF invokes directly the Naf_EventsSubscription service in the AF, specifying the UE-ID, and the Event-ID of the metrics to collect, and (optionally), other parameters or filters for the data collection (e.g. App-ID, . . . ).

[0146] 12. The AF acknowledges the subscription request.

[0147] In summary according to at least some of the herein disclosed embodiments, there has been presented mechanisms allowing the NWDAF to determine which NEF and AF instances are serving a specific UE for data collection purposes. The following alternatives have been disclosed: the UE-ID is registered in the NF profile of the NEF and AF in the NRF (i.e., the above disclosed 5GC network function entity 300a, 300b, 300c is an NRF 300a), or the mapping between UE and NEF or AF instance is registered in the BSF (i.e., the above disclosed 5GC network function entity 300a, 300b, 300c is a BSF 300b), or the mapping between UE and NEF or AF instance is registered in the UDM (i.e., the above disclosed 5GC network function entity 300a, 300b, 300c is a BSF 300c).

[0148] According to at least some of the herein disclosed embodiments, there has also been presented mechanisms for assigning a NEF instance to a UE. According to a first alternative, the NEF registers in NRF the UE-ID range that it handles. Then the NEF assigned to a certain UE-ID is selected based on this range by the NRF. According to a second alternative, the mapping between UE and NEF is stored in the network function entity 300a, 300b, 300b, such as either the NRF, the BSF, or the UDM. The NEF receives the first request related to a UE-ID from the AF and tries to retrieve from NRF, BSF or UDM the NEF instance that serves the UE. If there is no NEF assigned to the UE, the NRF might decides which NEF to assign the UE based on, for example, the NEF UE-ID range, App-IDs, NEF APIs the AF is interested to, and metrics that the AF indicates that it can provide for NWDAF data collection or NEF parameter provisioning procedures.

[0149] According to at least some of the herein disclosed embodiments, there has also been presented mechanisms for AF and NEF profile registration in the NRF. The NEF might register the UE-ID range that it will serve. If the AF is trusted the AF might registers its AF profile directly in the NRF. If the AF is untrusted the AF on-boards to the NEF and the NEF registers the AF profile in the NRF.

[0150] According to at least some of the herein disclosed embodiments, there has also been presented mechanisms for determining whether the AF is trusted (whereby NFs can communicate directly with the AF) or untrusted (whereby NFs communicate with the AF via the NEF). The NEF might determine whether the AF is trusted or untrusted. Information of whether the AF is trusted or untrusted is included in the AF profile in the NRF. If the AF is untrusted, the NRF responds with the corresponding NEF instance address in the AF discovery request.

[0151] FIG. 8 schematically illustrates, in terms of a number of functional units, the components of an NWDAF entity 200 according to an embodiment. Processing circuitry 210 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1210a (as in FIG. 12), e.g. in the form of a storage medium 230. The processing circuitry 210 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

[0152] Particularly, the processing circuitry 210 is configured to cause the NWDAF entity 200 to perform a set of operations, or actions, as disclosed above. For example, the storage medium 230 may store the set of operations, and the processing circuitry 210 may be configured to retrieve the set of operations from the storage medium 230 to cause the NWDAF entity 200 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus the processing circuitry 210 is thereby arranged to execute methods as herein disclosed.

[0153] The storage medium 230 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0154] The NWDAF entity 200 may further comprise a communications interface 220 for communications with other entities, functions, nodes and devices of the communication network 100. As such the communications interface 220 may comprise one or more transmitters and receivers, comprising analogue and digital components.

[0155] The processing circuitry 210 controls the general operation of the NWDAF entity 200 e.g. by sending data and control signals to the communications interface 220 and the storage medium 230, by receiving data and reports from the communications interface 220, and by retrieving data and instructions from the storage medium 230. Other components, as well as the related functionality, of the NWDAF entity 200 are omitted in order not to obscure the concepts presented herein.

[0156] FIG. 9 schematically illustrates, in terms of a number of functional modules, the components of an NWDAF entity 200 according to an embodiment. The NWDAF entity 200 of FIG. 9 comprises a number of functional modules; a provide module 210a configured to perform action S102, and a receive module 210b configured to perform action S104. The NWDAF entity 200 of FIG. 9 may further comprise a number of optional functional modules, such as any of a receive module 210c configured to perform action S106, a provide module 210d configured to perform action S108, a receive module 210e configured to perform action S110, a provide module 210f configured to perform action S112, and a receive module 210fg configured to perform action S114.

[0157] In general terms, each functional module 210a-210g may be implemented in hardware or in software. Preferably, one or more or all functional modules 210a-210g may be implemented by the processing circuitry 210, possibly in cooperation with the communications interface 220 and/or the storage medium 230. The processing circuitry 210 may thus be arranged to from the storage medium 230 fetch instructions as provided by a functional module 210a-210g and to execute these instructions, thereby performing any actions of the NWDAF entity 200 as disclosed herein.

[0158] FIG. 10 schematically illustrates, in terms of a number of functional units, the components of a 5GC network function entity 300a, 300b, 300c according to an embodiment. Processing circuitry 310 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1210b (as in FIG. 12), e.g. in the form of a storage medium 330. The processing circuitry 310 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

[0159] Particularly, the processing circuitry 310 is configured to cause the 5GC network function entity 300a, 300b, 300c to perform a set of operations, or actions, as disclosed above. For example, the storage medium 330 may store the set of operations, and the processing circuitry 310 may be configured to retrieve the set of operations from the storage medium 330 to cause the 5GC network function entity 300a, 300b, 300c to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus the processing circuitry 310 is thereby arranged to execute methods as herein disclosed.

[0160] The storage medium 330 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0161] The 5GC network function entity 300a, 300b, 300c may further comprise a communications interface 320 for communications with other entities, functions, nodes and devices of the communication network 100. As such the communications interface 320 may comprise one or more transmitters and receivers, comprising analogue and digital components.

[0162] The processing circuitry 310 controls the general operation of the 5GC network function entity 300a, 300b, 300c e.g. by sending data and control signals to the communications interface 320 and the storage medium 330, by receiving data and reports from the communications interface 320, and by retrieving data and instructions from the storage medium 330. Other components, as well as the related functionality, of the 5GC network function entity 300a, 300b, 300c are omitted in order not to obscure the concepts presented herein.

[0163] FIG. 11 schematically illustrates, in terms of a number of functional modules, the components of a 5GC network function entity 300a, 300b, 300c according to an embodiment. The 5GC network function entity 300a, 300b, 300c of FIG. 11 comprises a number of functional modules; a receive module 310i configured to perform action S218, and a provide module 310j configured to perform action S220. The 5GC network function entity 300a, 300b, 300c of FIG. 11 may further comprise a number of optional functional modules, such as any of a receive module 310a configured to perform action S202, a receive module 310b configured to perform action S204, a receive module 310c configured to perform action S206, a receive module 310d configured to perform action S208, a receive module 310e configured to perform action S210, a determine module 310f configured to perform action S212, a provide module 310g configured to perform action S214, and a receive module 310h configured to perform action S216.

[0164] In general terms, each functional module 310a-310j may be implemented in hardware or in software. Preferably, one or more or all functional modules 310a-310j may be implemented by the processing circuitry 310, possibly in cooperation with the communications interface 320 and/or the storage medium 330. The processing circuitry 310 may thus be arranged to from the storage medium 330 fetch instructions as provided by a functional module 310a-310j and to execute these instructions, thereby performing any actions of the 5GC network function entity 300a, 300b, 300c as disclosed herein.

[0165] The NWDAF entity 200 and/or the 5GC network function entity 300a, 300b, 300c may be provided as a standalone device or as a part of at least one further device. Alternatively, functionality of the NWDAF entity 200 and/or the 5GC network function entity 300a, 300b, 300c may be distributed between at least two devices, or nodes. In general terms, instructions that are required to be performed in real time may be performed in a device, or node, operatively closer to the cell than instructions that are not required to be performed in real time. Thus, a first portion of the instructions performed by the NWDAF entity 200 and/or the 5GC network function entity 300a, 300b, 300c may be executed in a first device, and a second portion of the instructions performed by the NWDAF entity 200 and/or the 5GC network function entity 300a, 300b, 300c may be executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the NWDAF entity 200 and/or the 5GC network function entity 300a, 300b, 300c may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by an NWDAF entity 200 and/or the 5GC network function entity 300a, 300b, 300c residing in a cloud computational environment. Therefore, although a single processing circuitry 210, 310 is illustrated in FIGS. 8 and 10 the processing circuitry 210, 310 may be distributed among a plurality of devices, or nodes. The same applies to the functional modules 210a-210g, 310a-310j of FIGS. 9 and 11 and the computer programs 1220a, 1220b of FIG. 12.

[0166] FIG. 12 shows one example of a computer program product 1210a, 1210b comprising computer readable means 1230. On this computer readable means 1230, a computer program 1220a can be stored, which computer program 1220a can cause the processing circuitry 210 and thereto operatively coupled entities and devices, such as the communications interface 220 and the storage medium 230, to execute methods according to embodiments described herein. The computer program 1220a and/or computer program product 1210a may thus provide means for performing any actions of the NWDAF entity 200 as herein disclosed. On this computer readable means 1230, a computer program 1220b can be stored, which computer program 1220b can cause the processing circuitry 310 and thereto operatively coupled entities and devices, such as the communications interface 320 and the storage medium 330, to execute methods according to embodiments described herein. The computer program 1220b and/or computer program product 1210b may thus provide means for performing any actions of the 5GC network function entity 300a, 300b, 300c as herein disclosed.

[0167] In the example of FIG. 12, the computer program product 1210a, 1210b is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 1210a, 1210b could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 1220a, 1220b is here schematically shown as a track on the depicted optical disk, the computer program 1220a, 1220b can be stored in any way which is suitable for the computer program product 1210a, 1210b.

[0168] The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept, as defined by the appended list of claims.