The Sh Cache Resource Adaptor contains a Diameter Sh stack which it uses to send requests to the HSS, and a series of caches in which it stores the information received in response. For more information on how to configure the Sh Cache Resource Adaptor see Sh Cache RA configuration. The Sh interface is specified on 3GPP TS 129 328 and 3GPP TS 129 329. The current implementation follows the Release 11.18.
Basic components
Important terms
Here are some key terms used in the diagram.
|
Basic cache function
When a cache client requires a piece of information for a given subscriber, it must ask the RA to provide it with the appropriate cache instance for that type of information. The client then queries the cache directly. If the cache already contains the requested information, it can provide it immediately. If it does not have the information, the cache will request the information from the appropriate HSS. When the data is received from the HSS,the cache will automatically store the information and then provide it back to the original requesting client.
The precise behaviour of a given cache instance is determined by its cache configuration. This configuration determines how and when to use data within the cache and when to request information from the HSS.
Cache instances and types
The Sh Cache RA holds many cache instances. These caches are contained within the JVM heap. Instances are created on demand through an API. At creation each cache is provided with a configuration that defines its caching behaviour.
Each cache instance has a specific type corresponding to the type of data contained within the cache instance. These cache types fall into one of two categories:
-
non-transparent data caches correspond to the non-transparent data fields defined in the Sh protocol where there is a cache type built into the Sh Cache RA for each of the available fields. Each non-transparent cache contains a single value type — this is a Java type that is directly mapped to the Sh protocol description.
-
transparent data cache types are defined by the clients using the Sh Cache RA. Each transparent data cache corresponds to a particular service indication as defined by the client. The appropriate codec and Java type for the cache data must be provided by the client.
Each transparent cache stores the XML document (a DOM element) and is templated on the Java type for this element, as well as the current sequence number for that Document. So transparent data caches are “document caches”.
Transparent data caches require a codec to convert their data between an XML document and its associated Java type. There are many different frameworks available for use of XML within Java. We have chosen JAXB for our Sh Cache RA, and therefore we also chose JAXB for the MMTEL services codec; however, there is nothing to prevent the choice of DOM, Apache JDOM, or any other framework instead of JAXB.
Cache configuration
Clients provide a cache configuration when asking for a cache. Each cache configuration corresponds directly to a cache instance within the RA. The first call to the RA with a given configuration will result in a new cache being created with that configuration. Subsequent calls to the RA with the same configuration will retrieve the already existing instance for that configuration. Clients can ask the RA to provide a default configuration for each non-transparent cache type.
All cache configurations contain the following information:
-
the Diameter destination host and destination realm for the HSS that is to be used by the cache instance (different cache instances may interact with different HSSs)
-
the Cache Retention Strategy, which includes:
-
the basic caching strategy (see Caching strategy)
-
whether or not to subscribe to updates
-
size and time parameters for the basic strategy.
-
Transparent data cache configurations also include:
-
the Service Indication of the transparent data.
Management interface
The Sh Cache RA provides an interface for management operations. These can be divided into invalidation and counting operations.
Invalidation operations
These act on all Sh Cache RAs within the rhino cluster
-
drop all caches
-
drop all transparent data caches
-
drop all transparent data caches of a specific service indication
-
drop all caches of a specified Data Reference
-
invalidate all transparent data cache entries of a specified subscriber
-
invalidate all cache entries matching an access key
More information on the invalidation operations can be found in Cache invalidation.
Counting operations
These return cache and cache entry counts for the rhino node they were invoked on
-
count all caches on
-
count all transparent data caches
-
count all transparent data caches of a specified service indication
-
count all caches of a specified data reference
-
count all transparent data cache entries for a specified subscriber
-
count all cache entries matching an access key
Diameter and Diameter Sh use
The Sh Cache RA embeds the OpenCloud Diameter Stack, and the Sh Protocol API. None of the Sh protocol “efficiency” features are used by the RA. When a client asks the Sh Cache RA for some data, the RA will check the cache for the data; if the data is not present, the RA will perform a single Sh query to the HSS for the data. The Sh Cache RA will not ask the HSS for multiple items within the same Sh request.
Diameter Peer and peer configuration in the Sh Cache RA works in the same way as other OpenCloud Diameter RAs.
Therefore, an entity of the Sh Cache RA can connect to multiple discrete HSS.
Synchronous and asynchronous lookups
The Sh Cache RA supports both synchronous and asynchronous methods of retrieving and updating information in the HSS:
-
Synchronous methods simply block the caller until the information retrieval/update is complete. This means that if the request requires communication with the HSS, the client is forced to wait until the Sh transaction is complete before doing anything else.
-
Asynchronous methods are non-blocking for retrieving and updating information. They use SLEE events to alert the client when their transaction is complete.