aaa gateway manager protocol support
TRANSCRIPT
Portal Documentation · Service Integration Components · AAA Gateway Manager
AAA Gateway Manager protocol support
About this documentAbout AAA Gateway Manager protocol supportFlist protocol support filesFlist input grammarFlist field blocksError handlingFlist input mappingFlist stream format descriptionFlist output grammarError handlingFlist output mappingSupported flist messagesDiameter protocol support filesDiameter input grammarDiameter field blocksError handlingDiameter input mappingDiameter stream format descriptionDiameter output grammarError handlingDiameter output mappingSupported Diameter messagesMBI protocol support filesMBI input grammarError handlingMBI input mappingMBI stream format descriptionMBI output grammarMBI output mappingError handlingSupported MBI messagesMBI CDR protocol support filesMBI CDR input grammarError handlingMBI CDR input mappingMBI CDR stream format descriptionCustomizing AAA Gateway Manager protocol supportConfiguring the gateway to support additional MBI data
About this document
This document describes the network message protocols supported by Portal™ AAAGateway 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 AAAGateway Manager and Portal understand, the gateway’s InSocketManager passes themessages to a parser. The parser uses protocol-specific input grammar and mapping files toconvert the messages into AAA EDR containers, the data structure understood by pipelinefunction modules. The FCT_Opcode module then converts the data in the containers into aninput flist and passes it to the appropriate opcode. The opcode uses the data to perform itsnormal Portal operations. After the opcode generates an output flist, the FCT_Opcodemodule converts the flist into an AAA EDR container. The gateway’s OutSocketManager thenpasses the container to a parser, which uses protocol-specific output grammar and mappingfiles to convert the container into an appropriately formatted network response.The following figure illustrates the AAA Gateway Manager protocol conversion process. Bluefiles are used to convert incoming messages to AAA EDR containers. Yellow files are used toconvert 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 andmapping files for this protocol, see Flist protocol support files.
• Diameter protocolTo enable AAA Gateway Manager to support this protocol, you must install DiameterCharging Manager (see Installing Diameter Charging Manager). For informationabout the grammar and mapping files for this protocol, see Diameter protocolsupport files.
• Tag/LengthOfValue/Value (TLV) format used by the HP OpenCall MessageBased Interface (MBI) protocolTo enable AAA Gateway Manager to support this protocol, you must install HPOpenCall Manager (see Installing HP OpenCall Manager). For information about thegrammar and mapping files for this protocol, see MBI protocol support files.
• MBI CDR protocolTo enable AAA Gateway Manager to process MBI CDRs, you must install HPOpenCall Manager (see Installing HP OpenCall Manager). For information about thegrammar 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 andfilling them with data from incoming flist-based messages. At startup, AAA GatewayManager uses this grammar to create a parser that implements the instructions.
By default, the flist input grammar supports these opcodes:NoteThe 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 fixedlength and is mapped to a block in the input grammar named WIRE_HEADER. The grammaris driven by the opcode number included in this header.Because fields following the wire header in flist-based messages can be arranged in anyorder, 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 isdefined 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. Toretrieve both values, the parser must treat them as two fields. Thus, the grammar defines aseparate 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 tocreate 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 erroroccurred is specified in the log.
Flist input mapping
To transfer data from fields in incoming flist-based messages to the appropriate fields inAAA 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 contextin which the field name appears. For example, in one opcode’s input flist, PIN_FLD_POIDcan be included in every level in every array. In addition, it can be included in the inputflists 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 aresupported by AAA Gateway Manager. For example, this entry specifies that the data type ofthe 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 networkmessages. The output parser uses this file to format responses.To process flist-based network messages, AAA Gateway Manager supports several flist datatypes. 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-basedmessages and filling them with data from AAA EDR containers. At startup, AAA GatewayManager 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 blocksassociated with the opcode specified in the flist wire header are incorporated into theparser. Each function block contains the following blocks:
• Mandatory fields — The edrOutputMapToBuffer() function transfers the data inmandatory fields to a buffer. When Portal finishes processing a request, theoutputWrite() function transfers the data in all such function-block buffers into anoutgoing flist-based message.
• Optional fields — Before data in optional fields is transferred to a buffer, theedrInternalState() function verifies that the fields are included in the output flistsof the opcodes that implemented the request or in the protocol-specific data in theASSOCIATED_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:
NoteThe names listed below are the new names of the opcodes. For the corresponding oldnames 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 appropriateinput flist to AAA Gateway Manager to authenticate the customer. After Portalexecutes this opcode, the gateway sends a response with the appropriate outputflist 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 thegateway to authorize the customer to use the GSM service. After Portal executesthis opcode, the gateway sends a response with the appropriate output flist to theprepaid network.
• PCM_OP_GSM_AAA_UPDATE_ACCOUNTING — To update an accounting session fora GSM service, the prepaid network sends this message with the appropriate inputflist to the gateway. After Portal executes this opcode, the gateway sends aresponse with the appropriate output flist to the prepaid network.
• PCM_OP_GSM_AAA_REAUTHORIZE — When a previously authorized customer’ssession expires or is about to expire, the prepaid network sends this message withthe appropriate input flist to the gateway to extend the ongoing session. After Portalexecutes this opcode, the gateway sends a response with the appropriate outputflist to the prepaid network.
• PCM_OP_GSM_AAA_UPDATE_AND_REAUTHORIZE — To simultaneously update andreauthorize an accounting session for a GSM service, the prepaid network sends thismessage with the appropriate input flist to the gateway. After Portal executes thisopcode, the gateway sends a response with the appropriate output flist to theprepaid network.
• PCM_OP_GSM_AAA_CANCEL_AUTHORIZATION — When a customer hangs up or asession is not completed, the prepaid network sends this message with theappropriate input flist to the gateway to end the session and release reservedresources. After Portal executes this opcode, the gateway sends a response with theappropriate output flist to the prepaid network.
• PCM_OP_GSM_AAA_START_ACCOUNTING — To start an accounting session for aGSM service, the prepaid network sends this message with the appropriate inputflist to the gateway. After Portal executes this opcode, the gateway sends aresponse with the appropriate output flist to the prepaid network.
• PCM_OP_GSM_AAA_STOP_ACCOUNTING — To end an accounting session for a GSMservice, the prepaid network sends this message with the appropriate input flist tothe gateway. After Portal executes this opcode, the gateway sends a response withthe appropriate output flist to the prepaid network.
In addition to the AAA messages, the gateway also supports the following flistadministrative messages:
• PCM_OP_GSM_AAA_ACCOUNTING_ON — To close all open sessions when anaccounting session is started, the prepaid network sends this message with theappropriate input flist to the gateway. After Portal executes this opcode, thegateway sends a response with the appropriate output flist to the prepaid network.
• PCM_OP_GSM_AAA_ACCOUNTING_OFF — To end all active sessions when theprepaid network is being shut down or a problem is encountered, the prepaidnetwork sends this message with the appropriate input flist to the gateway. AfterPortal executes this opcode, the gateway sends a response with the appropriateoutput 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 containersand filling them with data from incoming Diameter-based messages. At startup, AAAGateway Manager uses this grammar to create a parser that implements the instructions.By default, the Diameter input grammar supports these opcodes:NoteThe 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 toidentify 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
NoteFor 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 eachfield that corresponds to an AVP is defined as a separate block. Each AVP block contains afield descriptor in one of the following formats (the field descriptor is defined in theDiameter 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
M Indicates that the AVP must be supported. This flag is presumed to applyto 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 DiameterAVP. 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 tocreate 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 erroroccurred is specified in the log.
Diameter input mapping
To transfer data from fields in incoming Diameter-based messages to the appropriate fieldsin 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, theUSER_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-NAME;}When processing a Diameter-based message, the input grammar uses the AVP subblockthat 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-basedmessages supported by AAA Gateway Manager. For example, the following entry specifiesthat 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 requestmessages. The output parser uses this file to format answer messages.To process Diameter-based network messages, AAA Gateway Manager supports severalDiameter 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 outgoingDiameter-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 theinstructions.The output grammar file contains a block for each AAA function; only the function blocksassociated with the request identified in the message header are incorporated into theparser. Each function block contains the following blocks:
• Mandatory fields — The edrOutputMapToBuffer() function transfers the data inmandatory fields to a buffer. When Portal finishes processing a request, theoutputWrite() function transfers the data in all such function-block buffers into anoutgoing Diameter-based answer message.
• Optional fields — Before data in optional fields is transferred to a buffer, theedrInternalState() function verifies that the fields are included in the output flistsof the opcodes that implemented the request or in the protocol-specific data in theASSOCIATED_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 outgoingDiameter-based messages, the parser follows the mapping in the Diameter output mappingfile (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 theinput flist of PCM_OP_GSM_AAA_AUTHENTICATE. If authenticationsucceeds, AAA Gateway Server sends an AA-Answer message with theResult-Code AVP set to DIAMETER_SUCCESS to the Diameter server. Ifauthentication fails, the Result-Code AVP is set to the appropriate errorcode.
◦ AA-Answer — Answer to request for authentication and authorization.• Credit control
◦ CC-Request — Request for credit control operation. There are four types ofCC-Request messages. The type is specified in the message’s CC-Request-Type AVP. They are mapped to the input flist of the following Portalopcodes:
Message type Description Mapped to
INITIAL_REQUEST
Used to start acredit controlsession.Contains creditcontrolinformationrelevant to theinitiation ofthe session.
PCM_OP_GSM_AAA_AUTHORIZE.
UPDATE_REQUEST
Contains creditcontrolinformation foran existingcredit controlsession.Should be sentevery time acredit controlreauthorizationis neededwhen anallocatedresource orvalidity timeexpires.
PCM_OP_GSM_AAA_UPDATE_AND_REAUTHORIZE.
TERMINATION_REQUEST
Used to end acredit controlsession.Contains creditcontrolinformationrelevant to theterminatedsession.
When accounting is disabled in the Diameterregistry (diameter.reg file), this message type ismapped toPCM_OP_GSM_AAA_STOP_ACCOUNTING.When accounting is enabled in the Diameterregistry, this message type is not mapped to anyopcode. Instead, the opcode call is skipped, and adummy CC-Answer message is generated.NoteBy default, accounting is disabled. If the
Diameter credit control application usesaccounting commands, you must enableaccounting by adding theifw.isAccountingEnabled entry to theDiameter registry and setting it to 1. SeeConfiguring AAA Gateway Manager.
EVENT_REQUEST
Used whenthere is noneed tomaintain anycredit controlsession statein the server.
Unmapped. Portal doesn’t support credit controlevent requests.
◦ CC-Answer — Answer to request for credit control operation.• Accounting
◦ AC-Request — Request for accounting. There are four types of AC-Requestmessages. The type is specified in the message’s Accounting-Record-TypeAVP. They are mapped to the input flist of the following Portal opcodes:
Messagetype Description Mapped to
START
Used to start anactive session.Includes sessionstart timestamp.
PCM_OP_GSM_AAA_START_ACCOUNTING
INTERIM
Used to provideusageinformationabout anongoing activesession.
PCM_OP_GSM_AAA_UPDATE_ACCOUNTING
STOPUsed toterminate anactive session.
PCM_OP_GSM_AAA_STOP_ACCOUNTING
EVENT
Used to record aone-time event(event’s startand end timesare the same).
PCM_OP_GSM_AAA_STOP_ACCOUNTING
◦ AC-Answer — Answers to request for accounting.• Session termination
◦ ST-Request — Request to terminate session. Mapped to the input flist ofPCM_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 containersand filling them with data from incoming MBI-based messages. At startup, AAA GatewayManager 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 wireheader is the MESSAGE_TYPE field. All subsequent fields in the message are mapped toopcode blocks according to the message type specified in this field.NoteBecause 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, suchas 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 erroroccurred is specified in the log.
MBI input mapping
To transfer data from fields in incoming flist-based messages to the appropriate fields inAAA 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 aresupported by AAA Gateway Manager. For example, this entry specifies that the data type ofthe 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 networkmessages. The output parser uses this file to format responses.To process MBI-based network messages, AAA Gateway Manager supports several MBI datatypes. 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-basedmessages and filling them with data from AAA EDR containers. At startup, AAA GatewayManager 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 blockcontains the following blocks:
• Mandatory fields — The edrOutputMapToBuffer() function transfers the data inmandatory fields to a buffer. When Portal finishes processing a request, theoutputWrite() function transfers the data in all such function-block buffers into anoutgoing MBI-based message.
• Optional fields — Before data in optional fields is transferred to a buffer, theedrInternalState() function verifies that the fields are included in the output flistsof the opcodes that implemented the request or in the protocol-specific data in theASSOCIATED_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 GatewayManager to authorize the service.
• Authorize_conf — If AAA Gateway Manager verifies that the customer isauthorized to use the service and his account balance is sufficient to initiate theservice, the gateway sends this message with a token (for example, the timereserved for the service) to the SEC.
• Reauthorize_req — When a previously authorized customer’s token expires or isabout to expire, the SEC sends this message to the gateway. The gateway attemptsto reserve a new token for the ongoing session. These messages are sentperiodically until the customer runs out of credit or ends the session.
• Reauthorize_conf — If reauthorization is successful, the gateway sends thismessage to the SEC.
• Authorize_reject — If authorization or reauthorization is unsuccessful, thegateway sends this message to the SEC.
• End_req — When a customer hangs up or a session is not completed, the SECsends this message to the gateway to end and rate the session.
• End_ack — After Portal rates the session, debits the customer’s balance, and savesthe session data, the gateway sends this message with the customer’s remainingaccount balance to the SEC.
In addition to the AAA messages, the gateway supports the following MBI administrativemessages:
• StartUp_req — Immediately after a TCP/IP connection is established between anSEC and the gateway, the SEC sends this message to verify that the gateway isavailable to handle a service message. The gateway usesPCM_OP_GSM_AAA_ACCOUNTING_ON to ensure that all active sessions initiatedearlier by the SEC are closed.
• StartUp_response — After receiving a StartUp_req message, the gateway sendsthis 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 messageto verify that the gateway is still available.
• KeepAlive_response — After receiving a KeepAlive_req message, the gatewaysends this message to the SEC to signal that it is still available. If the gateway doesnot send this message in a timely fashion, the SEC resends its KeepAlive_req for auser-specified number of times after which it sends a ShutDown_req.
• ShutDown_req — The SEC sends this message to the gateway to signal that theSEC is shutting down. The gateway uses PCM_OP_GSM_AAA_ACCOUNTING_OFF toensure that currently active sessions initiated by the SEC are closed.
• ShutDown_response — After receiving a ShutDown_req message, the gatewaymust close all active sessions and then send this message to the SEC. The SEC thenterminates its connection to the gateway.
MBI CDR protocol support files
If AAA Gateway Manager is unavailable when an HP OpenCall MBI–based network sends itan end request (End_req), the network saves the session data in MBI CDR file format. MBICDRs contain information about the entire session, from start to end. When AAA GatewayManager is available again, the MBI CDRs are processed by the gateway’sMBI_CDR_PlaybackPipeline. To convert the CDRs into a format that the pipelineunderstands, AAA Gateway Manager uses the following files:
• MBI CDR input grammar• MBI CDR input mapping• MBI CDR stream format description
NoteNo output grammar or mapping files are provided for this protocol because AAAGateway 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 EDRcontainers and filling them with data from MBI CDRs. At startup, AAA Gateway Manageruses 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, suchas 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 erroroccurred 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 supportedby AAA Gateway Manager.
Customizing AAA Gateway Manager protocolsupport
When AAA Gateway Manager processes network messages, the opcodes it calls, theinformation it passes to the opcodes, and the information it receives from the opcodes andsends back to the network are determined by the AAA EDR container description (see AAAEDR container description). By default, this description supports fields in flist-based andMBI-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 tosupport other services, you must customize the description and its associated grammar andmapping files.To modify the AAA EDR container description, see Modifying and loading the EDR containerdescription.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 anadditional MBI protocol field called MY_FLD. This field will store integers. It will not beprocessed by an opcode. Instead, it will simply store data from incoming MBI-basedmessages 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’sASSOCIATED_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 inbold: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//containeredrInputMap(“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 containerfield 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 isconstructed, 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 2006Please send us your comments.