My Oracle Support Banner

Clarification Over GPRS Subsession Functionality (Doc ID 1057002.1)

Last updated on MARCH 05, 2019

Applies to:

Oracle Communications Billing and Revenue Management - Version and later
Information in this document applies to any platform.


This note has clarification over GPRS subsession functionality.

Questions and Answers

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!

In this Document
Questions and Answers
 Looking at the documentation, it is not immediately clear how one should configure BRM, so that GPRS sessions are stored into /active_session/telco/gprs/master and /active_session/telco/gprs/subsession objects.
Changing SubsessionMode to `3' in pin_telco_gprs_aaa_params.xml does not seem to influence BRM behaviour.
 How 'SubsessionMode' settings differ between each other? In other words how do they influence BRM behavior?
 Documentation states that:
By default, Portal stores information about master sessions in /active_session/telco/gprs objects.
However, if need to differentiate master and subsession types, one can configure Portal to store master sessions in /active_session/telco/gprs/master objects.
 Documentation states that:
The external network connects a GPRS service by opening a PDP context. The network then begins collecting information about any usage and sends it to Portal, which tracks the data in a master session object. If the customer accesses a second service during the same connection or if there is a network trigger like a quality of service (QoS) change,Portal creates a subsession object to store information about the second service usage.
This leaves under impression that the BRM should detect rating condition change, and start subsession.
 Documentation states that:
At the end of the connection, Portal either aggregates the data from the master and subsession objects into one session object or stores the data for each master and subsession object separately. Use subsession rating modes to specify how Portal manages subsession data.
There seems to be no way to aggregate data from separate master and subsession objects into one event object.
 Documentation states that:
Master and subsessions are treated as separate AAA sessions and are rated separately. The master and subsession objects are created on receipt of the authorization request. The master and subsession objects are rated, and the event is recorded when the final stop accounting request is received.
There seems to be no connection between master- and sub-sessions, so it seems impossible to close and rate all sub-sessions on a single final stop_request.

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.