The subject matter described herein relates to distributing NF topology information, such as 5G core NF topology information, among proxy nodes, such as service communications proxies (SCPs) and security edge protection proxies (SEPPs). More particularly, the subject matter described herein relates to distributing NF topology information among proxy nodes and for inter-SCP and inter-SEPP routing of messages using the NF topology information.
In 5G telecommunications networks, the network node that provides service is referred to as a producer network function (NF). A network node that consumes services is referred to as a consumer NF. A network function can be both a producer NF and a consumer NF depending on whether it is consuming or providing service.
A given producer NF may have many service endpoints, where a service endpoint is a combination of IP address and port number on a network node that hosts a producer NF. Producer NFs register with a network function repository function (NRF). The NRF maintains an NF profile of available NF instances and their supported services. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.
In addition to consumer NFs, another type of network node that can subscribe to receive information about NF service instances is the SCP. The SCP subscribes with the NRF and obtains reachability and service profile information regarding producer NF service instances. Consumer NFs connect to the SCP, and the SCP load balances traffic among producer NF service instances that provide the required service or directly routes the traffic to the destination producer NF.
In addition to the SCP, other examples of proxy nodes or groups of network nodes that route traffic between producer and consumer NFs include the SEPP, the service gateway, and nodes in the 5G service mesh. The SEPP is the network node used to protect control plane traffic that is exchanged between different 5G PLMNs (Public Land Mobile Networks). As such, the SEPP performs message filtering, policing and topology hiding for all application programming interface (API) messages.
The service gateway is a node that sits in front of a group of producer NFs that provide a given service. The service gateway may load balance incoming service requests among producer NFs that provide the service in a manner similar to the SCP.
The service mesh is a name for a group of intermediate proxy nodes that enable communications between producer and consumer NFs. The service mesh may include one or more SCPs, SEPPs, and service gateways.
One problem with the existing 3GPP service architecture is routing of messages among proxy nodes when the destination NF is not located in the same network as the proxy node that receives a message. For example, when a mobile subscriber roams into a network served by an SCP that is not the subscriber's home SCP, it may be necessary to contact the subscriber's home user data management (UDM) node to provide services to the subscriber while the subscriber is roaming. The subscriber's home UDM node is reachable through the home SCP of the subscriber. A node (such as an access and mobility management function (AMF)) in the visited network may need to contact the subscriber's home UDM through the subscriber's home SCP (for example, for an update location transaction). The AMF sends an update location message to the SCP in the network in which the subscriber is currently located. The SCP in the network currently serving the subscriber does not know how to reach the subscriber's home SCP. Accordingly, the SCP sends the update location message to each SCP in the network until the home SCP is reached. The home SCP sends the message to the home UDM, and the home UDM responds to the AMF.
One problem with this scenario is that the messages that are sent to the incorrect SCPs unnecessarily waste network bandwidth. Another problem with this scenario is that the delay in locating the correct SCP results in a delay in providing the service to the subscriber. Such delay may be unacceptable for some services, such as call setup or gaming.
Accordingly, there exists a need for methods, systems, and computer readable media for distributing network topology information among proxy nodes and using the network topology information for inter-proxy node message routing.
A method for distributing network function (NF) topology information among proxy nodes and for using the NF topology information for inter-proxy node message routing is provided. The method includes configuring a first proxy node as a leader service communications proxy (SCP). The method further includes configuring a plurality of second proxy nodes as worker proxy nodes. The method further includes registering the worker proxy nodes with the leader SCP. The method further includes subscribing, by the worker proxy nodes and with the leader SCP, to receive NF topology information from the leader SCP. The method further includes, at the leader SCP, receiving NF topology information from the worker proxy nodes and communicating the NF topology information to the worker proxy nodes subscribed to receive the NF topology information. The method further includes, at the worker proxy nodes, using the NF topology information to route messages to proxy nodes serving destination NFs.
According to another aspect of the subject matter described herein, configuring the first proxy node as the leader SCP includes configuring the first proxy node to receive NF topology information from the worker proxy nodes, store the NF topology information, and distribute the NF topology information among the worker proxy nodes.
According to yet another aspect of the subject matter described herein, configuring the second proxy nodes as worker proxy nodes includes configuring each of the second proxy nodes with the identity of the leader proxy node, to communicate the NF topology information of NFs connected to the second proxy node to the leader SCP and to receive NF topology information of other proxy nodes from the leader SCP.
According to yet another aspect of the subject matter described herein, registering the worker proxy nodes with the leader SCP includes communicating identities of NFs connected to each worker proxy node to the leader SCP.
According to yet another aspect of the subject matter described herein, subscribing with the leader SCP includes transmitting, from each of the worker proxy nodes, a subscribe message requesting NF topology information for at least one proxy node other than a sending proxy node of the subscribe message.
According to yet another aspect of the subject matter described herein, communicating the network topology information to the worker proxy nodes includes transmitting notify messages to the worker proxy nodes including the network topology information.
According to yet another aspect of the subject matter described herein, the method for distributing NF topology information among proxy nodes includes receiving an NF topology update from one of the worker proxy nodes, and, wherein communicating the NF topology information to the worker proxy nodes includes communicating the NF topology update to the worker proxy nodes subscribed to receive the NF topology information regarding the one worker proxy node.
According to yet another aspect of the subject matter described herein, using the network topology information to route messages to proxy nodes serving destination NFs includes, at one of the worker proxy nodes:
According to yet another aspect of the subject matter described herein, the second proxy nodes comprise SCPs.
According to yet another aspect of the subject matter described herein, the second wherein the second proxy nodes comprise worker service edge protection proxies (SEPPs).
According to yet another aspect of the subject matter described herein, a system for distributing network function (NF) topology information among proxy nodes and for using the NF topology information for inter-proxy node message routing is provided. The system includes a first proxy node configured as a leader service communications proxy (SCP). The system further includes a plurality of second proxy nodes configured as worker proxy nodes and including a registration module for registering with the leader SCP and communicating NF topology information to the leader SCP, a subscription module for subscribing with the leader SCP to receive, from the leader SCP, NF topology information of other proxy nodes, and an inter-proxy NF routing module for using the NF topology information of other proxy nodes to route messages to destination NFs served by the other proxy nodes. The leader SCP includes an inter-proxy node NF topology database for receiving and storing the NF topology information from the worker proxy nodes and an NF topology information distribution module for distributing the NF topology information to the worker proxy nodes subscribed to receive the NF topology information.
According to yet another aspect of the subject matter described herein, the worker proxy nodes are configured with the identity of the leader proxy node.
According to yet another aspect of the subject of the subject matter described herein, the registration modules of the worker proxy nodes are configured to communicate identities of NFs connected to each worker proxy node to the leader SCP.
According to yet another aspect of the subject matter described herein, the subscription module of each of the worker SCPs is configured to transmit a subscribe message requesting NF topology information for at least one proxy node or optionally all proxy nodes of the network, other than a sending proxy node of the subscribe message.
According to yet another aspect of the subject matter described herein, the NF topology distribution module is configured to transmit notify messages to the worker proxy nodes including the NF topology information.
According to yet another aspect of the subject matter described herein, the NF topology distribution module is configured to receive an NF topology update from one of the worker proxy nodes, and, in response, communicate the NF topology update to the worker proxy nodes subscribed to receive the NF topology information regarding the one worker proxy node
According to yet another aspect of the subject matter described herein, one of the worker proxy nodes is configured to:
According to yet another aspect of the subject matter described herein, a non-transitory computer readable medium having stored thereon executable instructions that when executed by a processor of a computer control the computer to perform steps is provided. The steps include configuring a first proxy node as a leader service communications proxy (SCP). The steps further include configuring a plurality of second proxy nodes as worker proxy nodes. The steps further include registering the worker proxy nodes with the leader SCP. The steps further include subscribing, by the worker proxy nodes and with the leader SCP, to receive network function (NF) topology information from the leader SCP. The steps further include, at the leader SCP, receiving NF topology information from the worker proxy nodes and communicating the NF topology information to the worker proxy nodes subscribed to receive the NF topology information. The steps further include, at the worker proxy nodes, using the NF topology information to route messages to proxy nodes serving destination NFs.
The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. As such, the terms “function” “node” or “module” as used herein refer to hardware, which may also include software and/or firmware components, for implementing the feature being described. In one exemplary implementation, the subject matter described herein may be implemented using a computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.
The subject matter described herein will now be explained with reference to the accompanying drawings of which:
The subject matter described herein relates to methods, systems, and computer readable media for distributing NF topology information among proxy nodes and for inter-proxy node routing of messages using the NF topology information.
NRF 100 is a repository for NF profiles. In order to communicate with a producer NF, a consumer NF or an SCP must obtain the NF profile from NRF 100. The NF profile is a JavaScript object notation (JSON) data structure defined in 3GPP TS 29.510. The NF 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.
In
A network slice selection function (NSSF) 116 provides network slicing services for devices seeking to access specific network capabilities and characteristics associated with a network slice. A network exposure function (NEF) 118 provides application programming interfaces (APIs) for application functions seeking to obtain information about Internet of things (IoT) devices and other UEs attached to the network. NEF 118 performs similar functions to the service capability exposure function (SCEF) in 4G networks.
A radio access network (RAN) 120 connects UE 114 to the network via a wireless link. Radio access network 120 may be accessed using a g-Node B (gNB) (not shown in
SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic exiting the home PLMN. SEPP 126 may communicate with an SEPP in a foreign PLMN which manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs may traverse a minimum of two SEPP functions, one for the home PLMN and the other for the foreign PLMN. In addition, if multiple messages are required to locate the home PLMN for a subscriber, multiple SEPPs and SCPs may be involved in a messaging transaction involving a subscriber in a foreign network.
As indicated above, one problem with the existing 3GPP service architecture is the inability of an SCP or SEPP to forward messages directly to a proxy node, such as an SCP−, in another network that is directly connected to the destination NF. SCPs act as hypertext transfer protocol (HTTP) proxies for service-based interface HTTP/HTTP2 signaling connecting NFs in the 5G core (5GC) network. Mobile network operators (MNOs) create a multiple 5GC networks, each consisting of a group of 5GC NFs serving a particular geographical region. Once such group of 5GC NFs is illustrated in
Each of these 5GC NF groups may have a dedicated SCP node for inter-NF communication within the group. The same SCP may also be used for inter-SCP communication when a subscriber moves from one region to another region. When the subscriber moves from region to another region, the SCP is not aware the subscriber's home network region SCP.
In
In order to avoid the unnecessary messaging, routing loops, and delay in inter-proxy node messaging, the subject matter described herein provides for proxy nodes, such as SCPs and SEPPs, in the network to exchange messages with each other conveying the identities of the NFs that are directly connected to or served by each proxy node. Each proxy node will notify another proxy node in the network whenever an addition, deletion, or update to an NF connected to the serving proxy node occurs. One of the proxy nodes of a group of proxy nodes will be designated as a leader SCP to which other proxy nodes subscribe to receive updates regarding NFs connected to other proxy nodes in the network. The subscribing proxy nodes are referred to as worker proxy nodes. The worker proxy nodes communicate their NF topology information to the leader proxy node, and the leader proxy node provides the NF topology information to worker proxy nodes subscribed to receive the NF topology information. It should be noted that a worker proxy node can be an SCP or an SEPP. In addition, the subject matter described herein is not limited distributing NF topology information between proxy nodes in the same service provider's network. The exchange and use of NF topology information using the leader SCP and worker proxy nodes described herein can be implemented to exchange NF topology information regarding NFs of different network operators without departing from the scope of the subject matter described herein.
Upon receiving the register messages, leader SCP3 242 may store the NF service information along with information identifying the serving SCP or SEPP in a database local to leader SCP3 242. Worker SCP1 214, worker SCP2 228, worker SEPP1 300 and worker SEPP2 302 may be configured to send the register messages with the NF information initially, when a worker SCP or SEPP is booted up and attached to the network and when changes to network topology connected to an SCP or SEPP occur. For example, each of worker SCP1 214, worker SCP2 228, worker SEPP1 300, and worker SEPP2 300 may be preconfigured with the identity of leader SCP3 242 and to send the initial registration message to leader SCP3 242. In addition, each of worker SCP1 214, worker SCP2 228, worker SEPP1 300, and worker SEPP2 300 may be configured to send a register message to leader SCP3 242 when an NF connected to a worker SCP or SEPP deregisters from the network to notify the leader SCP of the deregistration. The leader SCP may then remove the deregistered NF from its local database of NF and SCP/SEPP topology information. Similarly, when a new NF becomes connected to a worker SCP or SEPP, the worker SCP or SEPP may send a register message to the leader SCP to notify the leader SCP of the newly added NF. The leader SCP may add the identity new NF and its serving proxy node (SCP and/or SEPP) to its local database of NF and SCP/SEPP topology information. When a worker SCP or SEPP is notified of a change in capabilities (such as a software version update) of an NF connected to the worker SCP or SEPP, the worker SCP or SEPP sends a registration message to the leader SCP notifying the leader SCP of the change in NF capabilities. The leader SCP will then update the information in its local inter-proxy node NF topology database of the newly added NF information.
In addition to sending the register messages to the leader SCP, the worker SCPs and SEPPs send subscribe messages to the leader SCP to subscribe to receive notifications of changes in NF topology information regarding NFs connected to other worker SCPs or SEPPs or to the leader SCP. In the example illustrated in
The notify messages may include the NF topology information for all of the SCPs and SEPPs connected to the leader SCP other than the self topology information of the subscribing SCP or SEPP. For example, the NF topology information in the notify message sent to worker SCP1 214 may include the identities of worker SCP2 228, worker SEPP1 300, worker SEPP2 302, leader SCP3 242 and topology information for NFs connected to worker SCP2 228, worker SEPP1 300, worker SEPP2 302, and leader SCP3 242. The NF topology information in the notify message sent to worker SCP2 228 may include the identities of worker SCP1 214, worker SEPP1 300, worker SEPP2 302, leader SCP3 242 and the topology information for NFs connected to worker SCP1 214, worker SEPP1 300, worker SEPP2 302, and leader SCP3 242. The NF topology information in the notify message sent to worker SEPP1 228 may include the identities of worker SCP1 214, worker SCP2 228, worker SEPP1 300, worker SEPP2 302, leader SCP3 242 and the topology information for NFs connected to worker SCP1 214, worker SCP2 228, worker SEPP2 302, and leader SCP3 242. The NF topology information in the notify message sent to worker SEPP2 302 may include the identities of worker SCP1 214, worker SCP2 228, worker SEPP1 300, leader SCP3 242 and the topology information for NFs connected to worker SCP1 214, worker SCP2 228, worker SEPP1 300, and leader SCP3 242. Once the SCPs and SEPPs have the NF topology information for the NFs connected to other SCPs and SEPPs in the network, the SCPs and SEPPs can send inter-SCP/SEPP messaging directly to the SCP or SEPP serving the destination NF for a particular subscriber, avoiding unnecessary signaling, delay, and routing loops.
The subscribe messages sent from worker SCPs/SEPPs to the preconfigured leader SCP may request a list of all the registered SCPs in the network and corresponding lists of NFs connected to/served by each of the SCPs. Each subscribe message may optionally include a subscription duration and an indication of whether the subscription request is for all proxy nodes in the network or individual proxy nodes (identified by SCP or SEPP fully qualified domain name (FQDN)). As indicated above, the leader SCP may include the list of the registered SCPs and corresponding list of NFs/NF services in the subscription response back to worker SCPs/SEPPs.
The notify messages are sent from leader SCP to worker SCP/SEPP when there is change in network topology, i.e., addition/deletion/updating of NF instances connected to individual registered SCPs. The notify message will also include an indication as to whether a de-registration of worker SCPs/SEPPs in the network has occurred. If the subscription duration is included a subscribe message for a given subscription, on expiry of subscription duration, each worker SCP/SEPP is required to send a new subscription request to the leader SCP to receive NF topology information from the leader SCP. Each worker SCP/SEPP will use the registered SCP list and corresponding NF list connected to each of the SCPs/SEPPs to route the HTTP2 signaling messages between NFs through the right SCP to which destination NF is directly connected.
From Table 1, it can be seen that SCP4 includes a complete set of NF and SCP topology information for routing messages directly to the SCP that is connected to a destination NF for a particular message.
In step 602, the process includes configuring a plurality of second proxy nodes as worker proxy nodes. For example, a network operator or a network equipment vendor may configure SCPs and/or SEPPs to function as worker proxy nodes. Configuring the SCPs and/or SEPPs to function as worker proxy nodes may include configuring the SCPs and/or SEPPs with the identity of a leader SCP and to register with the leader SCP. The worker SCP/SEPP configuration may further include a list of SCP and/or SEPPs to which the worker SCP or SEPP may subscribe to receive network topology information.
In step 604, the process includes subscribing, by the worker proxy nodes and with the leader SCP, to receive NF topology information from the leader SCP. In one example, a worker proxy node may be configured to subscribe to all SCPs and/or SEPPs of which the leader SCP has NF topology information. In an alternate implementation, the worker proxy node may be configured to subscribe to a subset of SCPs and/or SEPPs of which the leader SCP has NF topology information. The worker proxy nodes may send subscribe messages to the leader SCP to create a subscription.
In step 606, the process includes, at the leader SCP, receiving NF topology information from the worker proxy nodes and communicating the NF topology information to the worker proxy nodes subscribed to receive the NF topology information. For example, the leader SCP may receive NF topology information from the worker proxy nodes when the worker proxy nodes register with the network or any time that NF topology information associated with a worker proxy node is updated. The leader SCP may transmit notify messages to worker proxy nodes subscribed to receive the NF topology information, where the notify messages identify the proxy nodes (e.g., SCPs or SEPPs) and the NFs (e.g., AMFs, UDMs, PCFs, etc.) served by each of the proxy nodes.
In step 608, the process includes using the NF topology information to route messages to proxy nodes serving destination NFs. For example, when a worker or a leader proxy node receives a message that is intended for an NF that is not directly connected to the proxy node, the proxy node may access its inter-proxy node NF topology database populated using the methodology described herein. The proxy node may use the identity (such as the FQDN) of the destination NF to access the inter-proxy node NF topology database. The result of the access will be the identity (e.g., the FQDN or IP address) of the proxy node that serves the destination NF. The proxy node will then route the message to the proxy node that serves the destination NF. The message may be routed directly from the proxy node that receives the message from one of its local NFs to the proxy node that serves the destination NF, avoiding the need to contact multiple proxy nodes in an attempt to find the proxy node that serves a particular NF.
It should be understood that while the examples described above include a single proxy node designated as a leader SCP, the subject matter described herein is not limited to such an implementation. As an operator's network grows, the operator may configure multiple SCPs as leader SCPs, where the leader SCPs each serve different groups of worker SCPs. So that each worker SCP can obtain a complete set of NF topology information, the leader SCPs may be deployed in a hierarchical manner such that the SCPs in the first level of leader SCPs each communicate directly with worker SCPs to obtain and distribute network topology information. The leader SCPs in the next level of leader SCPs may only communicate with leader SCPs in the first level to consolidate network topology information obtained by different leader SCPs. The leader SCP or SCPs in the highest level of the hierarchy may contain a complete set of NF topology information for all of the NFs in all of the regions of an operator's network. Thus, when a worker SCP subscribes to receive NF topology information for all of the NFs in an operator's network with a hierarchy of leader SCPs, the subscribe message may be forwarded up the levels in the hierarchy until the subscription reaches a level that contains the requested information, and a leader SCP in that level may provide the NF topology information to the requesting worker SCP.
Thus, using the system of leader SCPs and worker proxy nodes described herein, routing loops and unnecessary messaging resulting from routing messages to incorrect proxy nodes can be reduced and even avoided. In addition, latency in messaging associated with authentication and other transactions involving mobile subscribers and non-local NFs can be reduced.
It will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.
Number | Name | Date | Kind |
---|---|---|---|
5592672 | Grewal | Jan 1997 | A |
5719861 | Okanoue | Feb 1998 | A |
6105034 | Buckler | Aug 2000 | A |
6366577 | Donovan | Apr 2002 | B1 |
6385198 | Ofek et al. | May 2002 | B1 |
6404746 | Cave et al. | Jun 2002 | B1 |
6735291 | Schmid et al. | May 2004 | B1 |
7308499 | Chavez | Dec 2007 | B2 |
7742421 | Bantukul et al. | Jun 2010 | B2 |
7929419 | Sprague | Apr 2011 | B2 |
8498202 | Kanode et al. | Jul 2013 | B2 |
9071512 | Marsico | Jun 2015 | B2 |
10299128 | Suthar et al. | May 2019 | B1 |
10361843 | Suthar et al. | Jul 2019 | B1 |
10595256 | Marupaduga et al. | Mar 2020 | B1 |
10609154 | Talebi Fard et al. | Mar 2020 | B2 |
10616934 | Talebi Fard et al. | Apr 2020 | B2 |
10778527 | Assali et al. | Sep 2020 | B2 |
20010039585 | Primak et al. | Nov 2001 | A1 |
20030086410 | Eikkula | May 2003 | A1 |
20040088424 | Park et al. | May 2004 | A1 |
20040114744 | Trossen | Jun 2004 | A1 |
20040158606 | Tsai | Aug 2004 | A1 |
20040205190 | Chong et al. | Oct 2004 | A1 |
20040221061 | Chavez | Nov 2004 | A1 |
20050207402 | Kobayashi et al. | Sep 2005 | A1 |
20050227685 | Costa Requena et al. | Oct 2005 | A1 |
20050232407 | Craig et al. | Oct 2005 | A1 |
20060010321 | Nakamura et al. | Jan 2006 | A1 |
20060069776 | Shim et al. | Mar 2006 | A1 |
20060101143 | Garcia et al. | May 2006 | A1 |
20060104210 | Nielsen | May 2006 | A1 |
20060253563 | Yang et al. | Nov 2006 | A1 |
20070156909 | Osborn et al. | Jul 2007 | A1 |
20070191004 | Yamakawa et al. | Aug 2007 | A1 |
20080280623 | Danne et al. | Nov 2008 | A1 |
20090185494 | Li et al. | Jul 2009 | A1 |
20090268723 | Przybysz | Oct 2009 | A1 |
20100261490 | Berry et al. | Oct 2010 | A1 |
20120079082 | Ding et al. | Mar 2012 | A1 |
20130029708 | Fox et al. | Jan 2013 | A1 |
20150003296 | Fan | Jan 2015 | A1 |
20150249588 | Leon | Sep 2015 | A1 |
20150351084 | Werb | Dec 2015 | A1 |
20160149811 | Roch | May 2016 | A1 |
20160352588 | Subbarayan et al. | Dec 2016 | A1 |
20170220367 | Li | Aug 2017 | A1 |
20170353387 | Kwak | Dec 2017 | A1 |
20180227243 | Zhang | Aug 2018 | A1 |
20180324646 | Lee et al. | Nov 2018 | A1 |
20180343567 | Ashrafi | Nov 2018 | A1 |
20190045351 | Zee et al. | Feb 2019 | A1 |
20190075552 | Yu et al. | Mar 2019 | A1 |
20190116486 | Kim et al. | Apr 2019 | A1 |
20190116521 | Qiao et al. | Apr 2019 | A1 |
20190158364 | Zhang et al. | May 2019 | A1 |
20190173740 | Zhang et al. | Jun 2019 | A1 |
20190174561 | Sivavakeesar | Jun 2019 | A1 |
20190182875 | Talebi Fard et al. | Jun 2019 | A1 |
20190191348 | Futaki et al. | Jun 2019 | A1 |
20190191467 | Dao et al. | Jun 2019 | A1 |
20190223093 | Watfa et al. | Jul 2019 | A1 |
20190261244 | Jung et al. | Aug 2019 | A1 |
20190306907 | Andreoli-Fang et al. | Oct 2019 | A1 |
20190313236 | Lee et al. | Oct 2019 | A1 |
20190313437 | Jung et al. | Oct 2019 | A1 |
20190313469 | Karampatsis et al. | Oct 2019 | A1 |
20190335002 | Bogineni et al. | Oct 2019 | A1 |
20190335534 | Atarius et al. | Oct 2019 | A1 |
20190342921 | Loehr et al. | Nov 2019 | A1 |
20190349901 | Basu Mallick et al. | Nov 2019 | A1 |
20190357092 | Jung et al. | Nov 2019 | A1 |
20190380031 | Suthar et al. | Dec 2019 | A1 |
20190394624 | Karampatsis et al. | Dec 2019 | A1 |
20190394833 | Talebi Fard et al. | Dec 2019 | A1 |
20200008069 | Zhu et al. | Jan 2020 | A1 |
20200028920 | Livanos et al. | Jan 2020 | A1 |
20200045753 | Dao et al. | Feb 2020 | A1 |
20200045767 | Velev et al. | Feb 2020 | A1 |
20200053670 | Jung et al. | Feb 2020 | A1 |
20200053724 | Molavianjazi et al. | Feb 2020 | A1 |
20200053828 | Bharatia et al. | Feb 2020 | A1 |
20200059856 | Cui et al. | Feb 2020 | A1 |
20200084663 | Park et al. | Mar 2020 | A1 |
20200092423 | Qiao et al. | Mar 2020 | A1 |
20200092424 | Qiao et al. | Mar 2020 | A1 |
20200136911 | Assali et al. | Apr 2020 | A1 |
20200192725 | Feldkamp | Jun 2020 | A1 |
Number | Date | Country |
---|---|---|
1700694 | Nov 2005 | CN |
101151861 | Mar 2008 | CN |
ZL 200780036907.1 | Feb 2012 | CN |
0 950 952 | Oct 1999 | EP |
1 175 074 | Jan 2002 | EP |
333811 | Mar 2020 | IN |
2006-279805 | Oct 2006 | JP |
10-2004-0057858 | Jul 2004 | KR |
10-2005-0002335 | Jan 2005 | KR |
10-2006-0025869 | Mar 2006 | KR |
WO 0069140 | Nov 2000 | WO |
WO 0113228 | Feb 2001 | WO |
WO 2008019056 | Feb 2008 | WO |
WO 2009018418 | Feb 2009 | WO |
WO 2011100629 | Aug 2011 | WO |
WO 2018174021 | Sep 2018 | WO |
WO 2018174516 | Sep 2018 | WO |
WO 2019034609 | Feb 2019 | WO |
WO 2019220172 | Nov 2019 | WO |
WO 2020091934 | May 2020 | WO |
Entry |
---|
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 16/176,920 (dated Apr. 16, 2020). |
Applicant-Initiated Interview Summary for U.S. Appl. No. 16/176,920 (dated Apr. 1, 2020). |
Non-Final Office Action for U.S. Appl. No. 16/176,920 (dated Mar. 6, 2020). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application Serial No. PCT/US2019/053912 (dated Dec. 18, 2019). |
“3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Enhancements to the Service-Based Architecture (Release 16),” 3GPP TR 23.742, V0.2.0, pp. 1-39 (Jun. 2018). |
“5G; Procedures for the 5G System (3GPP TS 23.502 version 15.2.0 Release 15),” ETSI TS 123 502 V15.2.0, pp. 1-46 (Jun. 2018). |
“Pseudo-CR on Service Discovery and Registration using NRF service,” Ericsson, 3GPP TSG CT4 Meeting #79, 3GPP TR 29.891-v0.3.0, pp. 1-4 (Aug. 21-25, 2017). |
Commonly-assigned, co-pending U.S. Appl. No. 16/176,920 for “Methods, Systems, and Computer Readable Media for Providing a Service Proxy Function in a Telecommunications Network Core Using a Service-Based Architecture,” (Unpublished, filed Oct. 31, 2018). |
“3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 16),” 3GPP TS 29.510, V16.0.0, pp. 1-135 (Jun. 2019). |
“3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Enhancements to the Service-Based Architecture (Release 16),” 3GPP TR 23.742, V0.3.0, pp. 1-64 (Jul. 2018). |
Scholl et al., “An API First Approach to Microservices Development,” Oracle, https://blogs.oracle.com/developers/an-api-first-approach-to-microservices-development, pp. 1-12 (Nov. 8, 2017). |
Hearing Notice for Indian Application No. 1106/CHENP/2009 (May 28, 2015). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 13/197,566 (dated Feb. 20, 2015). |
Notification of the Second Office Action for Chinese Application No. 201180013381.1 (dated Feb. 10, 2015). |
Notification of Reexamination for Chinese Application No. 200880109633.9 (dated Jan. 29, 2015). |
Extended European Search Report for European Patent Application No. 08796925.9 (dated Nov. 21, 2014). |
Non-Final Office Action for U.S. Appl. No. 13/197,566 (dated Aug. 27, 2014). |
Notification of Reexamination for Chinese Patent Application No. 200880109633.9 (dated Jul. 28, 2014). |
Notification of the First Office Action for Chinese Application No. 201180013381.1 (dated Jun. 5, 2014). |
First Examination Report for Indian Patent Application No. 1106/CHENP/2009 (dated Jan. 28, 2014). |
Extended European Search Report for European Application No. 07836478.3 (dated Nov. 18, 2013). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 13/026,153 (dated Apr. 15, 2013). |
Communication of European Publication No. And Information on the Application of Article 67(3) EPC for European Patent Application No. 11742923.3 (dated Nov. 21, 2012). |
First Office Action for Chinese Patent Application No. 200820109633.9 (dated May 3, 2012). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2011/024645 (dated Oct. 28, 2011). |
Notice of Allowance for U.S. Appl. No. 11/510,284 (dated Dec. 9, 2010). |
Chinese Office Action for Chinese Patent Application No. 200780036907.1 (dated Oct. 11, 2010). |
Final Official Action for U.S. Appl. No. 11/510,284 (dated Jun. 22, 2010). |
Official Action for U.S. Appl. No. 11/510,284 (dated Feb. 23, 2010). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 12/183,406 (dated Feb. 12, 2010). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Diameter-based Protocols Usage and Recommendations in 3GPP (Release 9),” 3GPP TR 29.909 V9.0.0 (Dec. 2009). |
Tsou et al., “Realm-Based Redirection in Diameter,” Internet Engineering Task Force, draft-ietf-dime-realm-based-redirect-02, pp. 1-7 (Oct. 27, 2009). |
Final Official Action for U.S. Appl. No. 11/510,284 (dated Jul. 9, 2009). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2008/071718 (dated Jan. 28, 2009). |
Official Action for U.S. Appl. No. 11/510,284 (dated Dec. 24, 2008). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US07/17329 (dated Feb. 15, 2008). |
A. B. Roach, “Session Initiation Protocol (SIP)-Specific Event Notification,” dynamicsoft, Network Working Group, pp. 1-38 (Jun. 2002). |
Rosenberg, “SIP Proxies,” www.dynamicsoft.com, pp. 1-30 (Jul. 2000). |
Wiesmann et al., “Understanding Replication in Databases and Distributed Systems,” IEEE, pp. 464-474 (Apr. 10, 2000). |
Wang et al., “A Signaling System Using Lightweight Call Sessions,” IEEE, pp. 697-706 (Mar. 26, 2000). |
Gribble et al., “The MultiSpace: an Evolutionary Platform for Infrastructural Services,” the University of California at Berkeley, pp. 157-170 (Jun. 6, 1999). |
Handley et al., “SIP: Session Initiation Protocol,” IETF RFC 2543, pp. 1-153 (Mar. 1999). |
Handley et al., “SDP: Session Description Protocol,” IETF RFC 2327, pp. 1-42 (Apr. 1998). |
S. Paul et al., “Reliable Multicast Transport Protocol (RMTP),” IEEE Journal on Selected Areas in Communications, vol. 15, No. 3, pp. 407-421 (Apr. 1997). |
Lin et al., “A Reliable Multicast Transport Protocol,” IEEE Infocom, pp. 1414-1424 (1996). |
Commonly-assigned, co-pending International Application No. PCT/US19/53912 for “Methods, Systems, and Computer Readable Media for Providing a Service Proxy Function in a Telecommunications Network Core Using a Service-Based Architecture,” (Unpublished, filed Sep. 30, 2019). |
Commonly-assigned, co-pending U.S. Appl. No. 17/082,871 for “Methods, Systems, and Computer Readable Media for Rank Processing for Network Function Selection,” (Unpublished, filed Oct. 28, 2020). |
Number | Date | Country | |
---|---|---|---|
20210111985 A1 | Apr 2021 | US |