Patent Description:
The described technology provides implementations of systems and methods for allocating computing resources. More specifically, the described technology provides implementations of systems and methods for allocating resources that are associated with a device being served by the communication systems.

A method for allocating a device-specific resource from one or more databases is provided. The method includes receiving an initial processing request from a device; generating a device-specific resource based on the device, responsive to the initial processing request; associating a pool identifier with the device and the device-specific resource; generating a coupling identifier based on the pool identifier and a resource identifier; and associating the coupling identifier with data, comprising the device specific resource, in a cached object from the one or more databases; transmitting the coupling identifier to the device, the device being a requesting entity; and subsequently: receiving, at an interface, the coupling identifier including the pool identifier and the resource identifier, as part of a processing request from the requesting entity, the processing request including a request for the device-specific resource, wherein the coupling identifier associates the requesting entity with the device-specific resource based on the resource identifier; extracting, at the interface, the pool identifier from the coupling identifier; identifying, by the interface, the processing service in which the device-specific resource associated with the resource identifier is cached, based on the pool identifier; and transmitting, from the interface to the identified processing service, at least a part of the processing request to process the cached requested device-specific resource.

This summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description.

A communication service, such as in a cellular communication network or a mobile communication network, is expected to interact with devices having any number of protocols. In some systems, the processing engine (e.g., a processing service) stores the data to be processed locally. A disadvantage of such systems is that if the processing engine crashes, data being accessed by that processing engine for many different users can be lost. Further, dynamic assignment of processing services for any address space or communication protocol can better utilize storage and processing power.

A communication system may use a cloud-native architecture, which decouples the data from the processing engine used to process the data, facilitating more dynamic use of system resources. Such decoupling also reduces the risk of massive data loss from a crash of a particular instance of processing service. In implementations, the interfaces of the cloud-native architecture are dynamically assigned to devices attempting to access a network. Linking a device with an interface, linking the interface with a processing service, and fetching data from a database to accomplish the needs of the processing service may benefit from a uniform system for identification that links data in the database and the requesting device.

<NUM> is a fifth-generation cellular data network standard with service areas of <NUM> networks composed of geographical cells. The <NUM> standard allows for greater bandwidth than prior network communication generations. To identify devices, <NUM> networks allocate globally unique temporary identifiers (GUTIs) relatively frequently, so using the GUTI infrastructure for interface identifiers may be less practical than basing IDs on other elements, such as static elements of device and network equipment or application-specific ones assigned and stored.

A cloud-native system may benefit from the dynamic assignment of temporary IDs that are associated with particular devices. By making the IDs temporary, the temporary IDs can be readily assigned, if necessary, for new devices. The system may make a uniform ID structure across all devices and platforms to avoid some of the most significant limitations of individual permanent IDs supplied by devices. Further, because of the independence of the interface services, processing services, and database storage relative to one another in a cloud-native environment, temporary IDs can also more efficiently utilize the resources provided.

Cloud-native systems provide advantages, but some systems make it difficult to know whether a processing service that recently processed a request for a particular device still has the data for that device cached. However, various implementations of the described technology increase the likelihood that the device's request is routed to a processing service that has cached the resources for that particular device. For this, consistent hashing can provide request distribution that is more likely to result in cache hits. A challenge for consistent hashing has been the disparity in interfaces between communication devices and interfaces between the communication server system and its peer communication server system in serving communication devices. This can be overcome by assigning each device and peer communication server a coupling ID with a similar format across interfaces. Coupling IDs may be identifiers for specific interfaces between entities and a cloud communication server that may be device-specific (e.g., specific to a user equipment unit or mobile device) and used to reference device-specific resources. The coupling IDs can associate the interfaces with device-specific resources in order to retrieve the device-specific resources from a database or from cache of a processing service when the entities make a device-related processing request. In an implementation, a coupling ID is a temporary ID that may change, perhaps based on requirements of the network of the cloud communication server. In this specification, any implementation contemplated for a temporary ID is also contemplated for a coupling ID which may or may not be temporary. Each temporary ID may have a pool ID, representing a pool within an address space of available resource IDs that are associated with the pool. If there are a sufficient number of pools, it increases the likelihood that any particular device assigned to a pool will be assigned to a processing service that, at least temporarily, has data from devices assigned to that pool. The pool ID may be usable to represent a pool of resource identifiers in an address space. The pool ID may be common across all interfaces and, correspondingly, across all resource IDs of the device, each associated with an interface.

The pools may be divisions of different address spaces, the address spaces perhaps representing different types of interfaces with different types of temporary identifiers, addressing elements, or interfaces. Each device may be assigned a pool identifier such that the device will only pull temporary resource identifiers from the relevant pool. The resource identifiers can be concatenated, encoded, or otherwise joined with the pool identifiers to make temporary identifiers. When a processing service is assigned to a task for a device, the task can be associated with the pool ID. The processing service may keep the data associated with the device in cache for a time after the first use. Then, when the same or another interface later makes a request to the system from another system (e.g., a user device or a server communication system), the interface may take the temporary identifier received in the incoming request, extract the pool ID, and use the pool ID to identify a processing service that has recently been associated with the pool. The pool ID may be used by hashing the pool ID and associating it in a table with processing services that still have cached data from a prior request. The processing service may use the coupling ID, temporary ID, and/or resource ID to determine whether device data is still locally cached. These cache hits may save considerable processing resources while reducing traffic and latency of operations.

Dividing resources into pools can allow the system to distribute resources more uniformly instead of static addressing that can tax frequently used static elements. Further, adding or removing processing services can be taxing in existing systems, causing issues with scaling out. The coupling or temporary IDs may allow for more dynamic scaling and load balancing. The consistency of the coupling or temporary IDs given a device for each interface by giving them common pool IDs allows for a more convenient allocating mechanism to allocate communication server system requests to processing services more likely to have cached resources associated with a particular device.

<FIG> illustrates an example system <NUM> for allocating resources for device requests. In <FIG>, a device <NUM> communicates with a communication server system <NUM> over a communication network <NUM>. The device <NUM> may be any communication device, for example, a cellular phone, laptop computer, tablet, or <NUM>-in-<NUM> hybrid. The device <NUM> transmits a processing request for an operation that involves data associated with the device <NUM> to the communication server system <NUM>. The processing request includes a coupling ID. The coupling ID associates the requesting entity with a device-specific resource in one or more of a cache of a processing service 140A, 140B or a database <NUM> of the communication server system <NUM>. While the requesting entity is illustrated as the device <NUM>, the requesting entity may be any entity for which retrieval of device-specific data may be useful. For example, the requesting entity may be a radio of the communications network <NUM>, a communication sub-service <NUM>, or a peer communication server system. In an implementation, the coupling ID is a temporary ID that temporarily identifies the device to the communication server system <NUM>. Implementations are contemplated where the coupling ID is not a temporary ID, but the terms coupling ID and temporary ID may be used interchangeably to reference analogous elements throughout this specification. The initial request from the device may use a permanent identifier (e.g., an IMSI) or a concealed version of a permanent identifier. Upon successful initial request, the Communication Server System <NUM> may allocate a temporary identifier to the device <NUM>. The device <NUM> may use the received temporary identifier for future requests to the communication server system <NUM>.

The temporary ID includes a pool ID and a resource ID. The pool ID represents a particular pool of resource IDs in an address space. An address space may be specific to a particular interface for which the temporary identifier is allocated. Each address space has a number of pools, and in an implementation, the number of pools is the same for each address space. The distribution into pools may improve load balancing and may improve the likelihood that any given device <NUM> making a request can target a processing service 140B that has data associated with the device <NUM> cached in the processing service 140B. The communication server system <NUM> may also attempt to balance the number of assigned resource IDs between the pools to better facilitate load management.

The communication server system <NUM> has a plurality of interfaces and a plurality of processing services 140A, 140B. The interfaces may be of different types and foster communications between the communication server system <NUM> and entities, such as a radio, the device <NUM>, peer communication server systems, and the communication sub-service <NUM>. For instance, there may be interfaces to the radio of a communication network <NUM> and/or the device <NUM> or interfaces to serving gateways. For each type of radio interface for a radio in communication network <NUM> and/or the device <NUM>, the communication server system <NUM> may have multiple micro-services to handle requests from radios. Any requests from the device <NUM> may be carried in messages from a radio and may be handled by any of the microservices handling requests from radios. The interfaces can also have a different set of micro-services to handle messages received from the serving gateway or other communication subsystem. The plurality of interfaces and the plurality of processing services can be assigned to any device <NUM> or communication server system <NUM> requests and may be agnostic to the particular device <NUM> and/or device type. An interface receives requests from a network function for device <NUM> and uses a temporary ID assigned to or for the device <NUM> to determine to which pool the device <NUM> has been assigned and to which resource ID within the pool the device interface has been assigned. The interface extracts or otherwise parses the pool ID from the temporary ID using an ID extractor, and a message router uses the pool ID to associate the device request with a processing service 140A, 140B that has recently performed operations on items associated with the same pool.

A messaging router may transmit from the interface to the identified processing service 140A, 140B at least a part of a processing request to process the cached requested resource, the processing request perhaps based at least in part on the hashed pool identifier. The message router may include an HTTP proxy to apply hashing and a router or distributor, depending on the system. For example, in an implementation, the message router hashes the pool ID and refers the request to a correspondingly hashed processing service 140A, 140B to increase the likelihood that the assigned processing service 140A, 140B has cached device data <NUM> associated with the device <NUM>. Requests can be made on behalf of the device <NUM>, whether by the device <NUM> itself or by elements of the communication server system <NUM>.

In the implementation illustrated in <FIG>, the device <NUM> has a pool ID that is associated with device-specific resources, herein referred to as device data <NUM>, contained in cache or local memory of a processing service 140B. In this implementation, as illustrated by the dashed line, the device data <NUM> has been copied in a prior operation from the database <NUM> and stored in the cache of the processing service 140B as cached device data <NUM>. The device data <NUM> and cached device data <NUM> may contain all relevant information or device state information for the particular user or device <NUM>. The processing request from the device <NUM> has been assigned to the processing service 140B that has the cached device data <NUM> associated with the device <NUM>. The operation can be considered a cache hit that makes a second retrieval operation for the same data from the database <NUM> unnecessary. While shown as a processing request from the device <NUM>, the processing request may come from any requesting entity, for instance, a gateway, a radio of the communications network <NUM>, a peer communication server system, or the communication sub-service <NUM>. Determining whether the cache of the processing service 140A, 140B has cached device data <NUM> may involve searching a cache of the processing service 140B for the cached requested resource using at least part of the temporary ID, for example, the resource ID. Because an interface of the communication server system <NUM> was able to identify the processing service 140B using a pool ID associated with the device <NUM>, the processing service 140B was chosen as opposed to processing service 140A to execute the device request. Processing service 140A does not have the cached device data <NUM>. If the interface had routed the device request to processing service 140A, the processing service 140A would have had to fetch the device data <NUM> from the database <NUM> to make a new cached device data <NUM> copy for the same device data <NUM>. It should be appreciated that it may be unlikely for the processing service 140A to be selected if the consistent hashing is used, so it is unlikely that the 140B would have the cached device data <NUM> if processing service 140A is selected.

The communication server system <NUM> may have multiple temporary IDs for each device <NUM> in different address spaces. One of these identifiers may be transmitted to the device <NUM> itself for the device <NUM> to make requests to the communication server system. Other IDs are from different address spaces, each ID in each address space referring to a specific resource in device state data of the device <NUM> stored in the device data <NUM>. In an example in the mobility management entity (MME) context, the device <NUM> may be allocated many different types of device identifiers. The mobility management entity may be an example implementation of the communication server system <NUM>. One identifier is a globally unique temporary identifier (GUTI). The GUTI is transmitted to the device <NUM>, and the device <NUM> would use the GUTI in requests. Another identifier is a tunnel endpoint ID (TEID). The TEID may be transmitted to the serving gateway and used when the MME requests that the serving gateway set up an IP address for the device <NUM>. If, later on, the serving gateway requests to modify related to the IP address of the device <NUM>, the serving gateway may provide the TEID back to the MME in the request to inform the MME which device <NUM> or device data <NUM> to modify.

In an implementation, a device <NUM> may need to go through a procedure to be initially assigned a temporary ID for future requests. The device <NUM> may make an initial request from the communication server system <NUM> using an interface service in communication with a processing service 140A, 140B. The communication server system <NUM> may responsively authenticate the device by an authentication method, for example, one or more of authenticating a permanent device ID (e.g., international mobile subscriber identity, international mobile station equipment identity, integrated circuit card identifier, etc.), looking up whether the device <NUM> has an active subscription, and a challenge to the device <NUM>. When the device is authenticated, a processing service 140A, 140B may assign a temporary ID including a pool ID and a resource ID. The assignment of the pool ID may be strategic, for example, assigning within the appropriate address space to a pool that has fewer assigned resource IDs to balance the load. The pool ID may be used for consistent hashing to better allocate requests to processing services 140A, 140B more likely to have relevant cached device data <NUM>. All resource IDs of a device that represent interfaces used on behalf of the device, whether the requests are from the device <NUM> or subsystems of the communication server system <NUM> (e.g., communication sub-service <NUM>), share a common pool ID. The communication sub-service <NUM> may in turn receive the requests from other communication systems and subsystems. Examples of interfaces may include, for example, a relationship between Access and Mobility Management Function (AMF) and Session Management Function (SMF) in <NUM> or an interface between a Mobility Management Entity (MME) and a serving gateway in <NUM>. Using the disclosed technology with other interfaces, including earlier generation interfaces (e.g., interfaces in <NUM> or <NUM>) and interfaces of network and/or communication technology yet to be developed, is contemplated.

The temporary ID is generated from the pool ID and the resource ID. After the temporary ID is generated by the processing service 140A, 140B, the temporary ID is transmitted to the device <NUM> or to other communication systems or subsystems with which the communication server system <NUM> interfaces, and the temporary ID is associated with the relevant device and its device data <NUM> in the database <NUM>. The device itself or other communication systems use the temporary ID in future requests concerning the communication server system <NUM>. A device may have multiple temporary identifiers, one for each interface the communication server system <NUM> supports (e.g., interfaces with device <NUM> and other communication systems). All the temporary identifiers share the same pool ID and may represent elements of device state information in device data <NUM>. Implementations in which non-numeric resources are elements of the requested network function may benefit from using static addressing between the temporary IDs and pool IDs.

In implementations, a communication sub-service <NUM> may need to access device data <NUM>. The communication sub-service <NUM> may be, for example, one or more of a gateway service and a radio service. The communication sub-service <NUM> may have specific resources and/or temporary identifiers specifically representing the device <NUM> and the interface between the communication sub-service <NUM> and the processing service 140A, 140B. These temporary IDs for the communication sub-service <NUM> may have the same pool IDs for the device <NUM> as the temporary IDs used for the interface between the device <NUM> and the processing service 104A, 104B. In an implementation, if there is an instance of processing service 140B with cached device data <NUM>, whether from the same type of interface or a different type of interface, the communication sub-service <NUM> may route the request to the same processing service 140B based on the pool ID being the same. In this implementation, the pool ID is the same for a particular device <NUM>, regardless of the interface, and the cached device data <NUM> may be sufficient to provide some or all interfaces with some or all resources necessary for requests. This may increase the likelihood of a cache hit that can reduce the computational expense and/or latency of the request. In an implementation, temporary IDs for the communication sub-service <NUM> and the temporary IDs for the device interfaces may be initially assigned with the same initial assignments. The resource IDs may change with time, and, correspondingly, so may the temporary IDs that derive from the resource IDs.

In implementations, the pool ID may persistently associate with and/or be valid for the device, for example, for one or more of a lifecycle of the device <NUM>, a subscription period of the device <NUM>, or for all interactions between the device <NUM> and the communication server system <NUM> over a predefined period. In implementations, resource IDs may be stored in the state information in the database <NUM> that is associated with the device <NUM>. The temporary identifier may be used to find the state information of the device <NUM> from the database <NUM>. In implementations, the temporary ID may only persist or be valid, for example, for a device <NUM> session, for a specific request from the device <NUM>, for a period over which the device remains in a particular coverage area, for a predefined amount of time, or for a specific operation that requires multiple requests. In implementations, the resource ID and, hence, the temporary ID may be valid for less time than the pool ID. The period over which the temporary ID is valid may vary with the interface and with the type of device.

In implementations, the temporary ID may be an unencoded ID with no manipulation of the pool ID and resource ID. In other implementations, the temporary ID may be encoded, cyphered, or otherwise manipulated to mask the represented pool ID and resource ID. The encoded implementation may be advantageous in situations where there is a danger of discovering the temporary ID. An example of this is when there are a large number of pools, each with only a few resource IDs. This scenario would make it more likely that a particular pool ID will have a predictable resource ID from a very limited supply and make an unencoded ID easier to interpret and misuse. In implementations where the coupling ID is not a temporary ID, the coupling ID may be more persistent, perhaps as persistent as a pool ID.

Service-based interfaces (SBIs) or other interfaces used between the Communication server system <NUM> and other communication systems may use permanent identifiers. In implementations that use SBIs for communication, the communication server system <NUM> may provide an identification package that includes a pool ID assigned to a device <NUM> that identifies the device <NUM> to another communication server system or subsystem when requesting its service. The other communication server system or subsystem may responsively return the identification package that includes the pool ID when requesting service from this communication server system <NUM>. The pool ID in the identification package may be used for consistent hashing for the SBI request. At the same time, the other communication server system or subsystem can also provide its own identifying package for the device <NUM> to the communication server system <NUM>, which would return the identifying package in a future request to the other communication server system or subsystem.

In implementations where the message router of the interface routes the request to a processing service 140A, 140B using hashing, the hashing can be accomplished different ways. For instance, for HTTP connections, the hashing can use extended HTTP headers, cookies, or other properties. In implementations using hash-based load balancing to provide soft session affinity based on HTTP headers, the affinity to a particular destination processing service 140A, 140B may be lost when one or more processing services 140A and/or 140B are added or removed from the destination service. Examples of hashing for HTTP connections include data such as a string type hash based on a specific HTTP header, an HTTPCookie type hash based on an HTTP cookie, a Boolean type hash based on the source IP address, a string type hash based on a specific HTTP query parameter, and a uint64 type hash with virtual nodes to use for the hash ring. In the last example, the minimum number of virtual nodes to use may default to <NUM>. Larger ring sizes result in more granular load distributions. If the number of processing services 140A, 140B in the load balancing pool is larger than the ring size, each processing service 140A, 140B may be assigned a single virtual node. In implementations where a temporary identification package is used, for example, for SBIs, other hashing data that may be used may include one or more of a string type with a name of the identification package, a string type for a path to set for the temporary identification package, and duration type representing the lifetime of the identification package.

The communication server system <NUM> may also have data elements that store data associated with the processing services 140A, 140B, and the hashed pool IDs associated with data stored in the processing services 140A, 140B. This data may be persistent for as long as the related data is cached in the processing service 140A, 140B. While the cached device data <NUM> is cached in the processing service 140A, 140B, the database <NUM> may lock editing of the corresponding device data <NUM> in the database until the cached device data <NUM> is released. This data may be stored in the device data <NUM>, in the database <NUM>, or elsewhere.

<FIG> illustrates another example system <NUM> for allocating resources for device requests. The Communication server system <NUM> has an ID manager <NUM> that contains ID information. The ID manager <NUM> may be organized into address spaces <NUM>, <NUM>. The address spaces <NUM>, <NUM> may be distinguished from one another based on, for example, one or more types of devices and/or interfaces. For example, an address space might be defined as all devices that have a <NUM>-bit space for addressing. In an implementation, each address space may be organized into the same number of pools. In the illustrated implementation, both address spaces <NUM>, <NUM> are divided into N pools 262A-262N and 272A-272N. The ellipses in <FIG> illustrate intermediate pools between <NUM>-B and <NUM>-N and between 272B and 272N. While there is the same number of pools in the illustrated embodiments, it can be appreciated that the pools 262A through 262N each have fewer resource IDs than the pools 272A through 272N. However, in the illustrated embodiment, each pool within an address space <NUM>, <NUM> has the same number of resource IDs, for example, three resource IDs for each of the pools 262A, 262B, 262N, and any intermediate pools not shown and four resource IDs for each of 272A, 272B, 272N, and any intermediate pools not shown. The number of resource IDs in each pool may be based on limitations of devices classified within an address space <NUM>, <NUM>, for example, based on limiting addressing bits in the devices. At any given time, resource IDs used or occupied may be different within each pool. When a resource ID is being used, it may be prevented from being assigned to another device resource or request. The communication server system <NUM> may attempt to load balance by utilizing close to the same number of resource IDs within each pool at any given time. Implementations are also contemplated where resource IDs are allocated disproportionately between pools. The communication server system <NUM> may be an implementation of communication server system <NUM>.

<FIG> illustrates an example system <NUM> for assigning and using a temporary ID. The device <NUM> communicates an initial processing request for communication services from the communication server system <NUM> in communication <NUM>. While device <NUM> is illustrated as the requesting entity, other requesting entities are contemplated (e.g., communication sub-services, peer communication service servers, or radios of communications networks). The interface service <NUM> receives the request from the device <NUM>. As illustrated, the interface service <NUM> may be one of a plurality of interface services in the communication server system <NUM>. The interface service <NUM> determines that the device interface has not yet been assigned a temporary identifier. The request for an identifier is transmitted to a processing service 340B in communication <NUM>. The processing service 340B authenticates the device <NUM> by an authentication method, for example, one or more of authenticating a permanent device ID (e.g., international mobile subscriber identity, international mobile station equipment identity, integrated circuit card identifier, etc.), looking up whether the device <NUM> has an active subscription, and a challenge to the device <NUM>.

When the device <NUM> is authenticated, the processing service 340B will assign a pool ID and a resource ID, perhaps from an ID manager in database <NUM>, and will form a temporary ID from the assigned pool ID and resource ID. The pool ID may be assigned to the device <NUM>, and the resource ID may be assigned to a data resource (e.g., device data <NUM>) associated with the device <NUM>. In an implementation, the temporary ID is formed by encoding data including the assigned pool ID and resource ID. The processing service 340B will further create the device data <NUM> as an object in the database <NUM>, the device data <NUM> including data associated with the device <NUM>. The processing service 340B may create a temporary ID of a different type corresponding to each of the interfaces the communication server system <NUM> uses to obtain services on behalf of the device <NUM>, but all have a common pool ID for the devices assigned to that pool.

When the temporary ID has been generated, it is transmitted to the interface service <NUM> in communication <NUM> and then to the device <NUM> in communication <NUM>. The processing service may also store a database <NUM> entry that associates the cached device data <NUM> including the temporary identifiers assigned to or for the device <NUM>. The communication server system <NUM> may also prevent the resource ID from being used for another request while assigned to the particular temporary ID. The temporary ID transmitted in communication <NUM> is stored in the device <NUM>. Then, the device <NUM> makes a subsequent request to the communication server system <NUM> that contains the temporary ID in communication <NUM>. The interface service <NUM> receives the communication with the temporary ID. The interface service <NUM> extracts the pool ID from the temporary ID with an ID extractor <NUM>. In implementations, because this is the first network request after the initial ID allocation and device data generation, it may be that no processing service 340A, 340B has cached device data <NUM>, even if it initially provides the IDs. Implementations are also contemplated in which the cached device data <NUM> remains from the first processing request. In the illustrated implementation, the message router <NUM> identifies processing service 340B to process the network request, as there is no processing service with associated cached device data <NUM>. The processing service 340B in communication <NUM> retrieves the device data <NUM> data object and caches the object locally as cached device data <NUM> to effectuate the network request.

In communication <NUM>, the device <NUM> makes a subsequent communication processing request. The interface service <NUM> receives the communication with the temporary ID. The interface service <NUM> extracts the pool ID from the temporary ID with an ID extractor <NUM>. In an implementation, the ID extractor <NUM> is a worker, which may be logic that implements the majority of the function of a micro-service. The pool ID having been extracted is then transmitted to the message router <NUM>. In an implementation, the message router <NUM> is an HTTP proxy. In this implementation, the ID extractor may extract the pool ID and use pool ID as an HTTP header for the HTTP proxy for consistent hashing. A message router <NUM> may transmit from the interface to the identified processing service at least a part of a processing request to process the cached requested resource, the processing request based at least in part on the hashed pool identifier. The message router <NUM> routes the request from communication <NUM> to the processing service 340B in communication <NUM> based on identifying the processing service 340B as being the most likely to have relevant cached data. The message router <NUM> may use hashing of the extracted pool ID for consistent hashing. The message router <NUM> may use the hashed pool ID to allocate the request to a processing service 340A, 340B. Because the processing service 340B in communication still has the cached device data <NUM>, processing service 340B will still have data associated with the pool ID that represents the device <NUM>. The message router <NUM> will then transmit the network function request to processing service 340B. Determining whether the cache of the processing service has cached device data may involve searching a cache of the processing service for the cached requested resource using at least part of the temporary ID, for example, the resource ID. Because the processing service 340B has cached device data <NUM>, the allocation of the network function request to the processing service 340B can be considered a cache hit. This means that the processing service 340B will not be required to fetch the device data <NUM> again to be cached as cached device data <NUM>. This will save compute resources and reduce latency in the network function.

While not illustrated, other entities, such as communication sub-services, peer communication service servers, or radios of communications networks, may also get device-specific associated temporary IDs for their interfaces in communication <NUM>. The communication sub-services may similarly retrieve the temporary IDs to interface with the processing services 340A, 340B. Because a temporary identifier will have a pool ID associated with the device <NUM>, a message router <NUM> may use the pool ID to identify a processing service 340B likely to have cached device data <NUM> and route requests from the communication sub-services to the processing service 340B.

The device <NUM>, communication server system <NUM>, database <NUM>, device data <NUM>, processing services 340A, 340B, and cached device data <NUM> may be implementations of device <NUM>, communication server system <NUM>, database <NUM>, device data <NUM>, processing services 140A, 140B, and cached device data <NUM>, respectively.

<FIG> illustrates example operations <NUM> of using a temporary ID for communication requests. A receiving operation <NUM> receives a processing request with an accompanying temporary identifier. The temporary identifier may be transmitted from a requesting entity. In implementations, the requesting entity may be a device or one of a communication sub-service, peer communication service server, or radio of a communication network, operating on behalf of the device and received by an interface of a communication server system. The temporary identifier may have been previously assigned to a communication request from the device, communication sub-service, or another process server system or subsystem on behalf of the device. The temporary identifier has a pool ID and a resource ID. In implementations, the processing request is for a device-specific resource from one or more databases of a communication service server or from a cache of a processing service. In an implementation, the temporary identifier associates the requesting entity with the device-specific resource.

An extraction operation <NUM> extracts a pool ID from a temporary ID. The extraction operation <NUM> may use an ID extractor to extract the pool ID from the temporary ID. The extraction operation <NUM> may be a simple excision from the existing data or may require decoding if the temporary ID is encoded. The pool ID extracted from the temporary ID may be used for consistent hashing.

An identifying operation <NUM> identifies a processing service in which a resource identified by a resource identifier may be cached based on a data association between the pool ID and the processing service. The interface may take the extracted pool ID and use the pool ID to identify a processing service that has recently processed a request on data that is associated with the same pool ID. The interface may use a message router to hash or otherwise relate the pool ID to a processing service that has or recently had cached data that is associated with the same pool ID. This may increase the likelihood that the processing service chosen has cached data relevant to the communication request. The hashing can be accomplished in different ways based on the type of interface. For example, for HTTP connections, the hashing can use extension HTTP headers to contain the identifying package. For other types of interfaces, different types of temporary identifiers can be used for consistent hashing. In implementations using hash-based load balancing to provide soft session affinity, the affinity to a particular destination processing service may be lost when one or more processing services are added or removed from the destination service. Therefore, consistent hashing may be used to reduce the loss of soft affinity. In implementations where a temporary identification package is used, for example, for SBIs, other hashing data that may be used may include one or more of a string type with a name of the identification package, a string type for a path to set for the temporary identification package, and duration type representing the lifetime of the identification package.

The identifying operation <NUM> may use data elements of the communication service database that associate the processing services and/or the hashed pool IDs associated with data stored in the processing services. For example, the communication server system may have a hasher executable by a server processor and operable to hash the pool identifier, and the identifying operation <NUM> has an identifier that is usable to identify the identified processing service using the hashed pool identifier. This data may be persistent for as long as the related data is cached in the processing service. While the cached device data is cached in the processing service, the database may lock editing of the corresponding device data in the database until the cached device data is released.

A transmitting operation <NUM> transmits the request from the interface to the identified processing service. The transmitting operation <NUM> may transmit from the interface to the identified processing service, at least a part of a processing request to process the cached requested resource, the processing request based at least in part on the hashed pool identifier. The identified processing service may have cached data from a prior network function request that is relevant to the present network function request such that the processing service does not need to retrieve further data from a database outside of local cache storage. Determining whether the cache of the processing service has cached device data may involve searching a cache of the processing service for the cached requested resource using at least part of the temporary ID, for example, the resource ID. Implementations are contemplated where some but not all of the resources are cached such that some of the resources may still need to be fetched from the database outside of local storage. If the processing service does not have the necessary data in its cache, the processing service may fetch the data from the database outside of local storage.

In an implementation, each of the operations of the example operations <NUM> shown in <FIG> is a distinct operation. In another implementation, although depicted as distinct operations in <FIG>, operations <NUM>-<NUM> may not be distinct operations. In other implementations, the example operations <NUM> shown in <FIG> may not have all of the above operations and/or may have other operations in addition to or instead of those listed above. The operations of the example operations <NUM> shown in <FIG> may be performed in another order. Subsets of the operations listed above as part of the example operations <NUM> shown in <FIG> may be used to form their own example operations. The operations of example operations <NUM> may be repeated in any combination and order any number of times, for instance, continuously or selectively looping to satisfy further communication requests from the device or other communication server system on behalf of the device.

<FIG> illustrates example operations <NUM> of assigning a temporary ID for communication requests. A receiving operation <NUM> receives an initial request for a network function. The receiving operation <NUM> receives the request from a device. The request is routed to an interface of a communication server system. The interface determines that the device and its interface have yet to be assigned a temporary ID. The interface selects a processing service to which to route the task of assigning temporary IDs.

A generating operation <NUM> selects a pool ID for the device and generates temporary IDs based on the pool ID and resource IDs. The pool ID is the same for all temporary IDs assigned to the device. The resource IDs correspond to the data to be accessed when processing the request from the device. The generating may include generating temporary IDs for each interface the communication server system may use to interact with other communication server systems on behalf of the device, all having the same pool ID but differing resource IDs. This may include assigning temporary IDs for communication sub-services. The processing service may receive the initial request and may retrieve data associated with the device from a database or create a new copy of the data for the device in the database. The processing service may responsively authenticate the device by an authentication method, for example, one or more of authenticating a permanent device ID (e.g., international mobile subscriber identity, international mobile station equipment identity, integrated circuit card identifier, etc.), looking up whether the device has an active subscription, and a challenge to the device. When the device is authenticated, a processing service may assign a temporary ID including a pool ID and a resource ID. The assignment of the pool ID may be strategic, for example, assigning within the appropriate address space to a pool that has fewer assigned resource IDs to balance the load. The pool ID may be used for consistent hashing to better distribute requests to processing services more likely to have relevant cached device data. After the temporary ID is generated by the processing service in the generating operation <NUM>, the temporary ID is transmitted to the device to be used in future device requests. Other temporary identifiers generated for the device may be transmitted in the message to other communication server systems such that it can be passed back when other communication server system requests service on behalf of the device. When the new temporary IDs are created, if the device has never been allocated IDs before, a device data object is generated in a database that is associated with the device. This object may contain information related to the device as well as other relevant location and usage data.

An associating operation <NUM> associates the temporary IDs with data in the database. The temporary IDs having been assembled from a pool ID and resource IDs have an association between the temporary ID and the interfaces and interface resource represented by the resource IDs. When a particular resource ID is used for an operation, the resource ID may not be used by another process, making the temporary ID unique for the network function or elements thereof. Data associations between temporary IDs and devices may be stored in the data object.

In implementations, after the temporary ID has been generated, the temporary ID is transmitted to the device or other communication server system for further requests.

In an implementation, each of the operations of the example operations <NUM> shown in <FIG> is a distinct operation. In another implementation, although depicted as distinct operations in <FIG>, operations <NUM>-<NUM> may not be distinct operations. In other implementations, the example operations <NUM> shown in <FIG> may not have all of the above operations and/or may have other operations in addition to or instead of those listed above. The operations of the example operations <NUM> shown in <FIG> may be performed in another order. Subsets of the operations listed above as part of the example operations <NUM> shown in <FIG> may be used to form their own example operations. The operations of example operations <NUM> may be repeated in any combination and order any number of times, for instance, continuously or selectively looping to further allocate temporary IDs.

<FIG> illustrates an example communication device <NUM> for implementing the features and operations of the described technology. The device <NUM>, the communication server system <NUM>, and/or the communication sub-service <NUM> may be embodiments of the communication device <NUM>. The communication device <NUM> may embody a remote-control device or a physical controlled device and is an example network-connected and/or network-capable device and may be a client device, such as a laptop, mobile device, desktop, tablet; a server/cloud device; an internet-of-things device; an electronic accessory; or another electronic device. The communication device <NUM> includes one or more processor(s) <NUM> and a memory <NUM>. The memory <NUM> generally includes both volatile memory (e.g., RAM) and nonvolatile memory (e.g., flash memory). An operating system <NUM> resides in the memory <NUM> and is executed by the processor(s) <NUM>. It should be understood that the communication device <NUM> may also be a computing device and/or may be a virtual machine of the communication device <NUM>.

In an example communication device <NUM>, as shown in <FIG>, one or more modules or segments, such as applications <NUM>, workers, HTTP proxies, interface services, interface micro-services, processing services, processing micro-services, data transmission protocols, ID extractors, ID managers, hashers, identifiers, generators, transmitters, receivers, encoders, receiver interfaces, extractors, processing service identifiers, transmitter interfaces, pool identifier associator, coupling identifier generators, device-specific resource generators, coupling identifier associators, coupling identifier transmitters, searchers and message routers are loaded into the operating system <NUM> on the memory <NUM> and/or storage <NUM> and executed by processor(s) <NUM>. The storage <NUM> may include one or more tangible storage media devices and may store device data, cached device data, databases, coupling IDs, device-specific resources, resource IDs, pool IDs, temporary IDs, address spaces, pools, ID sets, requests, HTTP headers, string type hashes based on specific HTTP headers, HTTPCookie type hashes based on cookies, Boolean or non-Boolean type hashes based on source IP addresses, string type hashes based on specific HTTP queries, uint64 type hashes with virtual nodes for use with a hashring, strings with names of identification packages, strings for paths set for temporary identification, duration type data representing the lifetime of an identification package, an identification package, a permanent ID, an IMSI, an IMEI, an ICCI, pool ID hashes, and data objects locally and globally unique identifiers, requests, responses, and other data and be local to the communication device <NUM> or may be remote and communicatively connected to the communication device <NUM>.

The communication device <NUM> includes a power supply <NUM>, which is powered by one or more batteries or other power sources and which provides power to other components of the communication device <NUM>. The power supply <NUM> may also be connected to an external power source that overrides or recharges the built-in batteries or other power sources.

The communication device <NUM> may include one or more communication transceivers <NUM>, which may be connected to one or more antenna(s) <NUM> to provide network connectivity (e.g., mobile phone network, Wi-Fi®, Bluetooth®) to one or more other servers and/or client devices (e.g., mobile devices, desktop computers, or laptop computers). The communication device <NUM> may further include a network adapter <NUM>, which is a type of communication device. The communication device <NUM> may use the adapter and any other types of communication devices for establishing connections over a wide-area network (WAN) or local-area network (LAN). It should be appreciated that the network connections shown are examples and that other communication devices and means for establishing a communications link between the communication device <NUM> and other devices may be used.

The communication device <NUM> may include one or more input devices <NUM> such that a user may enter commands and information (e.g., a keyboard or mouse). These and other input devices may be coupled to the server by one or more hardware or virtual interfaces <NUM>, such as a serial port interface, ethernet port, parallel port, or universal serial bus (USB). The communication device <NUM> may further include a display <NUM>, such as a touch screen display.

The communication device <NUM> may include a variety of tangible processor-readable storage media and intangible processor-readable communication signals. Tangible processor-readable storage can be embodied by any available media that can be accessed by the communication device <NUM> and includes both volatile and nonvolatile storage media, removable and non-removable storage media. Tangible processor-readable storage media excludes communications signals (e.g., signals per se) and includes volatile and nonvolatile, removable and non-removable storage media implemented in any method or technology for storage of information such as processor-readable instructions, data structures, program modules, or other data. Tangible processor-readable storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices, or any other tangible medium which can be used to store the desired information and which can be accessed by the communication device <NUM>. In contrast to tangible processor-readable storage media, intangible processor-readable communication signals may embody processor-readable instructions, data structures, program modules, or other data resident in a modulated data signal, such as a carrier wave or other signal transport mechanism. By way of example, and not limitation, intangible communication signals include signals traveling through wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media.

Various software components described herein are executable by one or more processors, which may include logic machines configured to execute hardware or firmware instructions. For example, the processors may be configured to execute instructions that are part of one or more applications, services, programs, routines, libraries, objects, components, data structures, or other logical constructs.

Aspects of processors and storage may be integrated together into one or more hardware logic components. Such hardware-logic components may include field-programmable gate arrays (FPGAs), program- and application-specific integrated circuits (PASIC/ASICs), program- and application-specific standard products (PSSP/ASSPs), system-on-a-chip (SOC), and complex programmable logic devices (CPLDs), for example.

The terms "module," "program," and "engine" may be used to describe an aspect of a remote-control device and/or a physically controlled device implemented to perform a particular function.

It will be appreciated that a "service," as used herein, is an application program executable across one or multiple user sessions. In some implementations, a service may run on one or more server computing devices.

The logical operations making up embodiments of the invention described herein may be referred to variously as operations, steps, objects, or modules. Furthermore, it should be understood that logical operations may be performed in any order, adding or omitting operations as desired, regardless of whether operations are labeled or identified as optional, unless explicitly claimed otherwise or a specific order is inherently necessitated by the claim language.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any inventions or of what may be claimed, but rather as descriptions of features specific to particular implementations of the particular described technology. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed to achieve desirable results.

An example method for allocating a device-specific resource from one or more databases is disclosed. The method includes receiving, at an interface, a coupling identifier including a pool identifier and a resource identifier, as part of a processing request from a requesting entity, the processing request including a request for the device-specific resource, wherein the coupling identifier associates the requesting entity with the device-specific resource based on the resource identifier, extracting, at the interface, the pool identifier from the coupling identifier, identifying, by the interface, the processing service in which the device-specific resource associated with the resource identifier is cached, based on the pool identifier, and transmitting, from the interface to the identified processing service, at least a part of the processing request to process the cached requested device-specific resource.

Another example method of any preceding method is provided, the method further including receiving an initial processing request from a device, generating the device-specific resource based on the device, responsive to the initial processing request, associating the pool identifier with the device and the device-specific resource, generating the coupling identifier based on the pool identifier and a resource identifier, and associating the coupling identifier with data in the cached object from the one or more databases.

Another example method of any preceding method is provided, the method further including transmitting the coupling identifier to the requesting entity.

Another example method of any preceding method is provided, wherein the pool identifier represents a pool of resource identifiers in an address space.

Another example method of any preceding method is provided wherein the address space is one of a plurality of address spaces and each of the plurality of address spaces has a same number of pools of resource identifiers.

Another example method of any preceding method is provided, the method further including searching a cache of the processing service for the cached requested resource using at least part of the coupling identifier.

Another example method of any preceding method is provided, the method further including hashing the pool identifier and identifying the identified processing service using the hashed pool identifier.

An example communication server system for allocating a device-specific resource from one or more databases is provided. The communication server system includes a processor and a memory, the processor configured to execute operations stored in the memory. The communication server system further includes a receiver interface operable to receive a coupling identifier including a pool identifier and a resource identifier, as part of a processing request from a requesting entity, the processing request including a request for the device-specific resource, wherein the coupling identifier associates the requesting entity with the device-specific resource based on the resource identifier, an extractor executable by the processor to extract, at the interface, the pool identifier from the coupling identifier, a processing service identifier executable by the processor to identify, by the interface, the processing service in which the device-specific resource associated with the resource identifier is cached, based on the pool identifier, and a transmitter interface operable to transmit, from the interface to the identified processing service, at least a part of the processing request to process the cached requested device-specific resource.

Another example communication server system of any preceding communication server system is provided, wherein the receiver is further operable to receive an initial processing request from the device, wherein the receiver interface is further operable to receive an initial processing request. The communication server system further includes a generator executable by the processor to generate the device-specific resource based on the device, responsive to the initial processing request, a pool identifier associator executable by the processor to associate the pool identifier with the device and the device-specific resource, a generator executable by the processor to generate the coupling identifier based on the pool identifier and a resource identifier, and a coupling identifier associator executable by the processor to associate the coupling identifier with data in the cached object from the one or more databases.

Another example communication server system of any preceding communication server system is provided, the communication server system further including a coupling identifier transmitter interface operable to transmit the coupling identifier to the requesting entity.

Another example communication server system of any preceding communication server system is provided, wherein the pool identifier is usable to represent a pool of resource identifiers in an address space.

Another example communication server system of any preceding communication server system is provided, wherein the address space is one of a plurality of address spaces and each of the plurality of address spaces has a same number of pools of resource identifiers.

Another example communication server system of any preceding communication server system is provided, the communication server system further including a searcher executable by the processor and operable to search a cache of the processing service for the cached requested resource using at least part of the coupling identifier.

Another example communication server system of any preceding communication server system is provided, wherein the processing service identifier further includes a hasher executable by the processor and operable to hash the pool identifier, wherein the identifier is usable to identify the identified processing service using the hashed pool identifier.

An example one or more tangible processor-readable storage media embodied with instructions for executing on one or more processors and circuits of a computing device a process for allocating resources from one or more databases is provided. The process includes receiving, at an interface, a coupling identifier including a pool identifier and a resource identifier, as part of a processing request from a requesting entity, the processing request including a request for the device-specific resource, extracting, at the interface, the pool identifier from the coupling identifier, identifying, by the interface, the processing service in which the device-specific resource associated with the resource identifier is cached, based on the pool identifier, and transmitting, from the interface to the identified processing service, at least a part of the processing request to process the cached requested device-specific resource.

One or more other example tangible processor-readable storage media of any preceding media is provided, the process further including receiving an initial processing request from a device, generating the device-specific resource based on the device, responsive to the initial processing request, associating the pool identifier with the device and the device-specific resource, generating the coupling identifier based on the pool identifier and a resource identifier, wherein the association of the requesting entity with the device-specific resource is based on the resource identifier, and associating the coupling identifier with data in the cached object from the one or more databases.

One or more other example tangible processor-readable storage media of any preceding media is provided, the process further including transmitting the coupling identifier to the requesting entity.

One or more other example tangible processor-readable storage media of any preceding media is provided, wherein the pool identifier represents a pool of resource identifiers in an address space.

One or more other example tangible processor-readable storage media of any preceding media is provided, wherein the address space is one of a plurality of address spaces and each of the plurality of address spaces has a same number of pools of resource identifiers.

One or more other example tangible processor-readable storage media of any preceding media is provided, the process further including searching a cache of the processing service for the cached requested resource using at least part of the coupling identifier.

Thus, particular implementations of the subject matter have been described. In certain implementations, multitasking and parallel processing may be advantageous.

Claim 1:
A method (<NUM>) for allocating a device-specific resource (<NUM>) from one or more databases (<NUM>), comprising:
receiving an initial processing request from a device;
generating a device-specific resource based on the device, responsive to the initial processing request;
associating a pool identifier with the device and the device-specific resource;
generating a coupling identifier based on the pool identifier and a resource identifier; and
associating the coupling identifier with data, comprising the device specific resource, in a cached object from the one or more databases;
transmitting the coupling identifier to the device, the device being a requesting entity; and
subsequently:
receiving (<NUM>), at an interface (<NUM>), the coupling identifier including the pool identifier (262A) and the resource identifier (262A-<NUM>), as part of a processing request from the requesting entity (<NUM>), the processing request including a request for the device-specific resource (<NUM>), wherein the coupling identifier associates the requesting entity (<NUM>) with the device-specific resource (<NUM>) based on the resource identifier (262A-<NUM>);
extracting (<NUM>), at the interface (<NUM>), the pool identifier (262A) from the coupling identifier;
identifying (<NUM>), by the interface (<NUM>), the processing service (140B) in which the device-specific resource (<NUM>) associated with the resource identifier (262A-<NUM>) is cached, based on the pool identifier (262A); and
transmitting (<NUM>), from the interface (<NUM>) to the identified processing service (140B), at least a part of the processing request to process the cached requested device-specific resource (<NUM>).