This document provides a high-level overview of the Metaswitch Sh Cache Microservice and how Rhino TAS based applications interface with the Sh Cache Microservice.

Sections in this guide

Notices

Copyright © 2014-2019 Metaswitch Networks. All rights reserved

This manual is issued on a controlled basis to a specific person on the understanding that no part of the Metaswitch Networks product code or documentation (including this manual) will be copied or distributed without prior agreement in writing from Metaswitch Networks.

Metaswitch Networks reserves the right to, without notice, modify or revise all or part of this document and/or change product features or specifications and shall not be responsible for any loss, cost, or damage, including consequential damage, caused by reliance on these materials.

Metaswitch and the Metaswitch logo are trademarks of Metaswitch Networks. Other brands and products referenced herein are the trademarks or registered trademarks of their respective holders.

Sh Cache Microservice Overview

Sh Cache Microservice

The Sh Cache Microservice is a network element that provides a caching layer in front of a Home Subscriber Server (HSS) for certain queries over Sh.

Goals

  • Centralise the cache location, so that it is accessible to any number of users

  • Provide Sh access to a wide range of clients, that may not support Diameter but can support HTTP

  • Simplify configuration for the client (no diameter peer/routing tables to configure)

  • Efficent and effective caching of Sh data without the need for sharding subscribers

  • Provide a container/VM image for easy integration into virtualized environments.

  • Centralise connectivity to the HSS so the HSS has a controlled number of Sh peers

Network elements interface with the microservice via an Sh/HTTP API. The microservice provides responses to queries by consulting its internal cache and/or talking to the HSS via Sh.

Sh Cache Microservice in context
Figure 1. Sh Cache Microservice in Context

The top level architecture of the Sh Cache Microservice is present in the following section.

Top Level Architecture

The major elements of the Sh Cache Microservice are shown in the following diagram.

Top level architecture
Figure 2. Top Level Architecture

The Sh Cache Service decodes the request to determine what operation is being performed. This is looked up in the Cassandra database. If not found, use the Diameter Sh RA and perform the appropriate operation against the HSS to find/update the information. When the HSS replies, update the DB accordingly.

Tip

Elements in green correspond to existing components and products in the Metaswitch portfolio.

  1. HTTP Resource Adaptor

  2. Diameter Resource Adaptors

  3. Cassandra CQL Resource Adaptor

  4. Rhino Element Manager

  5. MetaView Service Assurance Server (SAS)

Sh Cache Service

The Sh Cache Service is a Rhino TAS based application that receives and processes Diameter Sh/HTTP requests from external network elements.

Notification Service

The Notification Service processes Diameter Sh requests from the HSS.

Cache (Cassandra)

Apache Cassandra is a distributed, highly available, NoSQL database management system designed to handle large amounts of data across many commodity servers.

For more details see: Apache Cassandra.

Sh Cache Service Overview

Sh Cache Service

There are three main components of the Sh Cache Service.

Sh Cache Service
Figure 3. Sh Cache Service

  1. Decode HTTP Request — decode and validate Sh/HTTP requests.

  2. Cache Facade — provide an interface to the Cassandra database so the service can query and update the cache.

  3. HSS Facade — provide an interface for the service to query and update the external HSS.

The following sections outline the behaviour of the Sh Cache Service for two simple scenarios.

Cache Miss Scenario

Sh Cache Service cache miss
Figure 4. Cache miss scenario

  1. Decode and validate a Sh/HTTP request. The request is valid so …​

  2. Query the cache to see if a result can be returned immediately.

  3. In this case there is nothing in the cache so …​

  4. Send an Sh query to the external HSS

  5. The HSS processes the query and sends a response

  6. Receive the Sh response and …​

  7. Update the cache …​

  8. By updating the Cassandra database

  9. Send an HTTP response to the the original Sh/HTTP request

Cache Hit Scenario

Sh Cache Service cache hit
Figure 5. Cache hit scenario

  1. Decode and validate a Sh/HTTP request. The request is valid so …​

  2. Query the cache to see if a result can be returned immediately.

  3. In this case there is something in the cache so …​

  4. Send an HTTP response to the the original Sh/HTTP request

Push Notification Handling

Notification Service

There are three main components of the Notification Service.

Notification Service
Figure 6. Notification Service

  1. HTTP Notify — send notification requests to clients of the Sh Cache Microservice.

  2. Cache Facade — provide an interface to the Cassandra database so the service can query and update the cache.

  3. HSS Facade — provide an interface for the service to query and update the external HSS.

When receiving a Push Notification Request from the HSS, the Sh Cache Microservice has to determine which data reference the notification is for. As the Push Notification Request does not contain an AVP indicating the data reference, the service parses the user data to determine the data reference. The data reference is determined by using the first rule from the list below which applies.

Rules for determining the data reference

If the PNR does not contain any user data, the request is rejected by sending a PushNotificationAnswer with result code of DIAMETER_MISSING_AVP (5005).

Data Reference If the user data contains …​

REPOSITORY_DATA

a non-empty <RepositoryData> element

IMS_PUBLIC_IDENTITY

a non-empty <IMSPublicIdentity> element

IMS_PUBLIC_IDENTITY

an <AliasIdentities>, <AllIdentities>, <ImplicitIdentities> or <RegisteredIdentities> element

INITIAL_FILTER_CRITERIA

an <IFCs> element

S_CSCFNAME

an <SCSCFName> element

CHARGING_INFORMATION

a <ChargingInformation> element

PSIACTIVATION

a <PSIActivation> element

DSAI

a non-empty <DSAI> element

IP_ADDRESS_SECURE_BINDING_INFORMATION

a non-empty <IPv4Address>, <IPv6Prefix> or <IPv6InterfaceIdentifier> element

UE_REACHABILITY_FOR_IP

a <UEReachabilityForIP> element

SERVICE_PRIORITY_LEVEL

a <ServicePriorityLevel> element

SERVICE_LEVEL_TRACE_INFO

a <ServiceLevelTraceInfo> element

EXTENDED_PRIORITY

a non-empty <ExtendedPriority> element

If the user data does not contain any of these elements, the request is rejected by sending a PushNotificationAnswer with result code of DIAMETER_MISSING_AVP (5005).

The following section outlines the behaviour of the Sh Cache Service for the UE reachability scenario.

UE reachability scenario

UE reachability
Figure 7. UE reachability

  1. Receive a PushNotificationRequest (PNR) from the HSS. Determine the data reference is UE_REACHABILITY_FOR_IP

  2. Query the cache for subscriber data

  3. In this case there is data in the cache …​

  4. Send a PushNotificationAnswer (PNA) to the HSS

  5. Build an HTTP request …​

  6. …​ and notify the microservice client

Sh Cache Microservice RA Overview

Sh Cache Microservice RA

The Sh Cache Microservice RA allows Rhino TAS based applications (such as Sentinel) to use the Sh Cache Microservice. It implements an existing RA type (Sh Cache RA type) and delegates to the Sh Cache Microservice using the Sh/HTTP api.

The following diagram shows the Sh Cache RA in context. The Sh Cache RA has an in process cache per node and interacts directly with the HSS. The API Rhino TAS based applications use is encapsulated in the Sh Cache RA type.

Sh Cache RA in context
Figure 8. Sh Cache RA in context

The following diagram shows how the same solution would be realised with the Sh Cache Microservice. The Sh Cache Microservice RA also implements Sh Cache RA type, so Rhino TAS based applications require no change to make use of the Sh Cache Microservice. In this scenario there is now one central cache (the microservice) that can also be used by other Rhino TAS based applications and other network elements via the Diameter Sh/HTTP api.

Sh Cache Microservice in context
Figure 9. Sh Cache Microservice in context

Sh Cache Microservice RA Implementation

The following diagram presents the architecture of the Sh Cache Microservice RA in more detail.

Sh Cache Microservice RA
Figure 10. Sh Cache Microservice RA

The Sh Cache Microservice is implemented using the Metaswitch RA framework. This framework simplifies the development of resource adaptors by providing components to simplify common tasks such as RA configuration and changes during the RA lifecycle. The implementation uses two libraries to support the development of the Diameter Sh/HTTP API: Swagger and Vert.x