WO2019071582A1

WO2019071582A1 - Transferring multiple resources between network functions

Info

Publication number: WO2019071582A1
Application number: PCT/CN2017/106105
Authority: WO
Inventors: Yunjie Lu; Yong Yang
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2017-10-13
Filing date: 2017-10-13
Publication date: 2019-04-18
Anticipated expiration: 2020-04-13
Also published as: TW201924428A

Abstract

Systems and methods for transferring multiple resources between Network Functions (NFs) are provided. A method of operation of a source NF includes providing, to a target NF, information describing resources that the source NF would like to transfer. The source NF also receives a response indicating at least partial acceptance of the transfer. The source NF then transfers resources corresponding to the at least partial acceptance of the transfer. In this way, a negotiable way for pushing multiple resources between NFs is provided. This makes use of the HTTP/2 feature server push to perform the transfer. This may allow the target NF to control, and guide what resources, and the number of resources that can be accepted. This also may provide better performance by pre-emptively sending resources to avoid unnecessary signaling and waiting time which may avoid potential Head-Of-Line blocking by sending resources in separate streams.

Description

TRANSFERRING MULTIPLE RESOURCES BETWEEN NETWORK FUNCTIONS

Technical Field

The present disclosure relates to Network Functions (NFs) in a core network of a wireless communication system and, in particular, to transferring resources between NFs.

Background

Figures 1 and 2 illustrate the non-roaming and roaming Fifth Generation (5G) system architectures as specified by the Third Generation Partnership Project (3GPP) . As illustrated the 5G Core (5GC) network includes a number of Network Functions (NFs) e.g. an Access and Mobility Management Function (AMF) , a Session Management Function (SMF) , an Authentication Server Function (AUSF) , a Network Slice Selection Function (NSSF) , a Network Exposure Function (NEF) , a Network Repository Function (NRF) , a Policy Control Function (PCF) , an Application Function (AF) , and a Unified Data Management (UDM) function. 3GPP has determined that NFs within the 5GC Control Plane (CP) are to only use service-based interfaces for their interactions, as specified in subclause 4.2.1 of 3GPP Technical Specification (TS) 23.501 V1.3.0. There are typically many instances of each type of NF within the 5GC. The 5G system architecture contains the following service-based interfaces:

● Namf: Service-based interface exhibited by the AMF.

● Nsmf: Service-based interface exhibited by the SMF.

● Nnef: Service-based interface exhibited by the NEF.

● Npcf: Service-based interface exhibited by the PCF.

● Nudm: Service-based interface exhibited by the UDM.

● Naf: Service-based interface exhibited by the AF.

● Nnrf: Service-based interface exhibited by the NRF.

● Nnssf: Service-based interface exhibited by the NSSF.

● Nausf: Service-based interface exhibited by the AUSF.

A CP NF within the 5GC may expose its capabilities as services via its service-based interface, which can be re-used by CP NFs. NF service discovery enables a core network NF to discover NF instance (s) that provide a desired or expected NF service (s) . NF service discovery is implemented via NF discovery functionality.

In subclause 7.1.2 of 3GPP TS 23.501 V1.3.0, 3GPP further specifies NF interactions between a NF service consumer (i.e., a NF that consumes a service of another NF) and a NF service producer (i.e., a NF that produces a service consumed by another NF) .

Figure 3 illustrates a request-response interaction between a consumer NF (NF A) and a producer NF (NF B) . In this response-request interaction, a CP NF (NF B) receives a request from another CP NF (NF A) to provide a certain NF service to NF A. The NF service may be performing an action, providing information, or both. NF B provides the requested NF service for NF A in response to the request by NF A. In order to fulfill the request, NF B may in turn consume NF services from other NFs. In the request-response mechanism, communication is one-to-one between the two NFs (consumer and producer) , and a one-time response from the producer NF to a request from the consumer NF is expected within a certain timeframe.

Figures 4 and 5 illustrate a subscribe-notify mechanism. As illustrated in Figure 4, a CP NF (NF A) subscribes to a NF service offered by another CP NF (NF B) . Multiple CP NFs may subscribe to the same service provided by NF B. NF B notifies subscribing NFs of the result of the NF service. The subscription request from NF A may include a request for periodic updates or notification triggered through certain events such as a change in the information subscribed to by NF A, some value reaching a certain threshold, etc. Note that the subscription may be an explicit subscription or an implicit subscription (e.g., due to a successful registration procedure) . Figure 5 illustrates a subscribe-notify mechanism in which one CP NF (NF A) subscribes to a service provided by NF B on behalf of another CP NF (NF C) .

Within 3GPP, the following requirements for service selection, at least between NFs, e.g. an AMF and a SMF, have also been agreed upon:

1. If there is already a binding between a requester (i.e., consumer) NF and a provider (i.e., producer) NF, both NFs consume services from each other. For example, if an AMF (AMF-1) (which is also referred to as an AMF instance) has selected a particular SMF (SMF-1) (which is also referred to as an SMF instance) for a Packet Data Unit (PDU) session establishment, SMF-1 is to use AMF-1's services for the same PDU session.

2. If there is no binding yet between a requester (i.e., consumer) NF and a provider (i.e., producer) NF, the requester NF discovers the NF instances that support a desired or expected NF service according to the principles of subclause 6.8.1.2 of 3GPP TS 23.501 V1.3.0. The requester NF then selects one NF instance among the discovered NF instances.

Note that NF A and NF B may be of different NF types, e.g. communication between an AMF and a SMF, or they may have the same NF type, e.g. communication between v-SMF and h-SMF or communication between the old AMF and new AMF during an AMF relocation procedure. The binding between NF A and NF B implies that the communication between NF A (service consumer, e.g. an AMF) and NF B (service producer) is stateful. In other words, if NF A has invoked a service offered by NF B and the request has been accepted, then the binding between NF A and NF B is established； therefore, if subsequently the NF B desires to invoke a service offered by a NF having the same NF type as NF A, the NF B is to use NF A.

Currently, Hypertext Transfer Protocol Version 2.0 (HTTP/2) is selected to be used for the service-based interfaces between the 5GC NFs. However, the communication in HTTP/2 is unidirectional, i.e. fully bidirectional communication requires two client-server pairs, one per direction. This means that when NF A establishes a binding to NF B by sending an HTTP request to NF B over a Transmission Control Protocol (TCP) connection, NF B needs to send an HTTP request over another TCP connection when NF B desires to invoke a service of NF A.

Following requirements for the case when the common UE context storage function (e.g., by the Unstructured Data Storage Function (UDSF) ) has not been deployed, an AMF can be taken graciously out of service as follows:

The AMF can forward registered UE contexts, UE contexts grouped by the same Globally Unique AMF ID (GUAMI) value, to target AMF (s) within the same AMF set. The UE context includes the per AMF Set unique AMF N2AP UE ID. If there are ongoing transactions (e.g. N1 procedure) for certain UE (s) , AMF forwards the UE context (s) to a target AMF in the AMF set upon completion of an ongoing transaction.

However, other than the process of graciously taking an AMF out of service, there is no mechanism how the UE contexts (multiple UE contexts) can be forwarded from one AMF to the other. As such, systems and methods for transferring multiple resources between NFs are needed.

Summary

Systems and methods for transferring multiple resources between Network Functions (NFs) are provided. In some embodiments, a method of operation of a source NF in a core network of a wireless communication system includes providing, from the source NF to a target NF, information describing resources that the source NF would like to transfer to the target NF. The method also includes receiving, from the target NF by the source NF, a response indicating at least partial acceptance of a transfer of resources from the source NF to the target NF. In response to receiving the response indicating at least partial acceptance of the transfer, the method includes transferring, from the source NF to the target NF, resources corresponding to the at least partial acceptance of the transfer of resources from the source NF to the target. In this way, a negotiable way for pushing multiple resources between NFs is provided. In some embodiments, this makes use of the HTTP/2 feature server push to perform the transfer. This may allow the target NF to control and guide the source NF with regard to what resources (such as UE contexts) , and the number of resources that can be accepted. This also may provide better performance by pre-emptively sending resources to avoid unnecessary signaling and waiting time which may avoid potential Head-Of-Line (HOL) blocking by sending resources in separate streams.

In some embodiments, receiving the response indicating the at least partial acceptance of the transfer includes receiving a response indicating full acceptance of the transfer. In some embodiments, receiving the response indicating the at least partial acceptance of the transfer includes receiving a response indicating partial acceptance of the transfer of resources. In some embodiments, receiving the response indicating the partial acceptance of the transfer includes receiving an indication of a subset of resources the target NF is willing to have transferred from the source NF. In some embodiments, receiving the indication of the subset of the resources the target NF is willing to have transferred from the source NF includes receiving the indication of the subset of the resources as at least one of a type of the resources, a location associated with the resources, a service type associated with the resources, and/or a number of the resources.

In some embodiments, receiving the response indicating the at least partial acceptance of the transfer of resources from the source NF to the target NF includes receiving a request to a Uniform Resource Indicator (URI) indicating the at least partial acceptance and transferring the resources corresponding to the at least partial acceptance includes sending one or more PUSH_PROMISE frames for the resources indicated by the at least partial acceptance.

In some embodiments, the method further includes receiving, from the target NF by the source NF, a request to transfer a single resource from the source NF to the target NF. In response to receiving the request to transfer the single resource, the method includes transferring, from the source NF to the target NF, the single resource corresponding to the request.

In some embodiments, the method also includes deactivating the source NF. In some embodiments, prior to deactivating the source NF, the method includes waiting a predetermined amount of time after transferring the resources corresponding to the at least partial acceptance of the transfer of resources from the source NF to the target NF. In some embodiments, prior to deactivating the source NF, the method includes receiving a confirmation that the transfer of the resources corresponding to the at least partial acceptance of the transfer of resources from the source NF to the target NF was successful.

In some embodiments, a source NF in a core network of a wireless communication system is adapted to provide, from the source NF to a target NF, information describing resources that the source NF would like to transfer to the target NF； receive, from the target NF by the source NF, a response indicating at least partial acceptance of the transfer of resources from the source NF to the target NF； and in response to receiving the response indicating at least partial acceptance of the transfer, transfer, from the source NF to the target NF, resources corresponding to the at least partial acceptance of the transfer of resources from the source NF to the target NF. In some embodiments, the source NF is further adapted to perform the method of any one of the embodiments discussed herein.

In some embodiments, a source NF in a core network of a wireless communication system includes a communication interface and processing circuitry associated with the communication interface. The processing circuitry is operable to cause the first NF to provide, to a target NF, information describing resources that the source NF would like to transfer to the target NF； receive, from the target NF, a response indicating at least partial acceptance of a transfer of resources from the source NF to the target NF； and in response to receiving the response indicating at least partial acceptance of the transfer, transfer, to the target NF, resources corresponding to the at least partial acceptance of the transfer of resources from the source NF to the target NF. In some embodiments, the processing circuitry is further operable to cause the source NF to perform the method of any one of the embodiments discussed herein.

In some embodiments, a source NF in a core network of a wireless communication system includes a processing unit operable to cause the source NF to provide, from the source NF to a target NF, information describing resources that the source NF would like to transfer to the target NF and receive, from the target NF by the source NF, a response indicating at least partial acceptance of a transfer of resources from the source NF to the target NF. The source NF also includes a transfer unit operable to cause the source NF to, in response to receiving the response indicating the at least partial acceptance of the transfer, transfer, from the source NF to the target NF, resources corresponding to the at least partial acceptance of the transfer of resources from the source NF to the target NF.

In some embodiments, a method of operation of a target NF in a core network of a wireless communication system includes receiving, from a source NF by the target NF, information describing resources that the source NF would like to transfer to the target NF. The method also includes providing, from the target NF to the source NF, a response indicating at least partial acceptance of a transfer of resources from the source NF to the target NF and, in response to providing the response indicating the at least partial acceptance of the transfer, receiving, from the source NF by the target NF, resources corresponding to the at least partial acceptance of the transfer of resources from the source NF to the target NF.

In some embodiments, providing the response indicating the at least partial acceptance of the transfer includes providing the response indicating full acceptance of the transfer of resources from the source NF to the target NF. In some embodiments, providing the response indicating the at least partial acceptance of the transfer includes providing the response indicating partial acceptance of the transfer of resources from the source NF to the target NF. In some embodiments, providing the response indicating the partial acceptance of the transfer includes providing an indication of a subset of the resources the target NF is willing to have transferred from the source NF. In some embodiments, providing the indication of the subset of the resources the target NF is willing to have transferred from the source NF includes providing the indication of the subset of the resources as at least one of a type of the resources, a location associated with the resources, a service type associated with the resources, and/or a number of the resources.

In some embodiments, providing the response indicating the at least partial acceptance of the transfer of resources from the source NF to the target NF includes providing a request to a URI indicating the at least partial acceptance and receiving the resources corresponding to the at least partial acceptance includes receiving one or more PUSH_PROMISE frames for the resources indicated by the at least partial acceptance.

In some embodiments, the method also includes providing, to the source NF by the target NF, a request to transfer a single resource from the source NF (20-A) to the target NF (20-B) . In response to providing the request to transfer the single resource, the method includes receiving, from the source NF by the target NF, the single resource corresponding to the request.

In some embodiments, the method also includes providing, to the source NF by the target NF, a confirmation that a transfer of resources corresponding to the at least partial acceptance of the transfer of resources from the source NF to the target NF was successful.

In some embodiments, a target NF in a core network of a wireless communication system is adapted to receive, from a source NF by the target NF, information describing resources that the source NF would like to transfer to the target NF (20-B) ； provide, from the target NF to the source NF, a response indicating at least partial acceptance of a transfer of resources from the source NF to the target NF； and, in response to providing the response indicating at least partial acceptance of the transfer, receive, from the source NF by the target NF, resources corresponding to the at least partial acceptance of the transfer of resources from the source NF to the target NF. In some embodiments, the target NF is further adapted to perform the method of any one of the embodiments discussed herein.

In some embodiments, a target NF in a core network of a wireless communication system includes a communication interface and processing circuitry associated with the communication interface. The processing circuitry is operable to cause the target NF to receive, from a source NF by the target NF, information describing resources that the source NF would like to transfer to the target NF； provide, from the target NF to the source NF, a response indicating at least partial acceptance of a transfer of resources from the source NF to the target NF； and, in response to providing the response indicating the at least partial acceptance of the transfer, receive, from the source NF by the target NF, resources corresponding to the at least partial acceptance of the transfer of resources from the source NF to the target NF. In some embodiments, the processing circuitry is further operable to cause the target NF to perform the method of any one of the embodiments discussed herein.

In some embodiments, a target NF in a core network of a wireless communication system includes a processing unit operable to cause the target NF to receive, from a source NF, information describing resources that the source NF would like to transfer to the target NF and provide, from the target NF to the source NF, a response indicating at least partial acceptance of a transfer of resources from the source NF to the target NF. The target NF also includes a transfer unit operable to cause the target NF to, in response to providing the response indicating the at least partial acceptance of the transfer, receive, from the source NF, resources corresponding to the at least partial acceptance of the transfer of resources from the source NF to the target NF.

In some embodiments, the source NF and the target NF have the same NF type. In some embodiments, the source NF and the target NF are Core Access and Mobility Management Function (AMF) NFs and the resources include multiple User Equipment (UE) contexts. In some embodiments, the wireless communication system is a Fifth Generation (5G) wireless communication system.

Brief Description of the Drawings

The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

Figures 1 and 2 illustrate the non-roaming and roaming Fifth Generation (5G) system architectures as specified by the Third Generation Partnership Project (3GPP) .

Figure 3 illustrates a request-response interaction between a consumer Network Function (NF) and a producer NF.

Figures 4 and 5 illustrate a subscribe-notify mechanism in which one NF subscribes to a service of another NF on behalf of itself or yet another NF, respectively.

Figure 6 illustrates one example of a wireless communication system in which embodiments of the present disclosure can be implemented.

Figure 7 illustrates the operation of a source Network Function (NF) according to some embodiments of the present disclosure.

Figure 8 illustrates the operation of a target NF according to some embodiments of the present disclosure.

Figure 9 illustrates the operation of a system including a source NF and a target NF according to some embodiments of the present disclosure.

Figures 10 and 11 illustrate example embodiments of a network node in which a NF (s) is implemented.

Detailed Description

The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

Following requirements for the case when a common User Equipment (UE) context storage function (e.g., by the Unstructured Data Storage Function (UDSF) ) has not been deployed, an Access and Mobility Management Function (AMF) can be taken graciously out of service as follows:

The AMF can forward registered UE contexts, UE contexts grouped by the same Globally Unique AMF ID (GUAMI) value, to target AMF (s) within the same AMF set. The UE context includes the per AMF Set unique AMF N2AP UE ID. If there are ongoing transactions (e.g. N1 procedure) for certain UE (s) , AMF forwards the UE context (s) to the target AMF upon completion of an ongoing transaction.

However there is no general mechanism for how the UE contexts (multiple UE contexts) can be forwarded from one AMF to the other. As such, systems and methods for transferring multiple resources between NFs are needed.

Systems and methods for transferring multiple resources between Network Functions (NFs) are provided. The resources may correspond to resources that are associated with one or more UE (s) , e.g. such as UE contexts for AMF or PDU Sessions for SMF. In some embodiments, a method of operation of a source NF in a core network of a wireless communication system includes providing, from the source NF to a target NF, information describing resources that the source NF would like to transfer to the target NF. The method also includes receiving, from the target NF by the source NF, a response indicating at least partial acceptance of a transfer of resources from the source NF to the target NF. In response to receiving the response indicating at least partial acceptance of the transfer, the method includes transferring, from the source NF to the target NF, resources corresponding to the at least partial acceptance of the transfer of resources from the source NF to the target. In this way, a negotiable way for pushing multiple resources between NFs is provided. In some embodiments, this makes use of the HTTP/2 feature server push to perform the transfer. This may allow the target NF to control, and guide the source NF what resources (such as UE contexts) , and the number of resources that can be accepted. This also may provide better performance by pre-emptively sending resources to avoid unnecessary signaling and waiting time which may avoid potential Head-Of-Line (HOL) blocking by sending resources in separate streams.

In this regard, Figure 6 illustrates one example of a wireless communication system 10 in which embodiments of the present disclosure can be implemented. As illustrated, the wireless communication system 10 includes a number of wireless devices 12 served by a Radio Access Network (RAN) that includes a number of radio access nodes 14 having corresponding coverage areas or cells 16. The wireless communication system 10 also includes a core network 18. In the embodiments described herein, the wireless communication system 10 is a Third Generation Partnership Project (3GPP) Fifth Generation (5G) network and, as such, the RAN is a 5G RAN and the core network 18 is a 5G Core (5GC) . The core network 18 includes a number of NFs 20. As illustrated, the NFs 20 include an Access and Mobility Management Function (s) (AMF (s)) 22, Session Management Function (s) (SMF (s) ) 24, Network Repository Function (s) (NRF (s) ) 26, Network Slice Selection Function (s) (NSSF (s) ) 28, Network Exposure Function (s) (NEF (s) ) 30, Policy Control Function (s) (PCF (s)) 32, and Application Function (s) (AF (s) ) 34. The NFs 20 are also referred to as NF instances. Thus, as an example, multiple AMFs 22 may be referred to as AMF instances.

Many of the embodiments discussed herein relate to the source NF 20-A preparing to be deactivated. However, the current disclosure is not limited thereto. In some embodiments, these procedures can be used for load balancing or for any type of network optimization.

Figure 7 illustrates the operation of a source NF 20-A according to some embodiments of the present disclosure. NF 20-A provides, to a target NF 20-B, information describing resources that the source NF 20-A would like to transfer to the target NF 20-B (step 100) . Preferably, the resources correspond to resources that are associated with one or more UE (s) , e.g. such as UE contexts for AMF or PDU Sessions for SMF or similar. The NF 20-A and NF 20-B may be of the same NF type, which preferably provides a particular service with respect to UEs associated with the resources to be transferred. The source NF 20-A receives, from the target NF 20-B, a response indicating at least partial acceptance of the transfer of resources from the source NF 20-A to the target NF 20-B (step 102) . In response to receiving the response indicating at least partial acceptance of the transfer, the source NF 20-A transfers, from the source NF 20-A to the target NF 20-B, resources corresponding to the at least partial acceptance of the transfer of resources from the source NF 20-A to the target NF 20-B (step 104) .

In some embodiments, the response indicates full acceptance of the transfer. In some embodiments, the response indicates only a partial acceptance of the transfer of resources. In some embodiments, the partial acceptance of the transfer includes receiving an indication of a subset of resources the target NF is willing to have transferred from the source NF 20-A. In some embodiments, the indication is an indication of the subset of the resources as a type of the resources, a location associated with the resources, a service type associated with the resources, and/or a number of the resources.

In some embodiments,

steps

100 and 102 may be performed multiple times as the source NF 20-A and the target NF 20-B negotiate which resources will be transferred. For any of a number of reasons, the target NF 20-B may need a single resource or group of resources transferred from the source NF 20-A. One example would be if the transfer of resources in step 104 ends with one or more resources not properly transferred. In these cases, the source NF 20-A may optionally receive a request to transfer a single resource from the source NF 20-A to the target NF 20-B (step 106) . In response to receiving the request to transfer the single resource, the source NF 20-A may optionally transfer the single resource corresponding to the request (step 108) .

In embodiments where the source NF 20-A seeks to be deactivated, there may be a need for the source NF 20-A or some other entity to be sure that the transfer of the resources was complete.

Figure 7 illustrates two optional ways. In some embodiments, the source NF 20-A can wait a predetermined amount of time (step 110A) . In some of these embodiments, the source NF 20-A may assume that the target NF 20-B will make any failures of the transfer known to the source NF 20-A. If no such failure is indicated in the predetermined amount of time, then the source NF 20-A can assume the transfer has been successful. In some embodiments, this failure indication is communicated implicitly by the request from the target NF 20-B for a single resource as discussed in relation to step 106.

In some embodiments, the target NF 20-B may more explicitly indicate a successful transfer. In these embodiments, the source NF 20-A may optionally receive a confirmation that the transfer was successful (step 110B) .

Regardless of how the source NF 20-A becomes convinced that the transfer has been successful, the source NF 20-A may optionally be deactivated (step 112) . It should be noted that while these embodiments only describe the interaction between the source NF 20-A and a single target NF 20-B, if the target NF 20-B only partially accepts, the source NF 20-A may/should locate another target NF 20-B to negotiate the transfer of the rest of the resources. The source NF 20-A may/should shut down only when all the resources are transferred.

Figure 8 illustrates the operation of a target NF 20-B according to some embodiments of the present disclosure. In some embodiments, these steps are seen as the complementary functions to those described in relation to the source NF 20-A in Figure 7. Target NF 20-B receives from the source NF 20-A, information describing resources that the source NF 20-A would like to transfer to the target NF 20-B (step 200) . The target NF 20-B provides a response indicating at least partial acceptance of the transfer of resources from the source NF 20-A to the target NF 20-B (step 202) . In response to providing the response indicating at least partial acceptance of the transfer, the target NF 20-B receives, from the source NF 20-A, resources corresponding to the at least partial acceptance of the transfer of resources from the source NF 20-A to the target NF 20-B (step 204) .

In some embodiments,

steps

200 and 202 may be performed multiple times as the source NF 20-A and the target NF 20-B negotiate which resources will be transferred. For any of a number of reasons, the target NF 20-B may need a single resource or group of resources transferred from the source NF 20-A. One example would be if the reception of resources in step 204 ends with one or more resources not properly transferred. In these cases, the target NF 20-B may optionally provide a request to transfer a single resource from the source NF 20-A to the target NF 20-B (step 206) . In response to providing the request to transfer the single resource, the target NF 20-B may optionally receive the single resource corresponding to the request (step 208) .

There may be a need for the source NF 20-A or some other entity to be sure that the transfer of the resources was complete. Thus, in some embodiments, the target NF 20-B may explicitly indicate a successful transfer by providing a confirmation that the transfer was successful (step 210) .

In some embodiments, the solutions fill the gaps for the 3GPP requirements, provide a negotiable way between NFs for pushing massive resources, and make use of HTTP/2 feature server push to perform the transfer. Compared with other alternatives, these embodiments allow the target NF 20-B to control and guide the source NF 20-A in regards to which resources (e.g., what UE contexts) , and the number of resources the target NF 20-B can accept. These embodiments may provide better performance by pre-emptively sending resources to avoid unnecessary signaling and waiting time and avoid potential HOL blocking by sending resources in separate streams. Many of the embodiments discussed herein relate to the source NF 20-A and the target NF 20-B both being AMF NFs and the resources being UE contexts. However, the current disclosure is not limited thereto.

HTTP/2 provides new features of Server Push. In HTTP 1. x, clients request server resources in a “discover & fetch” way of working； i.e., a client usually starts to fetch a web page from server with a HTTP request, and the server responds with the web page document in response. After receiving the document, the client parses it to find out associated assets and then explicitly issues requests, one by one, to fetch the assets. To increase the performance, Server Push is introduced in HTTP/2 spec (RFC7540) . With server push, the server can preemptively “push” website assets to the client without waiting for the client to explicitly ask for them.

Some embodiments herein relate to a resource pushing request and acknowledgement mechanism between NFs 20. This provides a generic mechanism that can be used to transfer resources (e.g. UE contexts) from one NF 20 to the other NF 20, as an example, transfer UE contexts between AMFs.

When an NF 20 (the source NF 20-A) , determines to transfer some resources to another NF 20 (target NF 20-B) with the same NF type and in the same group/set, the source NF 20-A should consume a service offered by the target NF 20-B to indicate that the source NF 20-A would like to transfer some resources, with some optional metadata describing the UE Contexts, e.g. UE usage type, UE location, and also the number of UE Contexts that it intended to transfer.

To allow the target NF 20-B to consume fetching service, the source NF 20-A provides information describing and/or indicating resources that the source NF 20-A would like to transfer to the target NF 20-B, e.g. information in the form of a normal resource Uniform Resource Indicator (URI) in case one resource to be pushed； or a Collective URI that indicates and/or describes multiple resources to be pushed for this push request； or even an action Uniform Resource Locator (URL) describing a complete Service Operation.

The target NF 20-B should be able to accept, or reject, or partially accept receiving some of resources, e.g., when it would be overloaded if too many resources are accepted, or some resources require an additional feature, while such resources have been used up on the target NF 20-B.

If the target NF 20-B accepts the request, including the partial acceptance, the target NF 20-B will then act as a client to consume the service on the source NF 20-A to retrieve the resources to be transferred, where such resources are described and/or indicated in the previous step (100, 200) . In case of partial acceptance, the target NF 20-B indicates the desired number of resources to retrieve in the service request or some other subset of the offered resources.

When the source NF 20-A, acting as a server, receives the request, the source NF 20-A should send a response and push the requested number of resources to the target NF 20-B. In some embodiments, this is accomplished using the optimized mechanism discussed below.

In some embodiments, an optimized procedure for retrieving massive resources (e.g., UE contexts) between NFs 20 (e.g., two AMFs) , using a collective URI and HTTP/2 server push mechanism to send one resource (e.g., a UE context) per separate streams may be used.

In these embodiments, the target NF 20-B sends an HTTP request to the source NF 20-A with a collective URI that indicates and/or describes all the resources to be transferred, instead of a URI that refers to single resource.

In some embodiments, the Collective URI is generated by source NF 20-A for this multiple_resources_transfer request and provided to the target NF 20-B in the previous step (100, 200) . The Collective URI can also take parameters to indicate the specific partial of the resources to transfer. For instance, for UE Context of AMF, a collective URI can be in form like:

● http: //sourceAMF. instance/Namf_Communication/UEContexts？ push Token＝xxxx or

● http: //sourceAMF. instance/Namf_Communication/UEContexts？ push Token＝xxxx&from＝1&to＝500

After receiving the request, besides sending the response to target NF 20-B, the source NF 20-A also sends PUSH_PROMISE frames for the resources (one such Push_Promise frames per resource) to be transferred. In some embodiments, each PUSH_PROMISE frame includes:

PATH to the specific resource

Stream ID reserved for this specific resource

After that, the source NF 20-A starts sending the response to the target NF 20-B. Each response contains the contents of the corresponding resource to be delivered, via the corresponding stream reserved for the resource.

In some embodiments, in case a resource is not successfully delivered, the target NF 20-B can explicitly issue a HTTP request to get the resource from the source NF 20-A afterwards.

Figure 9 illustrates the operation of a system including a source NF 20-A and a target NF 20-B according to some embodiments of the present disclosure. This example uses the Server Push procedure and preferably the collective URI discussed above. When the source NF 20-A (e.g. an AMF) , determines to transfer some resources (e.g. UE contexts or PDU sessions) to the target NF 20-B (e.g. another AMF within the same AMF set) , it consumes Resource_Push service on target NF, to indicate that it would like to transfer some resources and the number of resources intended to be transferred (step 300) . The NF 20-A and NF 20-B may be of the same NF type, which preferably provides a particular service with respect to UEs associated with the resources. Preferably, the NF 20-A and NF 20-B are in the same group/set. In some embodiments, this is one way of performing step 100 as discussed in relation to Figure 7 and step 200 as discussed in relation to Figure 8.

The service request could also carry optional metadata describing the resources to be transferred. For instance, for an AMF to transfer UE Contexts, metadata can include UE usage type, UE location, etc. Additionally or alternatively, the service request can carry information for transferring, e.g., a Collective URI that indicates and/or describes the resources to be transferred. The Collective URI is generated by source NF 20-A, and provided to target NF 20-B. Preferably, the Collective URI indicates and/or describes all the resources to be transferred. As discussed above, the Collective URI can also take parameters to indicate the specific part of the resources to transfer. For instance, for UE Context of AMF, a collective URI can be in form as discussed above.

In some embodiments, the source NF 20-A is aware of the target NF 20-B because of a set concept, where the NFs in the same NF set are considered from the same vendor, supporting same features. However, these NFs may know of each other in any other suitable way. In some embodiments, the Resource_Push service could be a new or existing service offered by target NF 20-B. Which service to be used is NF specific and detailed service operations are implementation dependent.

In some embodiments, UE Context information may be subject to opaque data, which can be understood only by a NF with the same NF type and from the same vendor. However, in some embodiments, a standardized UE Context could be used which enables such UE context transferring even between the same type NFs but from different vendors.

Returning now to Figure 9, the target NF 20-B accepts (or partially accepts) the service request and responds with a positive Resource_Push service response (step 302A) . In some embodiments, step 302A is one way of performing step 102 as discussed in relation to Figure 7 and step 202 as discussed in relation to Figure 8.

In some embodiments, the target NF 20-B may reject the service request by responding negative Resource_Push service response (step 302B) . Some reasons for the potential rejection may include the target NF 20-B being overloaded if too many UE Contexts are accepted, or some resources being unavailable for UE Contexts requiring additional features. In such cases, no transfers may take place. However, the source NF 20-A may attempt the transfer again with this target NF 20-B with a modified request or may contact another target NF 20-B to transfer the resources.

If the target NF 20-B accepts the request, including the partial acceptance, the target NF 20-B consumes a Multiple_Resource_Fetch service on the source NF 20-A to retrieve (step 304) the multiple resources, using the collective URI previously received in Resource_Push service request (step 300) . In case of partial acceptance, the target NF 20-B indicates the desired number of resources to retrieve in the service request or some other subset of the resources. In some embodiments, step 304 is one way of performing step 102 as discussed in relation to Figure 7 and step 202 as discussed in relation to Figure 8.

Additionally, the target NF 20-B may also carry metadata in the service request, indicating service specific or resource specific metadata (e.g. data filtering) which are allowed for a Single_Resource_Fetch Service. In some embodiments, the Multiple_Resource_Fetch and Single_Resource_Fetch services to be used could be different for different NFs. In some embodiments, these services can be specifically defined extensions to existing services or new services. For example, for AMF to transfer UE contexts, Single_Resource_Fetch service could directly reuse Namf_Communication UE Context Transfer service； Multiple_Resource_Fetch can also reuse Namf_Communication UE Context Transfer service with a new extension (since current Namf_communication UE context transfer service is per UE context with explicit UE identity required, and the target AMF doesn't have UE identifier yet) , or a new context transfer service for this massive UE context transfer.

Returning again to Figure 9, When the source NF 20-A, acting as the server, receives the request, the source NF 20-A sends a Multiple_Resource_Fetch service response, together with Push Requests for the resources to be transferred (step 306) . In some embodiments, each PushRequest stands for a Single_Resource_Fetch service request as it would have been received from target NF 20-B and reserved a separate stream (stream r1 ～stream rn) for the specific resource. In some embodiments, step 306 is one way of performing step 104 as discussed in relation to Figure 7 and step 204 as discussed in relation to Figure 8.

In some embodiments, each Push Request includes a PUSH_PROMISE frame and subsequent CONTINUATION frames, carrying a header block that contains a complete set of request header fields that the server attributes to the Single_Resource_Fetch service request, including:

● method pseudo-header contains the HTTP method, should always be GET

● path pseudo-header contains URI to the specific resource. For AMF sending UE Context, it could be:

/Namf_Communication/UEContexts/<UE-ID>

In case additional service or resource metadata is received from

Multiple_Resource_Fetch service requests, these data should also be applied in Push Requests. The PUSH_PROMISE frames (push requests) are sent after Header frames of the response but before the Data frames carrying the response body.

The source NF 20-A sends push responses to the target NF 20-B using reserved streams (steps 308-1 through 308-N) . Each Push Response contains the contents of the corresponding resource, via the corresponding stream reserved for the corresponding resource. In some embodiments, steps 308-1 through 308-N are also included in step 104 as discussed in relation to Figure 7 and step 204 as discussed in relation to Figure 8.

As discussed above, in case a resource is not successfully delivered, the target NF 20-B can explicitly issue an HTTP request to get it from source NF 20-A afterwards. In case a resource is indicated in a Push Request but not successfully received from source NF 20-A, the target NF 20-B can explicitly consume Single_Resource_Fetch service on the source NF 20-A afterwards to get the single resource (steps 310 and 312) . In some embodiments,

steps

310 and 312 are one way of performing

steps

106 and 108, respectively, as discussed in relation to Figure 7 and

steps

206 and 208, respectively, as discussed in relation to Figure 8.

As discussed above, these embodiments may provide a negotiable way for pushing multiple resources between NFs. In some embodiments, this makes use of the HTTP/2 feature server push to perform the transfer. This may allow the target NF to control, and guide the source NF what resources (such as UE contexts) , and the number of resources that can be accepted. This also may provide better performance by pre-emptively sending resources to avoid unnecessary signaling and waiting time which may avoid potential HOL blocking by sending resources in separate streams.

Figure 10 illustrates one example of a network node 36 in which an NF (s) 20 may be implemented according to some embodiments of the present disclosure. As illustrated, the network node 36 comprises hardware 38 including a communication interface 40 configured to set up and maintain a wired or wireless connection with an interface of a different network node of the wireless communication system 10. The network node 36 further comprises processing circuitry 42, which may have storage and/or processing capabilities. In particular, the processing circuitry 42 may comprise one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations of these (not shown) adapted to execute instructions. The network node 36 further comprises software 44, which is stored in or is accessible by the network node 36 and executable by the processing circuitry 42. The software 44 includes an application 46. The application 46 may, for example, be a software application that provides one or more NFs 20 of the same NF type or different NF types.

Figure 11 illustrates the network node 36 in accordance with some other embodiments of the present disclosure. As illustrated, the network node 36 includes one or more modules or

units

48 and 50, each of which is implemented in software. As an example, if the network node 36 implements the source NF 20-A, then the processing unit 48 is operable to cause the source NF 20-A to provide information describing resources that the source NF 20-A would like to transfer to the target NF 20-B and receive a response indicating at least partial acceptance of a transfer of resources from the source NF 20-A to the target NF 20-B. The transfer unit 50 is operable to cause the source NF 20-A to, in response to receiving the response indicating the at least partial acceptance of the transfer, transfer, from the source NF 20-A to the target NF 20-B, resources corresponding to the at least partial acceptance of the transfer of resources from the source NF 20-A to the target NF 20-B as described above with respect to, e.g., Figure 7 and/or Figure 9. As another example, if the network node 36 implements the target NF 20-B, then the processing unit 48 is operable to cause the target NF 20-B to receive, from a source NF 20-A, information describing resources that the source NF 20-A would like to transfer to the target NF 20-B and provide a response indicating at least partial acceptance of a transfer of resources from the source NF 20-A to the target NF 20-B. The transfer unit 50 is operable to cause the target NF 20-B to, in response to providing the response indicating the at least partial acceptance of the transfer, receive resources corresponding to the at least partial acceptance of the transfer of resources from the source NF 20-A to the target NF 20-B, as described above with respect to, e.g., Figure 8 and/or Figure 9.

At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing (s) .

● 3GPP Third Generation Partnership Project

● 5G Fifth Generation

● 5GC Fifth Generation Core

● AF Application Function

● AMF Access and Mobility Management Function

● AUSF Authentication Server Function

● CP Control Plane

● GUAMI Globally Unique AMF ID

● HTTP/2 Hypertext Transfer Protocol Version 2.0

● HOL Head-Of-Line

● ID Identifier

● IE Information Element

● NEF Network Exposure Function

● NF Network Function

● NRF Network Repository Function

● NSSF Network Slice Selection Function

● O&M Operation and Maintenance

● PCF Policy Control Function

● PDU Packet Data Unit

● RAN Radio Access Network

● SMF Session Management Function

● TCP Transmission Control Protocol

● TS Technical Specification

● UDM Unified Data Management

● UDSF Unstructured Data Storage Function

● UE User Equipment

● URI Uniform Resource Indicator

● URL Uniform Resource Locator

Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

A method of operation of a source Network Function, NF, (20-A) in a core network (18) of a wireless communication system (10) , comprising:

providing (100, 300) , from the source NF (20-A) to a target NF (20-B) , information describing resources that the source NF (20-A) would like to transfer to the target NF (20-B) ；

receiving (102, 302A, 304) , from the target NF (20-B) by the source NF (20-A) , a response indicating at least partial acceptance of a transfer of resources from the source NF (20-A) to the target NF (20-B) ； and

in response to receiving the response indicating at least partial acceptance of the transfer, transferring (104, 306, 308) , from the source NF (20-A) to the target NF (20-B) , resources corresponding to the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) .
The method of claim 1 wherein receiving the response indicating the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) comprises:

receiving a response indicating full acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) .
The method of claim 1 wherein receiving the response indicating the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) comprises:

receiving a response indicating partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) .
The method of claim 3 wherein receiving the response indicating the partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) further comprises:

receiving an indication of a subset of resources the target NF (20-B) is willing to have transferred from the source NF (20-A) .
The method of claim 4 wherein receiving the indication of the subset of the resources the target NF (20-B) is willing to have transferred from the source NF (20-A) comprises:

receiving the indication of the subset of the resources as at least one of the group consisting of a type of the resources, a location associated with the resources, a service type associated with the resources, and a number of the resources.
The method of any one of claims 1 through 5 wherein:

receiving (102, 302A, 304) the response indicating the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) comprises receiving a request to a Uniform Resource Indicator, URI, indicating the at least partial acceptance； and

transferring the resources corresponding to the at least partial acceptance comprises sending one or more PUSH_PROMISE frames for the resources indicated by the at least partial acceptance.
The method of any one of claims 1 through 6 further comprising:

receiving (106, 310) , from the target NF (20-B) by the source NF (20-A) , a request to transfer a single resource from the source NF (20-A) to the target NF (20-B) ； and

in response to receiving the request to transfer the single resource, transferring (108, 312) , from the source NF (20-A) to the target NF (20-B) , the single resource corresponding to the request.
The method of any one of claims 1 through 7 further comprising deactivating (112) the source NF (20-A) .
The method of claim 8 further comprising:

prior to deactivating the source NF (20-A) , waiting (110A) a predetermined amount of time after transferring, from the source NF (20-A) to the target NF (20-B) , the resources corresponding to the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) .
The method of claim 8 further comprising:

prior to deactivating the source NF (20-A) , receiving (110B) a confirmation that the transfer, from the source NF (20-A) to the target NF (20-B) , of the resources corresponding to the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) was successful.
The method of any one of claims 1 through 10 wherein the source NF (20-A) and the target NF (20-B) have the same NF type.
The method of claim 11 wherein the source NF (20-A) and the target NF (20-B) are Core Access and Mobility Management Function, AMF, NFs and the resources comprise a plurality of User Equipment, UE, contexts.
The method of any one of claims 1 through 12 wherein the wireless communication system is a Fifth Generation, 5G, wireless communication system.
A source Network Function, NF, (20-A) in a core network (18) of a wireless communication system (10) , the first NF (20-A) adapted to:

provide, from the source NF (20-A) to a target NF (20-B) , information describing resources that the source NF (20-A) would like to transfer to the target NF (20-B) ；

receive, from the target NF (20-B) by the source NF (20-A) , a response indicating at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) ； and

in response to receiving the response indicating at least partial acceptance of the transfer, transfer, from the source NF (20-A) to the target NF (20-B) , resources corresponding to the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) .
The source NF (20-A) of claim 14 wherein the source NF (20-A) is further adapted to perform the method of any one of claims 2 through 13.
A source Network Function, NF, (20-A) in a core network (18) of a wireless communication system (10) , comprising:

a communication interface (40) ； and

processing circuitry (42) associated with the communication interface (40) , wherein the processing circuitry (42) is operable to cause: the first NF (20-A) to:

provide, to a target NF (20-B) , information describing resources that the source NF (20-A) would like to transfer to the target NF (20-B) ；

receive, from the target NF (20-B) , a response indicating at least partial acceptance of a transfer of resources from the source NF (20-A) to the target NF (20-B) ； and

in response to receiving the response indicating at least partial acceptance of the transfer, transfer, to the target NF (20-B) , resources corresponding to the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) .
The source NF (20-A) of claim 16 wherein the processing circuitry (42) is further operable to cause the source NF (20-A) to perform the method of any one of claims 2 through 13.
A source Network Function, NF, (20-A) in a core network (18) of a wireless communication system (10) , comprising:

a processing unit (48) operable to cause the source NF (20-A) to provide, from the source NF (20-A) to a target NF (20-B) , information describing resources that the source NF (20-A) would like to transfer to the target NF (20-B) and receive, from the target NF (20-B) by the source NF (20-A) , a response indicating at least partial acceptance of a transfer of resources from the source NF (20-A) to the target NF (20-B) ； and

a transfer unit (50) operable to cause the source NF (20-A) to, in response to receiving the response indicating the at least partial acceptance of the transfer, transfer, from the source NF (20-A) to the target NF (20-B) , resources corresponding to the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) .
A method of operation of a target Network Function, NF, (20-B) in a core network (18) of a wireless communication system (10) , comprising:

receiving (200, 300) , from a source NF (20-A) by the target NF (20-B) , information describing resources that the source NF (20-A) would like to transfer to the target NF (20-B) ；

providing (202, 302A, 304) , from the target NF (20-B) to the source NF (20-A) , a response indicating at least partial acceptance of a transfer of resources from the source NF (20-A) to the target NF (20-B) ； and

in response to providing the response indicating the at least partial acceptance of the transfer, receiving (204, 306, 308) , from the source NF (20-A) by the target NF (20-B) , resources corresponding to the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) .
The method of claim 19 wherein providing the response indicating the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) comprises:

providing the response indicating full acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) .
The method of claim 19 wherein providing the response indicating the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) comprises:

providing the response indicating partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) .
The method of claim 21 wherein providing the response indicating the partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) further comprises:

providing an indication of a subset of the resources the target NF (20-B) is willing to have transferred from the source NF (20-A) .
The method of claim 22 wherein providing the indication of the subset of the resources the target NF (20-B) is willing to have transferred from the source NF (20-A) comprises:

providing the indication of the subset of the resources as at least one of the group consisting of a type of the resources, a location associated with the resources, a service type associated with the resources, and a number of the resources.
The method of any one of claims 19 through 23 wherein:

providing the response indicating the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) comprises providing a request to a Uniform Resource Indicator, URI, indicating the at least partial acceptance； and

receiving the resources corresponding to the at least partial acceptance comprises receiving one or more PUSH_PROMISE frames for the resources indicated by the at least partial acceptance.
The method of any one of claims 19 through 24 further comprising:

providing (206, 310) , to the source NF (20-A) by the target NF (20-B) , a request to transfer a single resource from the source NF (20-A) to the target NF (20-B) ； and

in response to providing the request to transfer the single resource, receiving (208, 312) , from the source NF (20-A) by the target NF (20-B) , the single resource corresponding to the request.
The method of claim 19 further comprising:

providing (210) , to the source NF (20-A) by the target NF (20-B) , a confirmation that a transfer of resources corresponding to the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) was successful.
The method of any one of claims 19 through 26 wherein the source NF (20-A) and the target NF (20-B) have the same NF type.
The method of claim 27 wherein the source NF (20-A) and the target NF (20-B) are Core Access and Mobility Management Function, AMF, NFs and the resources comprise a plurality of User Equipment, UE, contexts.
The method of any one of claims 19 through 28 wherein the wireless communication system is a Fifth Generation, 5G, wireless communication system.
A target Network Function, NF, (20-B) in a core network of a wireless communication system (10) , the target NF (20-B) adapted to:

receive, from a source NF (20-A) by the target NF (20-B) , information describing resources that the source NF (20-A) would like to transfer to the target NF (20-B) ；

provide, from the target NF (20-B) to the source NF (20-A) , a response indicating at least partial acceptance of a transfer of resources from the source NF (20-A) to the target NF (20-B) ； and

in response to providing the response indicating at least partial acceptance of the transfer, receive, from the source NF (20-A) by the target NF (20-B) , resources corresponding to the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) .
The target NF (20-B) of claim 30 wherein the target NF (20-B) is further adapted to perform the method of any one of claims 20 through 29.
A target Network Function, NF, (20-B) in a core network (18) of a wireless communication system (10) , comprising:

a communication interface (40) ； and

processing circuitry (42) associated with the communication interface (40) , wherein the processing circuitry (42) is operable to cause the target NF (20-B) to:

receive, from a source NF (20-A) by the target NF (20-B) , information describing resources that the source NF (20-A) would like to transfer to the target NF (20-B) ；

provide, from the target NF (20-B) to the source NF (20-A) , a response indicating at least partial acceptance of a transfer of resources from the source NF (20-A) to the target NF (20-B) ； and

in response to providing the response indicating the at least partial acceptance of the transfer, receive, from the source NF (20-A) by the target NF (20-B) , resources corresponding to the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) .
The target NF (20-B) of claim 32 wherein the processing circuitry (42) is further operable to cause the target NF (20-B) to perform the method of any one of claims 20 through 29.
A target Network Function, NF, (20-B) in a core network (18) of a wireless communication system (10) , comprising:

a processing unit (48) operable to cause the target NF to receive, from a source NF (20-A) , information describing resources that the source NF (20-A) would like to transfer to the target NF (20-B) and provide, from the target NF (20-B) to the source NF (20-A) , a response indicating at least partial acceptance of a transfer of resources from the source NF (20-A) to the target NF (20-B) ； and

a transfer unit (50) operable to cause the target NF (20-B) to, in response to providing the response indicating the at least partial acceptance of the transfer, receive, from the source NF (20-A) , resources corresponding to the at least partial acceptance of the transfer of resources from the source NF (20-A) to the target NF (20-B) .