Methods, systems, and computer-readable media for providing service-based interface (SBI) support for network functions (NFs) that do not support SBI service operations

Abstract

A method for providing service-based interface (SBI) support for a network element (NE) that does not support SBI service operations includes receiving SBI configuration parameters for the NE that does not support SBI service operations. The method also includes establishing a connection with the NE that does not support SBI service operations. The method also includes registering the NE that does not support SBI service operations with a network function (NF) repository function (NRF) using the SBI configuration parameters. The method also includes monitoring a status of the NE that does not support SBI service operations over the connection. The method also includes updating the status of the NE that does not support SBI service operations to the NRF.

Description

[0001] Priority Declaration

[0002] This application claims the benefit of priority to U.S. Patent Application Serial No. 17 / 219,366, filed on March 31, 2021, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] This document describes topics related to interoperability in communication networks. More specifically, it describes methods, systems, and computer-readable media for providing SBI support to NFs that do not support SBI service operations. Background Technology

[0004] In 5G telecommunications networks, network functions that provide services are referred to as producer network functions (NFs) or NF service producers. Network functions that consume services are referred to as consumer NFs or NF service consumers. A network function can be a producer NF, a consumer NF, or both, depending on whether the network function consumes, produces, or both consumes and produces services. The terms "producer NF" and "NF service producer" are used interchangeably herein. Similarly, the terms "consumer NF" and "NF service consumer" are used interchangeably herein.

[0005] A given producer NF may have many service endpoints, where a service endpoint is a contact point for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of an Internet Protocol (IP) address and port number, or by a fully qualified domain name that resolves to the IP address and port number on the network node hosting the producer NF. An NF instance is an instance of the producer NF that provides a service. A given producer NF may include more than one NF instance. It should also be noted that multiple NF instances can share the same service endpoint.

[0006] Producer NFs register with the Network Functions Store (NRF). The NRF maintains service profiles that identify available NF instances and the services supported by each NF instance. The terms "service profile" and "NF profile" are used interchangeably herein. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.

[0007] Besides consumer NFs, another type of network node that can subscribe to receive information about NF service instances is the Service Communication Agent (SCP). The SCP subscribes to the NRF and obtains reachability and service profile information about producer NF service instances. Consumer NFs connect to the Service Communication Agent, which load balances traffic between producer NF service instances providing the required services, or directly routes traffic to the destination producer NF instance.

[0008] Besides SCP, another example of an intermediate proxy node that routes traffic between producer and consumer NFs is the Secure Edge Protection Proxy (SEPP). The SEPP is a network node used to protect control plane traffic exchanged between different 5G Public Land Mobile Networks (PLMNs). The SEPP performs message filtering, control, and topology hiding on all Application Programming Interface (API) messages transmitted between PLMNs.

[0009] A problem arises in 5G communication networks when interacting with network functions that do not support SBI service operations. In 5G networks, service-based interfaces are the interfaces through which 5G network elements, called NFs, communicate with each other. 3GPP standards, such as 3GPP Technical Specification (TS) 29.510, define operations performed via SBIs, referred to as service operations. Examples of service operations include the NFRegister service operation, which allows NFs to register their identity using the NF repository function; the NFUpdate operation, which allows NFs to update their state using the NRF; and the NF Heart-Beat operation, a subset of the NFUpdate operation that allows NFs to periodically communicate their availability to the NRF. Another NF service operation is the NFDiscover service operation, which allows other NFs to discover the identity and other attributes of NFs registered with the NRF.

[0010] In non-5G networks, there is no concept of registering network elements or network functions with the NRF. However, interaction with non-SBI network elements such as the 4G / 5G Equipment Identity Register (EIR), Application Function (AF), or Application Server (AS) that do not support SBI service operations may be desired. State updates for such nodes may also need to be provided to the 5G NF. However, since non-SBI NEs do not use SBI service operations for communication, it is impossible to inform the 5G NF of the identity or status of non-SBI NEs.

[0011] In view of these and other difficulties, there is a need for a method, system, and computer-readable medium to provide SBI support for NEs that do not support SBI service operations. Summary of the Invention

[0012] A method is provided for providing SBI support for network elements (NEs) that do not support Service-Based Interface (SBI) service operations, including receiving SBI configuration parameters for the NE that does not support SBI service operations. The method includes establishing a connection with the NE that does not support SBI service operations. The method also includes registering the NE that does not support SBI service operations with a Network Function (NF) repository function (NRF) using the SBI configuration parameters. The method further includes monitoring the status of the NE that does not support SBI service operations via the connection. The method also includes updating the status of the NE that does not support SBI service operations with the NRF.

[0013] According to another aspect of the subject matter described herein, receiving SBI configuration parameters includes receiving NF profile parameters for creating NF profiles for NEs that do not support SBI service operations.

[0014] According to another aspect of the subject matter described herein, registering an NE that does not support SBI service operations includes performing an NFRegister service operation on behalf of the NE that does not support SBI service operations to the NRF.

[0015] According to another aspect of the subject matter described herein, performing an NFRegister service operation involves sending a Hypertext Transfer Protocol (HTTP) PUT message to the NRF, which includes an NF profile for an NE that does not support SBI service operations.

[0016] According to another aspect of the subject matter described herein, establishing a connection with a NE that does not support SBI service operations includes establishing a transport layer connection between the Interoperability Function (IWF) and the NE that does not support SBI service operations.

[0017] According to another aspect of the subject matter described herein, monitoring the status of a NE that does not support SBI service operations includes the IWF exchanging Diameter watchdog messages with the NE that does not support SBI service operations via a connection.

[0018] According to another aspect of the subject described herein, updating the status of an NE that does not support SBI service operations with the NRF to the NRF includes performing an NF Heart-Beat service operation on behalf of the NE that does not support SBI service operations with the NRF.

[0019] According to another aspect of the subject matter described herein, monitoring the status of an NE that does not support SBI service operations includes detecting the availability of an NE that does not support SBI service operations using the NE's native protocol, and performing NF heartbeat service operations includes sending a Hypertext Transfer Protocol (HTTP) PATCH message to the NRF within the heartbeat interval, and instructing a replacement operation for the nfStatus attribute of the NF profile of the NE that does not support SBI service operations, with the value of the nfStatus attribute being REGISTERED.

[0020] According to another aspect of the subject matter described herein, updating the state of an NE that does not support SBI service operations to the NRF includes performing an NFUpdate service operation on behalf of the NE that does not support SBI service operations to the NRF.

[0021] According to another aspect of the subject matter described herein, monitoring the status of an NE that does not support SBI service operations includes using the native protocol of the NE that does not support SBI service operations to detect the unreachability of the NE that does not support SBI service operations, and wherein performing an NFUpdate service operation on behalf of the NE that does not support SBI service operations includes sending a Hypertext Transfer Protocol (HTTP) PATCH message to the NRF indicating a replacement operation of the nfStatus attribute of the NF profile of the NE that does not support SBI service operations and the value of the nfStatus attribute being UNDISCOVERABLE.

[0022] According to another aspect of the subject matter described herein, a system for providing SBI support for network elements (NEs) that do not support Service-Based Interface (SBI) service operations includes a cloud-native core console (CNCC) for receiving SBI configuration parameters for NEs that do not support SBI service operations and registering the NEs that do not support SBI service operations with a Network Function (NF) repository function (NRF) using the SBI configuration parameters. The system also includes an Interworking Function (IWF) for establishing connections with the NEs that do not support SBI service operations and monitoring the status of the NEs that do not support SBI service operations through these connections. The CNCC is configured to update the status of the NEs that do not support SBI service operations by sending updates to the NRF and monitoring the status based on the IWF.

[0023] According to another aspect of the subject described in this article, CNCC is configured to receive NF profile parameters for creating NF profiles for NEs that do not support SBI service operations.

[0024] According to another aspect of the subject matter described herein, CNCC is configured to register NEs that do not support SBI service operations by performing an NFRegister service operation on behalf of an NE that does not support SBI service operations to the NRF.

[0025] According to another aspect of the subject matter described herein, CNCC is configured to perform the NFRegister service operation by sending a Hypertext Transfer Protocol (HTTP) PUT message to NRF that includes an NF profile for NEs that do not support SBI service operations.

[0026] According to another aspect of the subject matter described herein, connections to NEs that do not support SBI service operations include transport layer connections.

[0027] According to another aspect of the subject matter described herein, the IWF is configured to monitor the status of NEs that do not support SBI service operations by exchanging Diameter watchdog messages with NEs that do not support SBI service operations on the connection.

[0028] According to another aspect of the subject matter described herein, CNCC is configured to update the state of NEs that do not support SBI service operations with NRF by performing an NF heartbeat service operation with NRF on behalf of NEs that do not support SBI service operations.

[0029] According to another aspect of the subject matter described herein, the IWF is configured to monitor the status of NEs that do not support SBI service operations by using the native protocol of the NE that does not support SBI service operations, and the CNCC is configured to perform NF heartbeat service operations by sending a Hypertext Transfer Protocol (HTTP) PATCH message to the NRF within the heartbeat interval and instructing a replacement operation of the nfStatus attribute of the NF profile of the NE that does not support SBI service operations, with the value of the nfStatus attribute being REGISTERED.

[0030] According to another aspect of the subject matter described herein, the IWF is configured to monitor the status of NEs that do not support SBI service operations by detecting the unavailability of NEs that do not support SBI service operations using the native protocol of the NEs that do not support SBI service operations, and the CNCC is configured to update the status of NEs that do not support SBI service operations by performing an NFUpdate service operation on behalf of the NEs that do not support SBI service operations, including sending a Hypertext Transfer Protocol (HTTP) PATCH message to the NRF indicating a replacement operation for the nfStatus attribute of the NF profile of the NEs that do not support SBI service operations and the value of the nfStatus attribute being UNDDISCOVERABLE.

[0031] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium is provided having executable instructions stored thereon that, when executed by a computer's processor, control a computer to perform steps. These steps include receiving service-based interface (SBI) configuration parameters for a network element (NE) that does not support SBI service operations. These steps also include establishing a connection with the NE that does not support SBI service operations. These steps further include registering the NE that does not support SBI service operations with a Network Function (NF) repository function (NRF) and using the SBI configuration parameters. These steps also include monitoring the status of the NE that does not support SBI service operations via the connection. These steps further include updating the status of the NE that does not support SBI service operations with the NRF.

[0032] The subjects described herein can be implemented using software in conjunction with hardware and / or firmware. For example, the subjects described herein can be implemented as software executed by a processor. In one exemplary embodiment, the subjects described herein can be implemented using a non-transitory computer-readable medium having computer-executable instructions stored thereon, which control computer execution steps when executed by a computer's processor. Exemplary computer-readable media suitable for implementing the subjects described herein include non-transitory computer-readable media, such as disk storage devices, on-chip memory devices, programmable logic devices, and application-specific integrated circuits (ASICs). Furthermore, computer-readable media implementing the subjects described herein can be located on a single device or computing platform or can be distributed across multiple devices or computing platforms. Attached Figure Description

[0033] Figure 1 This is a network diagram illustrating an exemplary 5G system network architecture;

[0034] Figure 2A This is a message flow diagram illustrating an example message exchanged as an NFRegister service operation.

[0035] Figure 2B This is a message flow diagram illustrating an example message exchanged as an NFUpdate or NF heartbeat service operation.

[0036] Figure 3 This is a block diagram illustrating an exemplary component for providing SBI support to NEs that do not support SBI service operations.

[0037] Figure 4 The diagram illustrates a network that provides SBI support for 4G / 5G EIRs that do not support SBI service operations.

[0038] Figure 5 The diagram illustrates a network that provides SBI support for 4G / 5G AF or AS that does not support SBI service operation.

[0039] Figure 6 This is a message flow diagram illustrating exemplary messages exchanged when a NE (Non-Service Provider) performing NFRegister, NFUpdate, and NF Heartbeat service operations on behalf of another NE that does not support SBI service operations; and

[0040] Figure 7 This is a flowchart illustrating an exemplary process for providing SBI support to NEs that do not support SBI service operations. Detailed Implementation

[0041] Figure 1 This is a block diagram illustrating an exemplary 5G system network architecture. Figure 1 The architecture includes NRF 100 and SCP 101, which can reside within the same Home Public Land Mobile Network (HPLMN). As described above, NRF 100 maintains profiles of available producer NF service instances and their supported services, and allows consumer NFs or SCPs to subscribe and be notified of new / updated producer NF service instance registrations. SCP 101 also supports service discovery and selection of producer NF instances. SCP 101 can perform load balancing of connections between consumer and producer NFs.

[0042] NRF 100 is a repository of service profiles for NF or producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain the producer NF instance's NF or service profile from NRF 100. The NF or service profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP TS 29.510. The NF or service profile definition includes at least one of a Fully Qualified Domain Name (FQDN), an Internet Protocol (IP) version 4 (IPv4) address, or an IP version 6 (IPv6) address.

[0043] exist Figure 1 In this context, any network function can be a consumer NF, a producer NF, or both, depending on whether it requests a service, provides a service, or requests and provides a service. In the example shown, the NFs include a PCF 102 that performs policy-related operations in the network, a User Data Management (UDM) function 104 that manages user data, and an Application Function (AF) 106 that provides application services.

[0044] Figure 1The NF shown also includes a Session Management Function (SMF) 108, which manages the session between the Access and Mobility Management Function (AMF) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by a Mobility Management Entity (MME) in a 4G network. The Authentication Server Function (AUSF) 112 performs authentication services for User Equipment (UE) seeking network access (such as User Equipment (UE) 114).

[0045] The Network Slice Selection Function (NSSF) 116 provides network slicing services for devices seeking access to specific network capabilities and characteristics associated with a network slice. The Network Exposure Function (NEF) 118 provides an application programming interface (API) for application functions seeking information about Internet of Things (IoT) devices and other UEs attached to the network. NEF 118 performs functions similar to the Service Capability Exposure Function (SCEF) in 4G networks.

[0046] Radio Access Network (RAN) 120 connects User Equipment (UE) 114 to the network via a radio link. This can be achieved using a gNode B (gNB). Figure 1 The UE 114 accesses the radio access network 120 via a wireless access point (not shown) or other wireless access points. The User Plane Function (UPF) 122 can support various proxy functions for user plane services. An example of such proxy function is the Multipath Transmission Control Protocol (MPTCP) proxy function. The UPF 122 can also support performance measurement functions, which the UE 114 can use to obtain network performance measurements. Figure 1 The diagram also shows a data network (DN) 124 through which the UE accesses data network services, such as Internet services.

[0047] SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic leaving the home PLMN. SEPP 126 can communicate with the SEPP in the external PLMN that manages the security of the external PLMN. Therefore, traffic between NFs in different PLMNs can traverse two SEPP functions, one for the home PLMN and the other for the external PLMN.

[0048] As mentioned above, one potential issue in 5G networks is that NFs that do not support SBI service operations cannot transmit their identity to 5G NFs, nor can they update their state with 5G NFs via communication with the NRF through SBI. Examples of non-SBI NEs that may have use cases in 5G networks include the aforementioned EIR, AF and AS, Policy Control Function (PCF), Home Subscriber Server (HSS), Home Location Register (HLR), or other non-SBI network elements that need to interface with NFs in the 5G network.

[0049] An example that might be expected to represent an SBI service operation not provided by an SBI NE is the NFRegister service operation. Figure 2A This is a message flow diagram illustrating exemplary messages exchanged during the execution of the NFRegister service operation. The NFRegister service operation is defined in 3GPP TS 29.510. The NFRegister service operation is used to register an NF with the NRF by providing the NRF with an NF profile requesting the NF. The NF profile is a data structure describing the NF, the services provided by the NF, and the identity of the NF in communication. When an NF successfully invokes the NFRegister service operation, the NRF marks the requesting NF as discoverable by other NFs. The NFRegister service operation is also used to register services associated with existing NF instances. The NFRegister service operation is also used to register NRF information and other information that is used to forward or redirect service discovery requests.

[0050] refer to Figure 2A In the message flow, in line 1, NF service consumer 200 requests NRF 100 to send an HTTP PUT message. The HTTP PUT message includes a Resource Uniform Resource Identifier (URI) representing the NF instance. The URI is determined by the NF instance. The variable “nfInstanceId” represents an identifier provided by NF service consumer 200 that is globally unique within the PLMN of the NRF 100 where the NF is registered. The NF instance ID is in the format of Universally Unique Identifier (UUID) version 4, as described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 4122.

[0051] The payload body of the PUT request contains a representation of the NF instance to be created. Figure 2A In the examples, it indicates that it is specified by an NF profile. An NF profile is a data structure that includes the attributes shown in Table 1 below:

[0052]

[0053]

[0054]

[0055]

[0056]

[0057]

[0058]

[0059]

[0060]

[0061]

[0062]

[0063]

[0064]

[0065]

[0066]

[0067]

[0068] Table 1: NF Profile Attributes

[0069] As shown in Table 1, the NF profile includes attributes describing the 5G network function being registered. 5G network functions are configured or programmed to include an NF profile. However, non-SBI NEs do not have an NF profile and therefore cannot register their identity with NRF 100.

[0070] exist Figure 2A In line 2a, after NF instance 200 successfully registers, NRF 100 returns a 201 Create message. The payload body of the 201 Create message contains a representation of the created resource, and the location header of the response contains the URI of the created resource. Additionally, NRF 100 returns a heartbeat timer containing the expected number of seconds between two consecutive heartbeat messages from NF instance 200 to NRF 100. The representation of the created resource can be a complete NF profile or an NF profile that includes mandatory attributes of the NF profile and attributes added or modified by NRF 100.

[0071] In Online 2b, in the event of a failure or redirection, if registration of NF instance 200 fails at NRF 100 due to an encoding error in the NF profile JSON object, NRF 100 will return a 4xx Error Request Status Code with a Problem Details Information element. If NF instance registration fails at NR 100 due to an internal error, this information element provides details of the error. NRF 100 returns a 5xx Internal Server Error Status Code with a Problem Details Information element providing details of the error. In the case of a redirection, NRF 100 returns a 3xx status code containing a location header with a URI pointing to an endpoint of another NRF service instance.

[0072] Other SBI service operations that may be expected to be performed on behalf of non-SBI NEs include NFUpdate service operations and NF heartbeat service operations, which are specific types of NFUpdate service operations. Figure 2B This is a message flow diagram illustrating an example message exchange of the NFUpdate service operation. The NFUpdate service operation updates the profile of an NF previously registered in the NRF by providing the NRF with an updated NF profile requesting the NF. The NFUpdate service operation can be applied to the entire profile of an NF (completely replacing the existing profile with the new profile), or it can be applied to only a subset of the profile's parameters (including adding / deleting / replacing services to the NF profile).

[0073] When using the NFUpdate service operation to perform NF heartbeat service operations, previously registered NFs periodically contact the NRF to indicate that the NF is still operational. The time interval at which the NRF should contact is deployment-specific, and the NRF returns this as a result of successful registration to the NF service consumer. When the NRF detects that a given NF has not updated its profile for a configurable amount of time (longer than the heartbeat interval), the NRF changes the NF's status to SUSPENDED and considers the NF and its services no longer discoverable by other NFs via the NFDiscovery service. The NRF notifies NFs subscribed to receive NF profile change notifications that the NF status has changed to SUSPENDED.

[0074] If the NRF modifies the heartbeat interval value of a given NF instance currently registered (e.g., as a result of an Operations, Administration and Maintenance (OA&M) operation), it should return the new value to the registered NF in the response to the next periodic heartbeat interaction received from that NF. Prior to this, the NRF should apply the heartbeat check procedure based on the original interval value.

[0075] like Figure 2B As shown in line 1, when performing the NFUpdate service operation, the NF service consumer 200 sends an HTTP PATCH request to the resource URI representing the NF instance. If the NFUpdate service operation is for the NF heartbeat service, the payload body of the PATCH request contains a "replace" operation on the "nfStatus" attribute of the NF instance's NF profile, and the value of the nfStatus attribute is set to either "REGISTERED" or "UNDDISCOVERABLE," depending on whether the NF is reachable.

[0076] Additionally, the NF service consumer 200 can also provide load information for the NF and / or the associated NF services. The provision of this load information can be limited by the NF through appropriate configuration (e.g., granular thresholds) to avoid notifying small load changes.

[0077] exist Figure 2B In line 2a, upon success, NRF 100 returns a 204 No Content message. NRF 100 can also reply with a 200 OK message along with the full NF profile, for example, if NRF 100 determines that the NF profile has changed significantly since the last heartbeat and wishes to send the new profile to NF service consumer 200.

[0078] exist Figure 2B In line 2b, upon failure or redirection, if the NF instance identified by nfInstanceID is not found in the list of registered NF instances in the NRF database, NRF 100 returns a "404 Not Found" status code along with a ProblemDetails IE providing error details. In the case of redirection, NRF 100 returns a 3xx status code, which includes a location header with a URI pointing to another NRF service instance endpoint.

[0079] Because non-SBI NE is not supported. Figure 2A and Figure 2B The service operations shown in the figure provide a mechanism for performing these service operations on behalf of non-SBI NEs. Figure 3 The diagram illustrates how an NE that does not support SBI service operations performs SBI service operations (as shown in the reference above). Figure 2A and 2B A diagram illustrating exemplary components of a system (describing the NFRegister, NFUpdate, and NF Heartbeat service operations). (See reference...) Figure 3 The Cloud Native Core Console (CNCC) 300 receives configuration information from the operator 302 for the non-SBI NE 304. In the example shown, the non-SBI NE 304 is an Equipment Identity Register (EIR) or Application Function (AF). The CNCC 300 includes an NF Management Service 306, which includes an NFRegister module 308 that implements the aforementioned NFRegister service on behalf of the non-SBI NE 304, an NFUpdate module 310 that implements the aforementioned NFUpdate service operation on behalf of the non-SBI NE 304, and an NF Heartbeat module 312 that implements the aforementioned NF Heartbeat service operation on behalf of the non-SBI NE 304.

[0080] CNCC 300 also includes a CNCC core 314, which receives non-SBI NE configuration parameters from the operator 302 and stores them in memory as a non-SBI module 316. The non-SBI NE configuration parameters can be NF profile parameters, such as those shown in Table 1, and CNCC 300 can use the received parameters to create an NF profile for the non-SBI NE 304. CNCC 300 also includes a CNCC Identity Access Management (IAM) module 321, which performs CNCC 300's authentication and authorization functions, such as creating roles and assigning roles to users.

[0081] Figure 3 The system shown also includes a non-SBI NE interoperability function (IWF) 320, which interfaces directly with non-SBI NEs (such as NE304) and also communicates with the CNCC core 314. The non-SBI NE IWF 320 includes an auditor 322 that monitors the status of the non-SBI NE304 and transmits status updates to the CNCC core 314. Modules 308, 310, and 312 can be triggered by status updates to update the NF profile of the non-SBI NE304 to the NRF 100. The NRF 100 includes an application programming interface (API) 324 defined in 3GPP TS29.510 and includes the above-mentioned... Figure 2A and 2B The message and parameters described.

[0082] When performing the NFRegister service operation, the NFRegister module 308 receives configuration parameters from the operator 302, creates an NF profile for non-SBI NE 304, and uses... Figure 2A The message flow shown transmits the NF profile to NRF 100. During the execution of the NFUpdate service operation, the NF update module 310 can be triggered by a non-SBI NE IWF 320 that receives or detects an update to one or more parameters of the NF profile of a non-SBI NE 304, and will use the above-mentioned... Figure 2B The NFUpdate service operation described here is used to update the NF profile.

[0083] The NF heartbeat module 312 can maintain the state of the non-SBI NE 304 and NRF 100 using the aforementioned NF heartbeat service operations, based on the results of monitoring the non-SBI NE 304 performed by the auditor 322. In one example of the non-SBI NE 304 implementing the Diameter protocol, as described in IETF RFC 6733, the auditor 322 can use Diameter watchdog message exchange to monitor the state of the non-SBI NE 304. Using the Diameter watchdog procedure, the auditor 322 can send a Diameter watchdog request to the non-SBI NE 304. After sending the Diameter watchdog request, the auditor 322 starts a Diameter watchdog timer and waits for a Diameter watchdog response from the non-SBI NE 304. If auditor 322 receives a Diameter watchdog response from non-SBI NE 304 before the timer expires, auditor 322 can reset the Diameter watchdog timer and update CNCC core 314 to indicate that non-SBI NE 304 is available. NF heartbeat module 312 can then use the NFUpdate service operation to send a heartbeat status message to NRF 100. If auditor 322 fails to receive a response to the Diameter watchdog request before the Diameter watchdog timer expires, auditor 322 can notify CNCC core 314, which causes NFUpdate module 310 and / or NF heartbeat module 312 to use the aforementioned NFUpdate and / or NF heartbeat procedures to update the reachability status (indicating UNDISCOVERABLE) of non-SBI NE 304 to NRF 100.

[0084] Figure 3 Components in a cloud network environment can be implemented using at least one processor 326 and memory 328. For example, CNCC 300 and IWF 320 can be implemented using computer-executable instructions stored in memory 328 and executed by processor 326. It should also be noted that CNCC 300 and IWF 320 can reside on the same or different computing platforms.

[0085] Figure 4The illustration shows an example of the 5G AMF 110 needing to communicate with the 4G / 5G EIR 400, for example, to verify or obtain the UE's International Mobile Equipment Identifier (IMEI). The 4G / 5G EIR 400 can utilize non-SBI interfaces (such as the Diameter interface) to communicate with other network elements. The IWF 320 can communicate with the 4G / 5G EIR 400 using native non-SBI interface protocols implemented by the 4G / 5G EIR 400, communicate with the AMF 110 using SBI protocols, and communicate with the CNCC300 using SBI or proprietary interface protocols. Using Diameter as an example, the IWF 320 can convert between Diameter and HTTP for messaging between the AMF110 and the 4G / 5G EIR 400.

[0086] In the example shown, operator 302 can use CNCC 300 to create a configuration for 4G / 5G EIR 400. In response to receiving configuration parameters, CNCC 300 can create an NF profile for the 4G / 5G EIR 400 and register the NF profile with NRF 100. The NF profile may include all or any suitable subset of the NF profile attributes shown in Table 1 above. IWF 320 can use a Diameter watchdog or other suitable procedure to monitor the status of the 4G / 5G EIR 400 and notify CNCC 300 of the current status of the 4G / 5G EIR 400. When a notification of the status of the 4G / 5G EIR 400 is received, CNCC 300 can use one of the SBI service operations described above to update the status of the 4G / 5G EIR 400's NF profile with NRF 100. If the AMF 110 is subscribed to receive notifications of changes to the NF profile of the 4G / 5G EIR 400, then the NRF 100 will notify the AMF 110 when the NF profile is changed or updated.

[0087] Figure 5 Another use case for the CNCC 300 and IWF 320 is illustrated. Figure 5In this configuration, Operator 302 can utilize CNCC300 to configure parameters for the 4G / 5G AF 500. CNCC300 can create an NF profile for the 4G / 5G AF 500 and register it within NRF 100. 5G NFs such as AMF 110, PCF 102, SEPP 126, SMF 108, NSSF 116, and AUSF 112 can subscribe to NRF 100 to receive updates on the AF 500's status. IWF 320 monitors the AF 500's status and transmits this status to CNCC 300. IWF 320 can also convert between message formats used in the 5G core and message formats compatible with AF 500. For example, IWF 320 can perform HTTP-to-Diameter conversion on messages directed to AF 500 and Diameter-to-HTTP conversion on messages from AF 500 to the 5G core.

[0088] Figure 6 This is a message flow diagram illustrating the NFRegister, NF Heartbeat, and NFUpdate service operations performed by non-SBI network elements. (Reference) Figure 6 In step 1, a user, such as network operator 302, configures the new consumer (or producer) NF as a non-SBI network element. The parameters input by network operator 302 can be those illustrated or indicated as mandatory in the NF profiles in Table 1 above. Below are examples of parameters that can be configured for a non-SBI NE:

[0089] parameter:

[0090] -Name:nfInstanceID

[0091] Within: path

[0092] Requirement: True

[0093] Description: The unique ID of the NF instance to be registered.

[0094] model:

[0095] $ref:TS29571_CommonData.yaml# / components / schemas / NfInstanceId'

[0096] - Name: Content-Encoding

[0097] Inside...: Header

[0098] Description: Content-Encoding, described in IETF RFC 7231

[0099] model:

[0100] type:string

[0101] - Name: Accept-Encoding

[0102] Inside...: Header

[0103] Description: Accept-Encoding, described in IETF RFC 7231

[0104] model:

[0105] type:string

[0106] requestBody:

[0107] content:

[0108] application / json:

[0109] model:

[0110] $ref:'# / components / schemas / NFProfile'

[0111] Requirement: True

[0112] In step 2, after receiving the configuration of the non-SBI network element 304, the CNCC 300 notifies the IWF 320 of the newly configured non-SBI network element. Details include information that allows the IWF 320 to initiate a connection with the non-SBI network element 304, such as its IP address or domain name.

[0113] In step 3, IWF 320 establishes a connection with the non-SBI network element 304. In one example, the connection is a transport layer connection, such as a Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) connection. In step 4, IWF 320 notifies CNCC 300 that the connection has been successfully established.

[0114] In step 5, upon receiving notification from IWF 320 of a successful connection establishment with non-SBI network element 304, CNCC 300 uses sufficient details to reach non-SBI network element 304 to perform the NFRegister service operation with NRF 100. Performing the NFRegister procedure may include sending an HTTP PUT message with relevant parameters to NRF 100, as described above. Figure 2A As described. In step 6, the NRF 100 responds, indicating whether the registration was successful. The response can be as described above regarding... Figure 2A Any response described.

[0115] In step 7, the IWF 320 monitors the status of the non-SBI network element 304. Monitoring the status of the non-SBI network element 304 may include exchanging heartbeat messages with the non-SBI network element 304 using its native protocols. In one example, the heartbeat message may be a Diameter watchdog message, as described above. In another example, if the non-SBI network element 304 implements SS7 or Sigtran messaging, then the heartbeat message may be a Message Transport Part (MTP) Level 3 User Adaptation Layer (M3UA) heartbeat message. If the non-SBI network element 304 implements Session Initiation Protocol (SIP), then the heartbeat message may be a SIP heartbeat or an equivalent message.

[0116] In step 8, IWF 320 sends a status message to CNCC 300 indicating that the non-SBI network element 304 is started or available. In step 9 of the message flow diagram, CNCC 300 performs an NF heartbeat service operation on behalf of the non-SBI network element 304. Performing the NF heartbeat service operation may include sending an HTTP PATCH message to NRF 100 indicating that the non-SBI network element 304 is available, as described above regarding... Figure 2B As described. In step 10 of the message flow graph, the NRF 100 responds to the CNCC 300, indicating whether the NF heartbeat service operation was successful or failed.

[0117] In step 11 of the message flow diagram, Diameter watchdog messaging between non-SBI network element 304 and IWF 320 fails. For example, non-SBI network element 304 may fail to respond to Diameter watchdog request messages within the timeout period. In response to detecting the failure of Diameter watchdog messaging, IWF 320 sends a notification to CNCC 300 in step 12 indicating that non-SBI network element 304 is unavailable.

[0118] In line 13 of the message flow diagram, CNCC 300, on behalf of non-SBI network element 304, performs the NFUpdate service operation, informing NRF 100 that non-SBI network element 304 is down or suspended. In an alternative example, an NF heartbeat service operation could be used to indicate that non-SBI network element 304 is down. In line 14 of the message flow diagram, depending on whether the service operation was successful, NRF 100 responds to CNCC 300 with a success or failure response.

[0119] Figure 7 This is a flowchart illustrating a method for providing Service-Based Interface (SBI) support to NEs that do not support SBI service operations. (Reference) Figure 7In step 700, the process includes receiving SBI configuration parameters for NEs that do not support SBI service operations. For example, CNCC 300 may receive SBI configuration parameters from operator 302, which may include NF profile parameters for creating NF profiles that enable 5G NFs to discover and subscribe to receive notifications about non-SBI NEs.

[0120] In step 702, the process includes establishing a connection with an NE that does not support SBI service operations. For example, after receiving configuration parameters, CNCC 300 may instruct IWF 320 to create a connection with a non-SBI NE 304. In response to this instruction, IWF 320 may create a transport layer connection, such as a TCP or SCTP connection with the non-SBI NE 304.

[0121] In step 704, the process includes registering the NE that does not support SBI service operations with the Network Function (NF) repository function (NRF) and using SBI configuration parameters. For example, CNCC 300 can perform the NFRegister service operation to transfer the NF profile of the non-SBI network element 304 to NRF 100.

[0122] In step 706, the process includes monitoring the status of NEs that do not support SBI service operations via a connection. For example, the IWF 320 can monitor the status of a non-SBI NE 304 using a native protocol. If the native protocol is Diameter, the IWF 320 can monitor the status of a non-SBI NE 304 using Diameter watchdog messaging. If the native protocol is SS7 via Sigtran, the IWF 320 can monitor the status using M3UA messages. If the native protocol is SIP, the IWF 320 can monitor the status using SIP messages.

[0123] In step 708, the process includes updating the status of NEs that do not support SBI service operations to the NRF. For example, CNCC300 can use NFUpdate or NF heartbeat service operations to transmit the availability status of non-SBI NE 304 to NRF 100.

[0124] Exemplary advantages of the subject matter described herein include allowing non-SBI NEs to register with the NRF, enabling the NF to discover non-SBI NEs and receive status updates about them. Another advantage of providing the CNCC and IWF to perform SBI service operations on behalf of non-SBI NEs is that individual non-SBI NEs do not need to be configured to support SBI service operations. Therefore, this solution offers scalability and configuration efficiency advantages compared to solutions where individual non-SBI NEs are configured to support SBI service operations.

[0125] The disclosures of the following references are hereby incorporated herein by reference in their entireties.

[0126] References

[0127] 1. 3 rd Generation Partnership Project;Technical Specification Group Core Network and Terminals;5G System;Network Function Repository Services;Stage 3 (Release 17), 3GPP TS 29.510 V17.0.0 (2020-12).

[0128] 2. 3 rd Generation Partnership Project;Technical Specification Group Core Network and Terminals;Numbering, addressing and identification;(Release 17), 3GPP TS 23.003 V17.0.0 (2020-12).

[0129] 3. 3 rd Generation Partnership Project;Technical Specification Group Core Network and Terminals;5G System;Technical Realization of the Service Based Architecture;Stage 3 (Release 17), 3GPP TS 29.500 V17.1.0 (2020-12).

[0130] 4. 3 rd Generation Partnership Project;Technical Specification Group Core Network and Terminals;5G System;Restoration Procedures (Release 16), 3GPP TS 23.527 V16.5.0 (2020-12).

[0131] 5.Fajardo, et al., "Diameter Base Protocol," IETF RFC 6733 (October2012);

[0132] 6. Leach, et.al., “A Universally Unique Identifier(UUID)URN Namespace,” IETF RFC 4122 (July 2005).

[0133] 7. Bray, T., “The JavaScript Object Notation(JSON)Data InterchangeFormat,” IETF RFC 8259 (December 2017).

[0134] 8. Fielding, R. and Reschke, J., “Hypertext Transfer Protocol (HTTP / 1.1: Semantics and Content,” IETF RFC 7321 (June 2014).

[0135] It should 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 illustrative purposes only and not for limiting purposes, as the subject matter described herein is defined by the claims set forth below.

Claims

1. A method for providing SBI support for a network element (NE) that does not support service-based interface (SBI) service operations, the method comprising: Receive SBI configuration parameters for NEs that do not support SBI service operations; Establish a connection with a NE that does not support SBI service operations; Register NEs that do not support SBI service operations with the Network Function NF Repository Function NRF and use SBI configuration parameters, wherein registering NEs that do not support SBI service operations includes performing the NFRegister service operation on behalf of NEs that do not support SBI service operations to the NRF. The status of NEs that do not support SBI service operations can be monitored via the connection. as well as Update the status of NEs that do not support SBI service operations to NRF.

2. The method of claim 1, wherein receiving SBI configuration parameters includes receiving NF profile parameters for creating NF profiles for NEs that do not support SBI service operations.

3. The method of claim 1, wherein performing the NFRegister service operation includes sending a Hypertext Transfer Protocol (HTTP) PUT message to the NRF, the HTTP PUT message including an NF profile for an NE that does not support the SBI service operation.

4. The method of claim 1, wherein establishing a connection with an NE that does not support SBI service operation includes establishing a transport layer connection between the Interoperability Function (IWF) and the NE that does not support SBI service operation.

5. The method of claim 4, wherein monitoring the status of an NE that does not support SBI service operations includes exchanging Diameter watchdog messages with the NE that does not support SBI service operations via the IWF and the connection.

6. The method of claim 1, wherein updating the state of an NE that does not support SBI service operations with the NRF includes performing an NF heartbeat service operation on behalf of the NE that does not support SBI service operations with the NRF.

7. The method of claim 6, wherein monitoring the status of an NE that does not support SBI service operations includes detecting the availability of an NE that does not support SBI service operations using a native protocol of the NE, and wherein performing an NF heartbeat service operation includes sending a Hypertext Transfer Protocol HTTP PATCH message to the NRF within a heartbeat interval, and instructing a replacement operation of the nfStatus attribute of the NF profile of the NE that does not support SBI service operations and that the value of the nfStatus attribute is REGISTERED.

8. The method as described in any of the preceding claims, wherein updating the state of an NE that does not support SBI service operations to the NRF includes performing an NFUpdate service operation on behalf of the NE that does not support SBI service operations to the NRF.

9. The method of claim 8, wherein monitoring the status of an NE that does not support SBI service operations includes detecting the unreachability of the NE that does not support SBI service operations using the native protocol of the NE, and wherein performing an NFUpdate service operation on behalf of the NE that does not support SBI service operations includes sending a Hypertext Transfer Protocol HTTP PATCH message to the NRF indicating a replacement operation of the nfStatus attribute of the NF profile of the NE that does not support SBI service operations and the value of the nfStatus attribute being UNDISCOVERABLE.

10. A system for providing SBI support for network elements (NEs) that do not support service-based interface (SBI) service operations, the system comprising: The cloud-native core console CNCC is used to receive SBI configuration parameters from NEs that do not support SBI service operations, and to register NEs that do not support SBI service operations with the Network Function NF Repository Function NRF using the SBI configuration parameters. The CNCC is configured to register NEs that do not support SBI service operations by performing an NFRegister service operation on behalf of the NEs that do not support SBI service operations to the NRF. Interoperability Function (IWF) is used to establish a connection with a NE that does not support SBI service operations and to monitor the status of the NE that does not support SBI service operations through the connection. as well as CNCC is configured to update the state of NEs that do not support SBI service operations by sending state updates to NRF and monitoring based on IWF.

11. The system of claim 10, wherein the CNCC is configured to receive NF profile parameters for creating NF profiles for NEs that do not support SBI service operations.

12. The system of claim 10, wherein the CNCC is configured to perform an NFRegister service operation by sending a Hypertext Transfer Protocol HTTP PUT message to the NRF including an NF profile for an NE that does not support SBI service operation.

13. The system of claim 10, wherein the connection to the NE that does not support SBI service operation includes a transport layer connection.

14. The system of claim 13, wherein the IWF is configured to monitor the status of an NE that does not support SBI service operations by exchanging Diameter watchdog messages with the NE that does not support SBI service operations on the connection.

15. The system of claim 10, wherein the CNCC is configured to update the state of the NE that does not support SBI service operations with the NRF by performing an NF heartbeat service operation with the NRF on behalf of the NE that does not support SBI service operations.

16. The system of claim 15, wherein the IWF is configured to monitor the status of NEs that do not support SBI service operations by using a native protocol of the NE that does not support SBI service operations, and wherein the CNCC is configured to perform an NF heartbeat service operation by sending a Hypertext Transfer Protocol HTTP PATCH message to the NRF within a heartbeat interval and instructing a replacement operation of the nfStatus attribute of the NF profile of the NE that does not support SBI service operations and setting the value of the nfStatus attribute to REGISTERED.

17. The system of any one of claims 10 to 16, wherein the IWF is configured to monitor the status of the NE that does not support SBI service operations by detecting the unreachability of the NE that does not support SBI service operations using a native protocol of the NE that does not support SBI service operations, and wherein the CNCC is configured to update the status of the NE that does not support SBI service operations by performing an NFUpdate service operation on behalf of the NE that does not support SBI service operations, including sending a Hypertext Transfer Protocol HTTP PATCH message to the NRF indicating a replacement operation of the nfStatus attribute of the NF profile of the NE that does not support SBI service operations and the value of the nfStatus attribute being UNDISCOVERABLE.

18. A non-transitory computer-readable medium having executable instructions stored thereon, the executable instructions, when executed by a computer's processor, controlling the computer to perform steps including the following: Receive SBI configuration parameters for network element NE that does not support service-based interface SBI service operations; Establish a connection with a NE that does not support SBI service operations; Register NEs that do not support SBI service operations with the Network Function NF Repository Function NRF and use SBI configuration parameters, wherein registering NEs that do not support SBI service operations includes performing the NFRegister service operation on behalf of NEs that do not support SBI service operations to the NRF. The status of NEs that do not support SBI service operations can be monitored via the connection. as well as Update the status of NEs that do not support SBI service operations to NRF.

Images