Portal Documentation · Service Integration Components · AAA Gateway Manager

AAA Gateway Manager protocol support

About this document

About AAA Gateway Manager protocol support
Flist protocol support files
Flist input grammar
Flist field blocks
Error handling
Flist input mapping
Flist stream format description
Flist output grammar
Error handling
Flist output mapping
Supported flist messages
Diameter protocol support files
Diameter input grammar
Diameter field blocks
Error handling
Diameter input mapping
Diameter stream format description
Diameter output grammar
Error handling
Diameter output mapping
Supported Diameter messages
MBI protocol support files
MBI input grammar
Error handling
MBI input mapping
MBI stream format description
MBI output grammar
MBI output mapping
Error handling
Supported MBI messages
MBI CDR protocol support files
MBI CDR input grammar
Error handling
MBI CDR input mapping
MBI CDR stream format description
Customizing AAA Gateway Manager protocol support
Configuring the gateway to support additional MBI data

About this document

This document describes the network message protocols supported by Portal™ AAA
Gateway Manager.
For background information, see the following topics:
• Using Portal AAA Gateway Manager
• AAA EDR container description
About AAA Gateway Manager protocol support
To convert messages from prepaid networks into a format that the pipeline-based AAA
Gateway Manager and Portal understand, the gateway’s InSocketManager passes the
messages to a parser. The parser uses protocol-specific input grammar and mapping files to
convert the messages into AAA EDR containers, the data structure understood by pipeline
function modules. The FCT_Opcode module then converts the data in the containers into an
input flist and passes it to the appropriate opcode. The opcode uses the data to perform its
normal Portal operations. After the opcode generates an output flist, the FCT_Opcode
module converts the flist into an AAA EDR container. The gateway’s OutSocketManager then
passes the container to a parser, which uses protocol-specific output grammar and mapping
files to convert the container into an appropriately formatted network response.
The following figure illustrates the AAA Gateway Manager protocol conversion process. Blue
files are used to convert incoming messages to AAA EDR containers. Yellow files are used to
convert AAA EDR containers to outgoing messages.

AAA Gateway Manager supports messages based on the following protocols:

• Flist protocol used by Portal opcodes
This protocol is supported by default. For information about the grammar and
mapping files for this protocol, see Flist protocol support files.
• Diameter protocol
To enable AAA Gateway Manager to support this protocol, you must install Diameter
Charging Manager (see Installing Diameter Charging Manager). For information
about the grammar and mapping files for this protocol, see Diameter protocol
support files.
• Tag/LengthOfValue/Value (TLV) format used by the HP OpenCall Message
Based Interface (MBI) protocol
To enable AAA Gateway Manager to support this protocol, you must install HP
OpenCall Manager (see Installing HP OpenCall Manager). For information about the
grammar and mapping files for this protocol, see MBI protocol support files.
• MBI CDR protocol
To enable AAA Gateway Manager to process MBI CDRs, you must install HP
OpenCall Manager (see Installing HP OpenCall Manager). For information about the
grammar and mapping files for this protocol, see MBI CDR protocol support files.

Flist protocol support files

To process flist-based messages, AAA Gateway Manager uses these files:
• Flist input grammar
• Flist input mapping
• Flist stream format description
• Flist output grammar
• Flist output mapping

Flist input grammar

The flist input grammar file (Pipeline_home/formatDesc/Formats/Flist/
Flist_v01_InGrammar.dsc) contains instructions for generating AAA EDR containers and
filling them with data from incoming flist-based messages. At startup, AAA Gateway
Manager uses this grammar to create a parser that implements the instructions.
By default, the flist input grammar supports these opcodes:
Note The names listed below are the new names of the opcodes. For the corresponding old
names of these opcodes, see Renamed opcodes in Portal 7.2
• PCM_OP_GSM_AAA_AUTHENTICATE
• PCM_OP_GSM_AAA_AUTHORIZE
• PCM_OP_GSM_AAA_UPDATE_ACCOUNTING
• PCM_OP_GSM_AAA_REAUTHORIZE
• PCM_OP_GSM_AAA_UPDATE_AND_REAUTHORIZE
• PCM_OP_GSM_AAA_CANCEL_AUTHORIZATION
• PCM_OP_GSM_AAA_START_ACCOUNTING
• PCM_OP_GSM_AAA_STOP_ACCOUNTING
• PCM_OP_GSM_AAA_ACCOUNTING_ON
• PCM_OP_GSM_AAA_ACCOUNTING_OFF

Flist field blocks

Each incoming flist-based message begins with a wire header. This header has a fixed
length and is mapped to a block in the input grammar named WIRE_HEADER. The grammar
is driven by the opcode number included in this header.
Because fields following the wire header in flist-based messages can be arranged in any
order, each field is defined as a separate block in the grammar.
Generally, flist blocks contain a field descriptor in the following format (the field descriptor is
defined in the Flist stream format description file):
FlistType("PIN_FLD_NAME");
Where
• Type is the data type of the flist field (see Flist stream format description).
• PIN_FLD_NAME is the name of the flist field.

Flist arrays and substructs

The headers for flist arrays and substructs contain two important values: index and size. To
retrieve both values, the parser must treat them as two fields. Thus, the grammar defines a
separate field for each value:
• The FlistIndex("PIN_FLD_ARRAY") field contains the index of an array.
• The FlistContainer("PIN_FLD_ARRAY/SUBSTRUCT_NAME") field contains the number
of fields in a substruct or the number of elements in an array.

Error handling

The grammar calls the edrAddError() function to report errors, such as the failure to
create a data block.
These errors are recorded in the AAA Gateway Manager stream log (Pipeline_home/log/
stream/InOutputlog_timestamp_transactionID.log). The block in which the error
occurred is specified in the log.

Flist input mapping

To transfer data from fields in incoming flist-based messages to the appropriate fields in
AAA EDR containers, the parser follows the mapping in the flist input mapping file
(Pipeline_home/formatDesc/Formats/Flist/Flist_v01_InMap.dsc).
Because flist field names are not unique, this file contains a mapping block for each context
in which the field name appears. For example, in one opcode’s input flist, PIN_FLD_POID
can be included in every level in every array. In addition, it can be included in the input
flists of multiple opcodes.

Flist stream format description

The flist stream format description file (Pipeline_home/formatDesc/Formats/Flist/
Flist_v01.dsc) specifies the data type of the fields in flist-based messages that are
supported by AAA Gateway Manager. For example, this entry specifies that the data type of
the PIN_FLD_POID field is FlistPoid:
PIN_FLD_POID FlistPoid("PIN_FLD_POID");
The input parser uses this file to identify the data type of fields in incoming network
messages. The output parser uses this file to format responses.
To process flist-based network messages, AAA Gateway Manager supports several flist data
types. For more information, see Flist data types.

Flist output grammar

The flist output grammar file (Pipeline_home/formatDesc/Formats/Flist/
Flist_v01_OutGrammar.dsc) contains instructions for generating outgoing flist-based
messages and filling them with data from AAA EDR containers. At startup, AAA Gateway
Manager uses this grammar to create a parser that implements the instructions.
The output grammar file contains a block for each AAA function; only the function blocks
associated with the opcode specified in the flist wire header are incorporated into the
parser. Each function block contains the following blocks:
• Mandatory fields — The edrOutputMapToBuffer() function transfers the data in
mandatory fields to a buffer. When Portal finishes processing a request, the
outputWrite() function transfers the data in all such function-block buffers into an
outgoing flist-based message.
• Optional fields — Before data in optional fields is transferred to a buffer, the
edrInternalState() function verifies that the fields are included in the output flists
of the opcodes that implemented the request or in the protocol-specific data in the
ASSOCIATED_PROTOCOL_INFO block.

Error handling

The logPipeline() function writes all errors to the pipeline log.

Flist output mapping

To transfer data from fields in AAA EDR containers to the appropriate fields in outgoing flist-
based messages, the parser follows the mapping in the flist output mapping file
(Pipeline_home/formatDesc/Formats/Flist/Flist_v01_OutMap.dsc).

Supported flist messages

By default, AAA Gateway Manager supports these flist-based AAA messages:
Note The names listed below are the new names of the opcodes. For the corresponding old
names of these opcodes, see Renamed opcodes in Portal 7.2
• PCM_OP_GSM_AAA_AUTHENTICATE — When a customer attempts to initiate a
prepaid GSM service, the prepaid network sends this message with the appropriate
input flist to AAA Gateway Manager to authenticate the customer. After Portal
executes this opcode, the gateway sends a response with the appropriate output
flist to the prepaid network.
• PCM_OP_GSM_AAA_AUTHORIZE — After a customer is successfully authenticated,
the prepaid network sends this message with the appropriate input flist to the
gateway to authorize the customer to use the GSM service. After Portal executes
this opcode, the gateway sends a response with the appropriate output flist to the
prepaid network.
• PCM_OP_GSM_AAA_UPDATE_ACCOUNTING — To update an accounting session for
a GSM service, the prepaid network sends this message with the appropriate input
flist to the gateway. After Portal executes this opcode, the gateway sends a
response with the appropriate output flist to the prepaid network.
• PCM_OP_GSM_AAA_REAUTHORIZE — When a previously authorized customer’s
session expires or is about to expire, the prepaid network sends this message with
the appropriate input flist to the gateway to extend the ongoing session. After Portal
executes this opcode, the gateway sends a response with the appropriate output
flist to the prepaid network.
• PCM_OP_GSM_AAA_UPDATE_AND_REAUTHORIZE — To simultaneously update and
reauthorize an accounting session for a GSM service, the prepaid network sends this
message with the appropriate input flist to the gateway. After Portal executes this
opcode, the gateway sends a response with the appropriate output flist to the
prepaid network.
• PCM_OP_GSM_AAA_CANCEL_AUTHORIZATION — When a customer hangs up or a
session is not completed, the prepaid network sends this message with the
appropriate input flist to the gateway to end the session and release reserved
resources. After Portal executes this opcode, the gateway sends a response with the
appropriate output flist to the prepaid network.
• PCM_OP_GSM_AAA_START_ACCOUNTING — To start an accounting session for a
GSM service, the prepaid network sends this message with the appropriate input
flist to the gateway. After Portal executes this opcode, the gateway sends a
response with the appropriate output flist to the prepaid network.
• PCM_OP_GSM_AAA_STOP_ACCOUNTING — To end an accounting session for a GSM
service, the prepaid network sends this message with the appropriate input flist to
the gateway. After Portal executes this opcode, the gateway sends a response with
the appropriate output flist to the prepaid network.
In addition to the AAA messages, the gateway also supports the following flist
administrative messages:
• PCM_OP_GSM_AAA_ACCOUNTING_ON — To close all open sessions when an
accounting session is started, the prepaid network sends this message with the
appropriate input flist to the gateway. After Portal executes this opcode, the
gateway sends a response with the appropriate output flist to the prepaid network.
• PCM_OP_GSM_AAA_ACCOUNTING_OFF — To end all active sessions when the
prepaid network is being shut down or a problem is encountered, the prepaid
network sends this message with the appropriate input flist to the gateway. After
Portal executes this opcode, the gateway sends a response with the appropriate
output flist to the prepaid network.
Diameter protocol support files
To process Diameter-based messages, AAA Gateway Manager uses these files:
• Diameter input grammar
• Diameter input mapping
• Diameter stream format description
• Diameter output grammar
• Diameter output mapping

Diameter input grammar

The Diameter input grammar file (Pipeline_home/formatDesc/Formats/Diameter/
Diameter_v01_InGrammar.dsc) contains instructions for generating AAA EDR containers
and filling them with data from incoming Diameter-based messages. At startup, AAA
Gateway Manager uses this grammar to create a parser that implements the instructions.
By default, the Diameter input grammar supports these opcodes:
Note The names listed below are the new names of the opcodes. For the corresponding old
names of these opcodes, see Renamed opcodes in Portal 7.2
• PCM_OP_GSM_AAA_AUTHENTICATE
• PCM_OP_GSM_AAA_AUTHORIZE
• PCM_OP_GSM_AAA_UPDATE_ACCOUNTING
• PCM_OP_GSM_AAA_REAUTHORIZE
• PCM_OP_GSM_AAA_UPDATE_AND_REAUTHORIZE
• PCM_OP_GSM_AAA_CANCEL_AUTHORIZATION
• PCM_OP_GSM_AAA_START_ACCOUNTING
• PCM_OP_GSM_AAA_STOP_ACCOUNTING

Diameter field blocks

Diameter messages consist of a message header followed by a list of attribute/value pairs

(AVPs). The AVPs can be listed in any order. Each header contains a command code to
identify the message type:
Diameter message type Command code

Authorization and authentication request (AA-Request) 265

Accounting request (AC-Request) 271

Credit control request (CC-Request) 272

Session termination request (ST-Request) 275

Note For more information about these message types, see Supported Diameter messages.
In the Diameter input grammar, the Diameter header is defined as a fixed block, and each
field that corresponds to an AVP is defined as a separate block. Each AVP block contains a
field descriptor in one of the following formats (the field descriptor is defined in the
Diameter stream format description file):
DiameterType1(AVP_Code, Flags, Vendor_ID)
DiameterType2(AVP_Code, Flags, Vendor_ID, Size)
DiameterType3(AVP_Code, Flags, Vendor_ID, Zone)
Where
 • Type1 is data type String or Grouped.
• Type2 is data type Integer or Decimal.
• Type3 is data type Time.
• AVP_Code is a value defined by the Internet Assigned Numbers Authority (IANA)
that uniquely identifies the message type. See Supported Diameter messages.
• Flags is one or more of the following flags:
Flag Description

Indicates that the AVP must be supported. This flag is presumed to apply
M
to all AVPs in incoming messages.

P Indicates that the AVP must be encrypted for end-to-end security.

V Indicates that the AVP header contains the optional Vendor-ID field.
• Vendor_ID is a value used with the AVP_Code to create a vendor-specific Diameter
AVP. For all incoming messages, Vendor_ID is presumed to be 0.
• Size is 32 or 64.
• Zone is local or utc.

Error handling

The grammar calls the edrAddError() function to report errors, such as the failure to
create a data block.
These errors are recorded in the AAA Gateway Manager stream log (Pipeline_home/log/
stream/InOutputlog_timestamp_transactionID.log). The block in which the error
occurred is specified in the log.

Diameter input mapping

To transfer data from fields in incoming Diameter-based messages to the appropriate fields
in AAA EDR containers, the parser follows the mapping in the Diameter input mapping file
(Pipeline_home/formatDesc/Formats/Diameter/Diameter_v01_InMap.dsc).
Some AVPs are mapped to different fields in different types of Diameter request messages.
For such AVPs, the input mapping file includes multiple subblocks. For example, the
USER_NAME AVP block has four request-specific subblocks, AUTHORIZE_AUTHENTICATE,
SESSION-TERMINATE, CREDIT-CONTROL, and ACCOUNTING:
USER_NAME
{
AUTHORIZE_AUTHENTICATE
{
USER_NAME -> DETAIL.ASS_PROTOCOL_INFO.ASS_DIAMETER_INFO.DIA_DETAIL.AUTHORIZE_
AUTHENTICATE.USER-NAME;

}
SESSION_TERMINATION
{
USER_NAME -> DETAIL.ASS_PROTOCOL_INFO.ASS_DIAMETER_INFO.DIA_
DETAIL.SESSION-TERMINATION.USER-NAME;
}
CREDIT_CONTROL
{
 USER_NAME -> DETAIL.ASS_PROTOCOL_INFO.ASS_DIAMETER_INFO.DIA_
DETAIL.CREDIT-CONTROL.USER-NAME;
}

ACCOUNTING
{
USER_NAME -> DETAIL.ASS_PROTOCOL_INFO.ASS_DIAMETER_INFO.DIA_DETAIL.DIAMETER_AC.USER-NA
}
When processing a Diameter-based message, the input grammar uses the AVP subblock
that corresponds to the request type identified in a message’s header.
For information about Diameter request messages, see Supported Diameter messages.

Diameter stream format description

The Diameter stream format description file (Pipeline_home/formatDesc/Formats/
Diameter/Diameter_v01.dsc) contains descriptions of the fields in Diameter-based
messages supported by AAA Gateway Manager. For example, the following entry specifies
that the data type of the HOST_IP_ADDRESS field is DiameterString, its AVP code is 257,
it must be supported per the mandatory flag M, and its vendor ID is 0:
HOST_IP_ADDRESS DiameterString(257, "M", 0);
For more information about field descriptors, see Diameter field blocks.
The input parser uses this file to identify the data type of fields in incoming request
messages. The output parser uses this file to format answer messages.
To process Diameter-based network messages, AAA Gateway Manager supports several
Diameter data types. For more information, see Diameter data types.

Diameter output grammar

The Diameter output grammar file (Pipeline_home/formatDesc/Formats/Diameter/
Diameter_v01_OutGrammar.dsc) contains instructions for generating outgoing
Diameter-based messages and filling them with data from AAA EDR containers. At startup,
AAA Gateway Manager uses this grammar to create a parser that implements the
instructions.
The output grammar file contains a block for each AAA function; only the function blocks
associated with the request identified in the message header are incorporated into the
parser. Each function block contains the following blocks:
• Mandatory fields — The edrOutputMapToBuffer() function transfers the data in
mandatory fields to a buffer. When Portal finishes processing a request, the
outputWrite() function transfers the data in all such function-block buffers into an
outgoing Diameter-based answer message.
• Optional fields — Before data in optional fields is transferred to a buffer, the
edrInternalState() function verifies that the fields are included in the output flists
of the opcodes that implemented the request or in the protocol-specific data in the
ASSOCIATED_PROTOCOL_INFO block.

Error handling

The logPipeline() function writes all errors to the pipeline log.

Diameter output mapping
To transfer data from fields in AAA EDR containers to the appropriate fields in outgoing
Diameter-based messages, the parser follows the mapping in the Diameter output mapping
file (Pipeline_home/formatDesc/Formats/Diameter/Diameter_v01_OutMap.dsc).

Supported Diameter messages

By default, AAA Gateway Manager supports these Diameter NASREQ application messages:
• Authentication and authorization
◦ AA-Request — Request for authentication and authorization. Mapped to the
input flist of PCM_OP_GSM_AAA_AUTHENTICATE. If authentication
succeeds, AAA Gateway Server sends an AA-Answer message with the
Result-Code AVP set to DIAMETER_SUCCESS to the Diameter server. If
authentication fails, the Result-Code AVP is set to the appropriate error
code.
◦ AA-Answer — Answer to request for authentication and authorization.
• Credit control
◦ CC-Request — Request for credit control operation. There are four types of
CC-Request messages. The type is specified in the message’s CC-Request-
Type AVP. They are mapped to the input flist of the following Portal
opcodes:
Message type Description Mapped to

Used to start a
credit control
session.
Contains credit
INITIAL_REQUEST control PCM_OP_GSM_AAA_AUTHORIZE.
information
relevant to the
initiation of
the session.

Contains credit
control
information for
an existing
credit control
session.
Should be sent
every time a
UPDATE_REQUEST PCM_OP_GSM_AAA_UPDATE_AND_REAUTH
credit control
reauthorization
is needed
when an
allocated
resource or
validity time
expires.

TERMINATION_REQUEST
When accounting is disabled in the Diamete
registry (diameter.reg file), this message
mapped to
Used to end a PCM_OP_GSM_AAA_STOP_ACCOUNTING.
credit control When accounting is enabled in the Diamete
session. registry, this message type is not mapped
Contains credit opcode. Instead, the opcode call is skipped
control dummy CC-Answer message is generated
information Note By default, accounting is disabled. If
relevant to the Diameter credit control application us
terminated accounting commands, you must ena
session. accounting by adding the
ifw.isAccountingEnabled entry to t
Diameter registry and setting it to 1.
Configuring AAA Gateway Manager.

Used when
there is no
need to
Unmapped. Portal doesn’t support credit co
EVENT_REQUEST maintain any
event requests.
credit control
session state
in the server.
◦ CC-Answer — Answer to request for credit control operation.
• Accounting
◦ AC-Request — Request for accounting. There are four types of AC-Request
messages. The type is specified in the message’s Accounting-Record-Type
AVP. They are mapped to the input flist of the following Portal opcodes:
Message
Description Mapped to
type

Used to start an
active session.
START PCM_OP_GSM_AAA_START_ACCOUNTING
Includes session
start timestamp.

Used to provide
usage
information
INTERIM PCM_OP_GSM_AAA_UPDATE_ACCOUNTING
about an
ongoing active
session.

Used to
STOP terminate an PCM_OP_GSM_AAA_STOP_ACCOUNTING
active session.

Used to record a
one-time event
EVENT (event’s start PCM_OP_GSM_AAA_STOP_ACCOUNTING
and end times
are the same).
 ◦ AC-Answer — Answers to request for accounting.
• Session termination
◦ ST-Request — Request to terminate session. Mapped to the input flist of
PCM_OP_GSM_AAA_CANCEL_AUTHORIZATION.
◦ ST-Answer — Answer to request to terminate session.

MBI protocol support files

To process MBI-based messages, AAA Gateway Manager uses these files:
• MBI input grammar
• MBI input mapping
• MBI stream format description
• MBI output grammar
• MBI output mapping

MBI input grammar

The MBI input grammar file (Pipeline_home/formatDesc/Formats/MBI/
MBI_v1.10_InGrammar.dsc) contains instructions for generating AAA EDR containers
and filling them with data from incoming MBI-based messages. At startup, AAA Gateway
Manager uses this grammar to create a parser that implements the instructions.
Each incoming MBI-based message begins with a wire header. The first field after the wire
header is the MESSAGE_TYPE field. All subsequent fields in the message are mapped to
opcode blocks according to the message type specified in this field.
Note Because the subsequent fields can be arranged in any order, each field is defined as a
separate block in the grammar.

Error handling

The grammar instructs the parser to use the edrAddError() function to report errors, such
as a failure to create a data block.
These errors are recorded in the AAA Gateway Manager stream log (Pipeline_home/log/
stream/InOutputlog_timestamp_transactionID.log). The block in which the error
occurred is specified in the log.

MBI input mapping

To transfer data from fields in incoming flist-based messages to the appropriate fields in
AAA EDR containers, the parser follows the mapping in the flist input mapping file
(Pipeline_home/formatDesc/Formats/MBI/MBI_v1.10_InMap.dsc).

MBI stream format description

The MBI stream format description file (Pipeline_home/formatDesc/Formats/MBI/
MBI_v1.10.dsc) specifies the data type of the fields in MBI-based messages that are
supported by AAA Gateway Manager. For example, this entry specifies that the data type of
the CALL_ATMPT_TM field is TlvTimestamp:
CALL_ATMPT_TM TlvTimestamp(1029, 2, 2);
The input parser uses this file to identify the data type of fields in incoming network
messages. The output parser uses this file to format responses.
To process MBI-based network messages, AAA Gateway Manager supports several MBI data
types. For more information, see MBI data types.

MBI output grammar

The MBI output grammar file (Pipeline_home/formatDesc/Formats/MBI/
MBI_v1.10_OutGrammar.dsc) contains instructions for generating outgoing MBI-based
messages and filling them with data from AAA EDR containers. At startup, AAA Gateway
Manager uses this grammar to create a parser that implements the instructions.

MBI output mapping

To transfer data from fields in AAA EDR containers to the appropriate fields in outgoing MBI-
based messages, the parser follows the mapping in the MBI output mapping file
(Pipeline_home/formatDesc/Formats/MBI/MBI_v1.10_OutMap.dsc).
The output grammar file contains a block for each AAA function. Each function block
contains the following blocks:
• Mandatory fields — The edrOutputMapToBuffer() function transfers the data in
mandatory fields to a buffer. When Portal finishes processing a request, the
outputWrite() function transfers the data in all such function-block buffers into an
outgoing MBI-based message.
• Optional fields — Before data in optional fields is transferred to a buffer, the
edrInternalState() function verifies that the fields are included in the output flists
of the opcodes that implemented the request or in the protocol-specific data in the
ASSOCIATED_PROTOCOL_INFO block.

Error handling

The logPipeline() function writes all errors to the pipeline log.

Supported MBI messages

By default, AAA Gateway supports these MBI-based AAA messages:
• Authorize_req — When a customer attempts to initiate a prepaid service, an HP
OpenCall Service Execution Processor (SEC) sends this message to AAA Gateway
Manager to authorize the service.
• Authorize_conf — If AAA Gateway Manager verifies that the customer is
authorized to use the service and his account balance is sufficient to initiate the
service, the gateway sends this message with a token (for example, the time
reserved for the service) to the SEC.
• Reauthorize_req — When a previously authorized customer’s token expires or is
about to expire, the SEC sends this message to the gateway. The gateway attempts
to reserve a new token for the ongoing session. These messages are sent
periodically until the customer runs out of credit or ends the session.
• Reauthorize_conf — If reauthorization is successful, the gateway sends this
message to the SEC.
• Authorize_reject — If authorization or reauthorization is unsuccessful, the
gateway sends this message to the SEC.
 • End_req — When a customer hangs up or a session is not completed, the SEC
sends this message to the gateway to end and rate the session.
• End_ack — After Portal rates the session, debits the customer’s balance, and saves
the session data, the gateway sends this message with the customer’s remaining
account balance to the SEC.
In addition to the AAA messages, the gateway supports the following MBI administrative
messages:
• StartUp_req — Immediately after a TCP/IP connection is established between an
SEC and the gateway, the SEC sends this message to verify that the gateway is
available to handle a service message. The gateway uses
PCM_OP_GSM_AAA_ACCOUNTING_ON to ensure that all active sessions initiated
earlier by the SEC are closed.
• StartUp_response — After receiving a StartUp_req message, the gateway sends
this message to the SEC to signal that it is ready to process a service message.
• KeepAlive_req — While processing an active session, the SEC sends this message
to verify that the gateway is still available.
• KeepAlive_response — After receiving a KeepAlive_req message, the gateway
sends this message to the SEC to signal that it is still available. If the gateway does
not send this message in a timely fashion, the SEC resends its KeepAlive_req for a
user-specified number of times after which it sends a ShutDown_req.
• ShutDown_req — The SEC sends this message to the gateway to signal that the
SEC is shutting down. The gateway uses PCM_OP_GSM_AAA_ACCOUNTING_OFF to
ensure that currently active sessions initiated by the SEC are closed.
• ShutDown_response — After receiving a ShutDown_req message, the gateway
must close all active sessions and then send this message to the SEC. The SEC then
terminates its connection to the gateway.

MBI CDR protocol support files

If AAA Gateway Manager is unavailable when an HP OpenCall MBI–based network sends it
an end request (End_req), the network saves the session data in MBI CDR file format. MBI
CDRs contain information about the entire session, from start to end. When AAA Gateway
Manager is available again, the MBI CDRs are processed by the gateway’s
MBI_CDR_PlaybackPipeline. To convert the CDRs into a format that the pipeline
understands, AAA Gateway Manager uses the following files:
• MBI CDR input grammar
• MBI CDR input mapping
• MBI CDR stream format description
Note No output grammar or mapping files are provided for this protocol because AAA
Gateway Manager does not need to respond to MBI CDRs.

MBI CDR input grammar

The MBI CDR input grammar file (Pipeline_home/formatDesc/Formats/MBI_CDR/
OCSAC_CDR_2.0_InGrammar.dsc) contains instructions for generating AAA EDR
containers and filling them with data from MBI CDRs. At startup, AAA Gateway Manager
uses this grammar to create a parser that implements the instructions.
Error handling

The grammar instructs the parser to use the edrAddError() function to report errors, such
as a failure to create a data block.
These errors are recorded in the AAA Gateway Manager stream log (Pipeline_home/log/
stream/InOutputlog_timestamp_transactionID.log). The block in which the error
occurred is specified in the log.

MBI CDR input mapping

To transfer data from fields in MBI CDRs to the appropriate fields in AAA EDR containers,
the parser follows the mapping in the flist input mapping file (Pipeline_home/formatDesc/
Formats/MBI_CDR/OCSAC_CDR_2.0_InMap.dsc).

MBI CDR stream format description

The MBI stream format description file (Pipeline_home/formatDesc/Formats/MBI_CDR/
OCSAC_CDR_2.0.dsc) specifies the data type of the fields in MBI CDRs that are supported
by AAA Gateway Manager.

Customizing AAA Gateway Manager protocol

support
When AAA Gateway Manager processes network messages, the opcodes it calls, the
information it passes to the opcodes, and the information it receives from the opcodes and
sends back to the network are determined by the AAA EDR container description (see AAA
EDR container description). By default, this description supports fields in flist-based and
MBI-based messages that are required to perform AAA for GSM services.
To pass more information to and from the default opcodes, to call additional opcodes, or to
support other services, you must customize the description and its associated grammar and
mapping files.
To modify the AAA EDR container description, see Modifying and loading the EDR container
description.
To modify the associated grammar and mapping files, see these topics:
• Configuring EDR input processing
• Configuring EDR output processing

Configuring the gateway to support additional MBI data

The following example shows how to configure AAA Gateway Manager to handle an
additional MBI protocol field called MY_FLD. This field will store integers. It will not be
processed by an opcode. Instead, it will simply store data from incoming MBI-based
messages and enable the gateway to include the data in outgoing MBI-based messages.
1. Modify the AAA EDR container description file (aaaContainerDesc.dsc) as follows:
Add the following line anywhere in the file’s
ASSOCIATED_PROTOCOL_INFO.ASSOCIATED_MBI_INFO block:
Integer MY_FLD;
For more information about this file, see AAA EDR container description.
2. Modify the MBI stream format description file (MBI_v1.10.dsc) as follows:
Using the protocol-defined tag value of MY_FLD, add the field definition to the file.
For example, if the tag value is 999, add the following definition to the file:
MY_FLD(TLV)
{
Info
{
}
MY_FLD TlvInteger(999, 2, 2);
}
For more information about this file, see MBI stream format description.
3. Modify the MBI input grammar file (MBI_v1.10_InGrammar.dsc) as follows:
In the mbi_item section of the file’s Grammar block, add the lines shown here in
bold:
mbi_item:
message_type
| scp_name
| protocol_version
...
...
| my_fld
;

...
...
my_fld:
MBI.MY_FLD
{
//call the mapping file to map the field to the EDR
//container
edrInputMap(“MBI.MY_FLD.STD_MAPPING”)
}
;
For more information about this file, see MBI input grammar.
4. Modify the MBI input mapping file (MBI_v1.10_InMap.dsc) as follows:
Anywhere in the MBI block of the input mapping file, specify the AAA EDR container
field that should receive data from MY_FLD:
MY_FLD
{
STD_MAPPING
{
MY_FLD -> DETAIL.ASS_PROTOCOL_INFO.ASS_MBI_INFO.MY_FLD;
}
}
For more information about this file, see MBI input mapping.
5. Modify the MBI output grammar file (MBI_v1.10_OutGrammar.dsc) as follows:
In the section of the file where the response in which this field must be included is
constructed, add all of the following code:
//Check whether the associated EDR field contains a value:
if(edrInternalState(DETAIL.ASS_PROTOCOL_INFO.ASS_MBI_INFO.
BALANCE_TYPE, 0, 0)!= CLEARED)
{
//If it does, write the value to the buffer:
edrOutputMapToBuffer(optMbiBuffer, “MBI.BALANCE_TYPE.STD_
 MAPPING”, 0, 0);
}
...
...
//After all fields are written to the buffer, write the buffer
//to the response:
outputWrite(headerBuffer + optMbiBuffer);
For more information about this file, see MBI output grammar.
6. Modify the MBI output mapping file (MBI_v1.10_OutMap.dsc) as follows:
Anywhere in the MBI block of the output mapping file, add the following code:
MY_FLD
{
STD_MAPPING
{
MY_FLD <- DETAIL.ASS_PROTOCOL_INFO.ASS_MBI_INFO.MY_FLD;
}
}

Copyright © 2006 Portal Software, Inc. All rights reserved.

Last Modified: March 2006
Please send us your comments.