Patent Description:
3GPP is currently standardizing the <NUM> Core Network as part of the overall <NUM> System architecture. The <NUM> Core Network is standardized in 3GPP TS <NUM> and <NUM>, and is composed of a set of certain functional entities, called Network Functions (NFs).

3GPP TS <NUM> describes a <NUM> System Architecture as a Service Based Architecture (SBA) for the control plane, a system architecture in which the system functionality is achieved by a set of NFs providing services to other authorized NFs to access their services. Control Plane (CP) Network Functions in the <NUM> System architecture are based on SBA. An NF service is one type of capability exposed by an NF (NF Service Producer) to other authorized NF (NF Service Consumer) through a service-based interface (SBI). An NF service may support one or more NF service operation(s). A service-based interface represents how the set of services is provided or exposed by a given NF. This is the interface where the NF service operations are typically invoked, and it is based on the HTTP/<NUM> protocol.

As provided in 3GPP TS <NUM> V15. <NUM>, NFStatusSubscribe/NFstatusNotify/ NFStatusUnsubscribe operations can be invoked by an NF Service Consumer (or "source NF") requesting to be notified about events (registration, deregistration, profile change) related to an NF instance (or "target NF") located in the same PLMN, or in a different PLMN.

Passages from 3GPP TS <NUM> V15. <NUM>, section <NUM>. <NUM>, which describe aspects of NRF service operation, are provided below:.

In particular, sections <NUM>. <NUM> to <NUM>. <NUM> relate to certain subscription and notification operations provided through the NRF:.

NOTE: Alternatively, other means such as OA&M can also be used to unsubscribe for NF status.

Additionally, section <NUM>. <NUM> relates to NF discovery services, passages of which are provided below:.

A summary Table <NUM>. <NUM>-<NUM> illustrates NF services currently provided by the NRF:.

According to embodiments, an update procedure for subscriptions is provided using an HTTP PATCH request to the resource that identifies the subscription as claimed in claims <NUM>,<NUM>,<NUM> and <NUM>. In certain aspects, by invoking this procedure, it is not necessary for the subscribing Network Function (NF) to wait until an existing subscription is terminated (by expiration of its validity time), and it is not necessary for the Network Repository Function (NRF) to create a brand new subscription, which can be computationally intensive depending on the particular subscription request.

According to embodiments, an NF Service Producer registers its profile in an NRF. A given NF Service Consumer, interested in invoking the services offered by such an NF Service Producer, creates a subscription in the NRF, and asks to be notified whenever the profile of that NF Service Producer is updated. As part of the subscription result reporting from the NRF, the NF Service Consumer receives an initial subscription validity time, after which the subscription can be considered as terminated at the NRF side. Based on this information, the NF Service Consumer, prior to the expiration of such initial subscription validity time, sends a PATCH request to the resource URI identifying the individual subscription resource. The payload body of the PATCH request can contain a "replace" operation on the "validityTime" attribute of the SubscriptionData structure. According to embodiments, the NRF, if it accepts the extension of the subscription validity time of the subscription, may answer with HTTP <NUM> No Content with an empty response body (e.g., if it accepts the proposed subscription validity time sent by the NF Service Consumer), or it may answer with HTTP <NUM> OK (if it does not accept the proposed subscription validity time, and requires a different subscription validity time; in this case, the new value is sent by the NRF to the NF Service Consumer as part of the HTTP response body, as part of the overall resource representation of the "subscription" resource).

According to embodiments, a method in a second node is provided, according to independent claim <NUM>. Further embodiments of the method are provided in dependent claims <NUM>-<NUM>.

According to embodiments, a method in a first node is provided, according to independent claim <NUM>. Further embodiments of the method are provided in dependent claims <NUM>-<NUM>.

According to embodiments, a node, such as an NRF or NF Service Consumer, is adapted to perform one or more the foregoing methods.

According to embodiments, a computer program is provided, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of the foregoing methods. According to embodiments, a carrier containing the computer program is provided, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

These and other features of the present disclosure will become apparent to those skilled in the art from the following detailed description of the disclosure, taken together with the accompanying drawings.

A <NUM> System reference architecture <NUM>, for instance as defined in 3GPP TS <NUM>, showing service-based interfaces used within the Control Plane, is depicted in <FIG>. In this example, not all NFs are necessarily depicted.

The Network Repository Function (NRF) is a key NF within the 5GC SBA Framework that provides support to service providers to register their services so that service consumers can dynamically discover them. The data that an NF provides to the NRF as part of its registration is called an "NF Profile," and comprises generic data associated to the specific NF instance, and also to the different NF service instances (HTTP services) that can be invoked.

The service discovery function enabled by an NRF provides the address of the NF instances that exist in a network for providing a service and all necessary information to issue and route requests towards the selected target NF producer (e.g., protocol, port, FQDN and/or IP address of target NF instance amongst other parameters required to create a URI used in the HTTP request).

The NFs interact with the NRF via two main services:.

Referring now to <FIG> illustrates a <NUM> network architecture <NUM> using service-based interfaces between the NFs in the control plane, according to some embodiments. In this example, the service(s) that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In <FIG>, the service-based interfaces are indicated by the letter "N" followed by the name of the NF, e.g. Namf for the service-based interface of the AMF and Nsmf for the service-based interface of the SMF, etc. <FIG> includes the Network Exposure Function (NEF) and the Network Repository Function (NRF).

As seen from the access side, the <NUM> network architecture shown in <FIG> 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 <NUM> base stations (gNBs) or similar. Seen from the core network side, the <NUM> core NFs shown in <FIG> 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).

Reference point representations of the <NUM> 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 reference points for connecting between AN and AMF and between AN and UPF are defined as N2 and N3, respectively. N4 is used by SMF and UPF so that the UPF can be set using the control signal generated by the SMF, and the UPF can report its state to the SMF. N9 is the reference point for the connection between different UPFs.

In many respects, the <NUM> core network aims at separating user plane and control plane. The user plane typically carries user traffic while the control plane carries signaling in the network. In <FIG>, the UPF is in the user plane and all other NFs shown, i.e., AMF, SMF, PCF, AF, AUSF, and UDM, are in the control plane. Separating the user and control planes helps each plane resource to be scaled independently. It also allows UPFs to be deployed separately from control plane functions in a distributed fashion. In this architecture, UPFs 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 <NUM> core network architecture is composed of modularized functions. For example, the AMF and SMF are independent functions in the control plane. Separated AMF and SMF allow independent evolution and scaling. Other control plane functions like PCF and AUSF can be separated as shown in <FIG>. Modularized function design enables the <NUM> core network to support various services flexibly.

Some properties of the NFs shown in <FIG> may be described in the following manner. The AMF provides UE-based authentication, authorization, mobility management, etc. A UE even using multiple access technologies is basically connected to a single AMF because the AMF is independent of the access technologies. The SMF is responsible for session management and allocates IP addresses to UEs. It also selects and controls the UPF for data transfer. 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 the PCF responsible for policy control in order to support Quality of Service (QoS). Based on the information, the PCF determines policies about mobility and session management to make AMF and SMF operate properly. The AUSF supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while UDM stores subscription data of UE. The Data Network (DN), not part of the <NUM> core network, provides Internet access or operator services and similar.

According to embodiments, an NF may be implemented either as a network element on 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.

According to embodiments, an NF (e.g., a "subscribing NF") creates a subscription in the NRF by providing a number of input criteria. Such input criteria may comprise:.

This information can be sent by the subscribing NF by means of an HTTP POST request to the NRF. For example, all input data can be sent in the HTTP request body, in the form of a JSON document.

Once the subscription is created, the NRF determines for how long the subscription is valid. After that time elapses, the subscription may be terminated.

In current systems, after a subscription has been created in the NRF, it is not possible to extend the subscription validity time, and the only way to keep the NF Service Consumer receiving the notifications is to create a new subscription when the former one has expired. This behavior is not optimal, and aspects of this disclosure provide systems and methods by which it is possible to extend an existing subscription for an additional time period.

Referring now to <FIG>, a messaging flow diagram according to embodiments is provided. <FIG> illustrates, for instance, how an HTTP PATCH message can be used to update an existing subscription in NRF.

According to embodiments, an extension request message may be sent from a first node (e.g., an NF Service Consumer) to a second node (e.g., an NRF) to extend the validity time of a subscription. The message may be, according to embodiments, an HTTP PATCH message that includes subscription information, such as subscription ID. The data may further include a requested extension of time, for instance, a new validity time corresponding to the subscription. According to embodiments, an NF Service Consumer sends an HTTP PATCH request to the resource URI identifying the individual subscription resource. The payload body of the PATCH request contains a "replace" operation on the "validityTime" attribute of the SubscriptionData structure and contains a new suggested value for it; no other attribute of the resource is updated as part of this operation, according to embodiments.

According to embodiments, the second node (e.g., the NRF) can respond in at least three ways, including:.

For instance, if the creation of the subscription fails at the NRF due to errors in the request body, the NRF could return "<NUM> Bad Request" status code with the details of the error. If the creation of the subscription fails at the NRF due to NRF internal errors, the NRF could return "<NUM> Internal Server Error" status code with the details of the error. According to embodiments, a full response, such as a <NUM> OK message may comprise additional data, including subscription ID and event type.

In one embodiment, responses 2a, 2b, and 2c of <FIG> may be defined as follows:.

Different specific messaging/content may be provided in other embodiments.

In certain aspects, the interaction between the subscribing NF and the NRF is more efficient, since the creation of a subscription may be a computationally intensive process (depending on the conditions for subscribing to sets/groups of NFs), and it can be more efficient to extend the lifetime of a subscription by updating the subscription validity time rather than having to re-create a new subscription.

Although <FIG> uses an NF Service Consumer and an NRF for the example, the messaging may be applied between different nodes and/or functions having a subscribe/notify pattern, including, for instance: any NF (e.g., AMF and SMF) that subscribes to UDM for the Subscribe Data Management service; any NF (e.g., NEF) that subscribes to UDM for the Event Exposure service; any NF (e.g., AMF) that subscribes to PCF for the AM Policy Control service; any NF (e.g., AF and NEF) that subscribes to PCF for the Policy Authorization service; any NF (e.g., SFM) that subscribes to NEF for the PFD Management service; any NF (e.g., AMF or SMF) that subscribes to SMF for the PDU Session service.

Similarly, <FIG> may be implemented with respect to such additional network functions and relationships. Additional examples are provided in 3GPP TS <NUM> V15. <NUM>, for instance in the service descriptions (e.g., <NUM>. <NUM>-<NUM>, Table <NUM>. <NUM>-<NUM>, and Table <NUM>. <NUM>-<NUM>). Aspects of the disclosure may be applied with respect to services listed by 3GPP TS <NUM> V15. <NUM> in Table <NUM>. <NUM>-<NUM> (Services of the NRF).

Referring now to <FIG>, a messaging flow diagram according to embodiments is provided. Such messaging <NUM> may be implemented, for instance, by one or more nodes <NUM>, <NUM>, and <NUM> as described with respect to <FIG> and <FIG>.

In certain aspects, subscription to notifications on NF Instances can be updated. Such updates can include an update to refresh the validity time when the time is about to expire. For example, an NF Service Consumer <NUM> may request a new validity time to the NRF <NUM>, and the NRF <NUM> may answer with the new assigned validity time, if the operation is successful. In some embodiments, this operation is executed by updating the resource identified by "subscriptionID," and is invoked by issuing an HTTP PATCH request on the URI representing the individual resource. The messaging illustrated with respect to <FIG> can provide for management of notifications for a first node <NUM>. For instance, second node <NUM> (e.g., an NRF) may handle subscription information and updates for one or more subscribing nodes <NUM> (e.g., an NF Service Consumer) that subscribe to notifications, including updates relating to a set of services or functions, which may correspond to a third node <NUM> (e.g., NF Service Producer).

According to some embodiments, the process may begin with a first node <NUM>, such as an NF Service Consumer, sending a message <NUM>. This message can be a subscription message, for example, to register and obtain updates to services. Such services could include those provided by node <NUM>, such as an NF Service Producer. In certain aspects, the message <NUM> is an HTTP POST message, which can include an Instance ID for the network function. With message <NUM>, the second node <NUM>, such as an NRF, can respond. Such a response can indicate a successful subscription. This can be a <NUM> Created response, in some instances, and may include one or more of a subscription ID and subscription validity time. As part of this process, the node <NUM> may determine an appropriate set of functions, such as from NF Service Producers, that meet the subscription request indicated by message <NUM>. Node <NUM> may also generate a token for the subscription, which may be the Subscription ID.

Subsequently, for instance when the subscription validity time is about to expire, node <NUM> may send another message <NUM> to update the subscription. According to embodiments, the message <NUM> is an HTTP PATCH. This message can include, for example, both the Subscription ID and a requested extension to the corresponding subscription validity time. The second node <NUM> (e.g., the NRF) can respond with message <NUM>. According to embodiments, the message <NUM> indicates a status of the request provided in message <NUM>. The message may comprise:.

An example of messages <NUM> and <NUM> is provided below:
<IMG>.

Although illustrated as an HTTP <NUM> message in this example, according to embodiments, the message <NUM> can be an HTTP <NUM> message:
<IMG>.

According to some embodiments, node <NUM> responds in message <NUM> with a different validity time than requested by node <NUM>.

The node <NUM> may also perform one or more determinations to evaluate the validity of the requested extension, including determining availability of one or more resources or any applicable restrictions/authorization requirements. The message <NUM> may be based on such a determination.

The messaging <NUM> may conclude, according to embodiments, with the expiration of the subscription.

In some embodiments, messaging <NUM> may also include messages <NUM> and <NUM>. These messages may come before messages <NUM>-<NUM>, and register one or more services with the node <NUM>. Message <NUM> may be, for instance an HTTP PUT, and message <NUM> may indicate a successful registration with respect to such services.

Referring now to <FIG>, a process <NUM> is provided according to embodiments. Process <NUM> may be implemented, for instance, by one or more nodes <NUM>, <NUM>, and <NUM> as described with respect to <FIG> and <FIG>. For example, process <NUM> may be performed by an NRF.

Process <NUM> may begin, for example, at step <NUM> in which a first message is received. The message may be a request for a subscription, and may be an HTTP POST message such as message <NUM> described with respect to <FIG>. In step <NUM>, a second message is sent. This message may comprise a subscription ID for the subscription, and may correspond to message <NUM> described with respect to <FIG>. In step <NUM>, a third message is received, which comprises a time extension request (i.e., a request to extend the subscription validity time) corresponding to the subscription. This message may correspond to message <NUM> described with respect to <FIG>. According to some embodiments, the process <NUM> may optionally include step <NUM>, in which a fourth message is sent that indicates an updated validity time for the subscription, such as message <NUM> of <FIG>. In some instances, a fourth message may be sent that indicates a problem with the request.

Referring now to <FIG>, a process <NUM> is provided according to embodiments. Process <NUM> may be implemented, for instance, by one or more nodes <NUM>, <NUM>, and <NUM> as described with respect to <FIG> and <FIG>. For example, process <NUM> may be performed by an NF Service Consumer.

Process <NUM> may begin, for example, at step <NUM> in which a first message is sent. The message may be a request for a subscription, and may be an HTTP POST message such as message <NUM> described with respect to <FIG>. In step <NUM>, a second message is received. This message may comprise a subscription ID for the requested subscription, and may correspond to message <NUM> described with respect to <FIG>. In step <NUM>, a third message is sent, which comprises a time extension request (i.e., a request to extend the subscription validity time) corresponding to the subscription. This message may correspond to message <NUM> described with respect to <FIG>. According to some embodiments, the process <NUM> may optionally include step <NUM>, in which a fourth message is received that indicates an updated validity time for the subscription, such as message <NUM> of <FIG>. In some instances, a fourth message may be received that indicates a problem with the request.

<FIG> is a diagram showing functional modules of a first node, such as node <NUM> (e.g., an NF Service Consumer), according to some embodiments. As shown in <FIG>, the first node comprises one or more of a sending unit <NUM> and a receiving unit <NUM>. According to embodiments, sending unit <NUM> is arranged to send messages, such as messages <NUM> and <NUM> and as described with respect to steps <NUM> and <NUM> of <FIG>. According to embodiments, receiving unit <NUM> is arranged to received messages, such as messages <NUM> and <NUM> and as described with respect to step <NUM>, and in some cases, step <NUM>. Similarly, the first node may be adapted to send and/or receive the messages set forth in <FIG>.

<FIG> is a diagram showing functional modules of a second node, such as node <NUM> (e.g., an NRF), according to some embodiments. As shown in <FIG>, the second node comprises one or more of a sending unit <NUM> and a receiving unit <NUM>. According to embodiments, sending unit <NUM> is arranged to send messages, such as messages <NUM> and <NUM> and as described with respect to steps <NUM> and optionally <NUM> of <FIG>. According to embodiments, receiving unit <NUM> is arranged to receive messages, such as messages <NUM> and <NUM> and as described with respect to steps <NUM> and <NUM>. Similarly, the second node may be adapted to send and/or receive the messages set forth in <FIG>.

<FIG> is a block diagram of a node, such as the first node <NUM> (e.g. NF Service Consumer), second node <NUM> (e.g. NRF), or third node <NUM> (NF Service Producer) according to some embodiments. As shown in <FIG>, the node may comprise: a data processing apparatus (DPA) <NUM>, which may include one or more processors (P) <NUM> (e.g., a general purpose microprocessor and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like); a transmitter <NUM> and a receiver <NUM> coupled to an antenna <NUM> for enabling the node to transmit data to and receive data from an AN node (e.g., base station); and local storage unit (a. , "data storage system") <NUM>, which may include one or more non-volatile storage devices and/or one or more volatile storage devices (e.g., random access memory (RAM)). In embodiments where the node includes a general purpose microprocessor, a computer program product (CPP) <NUM> may be provided. CPP <NUM> includes a computer readable medium (CRM) <NUM> storing a computer program (CP) <NUM> comprising computer readable instructions (CRI) <NUM>. CRM <NUM> may be a non-transitory computer readable medium, such as, but not limited, to magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory), and the like. In some embodiments, the CRI <NUM> of computer program <NUM> is configured such that when executed by data processing apparatus <NUM>, the CRI causes the node to perform steps described above (e.g., steps described above with reference to the flow charts). In other embodiments, the node may be configured to perform steps described herein without the need for code. That is, for example, data processing apparatus <NUM> may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

According to embodiments, aspects of an API are provided, for instance, with respect to network function management, such as an Nnrf_NFManagement API. An example comprises the following:
/subscriptions/{subscriptionID}:
patch:
summary: Updates a subscription
operationid: UpdateSubscription
tags:
- Subscription ID (Document)
parameters:
- name: subscriptionID
in: path
required: true
description: Unique ID of the subscription to update
schema:
type: string
pattern: '^([<NUM>-<NUM>]{<NUM>,<NUM>}-)?[^-]+$'
requestBody:
content:
application/json-patch+json:
schema:
type: array
items:
$ref:
'TS29571_CommonData. yaml#/components/schemas/PatchItem'
required: true
responses:
'<NUM>' :
description: Expected response to a valid request
content:
application/json:
schema:
$ref: '#/components/schemas/SubscriptionData'
'<NUM>' :
$ref: 'TS29571_CommonData. yaml#/components/responses/<NUM>'
'<NUM>' :
$ref: 'TS29571_CommonData. yaml#/components/responses/<NUM>'
'<NUM>' :
$ref: 'TS29571_CommonData. yaml#/components/responses/<NUM>'
'<NUM>' :
$ref: 'TS29571_CommonData. yaml#/components/responses/<NUM>'
'<NUM>' :
$ref: 'TS29571_CommonData. yaml#/components/responses/<NUM>'
'<NUM>' :
$ref: 'TS29571_CommonData. yaml#/components/responses/<NUM>'
'<NUM>' :
$ref: 'TS29571_CommonData. yaml#/components/responses/<NUM>'
'<NUM>' :
$ref: 'TS29571_CommonData. yaml#/components/responses/<NUM>'
'<NUM>' :
$ref: 'TS29571_CommonData. yaml#/components/responses/<NUM>'
default:
$ref:
'TS29571_CommonData. yaml#/components/responses/default'
delete:
summary: Deletes a subscription
operationId: RemoveSubscription
tags:
- Subscription ID (Document)
parameters:
- name: subscriptionID
in: path
required: true
description: Unique ID of the subscription to remove
schema:
type: string
pattern: '^([<NUM>-<NUM>]{<NUM>,<NUM>}-)?[^-]+$'.

While various embodiments of the present disclosure are described herein, it should be understood that they have been presented by way of example only, and not limitation. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

Claim 1:
A method (<NUM>) in a second node, comprising:
receiving (<NUM>), from a first node, a first message, wherein said first message is a request for a subscription;
sending (<NUM>), to said first node, a second message, wherein said second message comprises a subscription ID for the subscription, wherein said second message comprises an initial subscription validity time; and
receiving (<NUM>), from said first node, a third message, wherein said third message comprises a new subscription validity time for said subscription, further comprising:
sending (<NUM>), in response to said third message, a fourth message indicating that the second node accepts an extension of a lifetime of the subscription, wherein the fourth message is an HTTP <NUM> No Content message with an empty response body and indicates accepting the new subscription validity time for said subscription, and wherein said second node is a Network Repository Function, NRF (<NUM>), and said first node is a NF Service Consumer (<NUM>).