WO2020191513A1

WO2020191513A1 - Callback service in a core network

Info

Publication number: WO2020191513A1
Application number: PCT/CN2019/079189
Authority: WO
Inventors: Yunjie Lu; Yong Yang
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2019-03-22
Filing date: 2019-03-22
Publication date: 2020-10-01

Abstract

Disclosed herein is a method performed in a second core network function, NF, entity 520 and a corresponding core network NF 520 in a service based core network of a communications system 200 for handling a callback, CB, service; the method comprises: sending a service registration request towards a core network repository function entity 530 to register a CB service for at least one NF service, which request comprises at least one repository CB service instance that indicates a resource at the second NF entity 520 to which a first core NF entity 510 can send a notification to indicate an event associated with a NF service to be produced by the first NF entity 510 for the second NF entity 520; sending a service request towards the first NF entity 510, which service request indicates an expected NF service to be produced by the first NF entity 510 and comprises CB service instance information that indicates a requested CB service instance to be discovered among said at least one repository CB service instance by the first NF entity 510 for the expected NF service.

Description

CALLBACK SERVICE IN A CORE NETWORK

TECHNICAL FIELD

The present disclosure relates to a method of handling callback service in core network of a wireless communication system.

BACKGROUND

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. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. 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. Other objectives, features, and advantages of the enclosed embodiments will be apparent from the following description.

Figure 1 illustrates an exemplifying wireless communication system 100 represented as a 5G network architecture comprising a Radio Access Network (RAN) or an Access Network (AN) and a Core network (CN) , in which CN the interaction between any two Network Functions (NFs) is represented by a point-to-point reference point/interface.

Seen from the radio access side the 5G network architecture comprises a plurality of User Equipment (UEs) connected to either a Radio Access Network (RAN) or an Access Network (AN) as well as an Access and Mobility Management Function (AMF) . Typically, the R (AN) comprises base stations, e.g. such as evolved Node Bs (eNBs) or 5G base stations (gNBs) or similar. Seen from the Core Network side, the 5G core NFs shown in Figure 1 include a Network Slice Selection Function (NSSF) , an Authentication Server Function (AUSF) , a Unified Data Management (UDM) , an Access and Mobility Management Function (AMF) , a Session Management Function (SMF) , a Policy Control Function (PCF) , an Application Function (AF) .

The reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between UE and AMF. The N2 and N3 reference points are defined to carry signaling between R (AN) and AMF and between R (AN) and UPF respectively. The N11 reference point is defined to carry signaling between AMF and SMF. The N4 reference point is defined to carry signaling between SMF and UPF. The N9 reference point is defined to carry signaling between different UPFs and the N14 reference point is defined to carry signaling between different AMFs. The reference points N15 and N7 are defined to carry signaling between PCF and AMF and SMF respectively. The N12 reference point is defined to carry signaling between AMF and AUSF. The N8 and N10 reference points are defined to carry signaling between UDM and AMF and SMF respectively. The N13 reference point is defined to carry signaling between AUSF and UDM. The N22 reference point is defined to carry signaling between NSSF and AMF.

The 5G core network aims at separating user plane and control plane. The user plane carries user traffic (e.g. user data) while the control plane carries signaling in the network. In Figure 1, the UPF is in the user plane while the other NFs, i.e., AMF, SMF, PCF, AF, AUSF, and UDM, are in the control plane. Separating the user plane and the control plane allows the resources in each plane to be scaled independently. It also allows UPFs to be deployed separately from control plane functions in a distributed fashion. For example, an UPF may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.

The NFs in the 5G core network architecture are independent modularized functions, which allows independent evolution and scaling. Modularized function design enables the 5G core network to support various services in a flexible manner.

Each NF in the core network interacts with another NF directly, but it is possible to use intermediate functions to route messages from one NF to another NF.

Figure 2 illustrates an exemplifying wireless communication system 200 represented as a 5G network architecture that uses service-based interfaces (SBIs) between the NFs in the control plane, instead of the point-to-point reference points/interfaces used in the 5G network architecture of Figure 1. The NFs described above with reference to Figure 1 correspond to the NFs shown in Figure 2. The service (s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the SBI. In Figure 2 the SBIs are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the SBI of the AMF and Nsmf for the SBI of the SMF etc. The Network Exposure Function (NEF) and the Network Repository Function (NRF) in Figure 2 are not shown in Figure 1 discussed above. However, it should be clarified that all NFs depicted in Figure 1 can interact with the NEF and the NRF of Figure 2 as required, though not explicitly indicated in Figure 1. A main difference between the point-to-point architecture in figure 1 and the service-based architecture in figure 2 is that the service-based architecture doesn’t us predefined point-to-point interfaces between the NFs. Instead, a NF in the service-based architecture queries the NRF to discover and communicate with other NFs via the SBIs.

Some properties of the NFs shown in Figures 1-2 may be described in the following manner. The AMF provides UE-based authentication, authorization and mobility management, etc. A UE even if using multiple access technologies is basically connected to a single AMF, since the AMF is independent of the access technologies. The SMF is responsible for session management and allocates IP addresses to UEs and selects and controls the UPF for data transfer with respect to the UEs. If a UE has multiple sessions, different SMFs may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF provides information on the packet flow to PCF responsible for policy control in order to support Quality of Service (QoS) . Based on the information, PCF determines policies about mobility and session management to make AMF and SMF operate properly. The AUSF supports authentication function for UEs and thus stores data for authentication of UEs or similar while UDM stores subscription data of UEs. The Data Network (DN) , not part of the 5G core network, provides Internet access or operator services and similar. The NRF supports service discovery function. It receives NF Discovery Request from NF instances, and provides the information of the discovered NF instances to the requesting NF instance. Also, the NRF maintains the NF profile of available NF instances and their supported services.

An NF may 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., a cloud infrastructure.

A number of 5G core network NFs of different types are always instantiated per default in the 5G core network, e.g. such as an AMF, a NRF, a PCF and a SMF etc. Other 5G core network NFs may be instantiated as needed and several NFs of the same type can also be instantiated if required, e.g. to distribute load to additional NF (s) of the same typ. Thus, a NF instance may be seen as an example or a specimen of a certain NF. Similarly, NF service instance may be seen as an example or a specimen of a certain NF service. Herein, the terms NF and NF instance are used interchangeably and also the terms NF service and NF service instance are used interchangeably, unless otherwise expressly stated or is apparent from the context in which the terms are used.

Figure 3 is a schematic illustration of a core network function NF1 (e.g. a AMF) that supports one or more NF service (s) , e.g. NF session A and NF sessions P1 to Pn. Thus, NF1 can act as a NF service producer of one or more NF services A and P1 to Pn. The services supported by NF1 may be consumed by other NFs (e.g a SMF or a UDM, a PCF or a NEF etc. ) acting as service consumers. In addition, NF1 in figure 3 acts as a NF service consumer of at least one NF service C1 and possibly for one or more NF services service C1 to Cn that are produced by other NFs (e.g. a SMF or a NEF etc. ) in the core network.

Generally, a NF service offers a capability to authorized NF consumers. A NF may offer different capabilities and thus different NF services to other NF consumers. Each NF service that is offered by a NF is self-contained, reusable and uses management schemes independently of other NF services offered by the same NF (e.g. for scaling, healing, etc) . The NF services may e.g. include performing an action and/or providing information. More details about the NF services supported by various core network NF types can e.g. be found in 3GPP TS 23.501 clause 7.2.

Figure 4 is a schematic signaling diagram illustrating an example of the network function service framework in the service based 5G core network. The framework comprises:

1) a NF service registration procedure

2) a NF service discovery and authorization procedure, and

3) a NF service request-response or NF service subscribe-notify procedure.

1) Registration

The core network NF instances in the service based 5G core network register their NF profiles at the NRF. Thus, NF1 (e.g. a AMF) sends a Registration Request to the NRF in action 400a, which request comprises the NF profile of the registering NF1. The NF profile is typically included in the request as a JavaScript Object Notation (JSON) document or similar. The NF profile indicates the NF service (s) that is supported by the registering NF instance. In this example it is assumed that the registering NF1 supports a NF service labeled NF service A. Generally, a NF profile may comprise one or more of the following items for the registering NF: NF type, Fully Qualified Domain Name (FQDN) or IP address, Name (s) of supported service (s) , Endpoint information of instance (s) of each supported service and possibly other service parameter. In action 400b the NRF stores the NF profile of the registering NF1 and preferably marks the NF instance (i.e. NF1) as available. The NRF may then send a Registration Response to NF1 in action 400c, which response may include the registered NF profile as a confirmation of the registration made by the NRF.

The registration may take place when the NF instance becomes operative for the first time or upon an activation of an individual NF service within the NF instance, e.g. triggered after a scaling operation. The NF instance may register/expose one or more NF services. The information registered for an individual NF service may e.g. indicate security related information to be used for authorizing a discovering NF instance, e.g. security information that indicates the NFs that are allowed to discover the individual NF service, e.g. the type of NFs or the particular NFs of a certain type that are allowed to discover the NF service in question. However, known art NFs that does not produce/support any NF service will not register any service at the NRF. Thus, an NF instance that only consumes one or more NF services will not register anything at the NRF.

2) Discovery and Authorization

When a NF instance in the service based 5G core network intends to consume a NF service supported by another NF instance it will initiate a NF service discovery procedure with the NRF for the NF service in question. Thus, NF2 (e.g. a SMF) sends a Discovery Request to the NRF in action 402a, which request comprises discovery information. The discovery information may be included in the request as a JSON document or similar. The discovery information indicates the expected service to be consumed by the discovering NF (e.g. NF service A mentioned above) . Preferably, the discovery information indicates the service name or similar of the expected NF service. Additionally or alternatively, the discovery information may indicate one or more of: the NF type of the expected NF (i.e. the type of NF that is expected to produce the expected NF service) and/or the NF type of the discovering NF. Generally, the NF type may e.g. be any of NSSF, NEF, AUSF, AMF, PCF, SMF, UDM or AF or similar, unless the context in which the NF type is mentioned indicates otherwise.

The NRF authorizes the discovery request by determining –based on the discovery information provided in the discovery request and preferably also based on the profile registered by relevant expected target NF instance (s) –whether the discovering NF (i.e. the potential service consumer) is authorized to discover the expected NF service and/or NF instance (s) expected to produce the expected service. The discovery and authorization by the NRF is exemplified by action 402b in figure 4, wherein the expected target NF instance is NF1 and the potential service consumer is NF2.

For example, if the expected NF instance (s) or NF service instance (s) are deployed in a certain network slice, the NRF may authorize the discovery request according to the discovery configuration of the Network Slice, e.g. the expected NF instance (s) may only be discoverable by the NF in the same network slice etc.

When authorized, the NRF determines a set of one or more discovered NF instance (s) and/or NF service instance (s) that supports the expected service and sends a Discovery Request Response to the requester NF (service consumer) . Thus, the NRF sends a Discovery Request Response to NF2 in action 402c, which response comprises repository information indicating one or more discovered NF instance (s) and/or NF service instance (s) that supports the expected service, i.e. that can produce the expected service. The repository information may e.g. indicate one or more of: FQDN, IP address and/or endpoint addresses (e.g. Uniform Resource Locators (URLs) or similar) for said one or more discovered NF instance (s) and/or NF service instance (s) .

3) Request-Response/Subscribe-Notify

To invoke a requested NF service that has been discovered and authorized by the NRF, the interaction between the consumer NF and the producer NF in the service based 5G core network typically follows one of two mechanisms –i.e. the request-response mechanism or subscribe-notify mechanism, as briefly outlined below:

- Request-Response: A control plane NF (service producer) can be requested by another control plane NF (service consumer) to produce NF service that the other requesting NF has previously discovered. Thus, the service consumer NF2 (previously the discovering NF) sends a NF Service Request to the service producer NF1 in action 404a, preferably based on the response previously received in action 402c. The NF Service Request comprises request information that indicates the requested NF service (e.g. NF service A mentioned above) to be produced/provided by the receiving service producer NF1. The request information may e.g. indicate the service name or similar of the requested NF service. Additionally or alternatively, the request information may indicate one or more of: a FQDN, an IP address and/or endpoint addresses (e.g. URLs or similar) for a requested NF service instance.

In the request-response mechanism, the communication is one-to-one between two NFs (consumer and producer) . A one-time response from the producer NF to the requesting consumer NF is expected within a certain timeframe. Thus, NF1 sends a NF Service Response to NF2 in action 404b, which response comprises NF service results that indicates the result of the NF service produced by NF1 in response to the request received in action 404a. In order to fulfil the request, the producing NF may in turn consume NF services from other NFs.

Some request-response operations may be designed to allow the invocation of a NF Service Request such that the response can be received asynchronously. If the NF service consumer when sending a NF Service Request in action 404a cannot expect to receive an immediate final response in action 404b, the service consumer may provide a callback (CB) reference that indicates a resource at the requesting NF consumer to which the final response shall be sent or notified. Typically, the callback reference is a Uniform Resource Identifier (URI) or similar. The service provider, when receiving a request that contains a CB reference for final result notification, may then return an immediate "202 Accepted" (not shown in figure 4) , and at a later point in time notify the service consumer in action 404b about the final result using the received callback URI or similar.

- Subscribe-Notify: Subscribe/Notify communication between control plane NFs can be used to keep involved NFs (service consumers) informed of data changes or events that occur at another NF (service producer) . Here, the NF consumer subscribes to a previously discovered NF service that is supported by a NF producer by sending a subscription request to the NF producer. Thus, the service consumer NF2 (previously the discovering NF) sends a NF Service Subscribe Request to the service producer NF1 in action 406a, preferably based on the response received in action 402c. The NF Service Subscribe Request comprises request information that indicates the requested NF service (e.g. NF service A mentioned above) to be produced/provided by the receiving service producer NF1. The request information may e.g. indicate the service name or similar of the requested NF service. Additionally or alternatively, the request information may indicate one or more of: a FQDN, an IP address and/or endpoint addresses (e.g. URLs or similar) for a requested NF service instance. Additionally, the request information may include notification requests for periodic updates or notification triggered through certain events (for example, the information requested gets changed, reaches certain threshold, etcetera) and possibly additional filter criteria. Multiple control plane NFs may subscribe to the same control plane NF Service.

The NF Service Subscribe Request may also comprise a CB reference (e.g. a URI) to be used by NF service producer to notify the NF service consumer (s) about the subscribed change or event as will be elaborated below. The CB reference may indicate a resource at the NF consumer to which the notification shall be sent.

When a change/event that matches the request information (e.g. matches a filter criteria or similar in the request information) occurs at the NF service producer, then the NF service producer sends a notification to the service NF consumer (s) that has/have subscribed to the NF service in question. A notification is a message that contains information about the change/event. Thus, NF1 sends a NF Service Notification to NF2 in action 406b. The NF Service Notification comprises NF service results indicating the result from the NF service produced by NF1 in response to the subscription request received in action 406a.

However, the NF service producer uses the CB reference (e.g. URI) without any access control when it sends NF service responses or NF service notifications to the NF service consumer. This means that the system is vulnerable to denial-of-service (DoS) or distributed-denial-of-service (DDoS) attacks on the notification access points, which is very dangerous for commercial networks. For example, if the NF service request and/or NF service subscription comprising the CB reference (e.g. URI) in question is intercepted or otherwise obtained by a malicious network function, the it can be used to send an overwhelming amount of NF service responses or NF service notifications to the NF service consumer with the effect that the NF service consumer becomes overloaded.

Moreover, assume that the old NF service consumer (e.g. NF2 in figure 4) changes to a new NF service consumer, e.g. due to a failure or due to mobility causing a change of PLMN or similar. A failure or a change of PLMN that is not properly handled may result in that the original CB reference (e.g. URI) that was provided by the old NF service consumer is no longer valid, since the original CB reference points to the old NF service consumer while the callback notification (e.g. actions 404b or 406b in figure 4) should be sent to the new NF service consumer and not to the old NF service consumer.

SUMMARY

In view of the above there is a need for an improved handling of callback services in a core network. In particular, there is a need for an improved access authorization for callback notifications. In addition or alternatively, there is a need for an easier handling of inter-PLMN callback notifications. In addition or alternatively, there is a need for an easier handling of a backup callback notification in case of failure or similar in the original NF consumer.

One embodiment accomplishes at least a part of this by being directed to a method performed in a second core network function, NF, entity in a service based core network of a communications system for handling a callback, CB, service; the method comprises: sending a service registration request towards a core network repository function entity to register a CB service for at least one NF service, which request comprises at least one repository CB service instance that indicates a resource at the second NF entity to which a first core NF entity can send a notification to indicate an event associated with a NF service to be produced by the first NF entity for the second NF entity; and sending a service request towards the first NF entity, which service request indicates an expected NF service to be produced by the first NF entity and comprises CB service instance information that indicates a requested CB service instance to be discovered among said at least one repository CB service instance by the first NF entity for the expected NF service.

Another embodiment accomplishes at least a part of this by being directed to a method performed in a first core network function, NF, entity in a service based core network of a communications system for handling a callback, CB, service; the method comprises: -receiving a service request sent by a second core network function, NF, entity for producing an expected NF service for the second NF entity, which service request indicates the expected NF service and comprises CB service instance information that indicates a requested CB service instance to be discovered by the first NF entity for the expected NF service; sending a discovery request towards a core network repository function entity to discover the indicated requested CB service instance among at least one repository CB service instance that has been registered by the second NF entity and that indicates a resource at the second NF entity to which a first core NF entity can send a notification to indicate an event associated with a NF service to be produced by the first NF entity for the second NF entity; receiving a discovery request response sent by the core network repository function entity, which response comprises the requested CB service instance that indicates the resource at the second NF entity to which the first NF entity shall send a notification to indicate an event associated with the expected NF service.

Another embodiment accomplishes at least a part of this by being directed to a second core network function, NF, entity to be used in a service based core network of a communications system for handling a callback, CB, service; the second core NF entity is configured to operatively: send a service registration request towards a core network repository function entity to register a CB service for at least one NF service, which request comprises at least one repository CB service instance that indicates a resource at the second NF entity to which a first core NF entity can send a notification to indicate an event associated with a NF service to be produced by the first NF entity for the second NF entity; send a service request towards the first NF entity, which service request indicates an expected NF service to be produced by the first NF entity and comprises CB service instance information that indicates a requested CB service instance to be discovered among said at least one repository CB service instance by the first NF entity for the expected NF service.

Another embodiment accomplishes at least a part of this by being directed to a first core network function, NF, entity to be used in a service based core network of a communications system for handling a callback, CB, service; the first core NF entity is configured to operatively: receive a service request sent by a second core network function, NF, entity to produce an expected NF service for the second NF entity, which service request indicates the expected NF service and comprises CB service instance information that indicates a requested CB service instance to be discovered by the first NF entity for the expected NF service; send a discovery request towards a core network repository function entity to discover the indicated requested CB service instance among at least one repository CB service instance that has been registered by the second NF entity and that indicates a resource at the second NF entity to which a first core NF entity can send a notification to indicate an event associated with a NF service to be produced by the first NF entity for the second NF entity; receive a discovery request response sent by the core network repository function entity, which response comprises the requested CB service instance that indicates the resource at the second NF entity to which the first NF entity shall send a notification to indicate an event associated with the expected NF service.

Now, since the CB service instance (s) is/are registered in the network repository function entity (e.g. NRF 530) , there is no need for a NF service consumer (e.g. NFB 520) to explicitly provide a CB reference (e.g. URI) or similar to the NF service producer (e.g. NFA 510) . Also, since the NF service provider must use a discovery procedure towards the network repository function for the CB service it follows that the NF service provider cannot use the CB service unless the network repository function authorizes the NF service provider. All in all, this eliminates or reduces the risk for DoS and/or DDoS or similar. Moreover, since the CB service instance (s) for a NF service consumer is/are registered in the network repository function entity (e.g. NRF 530) , then any new NF service consumer can use the normal discovery procedures etc. to discover the CB service instance (s) for the old NF service consumer in the network repository function. In addition, the NF service producer may proactively discover CB services supported by the NF service consumer and take different actions in response and when delivering the CB notifications. e.g. reject the subscription creation if the NF service consumer doesn’t support certain CB services; deliver additional/supplementary notification to consumer etc.

BRIEF DESCRIPTION OF THE DRAWINGS

The objects, advantages and characteristics of the present disclosure will be more apparent, according to descriptions of preferred embodiments in connection with the drawings, on which:

Figure 1 illustrates a wireless communication system represented as a 5G network architecture composed of NFs using point to point reference points or interfaces;

Figure 2 illustrates a 5G network architecture using service-based interfaces (SBIs) between the NFs in the control plane, instead of the point-to-point reference points/interfaces used in the 5G network architecture of Figure 1;

Figure 3 is a schematic illustration of a core network function NF1 (e.g. a AMF) that supports one or more NF services, e.g. NF service A and NF service P1 to Pn;

Figure 4 is a schematic signaling diagram illustrating an example of the network function service framework in the service based 5G core network;

Figure 5 is a schematic illustration of a first core network function NFA (e.g. a AMF) that acts as a NF service producer and a callback service consumer;

Figure 6a is a schematic signaling diagram illustrating some example embodiment of the present disclosure;

Figure 6b is a schematic flowchart illustrating some example embodiment of the present disclosure;

Figure 6c is a schematic flowchart illustrating some example embodiment of the present disclosure;

Figure 7 is a schematic block diagram of a core network function entity 700 according to some embodiments of the present disclosure;

Figure 8 is a schematic block diagram of the core NF entity 700 according to some other embodiments of the present disclosure.

.

DETAILED DESCRIPTION

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

Radio Node: As used herein, a “radio node” is either a radio access node or a wireless device.

Radio Access Node: As used herein, a “radio access node” or “radio network node” is any node in a RAN of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a 3GPP 5G NR network or an eNB in a 3GPP LTE network) , a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like) , and a relay node.

Core Network Function Entity: As used herein, a “core network function entity” is any type of entity in a core network. The core network function entities involved in the exemplifying procedures shown herein may e.g. be a NSSF, NEF, AUSF, AMF, PCF, SMF, UDM or AF or similar, unless the context in which the network functions entities are mentioned indicates otherwise.

Wireless Device: As used herein, a “wireless device” is any type of device that has access to (i.e., is served by) a cellular communications network by wirelessly transmitting and/or receiving signals to a radio access node (s) . Some examples of a wireless device include, but are not limited to, a UE in a 3GPP network and a Machine Type Communication (MTC) device.

Network Node: As used herein, a “network node” is any node that is either part of the RAN or the core network of a cellular communications network/system.

Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

Figure 5 is a schematic illustration of an exemplifying first core network function NFA (e.g. a AMF or some other suitable core NF entity) that supports at least one NF service labeled NF service A. Thus, NFA acts as a NF service producer for at least one NF service. The first NFA may support one or more other NF services P1 to Pn. The NFA may act as a NF service consumer of one or more NF services service C1 to Cn produced by other core NFs. This is the same or similar as for the core NF1 and the corresponding NF services discussed above with respect to figures 3 and 4.

In addition, NFA acts as a consumer of a callback service (CB service) that is associated with at least one a NF service that is produced or is to be produced by NFA, e.g. a CB service A that is associated with NF service A. The first NFA may act as a producer of other CB services associated with other NF services supported by NFA, e.g. CB service n.

Further, figure 5 illustrates a second core network function NFB (e.g. a SMF or some other suitable core NF entity) that acts as a consumer of NF service (s) , e.g. NF service A. Indeed, NFB may act as a NF service consumer of one or more other NF services service and/or one or more other CB services, but that is not shown in figure 5.

In addition, NFB acts as a producer of a callback service (CB service) for at least one a NF service that is produced or is to be produced by NFA, e.g. a CB service A for NF service A. The second NFB may act as a producer of other CB services associated with other NF services supported by NFA, but that is not shown in figure 5..

Figure 6a is a schematic signaling diagram illustrating an exemplifying NF service registration procedure, an exemplifying NF service discovery and an exemplifying authorization procedure for a particular NF service (e.g. NF service A) . This is the same or similar as the corresponding procedures discussed above with respect to figure 4. The entities involved in the exemplifying procedures shown in figure 6a are a first core network function entity NFA 510 (e.g. a AMF) , a second core network function entity NFB 520 (e.g. a SMF) and a core network repository function entity 530 (e.g. a NRF or similar) . The first and second core network function entities may e.g. be a NSSF, NEF, AUSF, AMF, PCF, SMF, UDM or AF or similar, unless the context in which the network functions entities are mentioned indicates otherwise.

In addition, figure 6a illustrates a registration procedure for a callback service (CB service) wherein the second core network function entity NFB 520 sends a CB service registration request towards the core network repository function entity 530 for registering a CB service for at least one NF service. The request comprises at least one CB reference that can be used by the first core network function entity NFA 510 to identify at least one resource at the second NFB 520 to which the first NFA 510 can send a notification to indicate an event associated with a NF service to be produced by the first NFA 510 for the second NFB 520.

Moreover, figure 6a illustrates a callback discovery procedure wherein the first NFA 510 sends (510a) a CB Discovery Request towards the core network repository function entity 530 to request a CB reference that can be used by the first NFA 510 to identify at least one resource at the second NFB 520 to which the first NFA 510 can send a notification to indicate an event associated with an expected NF service to be produced by the first NFA 510 for the second NFB 520. The first NFA 510 then receives a Discovery Request Response sent by the core network repository function entity 530, which response comprises a CB reference that can be used by the first NFA 510 to identify at least one resource at the second NFB 520 to which the first NFA 510 can send a notification to indicate an event associated with the expected NF service.

The exemplifying signaling diagram comprises the following actions:

Action 500a

The first core network function entity NFA 510 sends a NF service registration request towards the network repository function entity 530 for registering at least one NF service. The request comprises a NF profile of the registering NFA 510. The NF profile indicates one or more NF service (s) that is supported by the registering NFA 510, e.g. a NF service labeled NF service A. Generally, a NF profile may comprise one or more of the following items for the registering NF: NF type, FQDN or IP address, Names of supported service (s) , e.g. such as NF Service A, Endpoint information of instance (s) of each supported service and possibly other service parameter.

The core network repository function entity 530 may e.g. be a NRF or a similar repository function entity. The network repository function entity 530 supports a service discovery function and maintains the NF profile of available NF instances and their supported services. It is preferred that the network repository function entity 530 or similar is configured to operatively receive a registration of a NF profile of a NF instance, to receive Discovery Requests for a service from a NF instance and to provide Discovery Request Response comprising information about the requested service to the discovering/requesting NF instance.

The registration in action 500a may take place when NFA 510 becomes operative for the first time or upon an activation of an individual NF service within NFA 510, e.g. triggered after a scaling operation. NFA 510 may register/expose one or more NF services.

The information registered by NFA 510 for an individual NF service (e.g. NF Service A) may e.g. indicate security related information to be used for authorizing a discovering NF instance, e.g. security information that indicates the NFs that are allowed to discover the individual NF service, e.g. the type of NFs or the particular NFs of a certain type that are allowed to discover the NF service in question. More details about NF services that are supported by various core network functions such as NFA 510 and similar can e.g. be found in 3GPP TS 23.501 clause 7.2.

Action 500a corresponds to action 400a discussed above with reference to figure 4.

Action 500b

The NRF 530 or similar stores the NF profile of the registering NFA 510. Also, it is preferred that the NRF 530 marks the NF instance (i.e. NFA 510) as available. For example, available to be discovered by other core network function entities, e.g. such as NFB 520. This action corresponds to action 400b discussed above with reference to figure 4.

Action 500c

The NRF 530 or similar may, in response to the service registration request received in Action 500a, send a service registration response to NFA 510, e.g. a NF Service Registration Response. The response may include a copy of the registered NF profile of NFA 510 as a confirmation of the registration made by the NRF 530. This action corresponds to action 402c discussed above with reference to figure 4.

Action 502a

The second core network function entity NFB 520 sends a service registration request towards the NRF 530 for registering one or more CB service (s) , each preferably for at least one NF service. The request comprises at least one repository CB service instance that indicates a resource at the second NFB 520 to which another network function entity such as the first NFA 510 can send a notification to indicate an event associated with a NF service to be produced by the other (e.g. NFA 510) for the second NFB 520.

The repository CB service instance may identify a single resource at the second NFB 520 to which other network function entities (e.g. NFA 510) can send notifications to indicate events associated with all NF services to be produced by the other network function entities such as the first NFA 510.

The CB service registration request may comprise a plurality of repository CB service instances that each can be used by other network function entities (e.g. NFA 510) to identify an individual resource at the second NFB 520 to which the other network function entities (e.g. NFA 510) can send a notification to indicate an event associated with a corresponding individual NF service to be produced by the other network function entities for the second NFB 520.

The repository CB service instance may comprise address information or endpoint information that indicates a resource at the second NF entity (520) . The address information or endpoint information may e.g. correspond to an IP address or URI or URL or similar. One single NF service may be associated with the address information or endpoint information comprised by the CB service instance. Alternatively, a plurality of NF services may be associated with the address information or endpoint information comprised by the CB service instance.

For example, a CB notification for a NF service may be sent using said address information or endpoint information that is preferably comprised or at least indicated by the repository CB service instance, which address or endpoint information preferably indicates the resource at the second NFB 520.

The event associated with the expected NF service may indicate that the status of the expected NF service has changed. For example, the event associated with the expected NF service may indicate that the expected NF service has been completed or that it cannot be completed or that it cannot be completed as expected (e.g. that it cannot be completed at the moment and/or within an expected time) or that it has failed, e.g. failed fully or partly.

The service registration request may also comprise security related information to be used for authorizing a discovering NF instance, e.g. security information that indicates the NFs that are allowed to discover the CB service (s) and/or an individual CB service, e.g. the type of NFs or the particular NFs of a certain type that are allowed to discover the CB service (s) in question.

The service registration for a core network function entity such as NFB 520 may e.g. take place when NFB 520 becomes operative for the first time or upon an activation of an individual NF service within NFB 520, e.g. triggered after a scaling operation. NFB 520 may register/expose one or more CB service (s) .

The service registration may e.g. be a separate CB registration or a combined registration, e.g. a part of some other registration such as an ordinary NF service registration (e.g. a combined NF service and CB service registration) , e.g. in case NFB 520 also supports ordinary NF service (s) and not only CB services.

Action 502b

The NRF 530 or similar stores the CB profile of the registering NFB 520. Also, it is preferred that the NRF 530 marks NFB 520 as available. For example, available for discovery by other core network function entities, e.g. such as NFA 510.

Action 502c

The NRF 530 or similar may, in response to the CB registration request received in Action 502a, send a CB service registration response to NFB 520. The response may include a copy or similar of the registered CB profile of NFB 520 as a confirmation of the registration made by the NRF 530.

Action 504a

When the second core network function entity NFB 520 intends to consume a NF service supported by the first NFA 510 it sends a discovery request to the NRF 530 or similar network repository function entity. The request indicates the expected NF service to be consumed by the discovering NFB 520 (e.g. indicates NF service A supported by NFA 510) . Preferably, the request indicates the NF service name or similar of the expected NF service. Additionally or alternatively, the request may indicate one or more of: the NF type of the expected NF (i.e. the type of NF that is expected to produce the expected NF service) and/or the NF type of the discovering NF. This action corresponds to action 402a discussed above with reference to figure 4.

Action 504b

The NRF 530 or similar authorizes the discovery request by determining –based on the information provided in the discovery request and preferably also based on the profile registered by the first NFA 510 –whether the discovering second NFB 520 is authorized to discover the expected NF service and/or NF instance (s) . This action corresponds to action 402b discussed above with reference to figure 4.

Action 504c

When authorized, it is preferred that the NRF 530 or similar determines a set of one or more discovered NF instance (s) and/or NF service instance (s) such as NFA 510 that supports the expected NF service. The NRF 530 sends a discovery request response to NFB 520, which response indicates that NFB 520 is allowed to consume the expected NF service (e.g. NF service A) from NFA 510. The response may e.g. indicate one or more discovered NF instance (s) and/or NF service instance (s) that support the expected NF service. The response may e.g. indicate one or more of: FQDN, IP address and/or endpoint addresses (e.g. URLs or similar) for said one or more discovered NF instance (s) and/or NF service instance (s) . This action corresponds to action 402c discussed above with reference to figure 4.

Action 506a

The second core network function entity NFB 520 sends, preferably based on the repository information received in action 504c, a service request towards the first NFA 510 to invoke the expected NF service (e.g. NF service A) at NFA 510, which supports the expected NF service. The service request may be a NF service request or NF service subscribe request. The service request indicates the expected NF service to be produced by the first NFA 510. The service request comprises CB service instance information that indicates a requested CB service instance to be discovered for the expected NF service by the first NFA 510 among at least one repository CB service instance that has been previously registered at the NRF 530 by the second NFB 520 in action 502a. Additionally, the service request may comprise the identity and/or FQDN or similar of the second NFB 520

Action 506b

The first NFA 510 may, in response to receiving the service request sent by the second NFB 520, process the expected NF service.

Action 506c

The first NFA 510 may, in case the expected service is processed 520, send a NF service response to the second NFB 520.

Action 508

At some point the first core network function entity NFA 510 decides to notify the second NFB 520 about an event that is associated with the expected NF service that was requested in action 506a.

For example, the event associated with the expected NF service may indicate that the expected NF service has been completed or that it cannot be completed or that it cannot be completed as expected (e.g. that it cannot be completed at the moment and/or within an expected time) or that it has failed, e.g. failed fully or partly.

For example, when a response from the first NFA 510 is expected by the second NFB 520 within a certain timeframe but the expected response could not be sent, at least not in time. For example, the expected NF service may fail in case the second NFB 520 has requested the first NFA 510 to send a message to another NF instance or to a UE or similar, but the other NF instance is currently unavailable (e.g. due to overload or maintenance or similar) or the UE is currently unavailable (e.g. in radio shadow or has been turned off) .

Action 510a

When the first core network function entity NFA 510 has decided to notify the second NFB 520, then the first NFA 510 sends a discovery request to the NRF 530 or similar network repository function entity. The discovery request is sent to discover a requested CB service instance among the at least one repository CB service instance, which instance was registered by the second NFB 510 in action 502a and which indicates a resource at the second NFB 520 to which the first NFA 510 can send a notification to indicate the event associated with the expected NF service to be produced by the first NFA 510 for the second NFB 520.

The discovery request comprises or at least indicates the CB service instance information that has been previously received in action 506a. The discovery request may additionally indicate at least one of: the identity of the second NFB 520 or the NF type of the second NFB 520 or the expected NF service to be produced by the first NFA 510.

Action 510b

The NRF 530 or similar determines –based on the information provided in the discovery request in action 510a and preferably also based on the CB service (s) registered by the second NFB 520 in actions 502a-502c –whether the discovering first NFA 510 is authorized to discover a CB service for the expected NF service and/or discover the second NFB 520 that is expected to consume the CB service. This action corresponds to action 402b discussed above with reference to figure 4, except that it is now a CB service that is expected not a NF service and it is a potential service producer that discovers the expected CB service not a potential service consumer that discovers an expected NF service. When authorized, the NRF 530 determines a set of one or more discovered NF instance (s) and at least one CB service instance, i.e. at least the CB service instance indicated in the CB service instance information previously received in action 506a.

Action 510c

The NRF 530 or similar sends a discovery request response towards the first core NF entity NFA 510. The response comprises the requested CB service instance that was requested/discovered in action 510a and which indicates the resource at the second NF entity (520) to which the first NF entity (510) shall send the notification to indicate an event associated with the expected NF service.

In the same or similar way as the repository CB services, the requested CB service instance may e.g. comprise address information or endpoint information that indicates a resource at the second NF entity (520) . The address information or endpoint inforamtion may e.g. correspond to an IP address or URI or URL or similar.

Action 512a

The first core NF entity NFA 510 sends a CB service notification towards the second core NF entity NFB 520, to indicate the event associated with the expected NF service. The CB notification is sent based on the requested CB service instance that was received in action 501c. Preferably, the CB service instance indicates the resource at the second NF entity (520) to which the CB notification is sent.

The CB notification for the expected NF service may be sent using address information or endpoint information that is preferably comprised or at least indicated by the received requested CB service instance, which address or endpoint information preferably indicates the resource at the second NFB 520.

Action 512b

The first core NF entity NFA 510 may send one or more subsequent a CB service notification (s) towards the second core NF entity NFB 520, to indicate further event (s) associated with the expected NF service and possibly other NF services that the first NFA 510 produces for the second NFB 520 or that is to be produced by the first NFA 510 for the second NFB 520.

Figure 6b is a schematic flowchart illustrating some exemplifying actions taken by the second NFB 520. The actions in figure 6a correspond to the actions in figure 6b, such that action 502a corresponds to action 602 and action 504a corresponds to action 604a and action 504c corresponds to action 604c and action 506a corresponds to action 606a and action 512 corresponds to action 612.

Figure 6c is a schematic flowchart illustrating some exemplifying actions taken by the second NFB 520. The actions in figure 6a correspond to the actions in figure 6c, such that action 506a corresponds to action 606a and action 510a corresponds to action 610a and action 510c corresponds to action 610c and action 512 corresponds to action 612.

Figure 7 is a schematic block diagram of a core network function entity 700 according to some embodiments of the present disclosure. The core NF entity 700 is a network function entity that implements one or more first core NF entity NFA 510 and/or one or more second core NF entity NFA 520 and/or network repository function entity NRF 530 in accordance with any of the embodiments disclosed herein. As illustrated, the NF entity 700 includes one or more processors 704 (e.g., CPUs, Application Specific Integrated Circuits (ASICs) , Field Programmable Gate Arrays (FPGAs) , and/or the like) , memory 706, and a network interface 708. The one or more processors 704 are also referred to herein as processing circuitry. The one or more processors 704 operate to provide one or more functions of NFA 510 and/or a NFB 520 and/or NRF 530 as described herein (e.g., one or more functions described above, e.g., with respect to Figure 6a) . In some embodiments, the function (s) are implemented in software that is stored, e.g., in the memory 706 and executed by the one or more processors 704.

Figure 8 is a schematic block diagram of the core NF entity 700 according to some other embodiments of the present disclosure. The core NF entity 700 includes one or more modules 800, each of which is implemented in software. The module (s) 800 provide the functionality of the core NF entity 700 described herein and, in particular, the functionality of the NFA 510 and/or NFB 520 and/or NRF 530 described herein (e.g., the functions described above, e.g., with respect to Figure 6a) .

Some of the exemplifying embodiments described above may be summarized in the following itemized manner:

A first item is directed to a method performed in a second core network function, NF, entity in a service-based core network of a communications system for handling a callback, CB, service; the method comprises:

- sending a service registration request towards a core network repository function entity to register a CB service for at least one NF service, which request comprises at least one repository CB service instance that indicates a resource at the second NF entity to which a first core NF entity can send a notification to indicate an event associated with a NF service to be produced by the first NF entity for the second NF entity;

- sending a service request towards the first NF entity, which service request indicates an expected NF service to be produced by the first NF entity and comprises CB service instance information that indicates a requested CB service instance to be discovered among said at least one repository CB service instance by the first NF entity for the expected NF service.

A second item is directed to the method according to the first item, the method comprises:

receiving, at a resource that is indicated by the requested CB service instance, a CB notification sent by the first NF entity which CB notification indicates an event associated with the expected NF service.

A third item is directed to a method according to any proceeding item, wherein: the NF service to be produced by the first NF entity is subscribed to or requested by the second NF entity.

A fourth item is directed to the method in according to any proceeding item, wherein:

the repository CB service instance indicates a single resource at the second NF entity to which the first NF entity can send notifications to indicate events associated with all NF services to be produced by the first NF entity.

A fifth item is directed to the method according to any one of the first, second or third item, wherein: the CB service registration request comprises a plurality of repository CB service instances that each can be used by the first NF entity to identify an individual resource at the second NF entity to which the first NF entity can send a notification to indicate an event associated with a corresponding individual NF service to be produced by the first NF entity for the second NF entity.

A sixth item is directed to the method according to any proceeding item, wherein:

said at least one resource is allocated by the NF entity per session or allocated for several sessions.

A seventh item is directed to the method according to any proceeding item, wherein the method comprises:

- sending a discovery request towards the repository function entity (530) , which request indicates an expected NF service to be consumed by the second NF entity (520) ;

- receiving a discovery request response sent by the repository function entity (530) , which response indicates that the second NF entity (520) is allowed to consume the expected NF service from the first NF entity (510) .

An eight item is directed to a method performed in a first core network function, NF, entity in a service-based core network of a communications system for handling a callback, CB, service; the method comprises:

- receiving a service request sent by a second core network function, NF, entity for producing an expected NF service for the second NF entity, which service request indicates the expected NF service and comprises CB service instance information that indicates a requested CB service instance to be discovered by the first NF entity for the expected NF service;

- sending a discovery request towards a core network repository function entity to discover the indicated requested CB service instance among at least one repository CB service instance that has been registered by the second NF entity and that indicates a resource at the second NF entity to which a first core NF entity can send a notification to indicate an event associated with a NF service to be produced by the first NF entity for the second NF entity;

- receiving a discovery request response sent by the core network repository function entity, which response comprises the requested CB service instance that indicates the resource at the second NF entity to which the first NF entity shall send a notification to indicate an event associated with the expected NF service.

A ninth item is directed to the method according to the eight item, wherein the method comprises: sending, based on the received requested CB service instance, a CB service notification towards the second core NF entity to indicate an event associated with the expected NF service.

A tenth item is directed to the method according to the ninth item, wherein: the CB service notification is sent using address information or endpoint information that is comprised by the received requested CB service instance.

An eleventh item is directed to the method according to the eight item, wherein the method comprises:

sending a NF registration request towards a core network repository function entity for registering a NF profile of the first NF entity, which NF profile indicates at least one NF service that is supported by the first NF entity.

A twelfth item is directed to the method according to any one of the eight item to the tenth item, wherein: the CB discovery request indicates at least one of: the identity of the second NF entity or the NF type of the second NF entity or the expected NF service.

A thirteenth item is directed to the method according to any proceeding item, wherein: the service request is a NF service request or a NF service subscription request.

A fourteenth item is directed to the method according to any proceeding item, wherein: the repository CB service instance comprises address information or endpoint information that indicates the resource at the second NF entity.

A fifteenth item is directed to the method according to the fourteenth item, wherein: one NF service is associated with the address information or endpoint information, or a plurality of NF service are associated with the address information or endpoint information.

A sixteenth item is directed to the method according to any proceeding item, wherein: the event associated with the expected NF service indicates that the status of the expected NF service has changed.

A seventeenth item is directed to the method according to any proceeding item, wherein: the event associated with the expected NF service indicates that the expected NF service has been completed or that it cannot be completed or that it cannot be completed as expected or that it has failed.

An eighteenth item is directed to a second core network function, NF, entity to be used in a service-based core network of a communications system for handling a callback, CB, service; the second core NF entity is configured to operatively:

- send a service registration request towards a core network repository function entity to register a CB service for at least one NF service, which request comprises at least one repository CB service instance that indicates a resource at the second NF entity to which a first core NF entity can send a notification to indicate an event associated with a NF service to be produced by the first NF entity for the second NF entity;

- send a service request towards the first NF entity, which service request indicates an expected NF service to be produced by the first NF entity and comprises CB service instance information that indicates a requested CB service instance to be discovered among said at least one repository CB service instance by the first NF entity for the expected NF service.

A nineteenth item is directed to the second core network function, NF entity according to the eighteenth item, wherein the second core NF entity is configured to operatively:

receive, at a resource that is indicated by the requested CB service instance, a CB notification sent by the first NF entity which CB notification indicates an event associated with the expected NF service.

A twentieth item is directed to a first core network function, NF, entity to be used in a service-based core network of a communications system for handling a callback, CB, service; the first core NF entity is configured to operatively:

- receive a service request sent by a second core network function, NF, entity to produce an expected NF service for the second NF entity, which service request indicates the expected NF service and comprises CB service instance information that indicates a requested CB service instance to be discovered by the first NF entity for the expected NF service;

- send a discovery request towards a core network repository function entity to discover the indicated requested CB service instance among at least one repository CB service instance that has been registered by the second NF entity and that indicates a resource at the second NF entity to which a first core NF entity can send a notification to indicate an event associated with a NF service to be produced by the first NF entity for the second NF entity;

- receive a discovery request response sent by the core network repository function entity, which response comprises the requested CB service instance that indicates the resource at the second NF entity to which the first NF entity shall send a notification to indicate an event associated with the expected NF service.

A twenty-first item is directed to the core network function, NF entity according to the twentieth item, wherein the first core NF entity is configured to operatively:

send, based on the received requested CB service instance, a CB service notification towards the second core NF entity to indicate an event associated with the expected NF service.

A twenty-second item is directed to a second core network function, NF, entity to be used in a service-based core network of a communications system for handling a callback, CB, service; the second core NF entity comprises at least one processor and memory comprising instructions executable by the at least one processor whereby the second core NF entity is operable to:

A twenty-third item is directed to a first core network function, NF, entity to be used in a service-based core network of a communications system for handling a callback, CB, service; the first core NF entity comprises at least one processor and memory comprising instructions executable by the at least one processor whereby the first core NF entity is operable to:

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include DSPs, special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM) , Random Access Memory (RAM) , cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc. ) .

Claims

A method performed in a second core network function, NF, entity (520) in a service-based core network of a communications system (200) for handling a callback, CB, service; the method comprises:

- sending (502a) a service registration request towards a core network repository function entity (530) to register a CB service for at least one NF service, which request comprises at least one repository CB service instance that indicates a resource at the second NF entity (520) to which a first core NF entity (510) can send a notification to indicate an event associated with a NF service to be produced by the first NF entity (510) for the second NF entity (520) ;

- sending (506a) a service request towards the first NF entity (510) , which service request indicates an expected NF service to be produced by the first NF entity (510) and comprises CB service instance information that indicates a requested CB service instance to be discovered among said at least one repository CB service instance by the first NF entity (510) for the expected NF service.
The method according to claim 1, the method comprises:

receiving (512) , at a resource that is indicated by the requested CB service instance, a CB notification sent by the first NF entity (510) which CB notification indicates an event associated with the expected NF service.
The method according to any proceeding claim, wherein: the NF service to be produced by the first NF entity (510) is subscribed to or requested by the second NF entity (520) .
The method according to any proceeding claim, wherein:

the repository CB service instance indicates a single resource at the second NF entity (520) to which the first NF entity (510) can send notifications to indicate events associated with all NF services to be produced by the first NF entity (510) .
The method according to any one of claim 1, 2 or 3, wherein: the CB service registration request comprises a plurality of repository CB service instances that each can be used by the first NF entity (510) to identify an individual resource at the second NF entity (520) to which the first NF entity (510) can send a notification to indicate an event associated with a corresponding individual NF service to be produced by the first NF entity (510) for the second NF entity (520) .
The method according to any proceeding claim, wherein:

said at least one resource is allocated by the NF entity (520) per session or allocated for several sessions.
The method according to any proceeding claim, wherein the method comprises:

- sending (504a) a discovery request towards the repository function entity (530) , which request indicates an expected NF service to be consumed by the second NF entity (520) ;

- receiving (504c) a discovery request response sent by the repository function entity (530) , which response indicates that the second NF entity (520) is allowed to consume the expected NF service from the first NF entity (510) .
A method performed in a first core network function, NF, entity (510) in a service-based core network of a communications system (200) for handling a callback, CB, service; the method comprises:

- receiving (506a) a service request sent by a second core network function, NF, entity (520) for producing an expected NF service for the second NF entity (520) , which service request indicates the expected NF service and comprises CB service instance information that indicates a requested CB service instance to be discovered by the first NF entity (510) for the expected NF service;

- sending (510a) a discovery request towards a core network repository function entity (530) to discover the indicated requested CB service instance among at least one repository CB service instance that has been registered by the second NF entity (510) and that indicates a resource at the second NF entity (520) to which a first core NF entity (510) can send a notification to indicate an event associated with a NF service to be produced by the first NF entity (510) for the second NF entity (520) ;

- receiving (510c) a discovery request response sent by the core network repository function entity (530) , which response comprises the requested CB service instance that indicates the resource at the second NF entity (520) to which the first NF entity (510) shall send a notification to indicate an event associated with the expected NF service.
The method according to claim 8, wherein the method comprises:

sending (512) , based on the received requested CB service instance, a CB service notification towards the second core NF entity (520) to indicate an event associated with the expected NF service.
The method according to claim 9, wherein: the CB service notification is sent using address information or endpoint information that is comprised by the received requested CB service instance.
The method according to claim 8, wherein the method comprises:

sending (500a) a NF registration request towards a core network repository function entity (530) for registering a NF profile of the first NF entity (510) , which NF profile indicates at least one NF service that is supported by the first NF entity (510) .
The method according to any one of claim 8 to 10, wherein: the CB discovery request indicates at least one of: the identity of the second NF entity (520) or the NF type of the second NF entity (520) or the expected NF service.
The method according to any proceeding claim, wherein: the service request is a NF service request or a NF service subscription request.
The method according to any proceeding claim, wherein: the repository CB service instance comprises address information or endpoint information that indicates the resource at the second NF entity (520) .
The method according to claim 14, wherein: one NF service is associated with the address information or endpoint information, or a plurality of NF service are associated with the address information or endpoint information.
The method according to any proceeding claim, wherein: the event associated with the expected NF service indicates that the status of the expected NF service has changed.
The method according to any proceeding claim, wherein: the event associated with the expected NF service indicates that the expected NF service has been completed or that it cannot be completed or that it cannot be completed as expected or that it has failed.
A second core network function, NF, entity (520) to be used in a service-based core network of a communications system (200) for handling a callback, CB, service; the second core NF entity (520) is configured to operatively:

- send (502a) a service registration request towards a core network repository function entity (530) to register a CB service for at least one NF service, which request comprises at least one repository CB service instance that indicates a resource at the second NF entity (520) to which a first core NF entity (510) can send a notification to indicate an event associated with a NF service to be produced by the first NF entity (510) for the second NF entity (520) ;

- send (506a) a service request towards the first NF entity (510) , which service request indicates an expected NF service to be produced by the first NF entity (510) and comprises CB service instance information that indicates a requested CB service instance to be discovered among said at least one repository CB service instance by the first NF entity (510) for the expected NF service.
The second core network function, NF entity according to claim 18, wherein the second core NF entity (520) is configured to operatively:

receive (512) , at a resource that is indicated by the requested CB service instance, a CB notification sent by the first NF entity (510) which CB notification indicates an event associated with the expected NF service.
A first core network function, NF, entity (510) to be used in a service-based core network of a communications system (200) for handling a callback, CB, service; the first core NF entity (510) is configured to operatively:

- receive (506a) a service request sent by a second core network function, NF, entity (520) to produce an expected NF service for the second NF entity (520) , which service request indicates the expected NF service and comprises CB service instance information that indicates a requested CB service instance to be discovered by the first NF entity (510) for the expected NF service;

- send (510a) a discovery request towards a core network repository function entity (530) to discover the indicated requested CB service instance among at least one repository CB service instance that has been registered by the second NF entity (510) and that indicates a resource at the second NF entity (520) to which a first core NF entity (510) can send a notification to indicate an event associated with a NF service to be produced by the first NF entity (510) for the second NF entity (520) ;

- receive (510c) a discovery request response sent by the core network repository function entity (530) , which response comprises the requested CB service instance that indicates the resource at the second NF entity (520) to which the first NF entity (510) shall send a notification to indicate an event associated with the expected NF service.
The core network function, NF entity according to claim 20, wherein the first core NF entity (520) is configured to operatively:

send (512) , based on the received requested CB service instance, a CB service notification towards the second core NF entity (520) to indicate an event associated with the expected NF service.
A second core network function, NF, entity (520, 700) to be used in a service-based core network of a communications system (200) for handling a callback, CB, service; the second core NF entity (520) comprises at least one processor (704) and memory (706) comprising instructions executable by the at least one processor (704) whereby the second core NF entity (520, 700) is operable to:

- send (502a) a service registration request towards a core network repository function entity (530) to register a CB service for at least one NF service, which request comprises at least one repository CB service instance that indicates a resource at the second NF entity (520) to which a first core NF entity (510) can send a notification to indicate an event associated with a NF service to be produced by the first NF entity (510) for the second NF entity (520) ;

- send (506a) a service request towards the first NF entity (510) , which service request indicates an expected NF service to be produced by the first NF entity (510) and comprises CB service instance information that indicates a requested CB service instance to be discovered among said at least one repository CB service instance by the first NF entity (510) for the expected NF service.
A first core network function, NF, entity (510, 700) to be used in a service-based core network of a communications system (200) for handling a callback, CB, service; the first core NF entity (510) comprises at least one processor (704) and memory (706) comprising instructions executable by the at least one processor (704) whereby the first core NF entity (520, 700) is operable to:

- receive (506a) a service request sent by a second core network function, NF, entity (520) to produce an expected NF service for the second NF entity (520) , which service request indicates the expected NF service and comprises CB service instance information that indicates a requested CB service instance to be discovered by the first NF entity (510) for the expected NF service;

- send (510a) a discovery request towards a core network repository function entity (530) to discover the indicated requested CB service instance among at least one repository CB service instance that has been registered by the second NF entity (510) and that indicates a resource at the second NF entity (520) to which a first core NF entity (510) can send a notification to indicate an event associated with a NF service to be produced by the first NF entity (510) for the second NF entity (520) ;

- receive (510c) a discovery request response sent by the core network repository function entity (530) , which response comprises the requested CB service instance that indicates the resource at the second NF entity (520) to which the first NF entity (510) shall send a notification to indicate an event associated with the expected NF service.