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

sh cache ra arch
Note
Important terms

Here are some key terms used in the diagram.

Term Definition

Cache Client

A client of the Sh Cache RA is the software that asks the RA to provide one or more caches. Clients can be Rhino SBBs and/or Sentinel features.

Non-transparent Data

Non-transparent data as defined in the Diameter Sh protocol (such as IMS User State, MSISDN, or IMS Public Identity).

Transparent Data

User-specified data that is transmitted over Diameter Sh protocol.

Service Indication

A string used to identify a specific type of transparent data (such as MMTel-Services).

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.

Previous page Next page