Patent ID: 12232015

DETAILED DESCRIPTION

Overview

This disclosure is directed in part to systems and techniques for performing for repository function address blocking in wireless communications networks and other networks that perform wireless device registration and resource provisioning. Such networks include any networks that may facilitate wireless communications services for one or more wireless communications devices. Such networks include networks that support one or more 3GPP standards, including, but not limited to, Long Term Evolution (LTE) networks (e.g., 4G LTE networks) and New Radio (NR) networks (e.g., 5G NR networks). However, the disclosed systems and techniques may be applicable in any network or system in which a user device may request and receive access to communicate with one or more network and/or remote devices using any protocol.

In conventional systems, a wireless user device (e.g., mobile telephone, smartphone, user equipment (UE), etc.) may wirelessly communicate with a base station (e.g., gNodeB, eNodeB, NodeB, base transceiver station (BTS), etc.) to request wireless communications services, such as a packet data communication session between the user device and a data network (e.g., the Internet, an IP multimedia system or subsystem (IMS), etc.). Various operations may be performed by network components, devices, and/or functions to obtain or otherwise establish the requested services for the wireless user device. Such operations may include authenticating the wireless user device and/or a user of the device, authorizing the requested services for the device and/or user, registering the device at the various systems and functions needed to provide the requested services, etc.

For example, a UE may transmit a request for a protocol data unit (PDU) session with a data network to a gNodeB. A PDU session, for example in a 5G network, may be an end-to-end communications session between a device (e.g., the UE) and a data network (e.g., the Internet). The gNodeB may relay or otherwise convey this PDU session request to an access management function (AMF) in the core of the wireless network in which the gNodeB is configured. The AMF may interact with one or more other components to perform the operations needed to establish this session, such as authenticating the device and/or user, registering the UE with the network, etc. In a particular example, the AMF may interact with a session management function (SMF) to establish the session. The SMF may perform various session establishment operations, such as determining and assigning particular functions and/or components to service the session, associating policies for the session, etc. In examples, an important function performed by an SMF may be providing the access information needed by the UE to communicate with a data network using the established session. The SMF provides this information to the AMF for relay to the gNodeB and ultimately to the UE requesting the PDU session. In 5G examples, a message that provides such information may be referred to as a “N1N2MessageTransfer.” These and other messages communicating similar information may be referred to generally herein as a “message transfer” messages.

Components and functions within a network, such as AMFs and SMFs, may vary and may change often due to operational circumstances (e.g., maintenance, load, failures, etc.). Therefore, in various examples, a network may include a repository component or function that is configured to store and provide current addresses and/or other connectivity information for the functions and/or components in the network. In response to receiving a request from a particular function in a network, a repository function may provide a current address (e.g., IP address) for another function to the requesting function. The requesting function may then use that address to communicate with the associated function to perform one or more operations. In 5G examples, such a repository function may be referred to as a network function (NF) repository function (NRF). These and other functions performing similar operations may be referred to generally herein as a “repository functions.” In various embodiments, for example, for load-sharing and/or redundancy purposes, multiple NRFs may be configured in “pools” of NRFs that may be queried by various components and/or functions in (e.g., particular portions of) a core of a wireless network.

In various examples, a particular function may have multiple addresses (e.g., IP addresses) that it may use to communicate with one or more other functions and/or components configured in a network. By using multiple address and/or communications interfaces, a single function or component in a network may interact with multiple other functions and/or components (e.g., substantially simultaneously) and thereby perform various operations more quickly and efficiently. By having multiple address and/or communications interfaces, a single function or component in a network may also have redundant means of communicating with other functions and/or components. For example, if one particular address or interface is no longer reachable for some reason, the function using that address or interface may communicate with other functions and/or components using one of its other addresses or interfaces. In some examples, one or more particular addresses or interfaces configured at a function may be dedicated to one or more particular services or operations, while in other examples, one or more addresses or interfaces configured at a function may be generally available for some or all of the services and/or operations performed at that function. In particular examples, an AMF may be configured with multiple addresses that may be used to communicate with the AMF for various operations, such as PDU session establishment operations.

The repository functions in a network, (e.g., the one or more NRFs in an NRF pool) may be configured to store and maintain the multiple addresses that may be configured for individual network functions and/or components. For example, each NRF in a particular NRF pool may be configured to store the multiple IP addresses that may be configured for a particular AMF. When a request for an IP address for the AMF is received by an NRF in the NRF pool, the NRF may determine one of the addresses to provide in response. For example, the NRF may randomly select an address associated with the AMF to provide in response. Alternatively, the NRF may provide the IP addresses in a round-robin manner, for example, in an effort to load balance traffic for the AMF across the available addresses. Other techniques may also, or instead, be used by a repository function to select an address from those available for a particular component or function. In some examples, a repository function may choose from addresses dedicated to a service or operation associated with the request for the address, while in other examples the repository function may select addresses without taking into account a service or operation.

Ideally, individual repository functions (e.g., each NRF in an NRF pool, and in some examples, each NRF across multiple NRF pools where such a configuration is in place), should have the same corresponding addresses stored for the functions and/or components for which it serves as an address repository. However, the address information stored at one or more repository functions may become out of synchronization with that stored on other repository functions and/or may be out of date for various reasons (e.g., missed updates, configuration error, communications issues, etc.). In such situations, the out-of-sync repository function may reply to requests for address with out-of-date and/or incorrect address information. In other cases, a particular address, even though current and in use by a particular component or function, may not be reachable or otherwise usable by another component. For example, there may be a routing issue or misconfiguration in the core wireless network that prevents a first component from successfully communicating with a particular address of a second component. If the first component queries a repository function for an address for the second component and receives the unreachable address in response, the first component will fail to successfully communicate with the second component, regardless if why the address is unreachable.

To address this issue of receiving unreachable addresses from a repository function and to mitigate the inefficiency introduced into a network by providing unreachable addresses to various functions and/or components, the disclosed systems and methods allow for the creation and use of a “block list” on a repository function. This block list may include one or more entries that indicate an address-requesting component and a corresponding blocked component and/or address. In various examples, a repository function may use this block list in determining the address to include in a response to a component or function that has requested an address for another component or function. After determining an address in response to an address request, the repository function may determine if the address is associated with the requesting component or function in the block list. If so, the repository function may determine another address instead (also checking that address against the block list) and reply with an address that is not blocked for the requesting component or function in the block list.

In various examples, a repository function may determine the information for use in such a block list from communications received from functions and/or components. For example, a particular component may receive a first address for a destination component from a repository function. The address-requesting component may then determine that it is unable to communicate with the destination component using the first address. The address-requesting component may transmit an instruction to the repository function requesting that the repository function include an entry in a block list that will prevent the first address from being provided to the address-requesting component in response to a request for an address for the destination component. In some examples, the repository function may also transmit a notification to the destination component that the address-requesting component is unable to communicate with the destination component using the first address. The destination component may use this information to avoid attempting to communicate with the address-requesting component using the first address.

The address-requesting component may attempt to communicate with the first address in the future (e.g., based on a timer expiry) and, if it is successful, it may transmit another instruction to the repository function to remove the entry in a block list. Alternatively or additionally, the address-requesting component may determine based on other factors to request that the repository function remove the entry from the block list. A repository function may notify a corresponding destination component when it removes an entry from a block list. The destination component may use this information to resume communicating with the address-requesting component using the previously blocked address.

By facilitating the use of such block lists and entries at a repository function, the systems and methods described herein provide more efficient and accurate determinations of addresses by repository functions and reduced resource utilization. By minimizing the distribution and attempted usage of unreachable function and component addresses, the systems and methods described herein can improve the performance and increase the efficiency of both network and user resources. For example, the methods and systems described herein may be more efficient and/or more robust than conventional techniques, as they may increase the use of valid addresses and reduce the wasting of resources on attempts to communicate using invalid or otherwise unreachable addresses. That is, the methods and systems described herein provide a technological improvement over existing address determination systems and processes by facilitating improved address determination accuracy and increasing network efficiency by reducing the traffic associated with failed attempts to communicate using unreachable addresses and repeated requests for addresses when unreachable addresses are used initially. In addition to improving the efficiency of network and device resource utilization, the systems and methods described herein can provide more robust systems by, for example, making more efficient use of network devices by reducing unnecessary and/or unproductive device and network signaling and processing associated with unreachable addresses and devices, thereby freeing network and device resources for more productive operations.

Illustrative environments, signal flows, and techniques for implementing systems and methods for repository function address blocking are described below. However, the described systems and techniques may be implemented in other environments.

Illustrative System Architecture

FIG.1is a schematic diagram of an illustrative wireless network environment100in which the disclosed systems and techniques may be implemented. The environment100may include a UE110that may wirelessly communicate with an gNodeB120and a UE112that may wirelessly communicate with a gNodeB122. While referred to as an “gNodeBs” for explanatory purpose herein, the gNodeBs120and122may be any type of base station, including, but not limited to, any type of BTS, NodeB, eNodeB, gNodeB, etc. The gNodeBs120and122may communicate with other components and functions in a core network101. The core network101may be any one or more networks that facilitate communications between particular devices, components, and/or functions of various types in the core of a wireless communications network that may facilitate communication between computing device and/or mobile devices (e.g. UEs). Various connections between components and functions in the core network101may be wired, wireless, or a combination thereof. The components and functions described herein may be implemented as physical devices, as software components executing on one or more computing devices, any combination thereof. In various embodiments, the core network101may facilitate the establishment of communications sessions for one or more wireless devices, such as UEs110and112. In examples, the core MAS network101may facilitate authorized packet-based communications between such wireless devices and other wireless devices, devices on the Internet, one or more IP multimedia subsystems (IMSs), and/or one or more other data networks (DNs).

InFIG.1, connections between components may be logical connections indicated by dashed lines. These logical connections may also be facilitated by one or more wired and/or wireless connections and may include traversal of one or more devices, components, and/or functions (not shown inFIG.1).

In environment100, the UE110may communicate with the gNodeB120to request the establishment of a PDU session (e.g., to communicate with one or more systems at the Internet190). The gNodeB120may relay the request or otherwise transmit a request for the establishment of the PDU session to an AMF130. In various examples, an AMF may interact with an SMF to allocate the resources required to establish PDU sessions for UEs. Such interactions may include authenticating and authorizing a user and/or user device (e.g., UE), creating contexts for such sessions, determining and applying session policies, establishing user plane resources, etc. Therefore, the AMF130, based on receiving this request for the establishment of a PDU session on behalf of the UE110, may query one or more of the NRF pools170and172for an address (e.g., IP address) for an SMF with which it may interact to establish the requested PDU session.

In examples, the AMF130may exchange SMF discovery communications133with one or more of NRFs170a-cof NRF pool170or NRFs172a-cof NRF pool172. As described herein, a wireless communications network may be configured with one or more NRF pools, each of which may include one or more NRFs. In this discovery communication133, the AMF130may provide an identifier of one or more particular SMFs with which it may wish to interact or it may request an SMF address generally. The AMF130may or may not specify in the communication133a particular service for which the AMF130is requesting an address.

In some examples, NRF pools such as pools170and172may be geographically located and configured to provide repository function services to functions and components that are relatively geographically proximate to the pool. In such examples, there may be one or more pools provided for a particular geographical area or region. The NRFs within each pool may be configured to have synchronized address information for the various devices represented in each NRF. However, as described herein, such information may become out of sync and/or may not be valid information for component users of such NRF.

In this example, the AMF130may receive an address for an SMF150from one of NRFs170a-cof NRF pool170or NRFs172a-cof NRF pool172. The AMF130may then initiate PDU session establishment communications, such as create context communications151, with SMF150. Note that the AMF130may be configured with multiple addresses and may use a first of such addresses in this example for the communications151. The SMF150may perform various PDU session establishment operations, in some examples interacting with one or more other components and/or functions. For example, the SMF150may interact with one or more of the registration services140, which may include any one more of an authentication server function (AUSF)142, a unified data management (UDM)144, a unified data repository (UDR)146, and a policy control function (PCF)148(operations not shown inFIG.1). In various examples, the SMF150may also communicate with the AMF130via communications151, for example, to acknowledge receipt of a context creation request, to indicate that the requested context for the PDU session has been successfully created, to indicate that creation of the requested context has failed, etc. In the communications151, the SMF150may use the first address associated with the AMF130that the AMF used to initiate the communications151.

Beyond context creation, the SMF may perform one or more other operations to complete establishing the PDU session for the UE110. For example, the SMF150may determine or otherwise perform operations to generate information that the UE110and/or the gNodeB120may use to facilitate packet communications with other devices using the PDU session. Such information may include tunnel information, quality of service (QoS) information, session identifier(s), security information, and/or any other information needed by a UE and/or a gNodeB to successfully use a PDU session for packet communications with one or more other devices and/or DNs. This information may be referred to here generally as message transfer data, or in specific 5G examples, as N1N2MessageTransfer data.

To convey message transfer data to the AMF130, the SMF150may use a separate and distinct communications sessions than communications151, which may be dedicated to context creation communications. For example, the SMF150may establish N1N2MessageTransfer communications157for providing message transfer data to the AMF130. In order to determine an address for the AMF130to use with communications157, the SMF150may query one of NRFs170a-cof NRF pool170or NRFs172a-cof NRF pool172. The SMF150may exchange AMF discovery communications153with one or more of these NRFs. In this discovery communication153, the SMF150may provide an identifier of the AMF130(e.g., received during communication151and/or as configured at the SMF150). The SMF150may or may not specify in the communication153a particular service for which the SMF150is requesting an address.

The queried NRF may respond via the discovery communications153with an address for the AMF130. In some examples, this may be the first address that was used in communication151. In other examples, this may be another address for the AMF130with which the SMF150is able to successfully communicate. In such examples, the SMF150may the use the provided address for the AMF130to establish the N1N2MessageTransfer communications157and provide message transfer data for the requested PDU session to the AMF130. The AMF130may then provide this information to the gNodeB120(that may provide some or all of such information to the UE110). Using this information, the UE110may, via the gNodeB120, exchange user data123with the devices and/or DNs (e.g., the Internet190) via a user plane function (UPF)160.

However, in other examples, a second address for the AMF130provided to the SMF150by the queried NRF may be different than the first address for the AMF140(used for the create context communications151) and may not be an address reachable by the SMF150. For example, the particular NRF queried may have out of date information and/or may be out of sync with other NRFs and may therefore be providing one or more expired or otherwise invalid addresses for the AMF130. Alternatively or additionally, the queried NRF may have provided a valid and current address for the AMF130, but for other reasons that address may not be reachable by the SMF150(e.g., due to a routing or configuration issue). In some examples, the queried NRF may have provided an empty, incomplete, improperly formatted, or otherwise invalid address for the AMF130(e.g., due to a configuration issue at the NRF). Regardless of the reason, because the address provided by the NRF is not reachable by the SMF150, the SMF150may be unable to provide the message transfer data to the AMF130, thereby preventing the completion and use of the PDU session requested by the UE110.

The SMF150may determine that the second address for the AMF130provided by the queried NRF is unreachable, for example due to failing to receive a response from the AMF150, receiving an indication of communications failure, etc. In response, the SMF150may transmit a block request via block request communications155to the NRF that provided the second address. For example, the SMF150may have queried NRF170cfor an address for the AMF130and may have received the second address in response. Based on determining that the second address is not reachable by the SMF150, the SMF150may generate and transmit a block request indicating that the NRF170cshould add the second address to a block list for the SMF150that will prevent the NRF170cfrom providing the second address to the SMF150. The SMF150may locally store the second address as an unreachable address and an indication of the NRF from which it received the unreachable address.

In response to receiving the block request via the block request communications155, the NRF170cmay generate an entry in a block list indicating that the second address is to be blocked from being provided to the SMF150(e.g., generally or specifically in response to requests from the SMF150for an address for the AMF130). The NRF170cmay also, or instead, transmit a block notification via block notification communications156to the AMF130indicating that the second address for the AMF130has been blocked for the SMF150on the NRF170c. The AMF130may store this information in a block list of its own and use it in determining communications means for future communications with the SMF150. For example, if the AMF130determines to initiate communications with the SMF150(e.g., create context communications based on receiving an address for the SMF150from an NRF), the AMF130may evaluate its own block list to determine if any of its own addresses are blocked for communications with the SMF150. If so, the AMF130may select one of its unblocked addresses to initiate the communications with the SMF150.

Continuing this example, the SMF150, in response to determining that the second address received for the AMF130is unreachable, may query one or more of NRFs170a-cof NRF pool170or NRFs172a-cof NRF pool172for another address for the AMF130. Because the second, unreachable address is now on a block list on NRF170c, even if the SMF150queries that particular NRF again, it will not receive the unreachable address in response and instead will receive another address for the AMF130. The SMF150may then attempt to provide the message transfer data to the AMF130using the newly obtained address for the AMF. In various examples, the SMF150may also generate and/or transmit an alarm or other indication to one or more users or operators of the wireless network indicating that an unreachable address has been detected. This may facilitate any remedial actions that may be needed by the network operator to remedy the problem causing the unreachability and/or to update NRFs to ensure that they have current and accurate information.

The SMF150may periodically check addresses for which it has stored indications that they are unreachable. For example, the SMF150may set a timer and/or associate a timestamp with an unreachable address when it stores an indication that the address is unreachable. After a threshold amount of time has passed and/or the expiration of the timer, the SMF150may transmit a test message or other type of communication to the indicated unreachable address to determine whether connectivity to the associated function or component has been restored. If the address remains unreachable, the SMF150may restart the time, update the associated timestamp, and/or otherwise set the unreachable address for a future test. In various examples, the SMF150may increase the time period between communications tests (e.g., to conserver resources). For example, the SMF may double the time period between tests (e.g., first test performed 5 seconds after address block requested, second test performed 10 second after first test, third test performed 20 seconds after second test, and so forth).

If the previously unreachable address is now reachable by the SMF150, the SMF150may transmit a notification to the NRF that provided the unreachable address that the address is now reachable and/or to otherwise remove the previously unreachable address from the NRF's block list for the SMF150. Continuing the particular example described above, the SMF150may determine (e.g., after testing following an expired time period) that the initially unreachable second address for the AMF130is now reachable. The SMF150may transmit an unblock request to the NRF170c(e.g., via communications155) that instructs the NRF170cto remove the second address from a block list of addresses for the SMF150. In response, the NRF170cmay remove that entry from its block list for the SMF150and may also, or instead, transmit an indication (e.g., via communications156) to the AMF130that it may now resume using the second address for (e.g., initiating) communications with the SMF150.

In various examples, rather than testing between time periods, the SMF150may be configured to remove block list entries after a period of time. For example, after the expiration of a period of time associated with a particular block list entry, the SMF150may transmit one or more requests to the NRF170cto remove the associated block list entry and may also remove data stored at the SMF150indicating the associated blocked address. This SMF150may then determine if the address remains unreachable the next time the address is provided by an NRF. In situations where connectivity restoration is rapid and/or where there are many addresses available for particular functions, this may be more efficient since the address is likely to be accessible and/or removed from NRFs before it is provided again to a same SMF (or other address-requesting function).

In various examples, the SMF150may receive an instruction (e.g., manually generated or user generated) to clear one or more block list entries. In response, the SMF150may transmit one or more requests to the NRF170cto remove block list entries and may also remove data stored at the SMF150indicating blocked addresses.

Similar operations may be performed for establishing a PDU session for the UE112. For example, the gNodeB122may interact with the AMF132, which may interact with the SMF150as described herein (e.g., in regard to the interactions between the AMF130and the SMF150) to perform create context communications152, N1N2MessageTransfer communications158, SMF discovery communications135, AMF discovery communications154, block list requests and notifications, etc. A PDU sessions established for the UE112may be used to exchange user data124with the devices and/or DNs (e.g., the Internet190) via a user plane function (UPF)162.

As described above, an NRF pool may be configured to serve a particular geographical region or area. In examples, the NRF pool172may be dedicated to the area or region in which the gNodeB122and/or the AMF132are configured, while the NRF pool170may be dedicated to the area or region in which the gNodeB120and/or the AMF130are configured. In such examples, a function or component may access NRF pools in multiple regions. For example, the SMF150may access both NRF pools170and172configured in distinct geographical regions. In other examples, both NRF pools170and172are configured in the same geographical region.

Illustrative Functions and Communications

FIGS.2and3illustrates schematic diagram200and300of exemplary functions and communications of various messages that may be exchanged in one or more of the disclosed systems and techniques for performing repository function address blocking as described herein. Reference may be made in this description of the exemplary functions and communications to devices, messages, function, components, and/or operations illustrated inFIG.1and described in regard to that figure. However, the functions and communications illustrated inFIGS.2and3and described herein may be implemented in any suitable system and/or with any one or more suitable devices and/or entities. Moreover, any of the functions and communications described in regard toFIGS.2and3may be used separately and/or in conjunction with other functions and communications and/or implemented using devices, systems, and or operations. All such embodiments are contemplated as within the scope of the instant disclosure.

The AMF130, as shown inFIG.2, may be configured with multiple IP addresses (e.g., 10.0.0.31, 10.0.0.32, and 10.0.0.33) while the SMF150may be configured with one or more IP addresses (e.g., 10.0.0.51). These addresses and identifiers for the associated functions may be stored in the NRF170c. For example, the NRF170cmay store the AMF130IP addresses231,232, and233and the SMF150address251as shown in this figure.

As described herein, the AMF130may determine to initiate communications with the SMF150(e.g., to request creation of a context for a PDU session). The AMF130may transmit an SMF address request210to the NRF170crequesting an IP address for the SMF150. The NRF170cmay respond with an SMF address message211providing the SMF150IP address251to the AMF130. The AMF130may then initiate communications with the SMF150using one of its addresses and the received address for the SMF150. For example, the AMF130may initiate signaling241using the AMF130address231to communicate with the SMF150address251.

The SMF150may also, or instead, determine to initiate communications with the AMF130(e.g., to provide message transfer data for a PDU session). The SMF150may transmit an AMF address request220to the NRF170crequesting an IP address for the AMF130. The NRF170cmay respond with an AMF address message221providing the AMF130IP address232to the SMF150. The SMF150may then attempt to initiate communications with the AMF130using its addresses and the received AMF address. For example, the SMF150may attempt to initiate signaling242using the SMF150address251to communicate with the AMF130IP address232. However, this communications may be unsuccessful (e.g., for any of the reasons set forth herein or any other reason) and signaling242may fail. The SMF150may receive an indication, or otherwise determine, that the signaling242has failed and/or that the AMF130IP address232is unreachable by the SMF150.

In response to detecting that the address232is unreachable, the SMF150may generate and transmit to the NRF170can AMF address block request222requesting that the NRF170cblock or otherwise stop providing the address232to the SMF150in response to requests for an address for the AMF130.

Referring now toFIG.3, the NRF170cmay be configured with a block list370that may include entries indicating AMF-SMF pairs that may be blocked. For example, the entries in the block list370may indicate a particular IP address for an AMF that is blocked from being provided to a particular SMF. Such entries may also, or instead, include other information, such as particular services or functions that may be blocked, SMF (e.g., IP) addresses, timestamps, expirations dates and/or times, etc.

In this example, entry371of the block list may be generated by the NRF170cin response to the AMF address block request222. As shown in this figure, the entry371may indicate the AMF130IP address232and the SMF150. Other entries may indicate other blocked addresses for other functions pairs, such as AMF A address blocked for function XMF X in entry372and YMF C address blocked for SMF Z in entry372. Any combinations of functions and addresses, and pairs of any of such functions and/or addresses, are contemplated for use in a block list as described herein.

The SMF150may also store an indication of the blocked or unreachable AMF address, as shown in entry352configured at SMF150. This entry may include an indication of the NRF at which the SMF150has requested the associated address be blocked so that the SMF150can later request that the address be unblocked should connectivity to the address be restored. As described herein, the SMF150may (e.g., periodically) test unreachable addresses to discover if communicative connectivity has been restored. If so, the SMF150may transmit a request to an NRF (e.g., NRF170c) that the previously unreachable address be unblocked.

As described herein, in response to receiving a request to block an address for a particular SMF (or other function), an NRF may also notify the function or component associated with the address that it has been blocked. For example, the NRF170cmay notify the AMF130that the SMF150has requested that the AMF address232be blocked for the SMF150and/or that the NRF170chas blocked that address for the SMF150. In response, the AMF130may generate and/or store an indication332(e.g., in a block list of its own) that its address232is blocked for SMF150. Based on this indication332, the AMF130may determine not to use its address232in communications with the SMF150, for example, in initiating a communications session with that SMF.

With these block list entries and indications in place, in this example the AMF130may transmit an SMF address request310to the NRF170c, for example in response to receiving a PDU session request from a UE. The NRF170cmay respond with an SMF address message311that may indicate the SMF150address251. The AMF130may use one or more blocked address entries to determine one of its IP addresses to use to initiate communications with the SMF150. For example, based on receiving the address for the SMF150, the AMF130may determine whether it has any blocked address entries for SMF150. In response to detecting the entry332indicating that the AMF130address232is blocked for the SMF150, the AMF130may select another address (e.g., other than one included on an entry associated with SMF150) for initiating the communications. In some examples, the AMF130may select one of its addresses and then compare the address to those in a list of blocked addresses, selecting another if there is a match. In other examples, other techniques may be used to determine an unblocked address for use with another function, all of which are contemplated as within the scope of the instant disclosure. In this particular example, the AMF130may determine to use the address231to establish communications with the SMF150using signaling341.

The SMF150may also, or instead, determine to initiate communications with the AMF130(e.g., to provide message transfer data for a PDU session). The SMF150may transmit an AMF address request320to the NRF170crequesting an IP address for the AMF130. The NRF170cmay determine an address to provide to the SMF150based on the block list370. For example, the NRF170cmay determine an address from among multiple addresses available for the AMF130(e.g., using round-robin, random selection, etc.) and then compare the determined address to the block list370. If the determined address matches an entry in the block list37, the NRF170cmay determine another address and compare that one to the block list, and so forth, until an address is determined that does not match an entry in the block list370. In other examples, other techniques may be used to determine an unblocked address for use with the SMF150, all of which are contemplated as within the scope of the instant disclosure. The NRF170cmay respond with an AMF address message321providing the AMF130IP address233to the SMF150. The SMF150may then initiate communications with the AMF130using its addresses and the received AMF address. For example, the SMF150may initiate signaling343using the SMF150address251to communicate with the AMF130IP address233.

Illustrative Signal Flows

FIG.4illustrates an exemplary signal flow400of various messages that may be exchanged in one or more of the disclosed systems and techniques for performing repository function address blocking. Reference may be made in this description of the signal flow400to devices, entities, and interfaces illustrated inFIG.1and described in regard to that figure. However, the operations, signals, and signal flow illustrated inFIG.4and described herein may be implemented in any suitable system and/or with any one or more suitable devices and/or entities. Moreover, any of the operations, signals, and/or entities described in regard toFIG.4may be used separately and/or in conjunction with other operations, signals, and/or entities. All such embodiments are contemplated as within the scope of the instant disclosure.

An AMF410may be configured in a wireless communications network (in some examples, similar to AMFs130and132) and may be further configured with multiple addresses, including AMF address411and AMF address412. An NRF420may also be configured in the network (in some examples, similar to NRFs170a-cof NRF pool170and NRFs172a-cof NRF pool172) as well as an SMF430(in some examples, similar to SMF150) that may be configured with an SMF address431.

In various examples, the AMF410may transmit an SMF address request441to the NRF420requesting an address for an SMF. The request441may include any one or more of an identifier of a specific SMF, a specific service, a specific function, etc. Alternatively, the request441may be more general, requesting an SMF generally or a function to provide particular service (session setup or management), etc. In response to the request441, the NRF420may transmit the SMF address431to the AMF410in response442.

Using the address431included in the response442, the AMF may generate and transmit a device resource request443to the SMF430(e.g., to the address431of the SMF430using the AMF address412). The device resource request443may be a request to register a device (e.g. UE), create a context for the device, establish a PDU session, etc. In response to the request443, the SMF430may establish, or initiate the establishment of, the initial resources requested at operation444. For example, the SMF430may create the context required for a PDU session requested with the device resource request443. The SMF430may interact with one or more other functions and/or components to establish the initial resources. The SMF430may transmit a device resource response445to the AMF410reporting the success, failure, statue, acknowledgement, and/or any other information or data associated with the resource request443. For example, the device resource response445may be a context creation response indicating that the SMF430has or has not successfully created a context based on the device resource request443. Alternatively or additionally, the device resource response445may be an acknowledgement that the request443has been received.

At operation450, the SMF430may further establish, or initiate the establishment of, the other (e.g. the remaining) resources required to provide the resources requested by request443. For example, the SMF430may generate and/or request message transfer data such as PDU session information, associated tunnel information, QoS parameters, etc., that may be required to provide the resources requested by the device resource request443. The SMF430may interact with one or more other functions and/or components to further establish and/or generate such other resources.

The SMF430may request an address for the AMF410by transmitting AMF address request451tthe NRF420. The SMF430may use this address to provide information regarding the resources requested by the request443to the AMF410so that such information can be provided to and/or used by, for example, a gNodeB and/or a UE for using the requested resources. In response to the request451, the NRF420may transmit the AMF address411in response452to the SMF430.

The SMF430may attempt to transmit the message transfer data determined at operation450in message transfer message453addressed to AMF address411. However, the message453may not be successful for any of various reasons as described herein. The SMF430may detect at operation454that the message453was not successfully delivered. In response, the SMF430may generate and transmit a block request461to the NRF420requesting that the NRF420block the AMF address411from responses to requests from the SMF430for an address for the AMF410. The SMF430may also, in response to the detection at operation454that the message453was not successfully delivered, store an indication that address411is blocked and/or was requested to be blocked (e.g., with request461) and a timestamp or other indication to attempt to retry connecting to address411.

Based on the request461, at operation462the NRF420may add the AMF address411to a block list entry associated with the SMF430. The NRF420may also, or instead, transmit a blocking notification463to the AMF410notifying the AMF410that its address411has been blockade at the NRF420for requests from the SMF430. The AMF410may use this information to avoid initiating communications with the SMF430using the AMF address411.

FIG.5illustrates an exemplary signal flow500of various messages that may be exchanged in one or more of the disclosed systems and techniques for performing repository function address blocking. Reference may be made in this description of the signal flow500to devices, entities, and interfaces illustrated inFIG.1and described in regard to that figure. However, the operations, signals, and signal flow illustrated inFIG.5and described herein may be implemented in any suitable system and/or with any one or more suitable devices and/or entities. Moreover, any of the operations, signals, and/or entities described in regard toFIG.5may be used separately and/or in conjunction with other operations, signals, and/or entities. All such embodiments are contemplated as within the scope of the instant disclosure.

Signal flow500represents a single flow that may be subsequent to signal flow400illustrated inFIG.4. As described in regard toFIG.4, the SMF430may have requested that NRF420block AMF address411in response to requests for an address for AMF410received at NRF420from SMF430. Also as described above, the SMF430may have stored an indication that it has requested NRF420block address411. The SMF430may determine to test connectivity to the AMF address411after this blocking operations based on one or more criteria. For example, the SMF430may set a timer and/or associate a timestamp with an indication that it has requested an address be blocked. In response to the expiration of a time period associated with the blocked address indication, the SMF430may attempt to communicate with the blocked address to determine if the address remains blocked. In this way, the SMF430may determine when a blocked address returns to service and resume using that address.

The SMF430may transmit a test message471to the blocked AMF address411. The AMF410, using the address411, may respond to the test message471with test message response472. These test messages may take any suitable form and may be dedicated test messages or any other type of message that may allow a function to determine whether if can successfully communicate with another message.

At operation473, in response to receiving the test message response472from the AMF address411at the AMF410, the SMF430may determine that communicative connectivity with the AMF410using the address411has been restored and/or that the SMF430may otherwise successfully communicate with the AMF410using the AMF address411.

In response to the determination of operation473, the SMF430may transmit an unblock request474to the NRF420requesting that the NRF420remove the block list entry corresponding to the AMF address411for the SMF430. In response to this request, the NRF420may remove that entry from its block list at operation475. The NRF420may also, or instead, transmit an unblocking notification476to the AMF410notifying the AMF410that its address411is no longer unreachable for the SMF430. In response to the notification476, the AMF410may determine to initiate communications with the SMF430using its address411.

Illustrative Operations

FIG.6shows a flow diagram of an illustrative process600for repository function address blocking according to the disclosed embodiments. The process600is illustrated as a collection of blocks in a logical flow diagram, which represents a sequence of operations that can be implemented in software and executed in hardware. In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform functions and/or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described blocks can be omitted and/or combined in any order and/or in parallel to implement the processes. For discussion purposes, the process600may be described with reference to the wireless network environment100ofFIG.1, however other environments may also be used.

At operation602, an SMF may transmit a request for an AMF address to an NRF. For example, and as described in more detail herein, an SMF may have message transfer data (e.g., PDU session information) to provide to an AMF to forward to a gNodeB and/or a UE. In order to obtain an address for the AMF, the SMF may transmit a request with an AMF identifier to an NRF. An identifier for the AMF may have been determined by the SMF from earlier communications, such as, but not limited to, a context request and creation process.

At operation604, the SMF may receive a response from the NRF that includes an AMF address. The SMF may then use the received AMF address to attempt to transmit the message transfer data to the AMF. If, at operation608, the message transfer data was successfully transmitted to the AMF using the address received at operation604, the SMF may continue with normal operations at operation620.

If, at operation608, the SMF determines that the message transfer data was not successfully communicated to the AMF using the address received at operation604, the SF may determine that the address is an unreachable address. At operation610the SMF may transmit a request to the NRF from which the unreachable address was received requesting that the NRF block the unreachable address from being used for responses to requests from the SMF for an address for the AMF associated with the unreachable address. The SMF may also, at this operation, store the unreachable address and the NRF from which the unreachable address was received. The SMF may also start a timer and/or associate a timestamp with the data indicating the unreachable address and the NRF from which it was received.

At operation612, the SMF may determine that a time period for the unreachable address has expired, for example, based on the expiration of a timer associated with the stored unreachable address and/or based on a current time and a timestamp associated with the stored unreachable address. In response to determining that a time period associated with an unreachable address has expired, the SMF may further, at operation612, transmit a test message or otherwise test communications with the unreachable address.

At operation614, the SMF may determine whether the communications test of operation612was successful. If not (e.g., if the unreachable address remains unreachable), the SMF may reset the time and/or update the timestamp associated with the unreachable address at operation616and the process600may return to612upon expiration of the new test time period determined based on the updated timer or timestamp.

If, at operation614, the SMF determines that the unreachable address has become reachable again (e.g., the SMF is currently able to successfully communicate with the destination function using the previously unreachable address), at operation618the SMF may transmit a request to the NRF associated with the previously unreachable address requesting that the NRF unblock or remove from its block list for the SMF the previously unreachable address. The SMF may also remove its own indication of the unreachable address and the NRF that originally provided the address when it was unreachable. At operation620, the SMF may resume normal operations.

FIG.7shows a flow diagram of an illustrative process700for repository function address blocking according to the disclosed embodiments. The process700is illustrated as a collection of blocks in a logical flow diagram, which represents a sequence of operations that can be implemented in software and executed in hardware. In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform functions and/or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described blocks can be omitted and/or combined in any order and/or in parallel to implement the processes. For discussion purposes, the process700may be described with reference to the wireless network environment100ofFIG.1, however other environments may also be used.

At operation702, an NRF may receive a request for an address from a function, for example, a request for an AMF address from an SMF. The request may include an AMF identifier or indicator and/or a service or function identifier or indicator. Alternatively, such a request may include any data that may allow an NRF to determine an appropriate function for which to provide an address to a requesting function or component. The NRF may determine the address at operation704. Various techniques of determining an address for an AMF or other function may be used, such as round-robin or random selection from multiple available addresses. In some examples, an NRF may have or determine data associated with workloads that may be associated with addresses and/or the function associated with such addresses and may select an address based on balancing workloads across such addresses and/or functions. Other means of selecting an address are contemplated as within the scope of this disclosure.

At operation706, the NRF may determine is the determined address is on a block list associated with the requesting function. For example, the NRF may determine is the selected AMF address is blocked for the requesting SMF as described herein. If so, the NRF may determine another, different address for the AMF at operation708. Note that in some embodiments, the NRF may evaluate the block list initially before selecting the address and remove ineligible addresses from a pool of candidate addresses prior to determining an address from the remaining candidate addresses.

It the determined address is not associated with a block list entry that is also associated with the function requesting the address, at operation710the NRF may transmit the determined address to the requesting function. For example, the NRF may transmit a determined AMF address to an SMF that requested an AMF address.

At operation712, the NRF may receive a request from the requesting function to block the address that was provided at operation710. For example, an SMF that requested an AMF address may have determined that the address provided by the NRF was not reachable by the SMF and may therefore have transmitted a request to the NRF that the provided address be blocked from being provided to that SMF.

In response to the request received at operation712, the NRF may add the address indicated in the request to a block list associated with the sender of the request. For example, the NRF may create an entry in a block list that indicates an AMF address and an SMF that requested blocking of that address. Alternatively or additionally, the NRF may maintain a distinct list for individual functions for which it may maintain blocking information and add an entry to such a list when a particular address is to be blocked for the associated function. Further at operation714, the NRF may transmit an indication to the function associated with the blocked address that the address is being blocked for a particular function. This may allow the function associated with the blocked address to avoid using that address in attempts to communicate with the particular function that requested the blocking.

At operation716, the NRF may determine if a request to remove the block list entry or otherwise unblock the address has been received. If not, the process may return to operation702to process further requests for function addresses.

If a request to unblock an address is received at operation716, at operation718, the NRF may remove the entry from its block list. The NRF may also, or instead, transmit an indication to the function associated with the blocked address that the address is no longer being blocked for a particular function. This may allow the function associated with the blocked address to begin using that address again for communication with the particular function that previously requested the blocking. The NRF may then resume processing requests for function addresses at operation702.

In summary, by more efficiently selecting function addresses and selectively avoiding those addresses that are unusable for particular functions, the disclosed systems and techniques may be able to increase the efficiency of usage of core network resources and other wireless network resources and improve the performance of both the network and user devices.

Example User Equipment

FIG.8is an example of a UE, such as UE110, for use with the systems and methods disclosed herein, in accordance with some examples of the present disclosure. The UE110may include one or more processors802, one or more transmit/receive antennas (e.g., transceivers or transceiver antennas)804, and a data storage806. The data storage806may include a computer readable media808in the form of memory and/or cache. This computer-readable media may include a non-transitory computer-readable media. The processor(s)802may be configured to execute instructions, which can be stored in the computer readable media808and/or in other computer readable media accessible to the processor(s)802. In some configurations, the processor(s)802is a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), or both CPU and GPU, or any other sort of processing unit. The transceiver antenna(s)804can exchange signals with a base station, such as gNodeB120.

The UE110may be configured with a memory810. The memory810may be implemented within, or separate from, the data storage806and/or the computer readable media808. The memory810may include any available physical media accessible by a computing device to implement the instructions stored thereon. For example, the memory810may include, but is not limited to, RAM, ROM, EEPROM, a SIM card, flash memory or other memory technology, CD-ROM, DVD or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which may be used to store the desired information and which may be accessed by the UE110.

The memory810can store several modules, such as instructions, data stores, and so forth that are configured to execute on the processor(s)802. In configurations, the memory810may also store one or more applications814configured to receive and/or provide voice, data and messages (e.g., SMS messages, Multi-Media Message Service (MMS) messages, Instant Messaging (IM) messages, Enhanced Message Service (EMS) messages, etc.) to and/or from another device or component (e.g., the eNodeB120). The applications814may also include one or more operating systems and/or one or more third-party applications that provide additional functionality to the UE110. The memory may also, or instead, store bandwidth information, such as UE supported bands, bandwidth(s) and bandwidth parts, as well as communications session information such as UE specific carrier bandwidth(s).

Although not all illustrated inFIG.8, the UE110may also comprise various other components, e.g., a battery, a charging unit, one or more network interfaces816, an audio interface, a display818, a keypad or keyboard, and one or more input devices820, and one or more output devices822.

Example Computing Device

FIG.9is an example of a computing device900for use with the systems and methods disclosed herein, in accordance with some examples of the present disclosure. The computing device900can be used to implement various components of a core network, a base station (e.g., gNodeB120), and/or any servers, routers, gateways, gateway elements, administrative components, etc. that can be used by a communication provider. One or more computing devices900can be used to implement the network101, for example. One or more computing devices900can also be used to implement base stations and other components.

In various embodiments, the computing device900can include one or more processing units902and system memory904. Depending on the exact configuration and type of computing device, the system memory904can be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. The system memory904can include an operating system906, one or more program modules908, program data910, and one or more digital certificates920. The system memory904may be secure storage or at least a portion of the system memory904can include secure storage. The secure storage can prevent unauthorized access to data stored in the secure storage. For example, data stored in the secure storage can be encrypted or accessed via a security key and/or password.

The computing device900can also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated inFIG.9by storage912.

The computing device900may store, in either or both of the system memory904and the storage912, block list information, such as blocked addresses, associated functions, timer information and/or timestamps, message transfer data, PDU session information, etc.

Non-transitory computer storage media of the computing device900can include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. The system memory904and storage912are examples of computer readable storage media. Non-transitory computer readable storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device900. Any such non-transitory computer readable storage media can be part of the computing device900.

In various embodiment, any or all of the system memory904and storage912can store programming instructions which, when executed, implement some or all of the functionality described above as being implemented by one or more systems configured in the environment100and/or components of the networks101and102.

The computing device900can also have one or more input devices914such as a keyboard, a mouse, a touch-sensitive display, voice input device, etc. The computing device900can also have one or more output devices916such as a display, speakers, a printer, etc. can also be included. The computing device900can also contain one or more communication connections918that allow the device to communicate with other computing devices using wired and/or wireless communications.

Example Clauses

The following paragraphs describe various examples. Any of the examples in this section may be used with any other of the examples in this section and/or any of the other examples or embodiments described herein.A: A method performed by a one or more computing devices configured in a wireless communications network, the method comprising: receiving, at a repository function from a session management function, a first request for a first address for an access management function; determining, at the repository function, the first address from among a plurality of addresses associated with the access management function; transmitting, from the repository function to the session management function, the first address; receiving, at the repository function from the session management function, a request to block the first address from responses to requests for addresses for the access management function; storing and associating, in a memory at the repository function, an indication of the first address and an indication of the session management function; receiving, at the repository function from the session management function, a second request for a second address for the access management function; determining, at the repository function, the second address from among the plurality of addresses associated with the access management function; determining, at the repository function, that the second address does not correspond to the indication of the first address; and transmitting, from the repository function to the session management function based at least in part on determining that the second address does not correspond to the indication of the first address, the second address.B: The method of paragraph A, further comprising: receiving, at the repository function from the session management function, a third request for a third address for the access management function; determining, at the repository function, the third address from among the plurality of addresses associated with the access management function; determining, at the repository function, that the third address corresponds to the indication of the first address; determining, at the repository function and based at least in part on determining that the third address corresponds to the indication of the first address, a fourth address from among the plurality of addresses associated with the access management function; determining, at the repository function, that the fourth address does not correspond to the indication of the first address; and transmitting the fourth address from the repository function to the session management function based at least in part on determining that the fourth address does not correspond to the indication of the first address.C: The method of paragraph A or B, further comprising transmitting, from the repository function to the access management function, the indication of the first address, the indication of the session management function, and an indication of the request to block the first address.D: The method of paragraph C, wherein the indication of the request to block the first address causes the access management function to block initiation of communications from the access management function to the session management function using the first address.E: The method of any of paragraphs A-D, The method of claim1, further comprising: receiving, at the repository function from the session management function, a request to unblock the first address; and removing, from the memory at the repository function, the indication of the first address and the indication of the session management function.F: The method of paragraph E, further comprising transmitting, from the repository function to the access management function, an indication of the request to unblock the first address.G: A network computing device configured at a wireless communications network, the network computing device comprising: one or more processors; one or more transceivers; and non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: transmitting a first request for a first address for an access management function to a repository function; receiving the first address from the repository function; determining that communications transmitted to the first address were not received by the access management function; based at least in part on determining that the communications transmitted to the first address were not received by the access management function, transmitting a request to block the first address from responses to requests for addresses for the access management function; storing and associating an indication of the first address, an indication of the repository function, and a timestamp; transmitting a second request for a second address for the access management function to the repository function; receiving the second address from the repository function, wherein the second address is distinct from the first address; and transmitting data to the access management function using the second address.H: The network computing device of paragraph G, wherein the operations further comprise: determining that a time period has expired based at least in part on the timestamp; and based at least in part on determining that the time period has expired, transmitting a communication to the first address.I: The network computing device of paragraph H, wherein the operations further comprise: receiving a response from the access management function using the first address; and based at least in part on receiving the response, transmitting a request to unblock the first address to the repository function.J: The network computing device of paragraph I, wherein the operations further comprise: determining that no response has been received from the access management function using the first address; and based at least in part on determining that no response has been received from the access management function using the first address, storing and associating an updated timestamp with the indication of the first address and the indication of the repository function.K: The network computing device of paragraph J, wherein the operations further comprise: storing and associating the time period with the timestamp, the indication of the first address, and the indication of the repository function; and based at least in part on determining that no response has been received from the access management function using the first address, storing and associating an updated time period with the updated timestamp, the indication of the first address, and the indication of the repository function.L: The network computing device of paragraph K, wherein the updated time period is greater than the time period.M: The network computing device of any of paragraphs G-L, wherein the first address is an incomplete address, an improperly formatted address, or an empty address.N: The network computing device of any of paragraphs G-M, wherein the data comprises 5G message transfer data.O: A non-transitory computer-readable media storing computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: transmitting a first request for an address for an access management function to a repository function; receiving the address from the repository function; determining that communications transmitted to the address were not received by the access management function; based at least in part on determining that the communications transmitted to the address were not received by the access management function, transmitting, to the repository function, a request to block the address from responses to requests for addresses for the access management function; storing and associating an indication of the address, an indication of the repository function, a time period, and a timestamp; determining, based at least in part on the timestamp, that the time period has expired; and based at least in part on determining that the time period has expired: transmitting a request to unblock the address to the repository function; and deleting the indication of the address, the indication of the repository function, the time period, and the timestamp.P: The non-transitory computer-readable media of paragraph O, wherein: the operations based at least in part on determining that the time period has expired further comprise determining that second communications transmitted to the address were successfully received by the access management function; and transmitting the request to unblock the address is further based at least in part on determining that the second communications transmitted to the address were successfully received by the access management function.Q: The non-transitory computer-readable media of any of paragraphs O or P, wherein transmitting the request to block the address to the repository function causes the repository function to transmit an indication of the request to block the address to the access management function to block initiation of second communications from the access management function using the address.R: The non-transitory computer-readable media of any of paragraphs O-Q, wherein transmitting the request to unblock the address to the repository function causes the repository function to transmit an indication of the request to unblock the address to the access management function to allow initiation of second communications from the access management function using the address.S: The non-transitory computer-readable media of any of paragraphs O-R, wherein the operations further comprise transmitting 5G message transfer data to the access management function.T: The non-transitory computer-readable media of any of paragraphs O-S, wherein the operations further comprise transmitting 5G context creations data to the access management function.

While the example clauses described above are described with respect to one particular implementation, it should be understood that, in the context of this document, the content of the example clauses can also be implemented via a method, device, system, computer-readable medium, and/or another implementation. Additionally, any of the examples A-T can be implemented alone or in combination with any other one or more of the examples A-T.

CONCLUSION

Depending on the embodiment, certain operations, acts, events, or functions of any of the algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the algorithm). Moreover, in certain embodiments, acts or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially.

The various illustrative logical blocks, components, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.

The various illustrative logical blocks, modules, and components described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The elements of a method, process, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of computer-readable storage medium known in the art. An exemplary storage medium can be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor and the storage medium can reside as discrete components in a user terminal.

Conditional language used herein, such as, among others, “can,” “might,” “may,” “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements, and/or states. Thus, such conditional language is not generally intended to imply that features, elements, and/or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or states are included or are to be performed in any particular embodiment. The terms “comprising,” “including,” “having,” “involving,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list.

Unless otherwise explicitly stated, articles such as “a” or “the” should generally be interpreted to include one or more described items. Accordingly, phrases such as “a device configured to” are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, “a processor configured to carry out recitations A, B and C” can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C.

While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the spirit of the disclosure. As will be recognized, certain embodiments of the inventions described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others. The scope of certain inventions disclosed herein is indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as illustrative forms of implementing the claims.