Patent ID: 12245192

DETAILED DESCRIPTION

FIG.1is a block diagram illustrating an exemplary 5G system network architecture. The architecture inFIG.1includes NRF100and SCP101, which may be located in the same home public land mobile network (HPLMN). As described above, NRF100may maintain profiles of available NF instances and their supported services and allow consumer NFs or SCPs to subscribe to and be notified of the registration of new/updated NF instances. SCP101may also support service discovery and selection of NF instances. SCP101may perform load balancing of connections between consumer and producer NFs.

NRF100is a repository for profiles of NF instances. In order to communicate with a producer NF instance, a consumer NF or an SCP must obtain the NF profile of the producer NF instance from NRF100. The NF profile is a JavaScript object notation (JSON) data structure defined in 3GPP TS 29.510. The NF profile includes attributes that indicate the type of service provided, capacity of the NF instance, and information for contacting the NF instance.

InFIG.1, any of the network functions can be consumer NFs, producer NFs, or both, depending on whether they are requesting, providing, or requesting and providing services. In the illustrated example, the NFs include a policy control function (PCF)102that performs policy related operations in a network, a unified data management function (UDM)104that manages user data, and an application function (AF)106that provides application services.

The NFs illustrated inFIG.1further include a session management function (SMF)108that manages sessions between access and mobility management function (AMF)110and PCF102. AMF110performs mobility management operations similar to those performed by a mobility management entity (MME) in 4G networks. An authentication server function (AUSF)112performs authentication services for user equipment (UEs), such as user equipment (UE)114, seeking access to the network.

A network slice selection function (NSSF)116provides network slicing services for devices seeking to access specific network capabilities and characteristics associated with a network slice. A network exposure function (NEF)118provides application programming interfaces (APIs) for application functions seeking to obtain information about Internet of things (loT) devices and other UEs attached to the network. NEF118performs similar functions to the service capability exposure function (SCEF) in 4G networks.

A radio access network (RAN)120connects user equipment (UE)114to the network via a wireless link. RAN120may be accessed using a g-Node B (gNB) (not shown inFIG.1) or other wireless access point. A user plane function (UPF)122can support various proxy functionality for user plane services. One example of such proxy functionality is multipath transmission control protocol (MPTCP) proxy functionality. UPF122may also support performance measurement functionality, which may be used by UE114to obtain network performance measurements. Also illustrated inFIG.1is a data network (DN)124through which UEs access data network services, such as Internet services.

SEPP126filters incoming traffic from another PLMN and performs topology hiding for traffic exiting the home PLMN. SEPP126may communicate with a SEPP in a foreign PLMN which manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs may traverse two SEPP functions, one for the home PLMN and the other for the foreign PLMN.

As stated above, one problem with the current NRF architecture is that there is no mechanism for the NRF to avoid sending duplicate notifications for overlapping subscriptions. Subscriptions are created at the NRF using the NFStatusSubscribe service operation defined in 3GPP TS 29.510.FIG.2is a message flow diagram illustrating exemplary messages exchanged in the NFStatusSubscribe service operation. Referring toFIG.2, In line1of the message flow diagram, an NF service consumer200initiates the NFStatusSubscribe service operation by sending an HTTP POST message to NRF100. The HTTP POST message contains subscription data used by NRF100to generate notifications. The subscription data can include information that indicates the target NF instance and/or NF set and the type of events for which notification is requested. The subscription data may also include a callback URI at which NF service consumer200is prepared to receive notifications from NRF100.

NRF100receives the subscription creation request and stores the subscription data in a subscription database. When an event occurs, NRF100checks the subscription data in the subscription database against attributes associated with the event to determine whether to generate notification messages and where to send the notification messages.

If creation of the subscription is successful, NRF100responds as indicated in line2awith a 201 Created message. The 201 Created message includes a subscription ID that consumer NF200can use to identify the subscription for subsequent modification or deletion requests. If creation of the subscription is not successful or if the request is redirected, NRF100responds as indicated in line2bwith a 4xx or 5xx message indicating problem details. If NRF100redirects the subscription request to another PLMN, NRF100responds with a 3xx message indicating redirection. It should be noted that whileFIG.2illustrates the creation of a subscription by an NRF located in the same PLMN as the subscribing consumer NF, subscriptions can also be created between consumer NFs and NRFs in different PLMNs.

When NRF100detects an event, such as an NFRegister, NFUpdate, or NFDeregister event that corresponds to subscription conditions for one of the subscriptions created using the messaging illustrated inFIG.2, NRF100performs the NFStatusNotify service operation to notify consumer NFs of the event.FIG.3is a message flow diagram illustrating exemplary messages exchanged in an NFStatusNotify service operation. Referring toFIG.3, when NRF100detects that conditions associated with a subscription have been met, NRF100sends an HTTP POST request to the callback URI identified in the subscription conditions, as indicated by line1of the message flow diagram. The HTTP POST request may contain the NfInstance URI of the NF instance, an indication of the event being notified, and, if the event relates to a newly registered NF, NF profile data for the NF. Consumer NF200responds as indicated in line2awith a 204 No Content message if the notification request is successful. If the notification request is not successful, consumer NF200responds as indicated in line2bwith a 4xx or 5xx message with problem details. If the notification request is redirected, consumer NF200responds with a 3xx message indicating redirection.

One problem with the service operations illustrated inFIGS.2and3is that a consumer NF can intentionally or unintentionally create overlapping subscriptions and the NF may respond with duplicate notification messages when an event matches subscription conditions associated with more than one subscription.FIG.4is a message flow diagram illustrating the creation of overlapping subscriptions with the NRF. Referring toFIG.4, in line1of the message flow diagram, consumer NF200sends a subscription request message to NRF100. In one example, the subscription criteria in the subscription request may identify target NF set #1. In line2of the message flow diagram, NF service consumer200sends another subscription request to NRF100. It is assumed that the subscription request includes subscription criteria that overlaps with the subscription criteria the subscription request in line1. For example, the overlapping subscription request may include subscription criteria that identifies target NF instance #1a, where target NF instance #1ais a member of NF set #1identified by the subscription request in line1.

The results of overlapping subscription requests are duplicate notifications, as illustrated byFIG.5. InFIG.5, it is assumed that NRF100detects an event matching the subscription data corresponding to both subscriptions created inFIG.4. Because NRF100has no way to detect overlapping subscriptions or refrain from sending duplicate notifications, in line1, NRF100sends a first notification request to consumer NF200and corresponding to the subscription created in line1ofFIG.4. In line2ofFIG.5, NRF100sends a second notification request to NF200and corresponding to the subscription created in line2ofFIG.4. The first notification request and the second notification request include identical content. For example, if an event is triggered by an NFUpdate request for NF instance #1a, the event will match the subscription data for the NF set created by the subscription in line1ofFIG.4and the subscription data for the NF instance created for the NF instance in line2ofFIG.4.

To address this issue of overlapping subscriptions and duplicate notifications, an NRF as described herein is capable of analyzing subscription data when an event occurs, detecting overlapping subscriptions, and refraining from sending duplicate notifications for subscriptions identified as overlapping. For example, when processing an NF status change event (i.e., an NFRegister, NFDeregister, or NFUpdate event), the NRF will identify duplicate notifications by identifying duplicity in the nfStatusNotificationUri attribute value defined in 3GPP TS 29.510 Section 6.1.6.2.16 Type: SubscriptionData. Section 6.1.6.2.16 defines the nfStatusNotificationUri as follows:

AttributeDataCardi-nametypePnalityDescriptionnfStatusNotificationUriUriM1Callback URI wherethe NF ServiceConsumer willreceive thenotificationsfrom NRF.

As indicated in the table above, the nfStatusNotificationUri contains the callback URI where the NF service consumer receives notifications (for matching subscriptions) from the NRF. Overlapping subscriptions for with the same nfStatusNotificationUri should be identified when an event occurs to avoid sending duplicate notifications.

Overlapping subscriptions can be created by specifying overlapping attribute values in the SubscriptionData defined for a subscription for the same nfStatusNotificationUri. For example, the subscrCond attribute is defined as follows:

AttributeDataCardi-NameTypePnalityDescriptionsubscrCondSubscrCondO0 . . . 1If present, this attributedshall contain the conditionsidentifying the set of NFInstances whose status isrequested to be monitored.If this attribute is notpresent, it means that theNF Service Consumerrequests a subscription toall NFs in the NRF (NOTE 1).

As indicated in the table, the subscrCond attribute contains data that identifies conditions identifying the set of NF instances whose status is requested to be monitored. If the subscrCond attribute for one subscription identifies an NF instance, the subscrCond attribute for another subscription identifies an NF set of which the NF instance is a member, and the subscriptions identify the same nfStatusNotificationUri, the subscriptions are overlapping. When an event occurs concerning the NF instance, without the duplicate notification avoidance mechanism described herein, the NRF will send duplicate notifications to the nfStatusNotificationUri.

Rather than analyzing each subscription and consolidating the subscriptions, the NRF as described herein identifies duplicate subscriptions at the time that an event occurs by generating a list of subscriptions whose conditions are satisfied by an event, identifying overlapping subscriptions as those that have the same nfStatusNotificationUri, and removing overlapping subscriptions from the list. After overlapping subscriptions have been identified and removed from the list, the NRF sends only a single notification per subscribed nfStatusNotificationUri.

FIG.6is a flow chart illustrating exemplary steps performed by the NRF to avoid the sending of duplicate notifications for overlapping subscriptions. Referring toFIG.6, in step600, the process includes detecting the occurrence of an NF event. The event may be an NFRegister service operation, an NFDeregister service operation, or an NFUpdate service operation affecting one or more NF instances. The NFRegister, NFUpdate, and NFDeregister service operations are defined in 3GPP TS 29.510 and involve the sending of an NFRegister, NFDeregister, or NFUpdate request message to the NRF. The NFRegister, NFDeregister, or NFUpdate request message includes attribute values that are used by the NRF to identify the NF profile of the NF instance or NF instances being registered, updated, or deregistered. The attribute values are also used by the NRF to determine whether the event matches the conditions associated with any subscriptions maintained by the NRF.

In step602, the process includes iterating through all subscriptions managed by the NRF to match subscription conditions against the NF event. In this step, the NRF compares the SubscriptionData object attribute values to data associated with the event received in the request message from the producer NF that triggered the event. The result of step602is a list of subscriptions matching the event.

In step604, the process includes iterating through the list prepared in step602, identifying entries with the same nfStatusNotificationUri, and removing duplicate entries so that only a single entry remains per nfStatusNotificationUri.

In step606, the process includes generating and sending notifications for all list entries remaining after step604is executed. Step606involves using the NFStatusNotify service operation illustrated inFIG.3to send an NFStatusNotify request message for each entry remaining in the list. Because duplicate entries were removed, only a single notification per nfStatusNotificationUri is sent. As a result, network traffic and unnecessary processing at the consumer NF corresponding to the nfStatusNotificationUri are reduced.

FIG.7is a message flow diagram illustrating an example of overlapping subscriptions and duplicate notification avoidance by the NRF. Referring toFIG.7, In step1, a target NF instance #1a202registers its NF profile with NRF100. In step2, NRF100responds with a 201 Created message.

In step3, subscribing NF instance200subscribes with NRF100to receive notification of all events concerning NF set #1of which target NF instance #1a202is a member. In step4, NRF100responds with a 201 Created message.

In step5of the message flow diagram, subscribing NF instance200sends another NFStatusSubscribe message to NRF100subscribing to receive notification of all events concerning NF instance #1a202. In step6, NRF100responds with a 201 Created message indicating that the second subscription has been created.

In step7, target NF instance #1a202updates its NF profile with NRF100by sending an NFUpdate request message to NRF100. In step8, NRF100responds with a 200 OK message.

In step9, NRF100determines that the NFUpdate event matches subscription conditions associated with subscription #1and subscription #2and generates a list of the matching subscriptions. The following table illustrates exemplary data that may be included in the list.

Subscription IDnfStatusNotificationUriSubscription #1SubscribingNFInstance_200Subscription #2SubscribingNFInstance_200

In the table, it can be seen that entries in the list for two subscriptions, subscription #1and subscription #2, have the same nfStatusNotificationUri attribute value. NRF100removes one of the entries from the list such that only a single entry exists with the same nfStatusNotificationUri. The following table illustrates the result of removing one of the entries from the list of matching subscriptions.

Subscription IDnfStatusNotificationUriSubscription #1SubscribingNFInstance_200

After removing the duplicate entry from the list, NRF100sends an NFStatusNotify request message corresponding to the single subscription remaining in the list. In the illustrated example, in step10, NRF100sends an NFStatusNotify request message concerning subscription #1to subscribing NF instance200. NRF100avoids sending the duplicate notification request message for subscription #2. In step11, subscribing NF instance200responds with a 200 OK message.

FIG.8is a message flow diagram illustrating another example of overlapping subscriptions and duplicate notification avoidance by the NRF. Referring toFIG.8, In step1, a target NF instance #1a202registers its NF profile with NRF100. In step2, NRF100responds with a 201 Created message.

In step3, a subscribing NF instance200subscribes with NRF100to receive notification of all events concerning target NF instance #1a202. Subscribing NF instance200may subscribe to receive notification of all events concerning NF instance #1a202by specifying a subscrCond attribute value identifying target NF instance #1a202and no reqNotifEvents attribute. By not specifying a reqNotifEvents attribute, subscribing NF instance202subscribes to all events concerning target NF instance #1a202by default. In step4, NRF100responds with a 201 Created message.

In step5of the message flow diagram, subscribing NF instance200sends another NFStatusSubscribe message to NRF100subscribing to receive all notification of NFUpdate events concerning NF instance #1a202. NFUpdate events may be subscribed to by specifying a reqNotifEvents attribute value indicating NFUpdate. In step6, NRF100responds with a 201 Created message indicating that the second subscription has been created.

In step7, target NF instance #1a202updates its NF profile with NRF100by sending an NFUpdate request message to NRF100. In step8, NRF100responds with a 200 OK message.

In step9, NRF100determines that the NFUpdate event matches subscription conditions associated with subscription #1and subscription #2and generates a list of the matching subscriptions. The following table illustrates exemplary data that may be included in the list.

Subscription IDnfStatusNotificationUriSubscription #1SubscribingNFInstance_200Subscription #2SubscribingNFInstance_200

In the table, it can be seen that entries for two subscriptions, subscription #1and subscription #2, have the same nfStatusNotificationUri attribute value. NRF100removes one of the entries from the table such that only a single entry exists with the same nfStatusNotificationUri. The following table illustrates the result of removing one of the entries from the list of matching subscriptions.

Subscription IDnfStatusNotificationUriSubscription #1SubscribingNFInstance_200

After removing the duplicate entry from the list, NRF100sends an NFStatusNotify request message corresponding to the single subscription remaining in the list. In the illustrated example, in step10, NRF100sends an NFStatusNotify request message concerning subscription #1to subscribing NF instance200. NRF100avoids sending the duplicate notification request message for subscription #2. In step11, subscribing NF instance200responds with a 200 OK message.

FIG.9is a block diagram illustrating an exemplary architecture for an NRF that avoids the sending of duplicate notifications for overlapping subscriptions. Referring toFIG.9, NRF100includes at least one processor900and a memory902. NRF100further includes an NF profiles database904that stores the NF profiles of NFs that have registered with NRF100. NRF100further includes a subscription database906that contains subscriptions that have been created by subscribing NFs within NRF100. NF profiles database904and subscription database906may be stored in memory902. NRF100further includes a duplicate notification avoidance controller908that performs the steps described herein for awarding sending of duplicate notification messages for overlapping subscriptions. Duplicate notification avoidance controller908may be implemented using computer executable instructions stored in memory902and executed by processor900.

Exemplary advantages of the subject matter described herein include the avoidance of duplicate notification messages being sent over the network caused by overlapping subscriptions. Avoiding duplicate notification messages reduces network traffic and decreases the processing load on subscribing NFs. In addition, because the NRF is capable of avoiding unnecessary notification messages by generating the list of subscriptions matching an event and using the nfStatusNotificationUri value in the list of matching subscriptions to identify duplicates, processing at the NRF is also optimized. For example, the NRF can use existing subscription condition comparison logic to generate the list and iterate through the list using only the nfStatusNotificationUri to identify duplicates.

The disclosure of each of the following references is hereby incorporated herein by reference in its entirety.

REFERENCES

1. 3rdGeneration Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 17) 3GPP TS 29.510 V17.6.0 (2022 June)’2. 3rdGeneration Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2; (Release 17) 3GPP TS 23.501 V17.5.0 (2022-06)

It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.