6 Understanding the Service Broker NG-IN Solution for Presence and Subscriber Status Applications

This chapter describes the principles of the Oracle Communications Service Broker NG-IN solution for Presence and Subscriber Status eXtensions applications.

Introduction

The Service Broker NG-IN solution enables a SIP application to access SS7 network entities that communicate using the MAP protocol. The solution currently supports interaction with HLRs and VLRs.

With the Service Broker NG-IN solution for PSX applications, your SIP application can access a mobile network to perform the following actions:

• Obtain a mobile subscriber's state, location, and service subscription information from an HLR

• Modify mobile subscriber's subscription information in an HLR and VLR

Solution Architecture

The Service Broker NG-IN solution for PSX applications consists of the following components:

• One or more SIP applications

• Service Broker

• MAP network entity

Figure 6-1 shows a SIP application that interacts with an HLR or VLR in a legacy mobile network.

Figure 6-1 Architecture for Interacting with MAP Network Entities

The application-facing side of Service Broker provides a SIP application with a standard SIP interface. The interface is based on the SIP SUBSCRIBE and SIP NOTIFY messages. Implementing the interaction between a SIP application and a network entity does not require any network-specific customization.

SIP SUBSCRIBE and SIP NOTIFY Interface

A SIP application interacts with Service Broker through a standard SIP interface using the subscribe and notify mechanism. Figure 6-2 shows a typical call flow in the solution:

1. The SIP application subscribes to Service Broker for a specific type of operation, such as obtaining the subscriber's status. The application performs the subscription by sending a SIP SUBSCRIBE message to Service Broker.

2. The SIP SUBSCRIBE message triggers Service Broker to perform an appropriate operation on the SS7 network entity.

3. After Service Broker received a response from the entity, Service Broker sends the application either a SIP NOTIFY message or a failure response. In both cases, Service Broker terminates the subscription by

   • Setting the Subscription-State header of the SIP NOTIFY message to "terminated"

   • Setting the "reason" token of the Subscription-State header of the SIP NOTIFY message to "timeout"

Figure 6-2 Basic Interrogation Call Flow

Exchanging Information Through the SIP Interface

Service Broker exchanges information with the SIP application through the common SIP interface using two different mechanisms:

• SIP headers

  To provide Service Broker with information required to trigger specific MAP operations, the SIP application uses SIP headers.

  Service Broker also supports several SIP header tokens. For example, Service Broker supports the requested-info token to allow the SIP application to specify which information it wishes to obtain.

• SIP message body

  Service Broker uses the SIP message body to exchange the following two types of information:

  • Accept XER or BER encoded MAP operation arguments that need to be sent towards SS7 entities. For example, Service Broker uses the SIP SUBSCRIBE message body to accept MAP ANY-TIME-SUBSCRIPTION-INTERROGATION argument, and further construct the argument before sending it towards the SS7 entity.

  • Pass XER or BER encoded MAP operation results to the SIP application.