ALU-LR14.02.00.01 UseCaseDocument

LR14.
02 Use Case Document
FGW Use Case Document For

LR14.02
Owner: Amulya Kujur(Amulya),
Author(s): Vishal J N (Vishal)

BCR4.3.2 Release Notes
Revision History
Software version Date Description

FGW-14.02.00.01 11-Feb-2014 Initial Version of 14.02.00.01 release
Alcatel-Lucent - Proprietary 2
Table of Contents
Contents
TABLE OF CONTENTS ................................................................................................................................. 3
CONTENTS ........................................................................................................................................................ 3
1 USE CASES ................................................................................................................................................. 5
1.1 SCENARIO 1: HOW TO TEST BSRDATA XML FILE DOWNLOAD FOR SECURITY HARDENING ............. 5
1.2 SCENARIO 2: HOW TO VERIFY & TEST BSR REGISTRATION STATUS ................................................... 7
1.3 SCENARIO 3: HOW TO TEST COMMON ID CHECK FUNCTIONALITY OF SECURITY HARDENING ........... 8
1.4 SCENARIO 4: HOW TO VERIFY & TEST REAL TIME MONITORING FEATURE ........................................ 8
1.5 SCENARIO 5: HOW TO VERIFY & TEST ONLINE DATA SYNCHRONIZATION IN BSG ............................. 9
1.6 BSGSAVESTATE SCRIPT .......................................................................................................................... 10
1.7 SCENARIO 7: HOW TO VERIFY & TEST THE BSRREGISTERAFTERINITTIMER OF THE SMALLCELLS
FEATURE.......................................................................................................................................................... 11
1.8 SCENARIO 8: HOW TO VERIFY & TEST THE BSRREGISTERAFTERFAILURETIMER OF THE
SMALLCELLS FEATURE................................................................................................................................... 12
1.9 SCENARIO 9: HOW TO VERIFY AND TEST FEMTO TO FEMTO PS HANDOVER ..................................... 12
7. DIRECT TRANSFER MESSAGES FROM CN SHOULD BE DIRECTED TO BSR-2. .... 13
1.10 SCENARIO 10 : HOW TO TEST MULTIPLE PS HANDOVERS FROM SAME BSR .................................. 13
1.11 SCENARIO 11 : HOW TO VERIFY AND TEST CS+PS HANDOVERS FROM SAME BSR........................ 14
6.VERIFY THE WIRESHARK TRACES FOR ..................................................................................... 15
1.12 SCENARIO 12: HOW TO CONFIGURE THE DUAL STACK FEATURE IN BSG ..................................... 15
1.13 SCENARIO 13: CREATING IU INSTANCES USING CLI ....................................................................... 17
1.14 SCENARIO14: IUFLEX – COMMANDS TO CREATE REGIONS ............................................................ 25
1.15 SCENARIO15: IUFLEX – COMMANDS TO CREATE CSREGIONNRITOCNNODECS .......................... 25
1.16 SCENARIO16: IUFLEX – COMMANDS TO CREATE PSREGIONNRITOCNNODEPS ........................... 26
1.17 SCENARIO17: IUFLEX – COMMANDS TO CREATE BSGLAITOCSREGION ...................................... 26
1.18 SCENARIO18: IUFLEX – COMMANDS TO CREATE BSGRAITOPSREGION....................................... 27
1.19 SCENARIO 19: ACTIVATION OF IUFLEX ........................................................................................... 27
1.20 SCENARIO 20: MAKING USE OF AN IPSP TO SUPPORT MULTIPLE NETWORK TRAFFIC .................. 29
1.21 SCENARIO 20: MAKING USE OF AN IPSP TO SUPPORT MULTIPLE NETWORK TRAFFIC .................. 29
1.22 SCENARIO 21: HOW TO DELETE AN IU INTERFACE ......................................................................... 30
1.23 SCENARIO 22: CREATING MANUAL PRESENCE & HO INSTANCES USING CLI .............................. 31
1.24 SCENARIO 23 : HOW TO TEST DUAL BAND FEMTO ......................................................................... 33
1.25 SCENARIO 24 : HOW TO TEST MR 1744 ........................................................................................... 34
1.26 SCENARIO 25: HOW TO TEST MR 1998 ........................................................................................... 34
1.27 SCENARIO 26: HOW TO TEST PARESEPMFILE SCRIPT ..................................................................... 34
1.28 SCENARIO 27 : HOW TO TEST AIOG ................................................................................................ 35
1.29 SCENARIO 28 : CREATING MANUAL AAASECURITYGATEWAY/AAAREMOTEAASERVER
INSTANCES USING CLI .................................................................................................................................... 37
1.30 SCENARIO 29 : HOW TO VERIFY HNB/BSR REGISTRATION INFO THROUGH BSGCONSOLE ........ 38
1.31 SCENARIO 30 : HOW TO VERIFY SECGW, VPNIP AND REMOTE SERVER INFO IN AAACONSOLE38
1.32 SCENARIO 31: HOW TO TEST MR 2115 – EMERGENCY CALL TESTING ......................................... 39
1.33 SCENARIO 32: HOW TO TEST RESUME STATE CR 413791 .............................................................. 39
1.34 SCENARIO 33: HOW TO TEST MR2245 ............................................................................................ 40
1.35 SCENARIO 34: HOW TO CREATE BVG MO CLASS AND ITS CHILD’S WHEN USERPLANE IP’S
CONFIGURED IN FLOATING MODE: ................................................................................................................. 40
1.36 SCENARIO 36: HOW TO TEST ACS ................................................................................................... 41
1.37 SCENARIO 37: HOW TO TEST END TO END SUBSCRIBER TRACING................................................. 41
1.38 SCENARIO 38:HOW TO TEST OPTIMIZED PAGING ........................................................................... 42
1.39 SCENARIO 39: HOW TO VERIFY AND TEST FEMTO STARTUP PROCEDURE FEATURE FOR AT&T . 42
1.40 PROCEDURE TO TEST AND VERIFY THE NAT PROXY FEATURE ...................................................... 43
1.41 HOW TO VERIFY THE NOTIFY CONNECTION STATUS MESSAGE IS SENT TO ALL BSR
ASSOCIATIONS ON FIXED IP INTERFACES AFTER SWITCHOVER .................................................................... 43
1.42 HOW TO VERIFY THAT AAA RECEIVES THE ACT BSR DATA FROM BSG DURING STARTUP....... 44
1.43 HOW TO VERIFY THE PEER SCTP COMMUNICATION BETWEEN AAA PROCESS ON BOTH
ACTIVE AND STANBY NODE ........................................................................................................................... 44
1.44 HOW TO VERIFY LOADING OF INCREMENTAL FILES UPON RESTART OF ACTIVE NODE ............ 45
1.45 HOW TO VERIFY THE STATE OF VPN IP INFO IS MAINTAINED AFTER SWITCHOVER IN NEWLY
ACTIVE NODE .................................................................................................................................................. 45
1.46 HOW TO CONFIGURE USER PLANE INTERFACES IN FLOATING MODE IN OAM_PRECONFIG.XML. 45
1.47 PROCEDURE TO VERIFY AGPS CACHE PROXY FEATURE ................................................................ 47
1.48 HOW TO CONFIGURE FEMTOOAMPROXY INTERFACE IN FLOATING FOR ATCA PLATFORM IN
OAM_PRECONFIG.XML.................................................................................................................................. 47
1.49 HOW TO TEST MR2265 ................................................................................................................... 50
1.50 PROCEDURE TO TEST MR2275 ........................................................................................................ 50
1.51 HOW TO TEST MR2196 ................................................................................................................ 51
1.52 THREADMON CONFIGURATION ........................................................................................................ 52
1.53 HOW TO CONFIGURE INTERNODE VLAN IN ATCA ................................................................. 53
1.54 HOW TO TEST MR2311 ................................................................................................................ 54
1.55 HOW TO TEST CR594573:............................................................................................................ 55
1.56 STANDARD PAGING WITH/WITHOUT SUPERLAC .......................................................................... 56
1.57 NOTIFY CONNECTION STATUS ......................................................................................................... 58
1.58 HOW TO ENABLE AMR FRAME CONCATENATION FEATURE ....................................... 58
1.59 MR2295 – RECONFIGURING FEMTOCP ON 10GETH IN BONO ........................................................ 59
1.60 CONFIGURE IPADDRESS OF INTERFACES IN OAM_PRECONFIG.XML ........................................... 60
1.61 MR2295 ALARM HANDLING. ........................................................................................................... 62
1.62 CMAS FEATURE USE CASES ............................................................................................................. 63
1.63 PROCEDURE TO ENABLE MCUI FEATURE ....................................................................................... 66
1.64 PROCEDURE TO DISABLE MCUI FEATURE ...................................................................................... 67
1.65 PROCEDURE TO MIGRATE ACCOUNTINGSERVERIPADDRESS FROM BACKPLAE IP TO PUBLIC IP
FOR MCUI ....................................................................................................................................................... 68
1.66 TROUBLESHOOTING IPMI ............................................................................................................... 69
1.67 ENABLING QUERY ALL VPN IN AAA DEBUG CONSOLE. ............................................................... 69
1.68 ENABLING MR2496 IN AAA ............................................................................................................ 69
1.69 ENABLING RADIUS PACKET DUMP IN AAA ..................................................................................... 69
1.70 TROUBLESHOOTING IPMI ............................................................................................................... 69
1.71 ADD 2ND IP ADDRESS FOR SECGW INTERFACE................................................................................ 70
1.72 HOW TO TEST FLEXIBLE RTM PORT BUNDLING FEATURE(163819) .................................................. 71
1.73 PROCEDURE TO ENABLE OR DISABLE DPDK FEATURE(124168) ................................................... 73
1.74 PROCEDURE TO UPDATE BANNER MESSAGE .................................................................................... 73
1.75 MOCN – COMMAND TO CREATE MO.............................................................................................. 73
1.76 ACTIVATION OF MOCN ................................................................................................................... 73
1.77 PROCEDURE TO PERFORM HOT SWAP IN ATCA HARDWARE. ..................................... 74
1.78 PROCEDURE TO ACTIVATE MS IUH INTEGRATION FEATURE .......................................................... 74
1.79 PROCEDURE TO STREAMED TO BE USED WITH SABP WHEN USING IUH ........................................ 75
1.80 PROCEDURE TO CONFIGURE MULTIUSER PLANE CONFIGURATION ................................................. 75
1 Use Cases
This document provides the details of some important use cases for the features
supported in this release
1.1 Scenario 1: How to test BSRData XML File download for Security
Hardening
Pre-requisite:
1. CLI, OAM and BSG should be running and ItfBsg is up.
2. OAM_PreConfig.xsd’ should be available in /opt/bsrdata directory since the
schema used by BSR Data XML file downloaded from FMS is
OAM_PreConfig.xsd.
1) Set the SFTP Server IP in ‘actBSRDataBsgBsrInfoRepository’ attribute of FGW
class through FGW CLI.
2) Set the BsrData XML file path on the SFTP server in
‘actBSRDataBsgBsrInformationFile’ attribute of FGW class through FGW CLI.
3) Initiate the action command ‘actBSRData’ by setting its value to ‘True’ through
FGW CLI
4) OAM should download the file to /opt/bsrdata directory and send the
downloaded file path to BSG.
5) BSG should parse and perform minimal validation of the downloaded BSR Data
file.
6) On successful parsing and validation of BSR Data file, BSG should populate the
BSR data to its internal data structures and create
‘OAM_BsrDataPersistentDB.xml’ file for persistence in /opt/bsrdata directory.
7) On response from BSG to OAM, OAM should delete the downloaded BSR data
file from /opt/bsrdata directory.
8) Parsing status of BSR data file can be checked in the
/opt/log/FMG/Log_FMG.log
9) Verification of downloaded file can also be done by evaluating the differences of
the downloaded BSR Data file and persistent ‘OAM_BsrDataPersistentDB.xml’.
1.1.1 Scenario 1.1: BSR record supporting Enterprise list should refer only an
existing Enterprise List
1. BSR record supporting Enterprise list should refer a existing Enterprise List
Eg:
<MOI fdn="FGW=10001,EnterpriseList=2">
<Attributes>
<Attribute DataType="Enumeration" Id="1"
Name="action" Value="create"/>
</Attributes>
</MOI>
<MOI fdn="FGW=10001,EnterpriseList=2,ACLEntry=1">
<Attributes>
<Attribute DataType="Enumeration" Id="1" Name="userType"
Value="Owner"/>
<Attribute DataType="Enumeration" Id="2" Name="action"
Value="addIMSI"/>
<Attribute DataType="OCTETSTRING" Id="3" Name="iMSI"
Value="123456789900000"/>
</Attributes>
</MOI>
<MOI fdn="FGW=10001, BSR=102">

<Attributes>
Value="updateCreate"/>
<Attribute DataType="DisplayString" Id="9" Name="aclListRef"
Value="FGW=10001,EnterpriseList=2"/>
</Attributes>
</MOI>
2. BSR record referring a non-existing Enterprise List Record will be ignored and
error will be displayed in Log_Security.log as below
ERROR: Parsing during PARTIAL SYNC UP of File:

/opt/bsrdata/BSR_DATA_DUMP.xml
****Error Record****
FDN:1
FSN:123456789900100
HNB Id:
Error Type: FDN_NOT_FOUND, for Enterprise List:
FGW=10001,EnterpriseList=1
1.1.2 Scenario 1.2: Logging of Failure Scenarios in Log_Security.log
1. All failure scenarios encountered during parsing will be logged in

Log_Security.log and parsing will be considered to be successful, specific error
records will be ignored.
2. XML validation failures are treated as file parsing errors and further processing
of the file will not happen. WMS has to fix the file and sync with FGW again.
3. Eg: Unsupported BSR action
ERROR: Parsing during PARTIAL SYNC UP of File:

/opt/bsrdata/BSR_DATA_DUMP.xml
**** Error Record ****
FDN:9
Error Type: UNSUPPORTED_ACTION, updated
1.1.3 Scenario 1.3: Modifications to Unique identity of BSR Record
1. Any modification to attributes FSN/HNB Identity/HNB UniqueIdentity will

require ‘delete’ of the existing BSR record followed by ‘updatecreate’
2. Eg:
Existing Record:
<MOI fdn="FGW=10001,BSR=102">
<Attributes>
<Attribute DataType="OCTETSTRING" Id="2" Name="serialNumber"
Value="123456789900102"/>
<Attribute DataType="DisplayString" Id="7" Name="hnbIdentity" Value=""/>
</Attributes>
</MOI>
To modify HNB Identity to above BSR Record:
<Attributes>
Value="delete"/>
</Attributes>
</MOI>
<Attributes>
<Attribute DataType="OCTETSTRING" Id="2" Name="serialNumber"
Value="123456789900102"/>
<Attribute DataType="DisplayString" Id="7" Name="hnbIdentity" Value="hnb1-
123456789900102@hcl.com"/>
</Attributes>
</MOI>
1.2 Scenario 2: How to verify & test BSR Registration Status

Pre-requisite:
2. At startup of BSG, when ‘bsrRegistrationCheckEnabled’ flag is set as ‘True’ for
enabling security hardening feature, ‘OAM_BsrDataPersistentDB.xml’ should be
available in /opt/bsrdata directory to open the SCTP connections towards BSR
for registrations. If the ‘OAM_BsrDataPersistentDB.xml’ file is not available,
download the BSR data file from FMS by executing the steps mentioned in
Scenario 1.
Scenario 1 is executed for loading the BSR Data provisioned from FMS.
1) Set the bsrRegistrationCheckEnabled flag to True via CLI for enabling the BSR
Registration functionality in the Security Hardening Feature.
2) Send BSR Registration request from BSR to BSG such that the BSR registration
data matches with the data provisioned by FMS.
3) Check BSR Registration stats using BSGConsole.
4) Run BSGConsole.exe
5) At the prompt “FMG-DBC>>” issue the command
bsg_get_bsr_registration_stats
1.3 Scenario 3: How to test Common Id check functionality of Security

Hardening
Pre-requisite: CLI, OAM and BSG should be running and ItfBsg is up.
Scenario 2 is executed to have a registered BSR at BSG.
1) Set the aclCheckEnabled flag to True via CLI for enabling the ACL check for
handling the Common Id messages functionality in the Security Hardening
Feature.
2) Start the wireshark trace
3) Establish a call from the BSR to the BSG.
4) Send a common ID message with valid IMSI. This IMSI should be present in the
BSR Data provisioned by FMS for the corresponding registered BSR. The IMSI
can be available in Normal ACL list of BSR or in Enterprise List which is used by
BSR.
5) Verify the Log_FMG.log for the successful validation of the IMSI present in the
common ID against the FMS table.
6) Verify the Log_FMG.log for the information regarding the Common ID message
is being forwarded unchanged to the BSR.
Verify the wireshark traces whether call is forwarded after successful validation
of IMSI.
1.4 Scenario 4: How to verify & test Real Time Monitoring feature
This feature has gone some modifications after MR 1744. Kindly refer Scenario 16
also for the exact functionality of RTM.
Scenario 2 is executed to have a registered BSR at BSG.
1. Invoke a ABW_MEASUREMENT cycle in BSR which should send

ABW_MEASUREMENT_PROBES and ABW_MEASUREMENT_REQUEST
2. BSG will respond to ABW_MEASUREMENT_REQUEST with
ABW_MEASUREMENT_RESPONSE
3. Check using BSGConsole
 Run BSGConsole.exe
 Under the prompt FMG-DBC >> issue the command
bsg_get_probetable_entry [bsrid] which will display the probe details for
the corresponding BSR as shown below.
Probe Details for BSR: 1
Cumulative intra measure time: 754 (ms)
No.Of Pairs: 10
----------------------------------
4. View the log file (/opt/log/FMG/Log_FMG.log) for a successful BSR
Registration
5. Sample log output when ABW_MEASUREMENT_PROBE are received is shown

below
*****************************
Received probe packet with MID: 24
PPSN: 1
PSN: 0
BSRID: 1
IPT: 75
TIME: 1251441728seconds 872678Micro Seconds
*****************************
08/28/09 06:42:08 GMT [1109494080] DEBUG ProbeHandler - RTM:

received a probe packet
08/28/09 06:42:08 GMT [1110546752] DEBUG ProbeProcessor -
*****************************
Received probe packet with MID: 24
PPSN: 1
PSN: 1
BSRID: 1
IPT: 75
TIME: 1251441728seconds 947824Micro Seconds
*****************************
08/28/09 06:42:08 GMT [1110546752] DEBUG ProbeProcessor -

***** INTRAMEASURE TIME CALCULATION *******
Even Probes time : 1251441728 Secs,872678 Micro Seconds
Odd Probes time : 1251441728 Secs,947824 Micro Seconds
Intra Measured delay 75milliseconds
******************
6. Sample log output when ABW_MEASUREMENT_REQUEST is handled.
08/28/09 06:42:20 GMT [1094756672] DEBUG bsrTrans - Req Type 0
08/28/09 06:42:20 GMT [1094756672] INFO bsrTrans - Total Intra
Measure Time : 521 Number of pairs : 7
08/28/09 06:42:20 GMT [1094756672] INFO bsrTrans -
ABW_RESPONSE: MIPT 74 ABW_RESPONSE: No.of Pairs 7
ABW_RESPONSE: BSRID 1 ABW_RESPONSE_TYPE: 1
1.5 Scenario 5: How to verify & test Online Data Synchronization in BSG
NLL File Synchronzaton:
1) Run the command “netstat –an | grep <port used for ODS>” in both active and
standby bsgs.
2) Check whether tcp connection is established between active and standby nodes
on the bonding ip addresses and port configured for ODS.
3) NLL File Synchronization: Keep the NLL file in /opt/natloc/download directory of
active bsg only.
4) Now execute the command ‘actNLL=True’ from CLI.
5) Check whether the NLL file is properly updated in the /opt/natloc/active
directory of standby bsg.
6) Check whether the updated file is used by the current active bsg after
switchover.
7) Repeat the steps 1 to 4 after switchover.
FMS-BSR Data File Synchronization:

1) Enable bsrRegistrationCheckEnabled=TRUE and aclCheckEnabled=TRUE

2) Check whether /opt/conf/OAM_BsrDataPersistentDB.txt (persistent copy of the
BSR DATA file) is synced up between active and standby nodes
3) Check whether the updated file is used by the current active bsg after
switchover when bsrRegistrationCheckEnabled=TRUE and
aclCheckEnabled=TRUE.
LR Files Synchronzaton:
1) Follow the process LR feature in BCR2_2 to Set the values for
legalReqIntervalTimer, legalReqOffset, legalReqServerAddress from CLI.
2) Once the call is executed successfully,check whether the LR temporary files are
updated in /opt/LRLog directory of standby bsg upon synchronization with
active bsg.
3) Check whether LR temporary files are deleted in /opt/LRLog directory of
standby bsg upon expiry of LR timer.
1.6 bsgsavestate script

The bsgsavestate script exists under $SCRIPTS_PATH (/opt/scripts). The purpose of
bsgsavestate script is to collect application logs, cores, to generate pstacks, pm files,
iptables, configuration files present in opt/conf/ etc.
1. The bsgsavestate script can be executed by issuing the following command in the
shell prompt
cd /opt/scripts
./bsgsavestate <Option list>
2. The option list that are passed as command line argument to the bsgsavestate
script are as below
-l => save log files, configuration data & system information
-c => save any core files present on system
-p => Generate pstacks for running processes
-g => Generate core files for running processes - run when processes
found in Stuck State. While giving –g as option, it may interrupt running processes
for short time.
-s <timestamp> => saves only files touched since <timestamp>
-e <timestamp> => saves only files touched before <timestamp>
Use both start and end timestamps to specify a range, e.g.:
bsgsavestate -s <start> -e <end> [-lcpg]
Examples of valid timestamps:
"03/22/2010 12:00"
"03/22/2010"
Note that if the time is omitted as in the third example above, it will default to
00:00:00. This means that if you want logs for only March 22, you must use the
following:
bsgsavestate -s "03/22/2010" -e "03/23/2010" –l
Example to capture logs and core files between 10am March 22 to 11:30am
March 22:
bsgsavestate -s "03/22/2010 10:00" -e "03/22/2010 11:30" –lc
Example to capture all logs and core files and generate pstacks
bsgsavestate –lcp.
Example to capture backup logs from /opt/log/appLogsBckp
bsgsavestate -s "03/22/2010" -e "03/23/2010" -l
Note that to capture backup logs, startdate and enddate must be specified. Also if you
provided same startdate and enddate, backup logs will not be captured.
1.7 Scenario 7: How to verify & test the bsrRegisterAfterInitTimer of the

Smallcells Feature
Pre-requisite:
1) CLI, OAM and BSG should be running and ItfBsg is up.
2) Scenario 10 is executed for loading the BSR Data provisioned from FMS
3) The administrative state of the ItfFgw class is unlocked to view the alarms in
trapd.
4) The attribute maxNumServiceAlarms which is the threshold for raising the
alarms related to the smallcells feature is configured through the CLI.
Verifying the bsrRegisterAfterInitTimer:
 Set the enableBSRServiceMonitoring flag to True via CLI for enabling the
smallcells feature.
 After this flag is enabled, the bsrRegisterAfterInitTimer is started.
 When the time out event of the bsrRegisterAfterInitTimer happens, the number
of unregistered Bsrs is verified.
 If the number of unregistered Bsrs is less than maxNumServiceAlarms, then
the bsrOutOfService alarm is raised for every unregistered BSR.
 If the number of unregistered Bsrs is equal to the maxNumServiceAlarms, then
the massBsrOutOfService alarm is raised.
 If the number of unregistered Bsrs is greater than maxNumServiceAlarms, then
an error is logged.
 Verify if the respective alarm is raised in the trapd.
1.8 Scenario 8: How to verify & test the bsrRegisterAfterFailureTimer of the

Smallcells Feature
Pre-requisite:
2. Scenario 10 is executed for loading the BSR Data provisioned from FMS
3. The administrative state of the ItfFgw class is unlocked to view the alarms in trapd.
4. The attribute maxNumServiceAlarms which is the threshold for raising the alarms
related to the smallcells feature is configured through the CLI
Verifying the bsrRegisterAfterFailureTimer

1) Set the enableBSRServiceMonitoring flag to True via CLI for enabling the
smallcells feature.
2) A BSR is registered with the respective BSG.
3) When this registered BSR gets de-registered due to SCTP failure or SCTP
Shutdown sent from the BSR to the BSG, the bsrRegisterAfterFailureTimer is
started.
4) When the time out of this timer happens. The number of unregistered BSRs is
checked.
5) If the number of unregistered BSRs is less than maxNumServiceAlarms, then
the bsrOutOfService alarm is raised for every unregistered BSR
6) If the number of unregistered BSRs is equal maxNumServiceAlarms, then the
massBsrOutOfService alarm is raised.
7) If the number of unregistered Bsrs is greater than maxNumServiceAlarms,
then an error is logged
8) Verify if the respective alarm is raised in the trapd
1.9 Scenario 9: How to verify and test Femto to Femto PS Handover
Pre-requisite:
FGW, 2 BSRs, CN, Presence Server
1. The presence events are received using an OAM MIM attribute “activatePresenceAPI”
which should be set to true
2. Two BSRs are required, source (BSR-1) and target (BSR-2) connected to BSG
3. BSR should be up and running and connected to CN and BSG
4. CN should be up and running and connected to BSG.
5. Presence Server should be up and running.
6. Start the Wireshark before executing the procedure for verifying the expected results
Verifying the Femto to Femto PS Handover
1. Register BSR-1 and BSR-2 with the BSG
2. Establish a PS call from BSR-1
3. Send the STRMGR_REDIRECT_REQUEST message from BSR-2 to BSG
4. Send the Incoming handover with PS RAB presence event from BSR-2 to BSG

 Issue the bsg_get_iu_connections to see the call is with the BSR-2
6. Verify the wireshark traces for

 STRMGR_REDIRECT_RESPONSE from message from BSG to BSR-2
 SIP PUBLISH-modify message from BSG to Presence Server
 Presence Event Notification – Outgoing Handover to BSR-1
 STRMGR_DATA_End-Indication message from BSG to BSR-1
7. Direct Transfer messages from CN should be directed to BSR-2.
1.10 Scenario 10 : How to test multiple PS handovers from same BSR
Pre-requisite :
FGW, 2 BSRs, CN, Presence Server
2. Two BSRs are needed, source(BSR-1) and target(BSR-2) connected to BSG
5. Presence Server should be up and running
Verifying multiple PS handovers from same BSR
2. Establish two PS calls from BSR-1
3.Send the STRMGR_REDIRECT_REQUEST message from BSR-2 to BSG for both PS and
CS calls
4.Send the Incoming handover with PS RAB presence event from BSR-2 to BSG

 Issue the bsg_get_iu_connections command to check both calls are with
BSR-2
6. Verify the wireshark traces for both PS calls

 STRMGR_REDIRECT_RESPONSE message from BSG to BSR-2
 Presence Event Notification – Outgoing Handover to BSR-1
7. Direct Transfer messages from CN should be directed to BSR-2 for both PS calls.
1.11 Scenario 11 : How to verify and test CS+PS handovers from same BSR
Pre-requisite :
2 BSRs, FGW, CN, Presence Server
2. Two BSRs are needed, source and target connected to BSG
5. Presence Server should be up and running
Verifying CS+PS handovers from same BSR
2. Establish a PS and CS call from BSR-1
3.Send the STRMGR_REDIRECT_REQUEST message from BSR-2 to BSG for both calls
4.Send the Incoming handover with CS and PS RAB presence event from BSR-2 to BSG
5.Check using BSGConsole

 Issue the bsg_get_iu_connections command to check both the calls are
with BSR-2
6.Verify the wireshark traces for
 STRMGR_REDIRECT_RESPONSE message from BSG to BSR-2
 Presence Event Notification – Outgoing Handover from BSG to BSR-1
7. Direct Transfer messages from CN should be directed to BSR-2 for both CS and PS
calls.
1.12 Scenario 12: How to configure the Dual Stack feature in BSG
1) To verify the Dual stack feature, four combinations of SS7 signaling types can be
configured in BSG as shown in the below table
S No IuCS IuPS
1 ITU ITU
2 ITU ANSI
3 ANSI ANSI
4 ANSI ITU
2) To change the family type, edit the OAM_PreConfig.xml and update the following
attribute
<MOI fdn="FGW=10001,IuCS=1">
<Attributes>
…
<Attribute DataType="Enumeration" Id="49" Name="family"
Value="iTU"/>
</Attributes>
</MOI>
<MOI fdn="FGW=10001,IuPS=1">
<Attributes>
…
<Attribute DataType="Enumeration" Id="49" Name="family"

Value="aNSI"/>
</Attributes>
</MOI>
3) After configuring the OAM_Preconfig.xml file, remove the OAM_PersistentDB.xml,
BSG_PreConfig.xml before restarting the BSG processes.
Note: Previous configurations will not be available on deleting the
OAM_PersistentDB.xml.
4) The following table shows the messages exchanged between the BSG and CN
during the handshake procedure. On successful handshake completion, Normal
call testing can be proceeded to verify the end to end call scenarios.
S No Sigtran Handshake Procedure

Layers
1 SCTP a) INIT
b) INIT-ACK
c) COOKIE-ECHO
d) COOKIE-ECHO ACK
2 M3UA a) ASP-UP
b) NTFY
c) ASP-UP ACTIVE
d) NTFY
3 SCCP a) SST
b) SSA
4 RANAP a) RESET
b) RESET-ACK
The change in the family (ITU/ANSI )can be verified from the wireshark traces by
looking into Edit->Preferences->Protocol->MTP3,here the MTP3 standard can be
changed to ITU or ANSI depending on the family type.
1.13 Scenario 13: Creating Iu instances using CLI
FGW NODE MSC 1 (OVER IP)
IPSP 1 LOCAL SCTP

END POINT 1 MSC 2 (OVER IP)
IPSP 2 LOCAL SCTP

END POINT 2
MSC 3 (OVER
ATM)
IPSP 3 LOCAL SCTP
END POINT 3
IPC MSC 4 (OVER

ATM)
IPSP 4 LOCAL SCTP
END POINT 4
SGSN 3 (OVER
LOCAL SCTP ATM)
IPSP 5
END POINT 5
SGSN 4 (OVER
IPSP 6 LOCAL SCTP
END POINT 6
ATM)
IPSP 7 LOCAL SCTP SGSN 1 (OVER

END POINT 7
IP)
IPSP 8 LOCAL SCTP

END POINT 8 SGSN 2 (OVER
IP)
Figure 1 IuFlex in mixed IP/ATM CN Environment
As indicated in the diagram above, each IPSP in BSG is linked to a local SCTP end point
and is detailed below:
1. IPSP 1 – Local SCTP End Point 1 – ipAddressCnCSCPLocal1:Port A

2. IPSP 2 – Local SCTP End Point 2 – ipAddressCnCSCPLocal2:Port B
3. IPSP 3 – Local SCTP End Point 3 – ipAddressIpcCPLocal1:Port C
BCR24_Phase0 Release Notes
4. IPSP 4 – Local SCTP End Point 4 – ipAddressIpcCPLocal2:Port D

5. IPSP 5 – Local SCTP End Point 5 – ipAddressIpcCPLocal1:Port E
6. IPSP 6 – Local SCTP End Point 6 – ipAddressIpcCPLocal2:Port F
7. IPSP 7 – Local SCTP End Point 7 – ipAddressCnPSCPLocal1:Port G
8. IPSP 8 – Local SCTP End Point 8 – ipAddressCnPSCPLocal2:Port H
Sample configuration values referenced in the use cases are listed below:
1. ipAddressCnCSCPLocal1 – 192.168.151.4
2. ipAddressCnCSCPLocal2– 192.168.168.4
3. ipAddressCnPSCPLocal1 – 192.168.157.4
4. ipAddressCnPSCPLocal2 – 192.168.169.4
5. ipAddressIpcCPLocal1 – 192.168.166.4
6. ipAddressIpcCPLocal2 – 192.168.163.4
7. Port A – 2905
8. Port B – 2905
9. Port C – 2905
10. Port D – 2905
11. Port E – 3905
12. Port F – 3905
13. Port G – 3905
14. Port H - 3905
15. MSC1 IP Adddress:Port (For 1st IPSP Reference) – 192.168.151.10:3995
16. MSC1 IP Adddress:Port (For 2nd IPSP Reference) – 192.168.168.10:3995
17. SGSN1 IP Address:Port (For 1st IPSP Reference) – 192.168.157.10:3995
18. SGSN1 IP Address:Port (For 2nd IPSP Reference) – 192.168.169.10:3995
19. IPC IP Address:Port (For 1st IPSP Reference towards MSC 3 and MSC 4) –
192.168.166.10:3995
20. IPC IP Address:Port (For 2nd IPSP Reference towards MSC 3 and MSC 4) –
192.168.163.10:3995
21. IPC IP Address:Port (For 1st IPSP Reference towards SGSN 3 and SGSN 4) –
192.168.166.10:4995
22. IPC IP Address:Port (For 2nd IPSP Reference towards SGSN 3 and SGSN 4) –
192.168.163.10:4995
Commands to create an Iu Interface through BSG CLI
Procedure to be done before creation of Iu
1. Administrative State of FGW and BSG classes should be unlocked.
Command to set Administrative state of FGW to “Unlock”

cd FGW:10001;
set {administrativeState=unlocked};
Command to set Administrative state of BSG to “Unlock”

cd BSG:1;
Creation of Iu should be preceded with creation of following classes in the specified

order:
1) Creation of SCTP Association
2) Creation of SCTPAssociationremoteSockAddress under the class SCTP

Association
3) Creation of DPCRoute
4) Creation of DPCRouterefAssociations under the class DPCRoute
For MSC 1 (Over IP)
To create SCTP Association
For any Iu interface to be operational it requires the SCTPAssociation to be created at

the transport layer. SCTP Association is a unique combination local and remote SCTP end
points. To create an SCTPAssociation in FGW, following two commands need to be
executed
1. create /FGW:80013/BSG:1/M3UA:1/SCTPAssociation:1
localSockAddressIpaddress="192.168.151.4",localSockAddressPort=2905,interfac
eReference="FGW=80013,ServerHardware=1,PhysicalInterfaceS=1",
routingContextPopOption=True};
Note 1: The above is for Sun cluster specific Incase of ATCA ie Blade Hardware Please
use the below where ever applicable
localSockAddressIpaddress="192.168.151.4",localSockAddressPort=2905,interfac
eReference="FGW=80013,BladeHardware=1,PhysicalInterfaceB=1”,
routingContextPopOption=True };
2. create
FGW:80013/BSG:1/M3UA:1/SCTPAssociation:1/SCTPAssociationremoteSockAddre
ss:1
{remoteSockAddressIpaddress="192.168.151.10",remoteSockAddressPort=3995
};
First command is to specify the details of local SCTP end point and the second one
specifies the details of remote SCTP end point.
Note 2: Mandatory Attribute “routingContextPopOption” is newly added to the creation of

SCTPAssociation. If the mandatory attribute “routingContextPopOption” value is set to
True (routingContextPopOption=True), then the routing context would be part of M3UA
messages sent through this SCTPAssociation. If the mandatory attribute
“routingContextPopOption” value is set to False (routingContextPopOption=False), then
the routing context would not be part of M3UA messages sent through this
SCTPAssociation. For 3.0.1.6 load, value of routingContextPopOption must be set to
“True” only. The actual functionality of MR 2303 would be available from 3.0.1.7 load,
but the MIM change is integrated into 3.0.1.6 for seamless upgrade from 3.0.1.6 to
3.0.1.7.
To create DPC Route Reference
DPCRoute provides routing information for an Iu interfaces by associating the Iu with an

SCTP association. DPCRoute can map multiple SCTPAssociations to an Iu interface. This
can be done by configuring multiple DPCRouterefAssociations under a DPCRoute.
Following are the list of commands used to create a DPCRoute:
1. create /FGW:80013/BSG:1/DPCRoute:1;
2. create /FGW:80013/BSG:1/DPCRoute:1/DPCRouterefAssociations:1
{refAssociationsRefAssociations="FGW=80013,BSG=1,M3UA=1,SCTPAssociation
=1"};
Minimum of 1 DPCRouterefAssociations need to be created under a DPCRoute for making

an Iu operational.
To create an Iu Interface
BSG provides connectivity from BSR cluster to multiple core network nodes which are
created using the below command.
During call origination if IuFlex is activated and the IDNNS Type received from BSR is
other than 1 and 2, Global CN id from BSR is compared with the ‘globalCnIdCnid’
attribute available in Iu class to select the core network node.
Support for configuring multiple routing context for an Iu is available, receive (local)
routing context and send (remote) routing context can be configured using the attributes
routingContext (for receive routing context) and routingContextRemote (for send routing
context) available in IuCS and IuPS MOs.
create /FGW:80013/IuCS:1
{administrativeState=unlocked,ranapRemoteSSN=142,cnMonRecoveryTmr=400,
cnMonThreshold=1,sccpReference="FGW=80013,BSG=1,SCCP=1",dpc=300,routingCont
ext=1,localPointCode=100,deloading=False,globalCnIdPlmnIdentityMcc="123",globalCnI
dPlmnIdentityMnc="45",globalCnIdCnid=2,ranapTimerInConnGuard=2000,family=iTU,ro
utingContextRemote=1, iuTransportType= sS7OverIP};
To Create IPSP Reference

The (IuCS/IuPS)iPSPReference class specifies the SIGTRAN layer details of an Iu by
mapping an Iu to an IPSP and a DPCRoute at M3UA and SCTP layers respectively.
1.create/FGW:80013/IuCS:1/IuCSiPSPReference:1
{iPSPReferenceIPSPReference="FGW=80013,BSG=1,M3UA=1,IPSP=1",iPSPReferenceDp
cRoute="FGW=80013,BSG=1,DPCRoute=1”};
Note: SIGTRAN based /ATM based IuCS/IuPS interface differentiation can only be done
based on the interfaceReference attribute used in the SCTPAssocication used by that
particular Iu interface.
NOTE: stopbsg/startbsg is required incase IuCS/IuPS MO is recreated with different

localPointCode attribute
For SGSN 1 (Over IP)

{localSockAddressIpaddress="192.168.157.4",localSockAddressPort=3905,interfa
ceReference="FGW=80013,ServerHardware=1,PhysicalInterfaceS=7”,routingCont
extPopOption=True};
2. create
/FGW:80013/BSG:1/M3UA:1/SCTPAssociation:7/SCTPAssociationremoteSockAddr
ess:1
};

=7"};
1. create /FGW:80013/IuPS:1
cnMonThreshold=1,sccpReference="FGW=80013,BSG=1,SCCP=1",dpc=400,routi
ngContext=2,localPointCode=200,deloading=False,globalCnIdPlmnIdentityMcc="
123",globalCnIdPlmnIdentityMnc="45",globalCnIdCnid=2,ranapTimerInConnGuar
d=2000,family=iTU,routingContextRemote=2, iuTransportType= sS7OverIP };
2.

1.create/FGW:80013/IuPS:1/IuPSiPSPReference:1
NOTE: stopbsg/startbsg is required incase IuCS/IuPS MO is recreated with different

localPointCode attribute
MSC 3(Over ATM- via IPC)

ceReference="FGW=80013,ServerHardware=1,PhysicalInterfaceS=16",
2. create
ess:1
};

=3"};
1. create /FGW:80013/IuCS:3

1.create/FGW:80013/IuCS:3/IuCSiPSPReference:1
SGSN 3(Over ATM- via IPC)

1. create /FGW:80013/BSG:1/M3UA:1/SCTPAssociation: 5
ceReference="FGW=80013,ServerHardware=1,PhysicalInterfaceS=16",
2. create
ess:1
};

=5"};
1. create /FGW:80013/IuPS:3

1. create /FGW:80013/IuPS:3/IuPSiPSPReference:1
{iPSPReferenceIPSPReference="FGW=80013,BSG=1,M3UA=1,IPSP=5",iPSPRefer
enceDpcRoute="FGW=80013,BSG=1,DPCRoute=5”};
Commands to create 2 IPSP’s for an Iu Interface through BSG CLI:
When testing with 2 IPSP’s, the traffic mode in BSG and CN Simulator’s (in
CNTT_SIGTRANConf.xml) must be configured to loadShareMode and loadSharemode
Type should be configured as SLS.
MSC1 ( IPSPs 1 and 2):
1. Creation of 1st SCTP Association:

create /FGW:80013/BSG:1/M3UA:1/SCTPAssociation:1
{localSockAddressIpaddress="192.168.151.4",localSockAddressPort=2905,interfaceRefe
rence="FGW=80013,ServerHardware=1,PhysicalInterfaceS=1”,
create
/FGW:80013/BSG:1/M3UA:1/SCTPAssociation:1/SCTPAssociationremoteSockAddress:1
{remoteSockAddressIpaddress="192.168.151.10",remoteSockAddressPort=3995};
2. Creation of 2nd SCTP association:

rence="FGW=80013,ServerHardware=1,PhysicalInterfaceS=18",
create
3. Creation of 1st DPCRoute

create /FGW:80013/BSG:1/DPCRoute:1;
create /FGW:80013/BSG:1/DPCRoute:1/DPCRouterefAssociations:1
{refAssociationsRefAssociations="FGW=80013,BSG=1,M3UA=1,SCTPAssociation=1"};
4. Creation of 2nd DPCRoute

5. Creation of Iu
create /FGW:80013/IuCS:1
cnMonThreshold=1,sccpReference="FGW=80013,BSG=1,SCCP=1",dpc=300,routingCont
ext=3,localPointCode=100,deloading=False,globalCnIdPlmnIdentityMcc="123",globalCnI
dPlmnIdentityMnc="45",globalCnIdCnid=2,ranapTimerInConnGuard=2000,family=iTU,ro
utingContextRemote=4, iuTransportType= sS7OverIP };
6.Creation of IPSPs
create /FGW:80013/IuCS:1/IuCSiPSPReference:1
create /FGW:80013/IuCS:1/IuCSiPSPReference:2
Commands to create Multiple DPCRouteRefAssociations for a DPC Route:
MSC 3:
1. Creation of 1st SCTP Association
rence="FGW=80013,ServerHardware=1,PhysicalInterfaceS=16"
,routingContextPopOption=True};
create
2. Creation of DPCRoute
3.Creation of Iu Interface
1. create /FGW:80013/IuCS:2
cnMonThreshold=1,sccpReference="FGW=80013,BSG=1,SCCP=1",dpc=300,routingC
ontext=4,localPointCode=100,deloading=False,globalCnIdPlmnIdentityMcc="123",glo
balCnIdPlmnIdentityMnc="45",globalCnIdCnid=2,ranapTimerInConnGuard=2000,fam
ily=iTU,routingContextRemote=7, iuTransportType= sS7OverIP };
4.Creation of IPSP reference

Create /FGW:80013/IuCS:2/IuCSiPSPReference:1
5.Creation of 2nd SCTPAssociation

Create /FGW:80013/BSG:1/M3UA:1/SCTPAssociation:9
rence="FGW=80013,ServerHardware=1,PhysicalInterfaceS=16",
create
6.Creation of 2nd DPCRouteRef Association

Create /FGW:80013/BSG:1/DPCRoute:3/DPCRouterefAssociations:2
Commands for Creating 2nd IPSP Reference for already existing Iu Interfaces
SGSN4:
1.Create 2nd SCTP Association
Create /FGW:80013/BSG:1/M3UA:1/SCTPAssociation:11
rence="FGW=80013,ServerHardware=1,PhysicalInterfaceS=13"
,routingContextPopOption=True};
create
2.Create 2nd DPCRoute
3.Create 2nd IPSPRefrence
Create /FGW:80013/IuPS:4/IuPSiPSPReference:2
For SIGTRAN based MSCs, interface reference can have the following values
interfaceReference="FGW=10001,ServerHardware=1,PhysicalInterfaceS=1" – This maps

to the vlan CnCSCPLocal1
interfaceReference="FGW=10001,ServerHardware=1,PhysicalInterfaceS=18" – This
maps to the vlan CnCSCPLocal2
For SIGTRAN based SGSNs, interface reference can have the following values
interfaceReference="FGW=10001,ServerHardware=1,PhysicalInterfaceS=7" – This maps

to the vlan CnPSCPLocal1
maps to the vlan CnPSCPLocal2
For ATM based MSCs/SGSNs, interface reference can have the following values
maps to the vlan IpcCPLocal1
maps to the vlan IpcCPLocal2
ATM based MSCs/SGSNs use the same vlans IpcCPLocal1 and IpcCPLocal2 but they are
differentiated by means of IPSPs i.e IuCS and IuPS interface created towards an IPC
would use unique SCTP end points during Iu creation.
1.14 Scenario14: IuFlex – Commands to create Regions
To support multiple Core Network connections, Regions are created.

Each region has an associated set of Iu Interfaces. The nriMaskSize attribute of region is
used to derive the NRI value when call is initiated from BSR to which the region is
mapped.
Command to create Region for CS Domain:

 create /FGW:10001/BSG:1/CsRegion:1 {nriMaskSize=3};
Command to create Region for PS Domain:

 create /FGW:10001/BSG:1/PsRegion:1 {nriMaskSize=2};
1.15 Scenario15: IuFlex – Commands to create CsRegionnriToCnNodeCS
CsRegionnriToCnNodeCS is a sub-class of CsRegion. This class links the core network

node MSC to region using the NRI value specified in the attribute ‘nriToCnNodeCSNri’
and the MSC node specified in attribute ‘nriToCnNodeCSCnNode’.
The NRI value received from BSR during call origination is compared with the value of
‘nriToCnNodeCSNri’ to connect to the corresponding MSC node available in the region.
The ‘nriToCnNodeCSWeight’ attribute is used to select the available interface in the

region during load sharing process. During call origination when NRI value received from
BSR is not matched with any of the network nodes available in the region, the current
interface available in load sharing list is selected if the value of the corresponding
interface’s ‘nriToCnNodeCSWeight’ is not zero.
IuCS interface should be created ahead to include its reference in this class.
Command to create CsRegionnriToCnNodeCS:
 create /FGW:10001/BSG:1/CsRegion:1/CsRegionnriToCnNodeCS:1
{nriToCnNodeCSNri=1,nriToCnNodeCSWeight=7,nriToCnNodeCSCnNode="FGW=
10001,IuCS=1"};
1.16 Scenario16: IuFlex – Commands to create PsRegionnriToCnNodePS
PsRegionnriToCnNodePS is a sub-class of PsRegion. This class links the core network

node SGSN to region using the NRI value specified in the attribute ‘nriToCnNodePSNri’
and the SGSN node specified in attribute ‘nriToCnNodePSCnNode’.
The NRI value received from BSR during call origination is compared with the value of
‘nriToCnNodePSNri’ to connect to the corresponding SGSN node available in the region.
The ‘nriToCnNodePSWeight’ attribute is used to select the available interface in the

region during load sharing process. During call origination when NRI value received from
BSR is not matched with any of the network nodes available in the region, the current
interface available in load sharing list is selected if the value of the corresponding
interface’s ‘nriToCnNodePSWeight’ is not zero.
IuPS interface should be created ahead to include its reference in this class.
Command to create PsRegionnriToCnNodePS:
 create /FGW:10001/BSG:1/PsRegion:1/PsRegionnriToCnNodePS:1
{nriToCnNodePSNri=1,nriToCnNodePSWeight=5,nriToCnNodePSCnNode="FGW=1
0001,IuPS=1"};
1.17 Scenario17: IuFlex – Commands to create BSGlaiToCsRegion
This class provides mapping from LAC and PLMN ID to a Region of CS domain. During
call origination, the combination of LAC and PLMN ID received from BSR is compared
with the combination of values available in the attributes ‘laiToCsRegionLac’,
‘laiToCsRegionPlmnIdentityMcc’, ‘laiToCsRegionPlmnIdentityMnc’ and the corresponding
region is selected to identify the associated core network node for communication. If
there is no mapped region, default region if configured is used for selecting the interface.
CsRegion class should be created ahead to include its reference in this class.
Command to create BSGlaiToCsRegion:
 create /FGW:10001/BSG:1/BSGlaiToCsRegion:1
{laiToCsRegionLac=11,laiToCsRegionPlmnIdentityMcc="123",laiToCsRegionPlmnI
dentityMnc="45",laiToCsRegionRegion="FGW=10001,BSG=1,CsRegion=1"};
1.18 Scenario18: IuFlex – Commands to create BSGraiToPsRegion
This class provides mapping from LAC, RAC and PLMN ID to a Region of PS domain.
During call origination, the combination of LAC, RAC and PLMN ID received from BSR is
compared with the combination of values available in the attributes ‘raiToPsRegionLac’,
‘raiToPsRegionRac’, ‘raiToPsRegionPlmnIdentityMcc’, ‘raiToPsRegionPlmnIdentityMnc’ and
the corresponding region is selected to identify the associated core network node for
communication. If there is no mapped region, default region if configured is used for
selecting the interface. PsRegion class should be created ahead to include its reference in
this class.
Command to create BSGraiToPsRegion:
 create /FGW:10001/BSG:1/BSGraiToPsRegion:1
{raiToPsRegionLac=14,raiToPsRegionRac=11,raiToPsRegionPlmnIdentityMcc="12
3",raiToPsRegionPlmnIdentityMnc="55",raiToPsRegionRegion="FGW=10001,BSG
=1,PsRegion=1"};
1.19 Scenario 19: Activation of IuFlex
To add multiple interfaces (Iu) per domain, IuFlex feature should be enabled per domain.
The attributes ‘activateIuFlexCS/ activateIuFlexPS’ available in FGW class should be set
to True as per the domain.
Command to activate IuFlex for CS domain:

 cd /FGW:10001;
 set {activateIuFlexCS=True};
Note: Before activating IuFlex, if an IuCS is available create CSRegion,

CsRegionnriToCnNodeCS and map the LAC, PLMNID of BSR in the BSGlaiToCsRegion to
region in order to maintain the call processing using the existing IuCS interface.
After activating IuFlex, to add multiple interfaces, either add a new region and update
the MSC node details or add the MSC node reference to the CsRegionnriToCnNodeCS
class available in the existing region. Create BSGlaiToCsRegion to map the LAC and
PLMNID to region.
Command to activate IuFlex for PS domain:

 cd /FGW:10001;
 set {activateIuFlexPS=True};
Note: Before activating IuFlex, if an IuPS is available create PSRegion,

PsRegionnriToCnNodePS and map the LAC, RAC, PLMNID of BSR in the
BSGraiToPsRegion to region in order to maintain the call processing using the existing
IuPS interface.
After activating IuFlex, to add multiple interfaces, either add a new region and update
the SGSN node details or add the SGSN node reference to the PsRegionnriToCnNodePS
class available in the existing region. Create BSGraiToPsRegion to map the LAC, RAC and
PLMNID to region.
Note: In IuFlex Enabled scenario Once IuCS/PS class is deleted and then created , the
nriToCnNodeCSCnNode or nriToCnNodePSCnNode attribute needs to be set
again in class CsRegionnriToCnNodeCS or PsRegionnriToCnNodePS. Then only Iu will be
available for the Particular region(LSL/EIL). Please see the below details
CLI >> cd CsRegionnriToCnNodeCS:1;

Waiting for OAM response ...
CD command response from OAM:cd COMMAND SUCCESS
CLI >> get;

Get command response from OAM:
nriToCnNodeCSCnNode="FGW=80013,IuCS=1"
nriToCnNodeCSId=1
nriToCnNodeCSNri=1
nriToCnNodeCSWeight=7
CLI >> delete IuCS:1;

Delete command response from OAM: DELETE COMMAND SUCCESS
Iu is not set in this region as Iu was deleted
CLI >> get CsRegionnriToCnNodeCS:1;

nriToCnNodeCSCnNode=""
nriToCnNodeCSId=1
nriToCnNodeCSNri=1
CLI >> create IuCS=1; and create IuCSiPSPReference class;

nriToCnNodeCSCnNode=" "
nriToCnNodeCSId=1
nriToCnNodeCSNri=1
CLI >> set {nriToCnNodeCSCnNode="FGW=80013,IuCS=1"};

Set command response from OAM: SET COMMAND SUCCESS
Iu is set in this region after explicitly setting using above set command

nriToCnNodeCSCnNode="FGW=80013,IuCS=1" nriToCnNodeCSId=1
nriToCnNodeCSNri=1
NOTE: If IuCS/IuPS is deleted, and then without deleting corresponding CsRegionnriToCnNodeCS/

PsRegionnriToCnNodePS, and a stop & start of FGW processes are done, then you will be seeing an
IuCS/IuPS instance of 0 in the PM files.
So it is advised that if IuCS/IuPS MO is deleted, also delete the corresponding
CsRegionnriToCnNodeCS/ PsRegionnriToCnNodePS
1.20 Scenario 20: Making use of an IPSP to support multiple network traffic
1.21 Scenario 20: Making use of an IPSP to support multiple network traffic
The nwkAppIncl flag, nwkAppForITU, nwkAppForANSI5Bit, nwkAppForANSI8Bit
parameters are required to make an IPSP operational in multiple families.
The nwkAppForITU, nwkAppForANSI5Bit, nwkAppForANSI8Bit values should be modified
through CLI only when IPSP is not referenced in any Iu’s created under the respective
networks. For eg:- The nwkAppForITU can be set only when the IPSP is not referenced
in any ITU Iu. The nwkAppForANSI5Bit, nwkAppForANSI8Bit can be set only when the
IPSP is not referenced in any ANSI Iu.
If the attribute aNSISlsLength of M3UA class value is Sls5, ANSI Iu will use the
nwkAppForANSI5Bit value as network appearance.
If the attribute aNSISlsLength of M3UA class value is Sls8, ANSI Iu will use the
nwkAppForANSI8Bit value as network appearance.
Case 1:
If an IPSP is not referenced in any Iu and the IPSP is going to support two different
families, then nwkAppIncl flag can be set to True.
Network appearance value is taken from the following,
 If the family is ITU, then the value will be taken from nwkAppForITU.
 If the family is ANSI, then the value will be taken from either
nwkAppForANSI5Bit or nwkAppForANSI8Bit depends on the
aNSISlsLength of M3UA class.
For example, IPSP:1 is going to support one ITU and ANSI family Iu’s using the following
commands,
 cd /FGW:10001/BSG:1/M3UA:1/IPSP:1;
 set {nwkAppIncl=True};
 Create one ITU CS/PS Iu.
 Create one ANSI CS/PS Iu.
Case 2:
If an IPSP is already referenced in an Iu and the IPSP is going to support two different
families, then nwkAppIncl flag is set to True.
 If the currently supported family is ITU and it is going to support ANSI
family then the network appearance value will be taken from either
nwkAppForANSI5Bit or nwkAppForANSI8Bit depends on the
aNSISlsLength of M3UA class.
 If the currently supported family is ANSI and it is going to support ITU
family then the network appearance value will be taken from
nwkAppForITU.
For example, IPSP:1 is supporting ITU family and is going to support ANSI family Iu’s
using the following commands,
 Create one ITU CS/PS Iu.

 set {nwkAppIncl=True};
 Create one ANSI CS/PS Iu.
Case 3:
The NwkAppIncl flag can be set from True to false in following conditions,
 If the IPSP is referenced in only one family (ITU/ANSI) Iu
 If the IPSP is already referenced in multiple family Ius, then the Iu(s)
belonging to one family must be deleted for operating that IPSP
without network appearance attribute.
For example, IPSP:1 is referenced in ITU and ANSI family Ius. Now the IPSP:1 is used to
reference to only ANSI family using the following commands,
 Create one ITU and ANSI CS/PS Iu

 delete ITU CS/PS Iu
 set {nwkAppIncl=False};
Note:
1. NetworkAppIncl flag state change as follows,
S No Current New Description

value Value
1 False False No Action
2 False True IPSP is ready to

support multiple
families
3 True False IPSP can support only

single family
4 True True No Action
1.22 Scenario 21: How to Delete an Iu Interface
As per the double exchange behaviour, specified by both the M3UA RFCs(3332 ,
4666), a link can be taken down (or deleted) only when it’s made INACTIVE from
both the directions. So, to ensure that Iu link is deleted completely, operator must
ensure its deleted at both ends (BSG and IPC/CN) or delete the corresponding SCTP
Association at FGW side. In case if an Iu link is deleted only at one end and the
corresponding SCTP Association is not deleted, then operator should not try to add
that link again as it’s not completely deleted. If an attempt is made to add a link that
is not completely deleted, then it would result in error.
Double exchange:
IPSP-A IPSP-B
| |
|<-------------ASP Up------------|
|-----------ASP Up Ack---------->|
| |
|-------------ASP Up------------>| (optional)
|<----------ASP Up Ack-----------| (optional)
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
|------- ASP Active(RCa)-------->| RC: Routing Context
|<-----ASP Active Ack (RCa)------| (optional)
| |
|<========= DATA (RCa) =========|
|========== DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->|
| |
|------ASP Inactive (RCa)------->| RC: Routing Context
|<----ASP Inactive Ack (RCa)-----|
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
|------------ASP Down----------->| (optional)
|<--------ASP Down Ack-----------| (optional)
| |
For deleting an Iu Interface use the following steps in order,

1. Delete the corresponding Iu Interface in IPC.
2. Delete the Iu Interface in FGW using the following commands,
cd /FGW:10001;
delete IuCS:1;
3. Follow the same procedure for deleting an IPSP Reference corresponding to one
of the VLANs in the Iu which has Dual VLAN Support. Command for deleting single
VLAN IPSP Reference is as follows,
delete /FGW:10001/IuCS:1/IuCSiPSPReference:1;
4. If Iu interface is not deleted from remote end, delete the corresponding SCTP
Assocication in FGW using the following commands,
delete /FGW:10001/BSG:1/DPCRoute:1;
delete /FGW:10001/BSG:1/M3UA:1/SCTPAssociation:1;
Note: Follow the same procedure for deleting IuPS interface also.
1.23 Scenario 22: Creating Manual Presence & HO instances using CLI
To create an Presence instance

Note: Sample values for DN - “FGW:80013” and IP Addresses must be replaced with
actual values in the target setup.
1. create /FGW:80013/BSG:1/Presence:1
{presenceServer="sip:192.168.156.40",uEType=authorisedUEs,psserverHeartbea
tTime=3,sipHeaderExpiresTimer=3600,operatorDomain="192.168.156.40",sIPTi
merT1=rTT500,sIPTimerT2=limit4000,sIPTimerT4=5,sipOptions=True};
2. create /FGW:80013/BSG:1/Presence:1/PresenceeventMapping:1
{eventMappingId=1,eventMappingBsrEvent=uEPresent,eventMappingStandardEv
ent="unknown"};
{eventMappingId=2,eventMappingBsrEvent=incomingHandoverWithCSRAB,event
MappingStandardEvent="on-the-phone"};
{eventMappingId=3,eventMappingBsrEvent=cSRABSetup,eventMappingStandard
Event="on-the-phone"};
{eventMappingId=4,eventMappingBsrEvent=cSRABRelease,eventMappingStandar
dEvent="unknown"};
{eventMappingId=5,eventMappingBsrEvent=outgoingHandover,eventMappingSta
ndardEvent="unknown"};
{eventMappingId=6,eventMappingBsrEvent=detach,eventMappingStandardEvent
="unknown"};
{eventMappingId=7,eventMappingBsrEvent=uELost,eventMappingStandardEvent
="unknown"};
{eventMappingId=8,eventMappingBsrEvent=unAuthorisedUE,eventMappingStand
ardEvent="unknown"};

{eventMappingId=9,eventMappingBsrEvent=transientUE,eventMappingStandardE
vent="unknown"};

{eventMappingId=10,eventMappingBsrEvent=expiry,eventMappingStandardEvent
="unknown"};

{eventMappingId=11,eventMappingBsrEvent=refresh,eventMappingStandardEven
t="unknown"};

{eventMappingId=12,eventMappingBsrEvent=incomingHandoverWithPSRAB,even
tMappingStandardEvent="unknown"};

{eventMappingId=13,eventMappingBsrEvent=incomingHandoverWithCSRABandP
SRAB,eventMappingStandardEvent="unknown"};
Note: To enable presence feature, proper value to BSG::ipAddressPresenceLocal is
mandatory. Its default value is “0.0.0.0” . This attribute cannot be set through CLI. For
changing the value,perform upload db, edit the xml for proper value and then trigger
download db. If default value exists for ipAddressPresenceLocal and presence feature is
enabled, BSG.exe and other exe’s will not come up
Note: After executing the above steps the Presence feature shall be enabled by setting
the activatePresenceAPI as True
To create an HO instance
Note: Sample value for DN - “FGW:80013” must be replaced with actual value in the
target setup.
1. create /FGW:80013/BSG:1/BSGbsrPSCforBasicCellId:1
{bsrPSCforBasicCellIdId=1,bsrPSCforBasicCellIdIndex=1,bsrPSCforBasicCellIdPsc
=350};
2. create /FGW:80013/BSG:1/BSGbsrPSCforBasicCellId:2
{bsrPSCforBasicCellIdId=2,bsrPSCforBasicCellIdIndex=2,bsrPSCforBasicCellIdPsc
=450};
3. create /FGW:80013/BSG:1/BSGbsrPSCforVirtEnhCellId:1
{bsrPSCforVirtEnhCellIdId=1,bsrPSCforVirtEnhCellIdIndex=1,bsrPSCforVirtEnhCel
lIdPsc=350,bsrPSCforVirtEnhCellIdType=closedAccess};
4. create /FGW:80013/BSG:1/BSGgsmMacroCellId:1
{gsmMacroCellIdId=1,gsmMacroCellIdBit1=bsrPSCIDbit,gsmMacroCellIdBit2=bsr
PSCIDbit,gsmMacroCellIdBit3=virtualCellIDbit,gsmMacroCellIdBit4=virtualCellIDbi
t,gsmMacroCellIdBit5=virtualCellIDbit,gsmMacroCellIdBit6=virtualCellIDbit,gsmM
acroCellIdBit7=virtualCellIDbit,gsmMacroCellIdBit8=virtualCellIDbit,gsmMacroCell
IdBit9=virtualCellIDbit,gsmMacroCellIdBit10=virtualCellIDbit,gsmMacroCellIdBit1
1=virtualCellIDbit,gsmMacroCellIdBit12=virtualCellIDbit,gsmMacroCellIdBit13=vir
tualCellIDbit,gsmMacroCellIdBit14=virtualCellIDbit,gsmMacroCellIdBit15=virtualC
ellIDbit,gsmMacroCellIdBit16=virtualCellIDbit};
5. create /FGW:80013/BSG:1/BSGumtsMacroCellId:1
{umtsMacroCellIdBit1=bsrPSCIDbit,umtsMacroCellIdBit2=bsrPSCIDbit,umtsMacro
CellIdBit3=virtualCellIDbit,umtsMacroCellIdBit4=virtualCellIDbit,umtsMacroCellId
Bit5=virtualCellIDbit,umtsMacroCellIdBit6=virtualCellIDbit,umtsMacroCellIdBit7=
virtualCellIDbit,umtsMacroCellIdBit8=virtualCellIDbit,umtsMacroCellIdBit9=virtual
CellIDbit,umtsMacroCellIdBit10=virtualCellIDbit,umtsMacroCellIdBit11=virtualCell
IDbit,umtsMacroCellIdBit12=virtualCellIDbit,umtsMacroCellIdBit13=virtualCellIDb
it,umtsMacroCellIdBit14=virtualCellIDbit,umtsMacroCellIdBit15=virtualCellIDbit,u
mtsMacroCellIdBit16=virtualCellIDbit,umtsMacroCellIdId=1};
6. create /FGW:80013/BSG:1/BSGgsmMacroFrequency:1
{gsmMacroFrequencyBCCHARFCN=1023,gsmMacroFrequencyBandIndicator=gSM
900,gsmMacroFrequencyId=1,gsmMacroFrequencyIndex=1};
7. create /FGW:80013/BSG:1/BSGumtsMacroFrequency:1
{umtsMacroFrequencyARFCN=1023,umtsMacroFrequencyId=1,umtsMacroFreque
ncyIndex=1};
8. For enhanced mode, create BSGgsmMacroFrequency or BSGumtsMacroFrequency

class for GSM or UMTS mode respectively and then create other required M2FHO
classes.
1.24 Scenario 23 : How to test Dual Band Femto
1. Configure the BSG to apply the target BSR selection method “Enhanced Cell Id” for
incoming GSM/UMTS handover.
2. Register a BSR with 6 GSM/UMTS Virtual Cell Ids and 6 GSM/UMTS Macro cells
3. After registering, check the following in the BSGConsole for

bsg_get_bsr_registrations.
i) The BSR should get registered with 6 GSM/UMTS Virtual Cell Ids and 6
GSM/Macro Cells.
ii) BSG should create 6 GSM/UMTS C-IDs for the registered BSR.
1.25 Scenario 24 : How to test MR 1744
Case 1:
1. Send Probe Messages from FemtoBSR to BSG.
2. Change the Measurement Id in the Probe Message and send it from FemtoBsr.
3. On receiving the Probe Message with change in Measurement Id, BSG has to send
Probe Measurement Response to FemtoBsr.
Case 2:
1. Send a Probe Measurement Request Message from FemtoBsr to BSG.

2. BSG should not send a Probe Measurement Response to the FemtoBsr.
1.26 Scenario 25: How to Test MR 1998
1. Start Active / Standby BSG.
2. Check that the alarms are entered in the newly created HFL file of Active though the
FMS is connected or not.
3. Unlock the adminstrativeState of class ItfFgw to check alarms at FMS.
4. Connect to FMS and cross check whether the alarms in HFL file are trapped at FMS.
1.27 Scenario 26: How to Test paresepmfile script
1. To see the option for parsepmfiles.pl script , type the below command
Perl parsepmfiles.pl –h
2. To see CS & PS Call and RANAP Counters, run the script as mentioned below:
Perl parsepmfiles.pl option InstanecName (This will parse all the pm files present
under /var/pm).
Perl parsepmfiles.pl option InstanecName /var/pm/pmfilename(This will parse

only the given pm files present under /var/pm).
Option:
For CS Call –cs
For PS Call –ps

For Ranap CS Call –rcs
For Ranap PS Call –rps
For example:
To run paresepmfiles.pl script for CS Call :
Perl pasrepmfiles.pl –cs 1
Here –cs is the option for CS Call

1 is the InstanceName like IuCS=1 or IuPS=1
Note: The output of the script will be displayed in the console as well as stored in
a csv file with a name option_IuCS=InstanceName.csv(For CS Call and RANAP CS
Call) and option_IuPS=InstanceName.csv(For PS Call and RANAP PS Call) like for
the above example the filename will be cs_IuCS=1.csv.
3. To run the script for other options
Perl parsepmfiles.pl option (This will parse all the pm files present under
/var/pm).
Perl parsepmfiles.pl option /var/pm/pmfilename (This will parse only the given
pm files present under /var/pm).
Option:
For m3ua –m
For sccp –s
For Core Processor Occupancy and System Memory –p
For example:
To run paresepmfiles.pl script for m3ua:
Perl pasrepmfiles.pl –m
Suppose in case the operator donot provide any option, then BSG Registration
information will be displayed.
For example:
To run paresepmfiles.pl script for BSG Registration information:
Perl pasrepmfiles.pl
Note: The output of the script will be displayed in the console only.
1.28 Scenario 27 : How to test AIOG
 To Configure AIOG with BVG exception UDP Port list

Configure Btg_config.ini file with exception port list info, so that these ports are
not monitored by BVG mentioned as below.
The ports are comma separated.
Port 5060 is used by presence and 9898 is used by BTG for handling dpat
request. Hence these mandatory ports are configured by default.
[BVG Configuration]
BVG_EXCEPTIONPORT_LIST = 5060,9898
Sample scenario:
1. Start BTG
2. Send the sip related packets.
3. Verify that the sip packets received by presence sip subsystem
4. Also, verify no BVG alarms are raised for the sip packets
 Pre-requisite: FGWMon/BSG/OAM and CLI should be up and running.

BVG or BPG instance and its child class should be present to run AIOG.
BVG, BPG MO classes can be created manually.
The virtualRncAddressesMsc1IpAddress and virtualRncAddressesMsc2IpAddress

attributes specifies the possible set of FGW’s IuCS User Plane IP addresses towards
the MSC(s). MSC(s) use these as the destination IP addresses for downlink packets.
The value should be from the Interface class with interfaceType=”cnCSUP1” or
”cnCSUP2” respectively.
The virtualRncAddressesIpc1IpAddress and virtualRncAddressesIpc2IpAddress

attributes specifies the possible set of FGW’s IuCS User Plane IP addresses towards
the IPC(s). IPC(s) use these as the destination IP addresses for downlink packets.
The BVG selects one of these addresses for each connection .
Command to create BVG MO:
 cd FGW:<DN>;
 create BVG:1 { amrFrameConcatTimer= FortyMs};
 create BVG:1/BVGvirtualRncAddressesMsc1:1
{virtualRncAddressesMsc1Id=1,virtualRncAddressesMscIpAddress="10.100.12.18
5"};
(OR)
 create BVG:1/BVGvirtualRncAddressesIpc1:1
{virtualRncAddressesIpc1Id=1,virtualRncAddressesIpcIpAddress="10.100.12.185
"};
Note: As child class for BVG either BVGvirtualRncAddressesIpc or

BVGvirtualRncAddressesMsc should be created, but not both
The gtpuEchoPeriod attribute of BPG is used to send GTP-U Echo requests once
every gtpuEchoPeriod. This is a mandatory attribute for creating BPG instance.
Command to create BPG MO:

 cd FGW:<DN>;
 create BPG:1 {gtpuEchoPeriod=60};
 create BPG:1/BPGvirtualRncAddresses1:1
{virtualRncAddresses1Id=1,virtualRncAddresses1IpAddress="10.100.12.185"};
The virtualRncAddresses1IpAddress and virtualRncAddresses2IpAddress attributes

specifies the possible set of FGW’s IuPS User Plane IP addresses towards the
SGSN(s). SGSN(s) use these as the destination IP addresses for downlink packets.
The value be from Interface class with interfaceType=”cnPSUP1” and
”cnPSUP2” respectively.
Once BVG and its child class (or BPG and its child class) created successfully then OAM
requests FGWMON to start BTG application. So BTG application started automatically.
To make a success CS/PS calls the BVG/BPG class should be unlocked.
 set BVG:1 {administrativeState=unlocked};

 set BPG:1 {administrativeState=unlocked};
1.29 Scenario 28 : Creating Manual SecurityGateway/AAARemoteAAServer

Instances using CLI
Pre-requisite: AAA executable will come up only if at least one SecurityGateway class
instance is present.
To create an SecurityGateway instance

 create SecurityGateway:1 {addressLeaseTime=45000,
calledStationId="10.10.12.80/30",defaultSeGW=False,femtoVPNSubnets="10.10
0.12.18/30",id=1,nasnasIdentifier="1001",nasIpAddress="10.100.12.238",nasPo
rts="1000",reservedAddressSubnets="10.110.16.12/30"};
Note: Do not give space between attributes.
To set an SecurityGateway instance

 set SecurityGateway:1 {addressLeaseTime=45,
calledStationId="100.10.12.80/30",defaultSeGW=False,femtoVPNSubnets="100.
100.12.18/30",nasnasIdentifier="1001",nasIpAddress="10.100.12.238",nasPorts
="1000"};
To delete an SecurityGateway instance

 delete SecurityGateway:1;
To create an AAAremoteAAAServer instance

 create AAAremoteAAAServer:1 {remoteAAAServerId=1,
remoteAAAServerIpAddress="10.100.12.238",
remoteAAAServerRealm="ds2460",remoteAAAServerSharedSecret="testing123"}
;
To set an AAAremoteAAAServer instance

 set AAAremoteAAAServer:1 {remoteAAAServerId=1,
remoteAAAServerIpAddress="10.100.12.238",
remoteAAAServerRealm="ds2460",remoteAAAServerSharedSecret="testing123"}
;
To delete an AAAremoteAAAServer instance

 delete AAAremoteAAAServer:1;
1.30 Scenario 29 : How to verify HNB/BSR registration info through

BSGConsole
Pre-requisite: CLI, OAM and BSG should be running and ItfBsg is up and HNB/BSR
should be registered with BSG.
 Upon successful registration of HNB/BSR, Run the BSGConsole.exe and give the
following command,
 FMG-DBC >> bsg_get_bsr_registrations
This command will print the entire table
 FMG-DBC >> bsg_get_bsr_registrations [<BSR-id>]
eg : bsg_get_bsr_registrations 10
This will print the particular entry of BSR/HNB registration info pertaining to the
HNB/BSR having id 10
1.31 Scenario 30 : How to verify SecGW, VPNIP and Remote Server info in
AAAConsole
Pre-requisite:
 CLI, OAM and AAA should be running
 Ensure AAAConsole executable is placed in /opt/bin/
 AAAConsole uses the configuration present in /opt/conf/AAA_config.ini
 Ensure AAAConsole session window is first maximized before starting it
 Run the AAAConsole.exe and give enter until view the session
 Choose one of the options displayed below:

1 Query VPN IP Status - All SecGWs 2 Query VPN IP Status - Selected SGW
3 Query VPN IP Status - Selected VPN IP 4 Query PM Counter values
5 Query All BSR-ID Info 6 Query All Remote-AAA Info
7 Exit
Description of each option is specified below:
 Option 1 - Query VPN IP Status - All SecGWs: Display all the security
Gateway details.
 Option 2 - Query VPN IP Status – Selected SGW : When this option is chosen
the following user is prompted for the following details
Enter the security gateway id :
Provide the Nas ID to display the specific Security Gateway details
 Option 3 - Query VPN IP Status - Selected VPN IP: When this option is
chosen the following user is prompted for the following details
Enter the VPN IP :
Allocation status of the VPN IP is displayed
 Option 4 - Query PM Counter values: Displays all the counter details
 Option 5 - Query All BSR-ID Info: Displays all the configured BSR ID info
 Option 6 - Query All Remote-AAA Info: Displays all configured Remote AAA
info
 Option 7 - Exit: Quit from AAAConsole application
The above commands can be checked during Radius Request processing and
during state changes. To save the output use Tab+F4 key and specify file name,
to see next/previous page use Tab+PageDown/PageUp key.
Note: Multiple instances of AAAConsole can be run.
1.32 Scenario 31: How to test MR 2115 – Emergency Call Testing
1. BSG::emCallCheckEnabled is used to control emergency call feature. If the

emCallCheckEnabled is set as True then emergency call detection is enabled. If
the emCallCheckEnabled is set as False, then emergency call detection is
disabled. Emergency call detection refers to whether BSG needs to decode UL
RANAP Initial UE and Direct Transfer messages.
2. If emergency call detection is enabled then the NAS PDU in the initial UE message
is decoded and the CM Service Request in the NAS PDU is checked to see if it is
emergency call setup.
3. If CM Service Request in the NAS PDU is received with request type as

“Emergency Call Establishment” analysis of UL DT messages will be stopped.
4. In case if the emergency call is preceded by LAU then the UL DT message prior to
RAB message is decoded. The NAS PDU is checked to determine whether it is a
MM message with CC emergency setup to indicate an emergency call.
5. If the NAS message in RANAP Initial UE message is CM Service Request with

request type not set to 'Emergency call establishment' or the NAS message in an
UL RANAP Direct Transfer message is not an MM message and not a CC
Emergency Setup message, then BSG shall release the call connection.
6. Irrespective of the ‘emCallCheckEnabled’ value being set, if the cause for call
connection is Emergency, validation of IMSI should not be done in case of UE is
from Closed Access BSR.
1.33 Scenario 32: How to test Resume state CR 413791
1. Delete the IuCS/PS interface (i.e those interfaces that move to RESUME state
very frequently) after upgrading to 2.4.1.6.
2. Stop/start BSG following deletion of IuCS/PS.
3. Create new IuCS/IuPS interface with IuCS/PS:: disableASPUP set to skip the ASPUP
message handshake. If the disableASPUP is set to “True” then BSG skips the ASPUP
message send to CN. Check if the issue is resolved.
Note:
If disableASPUP is set to False then BSG sends ASPUP message to CN.
If disableASPUP =”False” or if IuCS/PS is created without disableASPUP then BSG

send ASPUP message to CN.
1.34 Scenario 33: How to test MR2245
MR 2245 - Specify EAP-AKA serial number-stripping by the FGW RADIUS proxy function
in order to allow use of a 3rd party AAA server is enabled by setting the
AAA::eapAkaStripSN to True. The following are the steps that are followed to set
eapAkaStripSN to True.
1. Start the BSGCLI by issuing the following command in the shell prompt
cd /opt/bin/
./BSGCLI.exe
2. Execute the following commands in BSGCLI
cd FGW:<DN>;
cd AAA:1;
3. Execute the following command to enable
set { eapAkaStripSN = True};
4. The Attributes gets updated upon the restart of BSG
5. When eapAkaStripSN is True and the Username is in the format
“0<IMSI>!<FSN>@eapaka.*.” For Eg Username =
0261060000000602!000002181873319@eapaka.test.dnsalias.net, then Serial
number from the Username is stripped and forwarded to the RemoteAAA
Server.
6. When eapAkaStripSN = True and Username does not match the Regular
Expression the Username is forwarded to the RemoteAAA Server without
stripping the serial number.
7. When eapAkaStripSN = False, and Serial number is not stripped from the
Username while forwarding to the RemoteAAA Server
8. On receiving the Accounting start, if the Username matches the Regular
Expression as mentioned above, the Serial number is stripped from the
Username and forwarded to the RemoteAAA Server.
9. If EAP Message matches the Username, which in turn matches the Regular
Expression, then Serial number will be stripped from EAP Message Attribute
also
1.35 Scenario 34: How to create BVG MO class and its child’s when userplane
ip’s configured in floating mode:
As child class to BVG MO class, we can create either BVG VRnc towards MSC or BVG
VRnc towards IPC.
Following is the procedure to create BVG MO in case of Direct MSC
1. Create BVG MO class using the command

create BVG:1 { amrFrameConcatTimer= FortyMs};
2. Add child class for BVG using following command
create BVG:1/BVGvirtualRncAddressesMsc1:1
{virtualRncAddressesMsc1Id=1,virtualRncAddressesMsc1IpAddress="192.16
8.207.4"};
Following is the procedure to create BVG MO in case of Direct IPC

1. Create BVG MO class using the command
create BVG:1 { amrFrameConcatTimer= FortyMs};
2. Add child class for BVG using following command
create BVG:1/BVGvirtualRncAddressesIpc1:1
{virtualRncAddressesIpc1Id=1,virtualRncAddressesIpc1IpAddress="192.168.
219.4"};
Below table describes the possible set of configurations to configure userplane ip’s when
Direct MSC or IPC used.
Direct MSC Direct IPC

Floating 6 6
Loadshared NA NA
1.36 Scenario 36: How to test ACS
Pre-requisites:
i. Create the Basic/Virtual/Enhanced mode PSC class with the newly add attribute
bsrPSCforBasicCellIdARFCN/bsrPSCforVirtEnhCellIdARFCN (DLARFCN) for ACS.
Create supporting classes for cell-id generation via CLI.
ii. The value of bsrPSCforBasicCellIdARFCN/bsrPSCforVirtEnhCellIdARFCN
(DLARFCN) ACS attribute should be between –1 to 16383
BASIC MODE:
create /FGW:80013/BSG:1/BSGbsrPSCforBasicCellId:1
{bsrPSCforBasicCellIdId=1,bsrPSCforBasicCellIdIndex=1,bsrPSCforBasicCellIdPsc=35
0, bsrPSCforBasicCellIdARFCN=2};
VIRTUAL MODE:
create BSGbsrPSCforVirtEnhCellId:1
{bsrPSCforVirtEnhCellIdId=1,bsrPSCforVirtEnhCellIdIndex=1,bsrPSCforVirtEnhCel
lIdPsc=450,bsrPSCforVirtEnhCellIdType=closedAccess,bsrPSCforVirtEnhCellIdARF
CN=2};
Test Procedure:
1. Register BSR with PSC value and
bsrPSCforBasicCellIdARFCN/bsrPSCforVirtEnhCellIdARFCN (DLARFCN) value.
2. Cell-Id will be generated if the PSC & DLARFCN provided by the BSR matches with
the PSC and DLARFCN configured in the manual classes. Note: If the PSC and
DLARFCN is not matching with the configured manual classes then
cell id’s wont be generated.
3. Perform CS/PS macro-femto relocation using the generated Cell-Id, from CN
1.37 Scenario 37: How to test End to End Subscriber Tracing
Pre-requisites:
1. Set subscriberTraceEnable attribute of subscriber trace config class as true.
Ensure that sftp server value is filled with valid IP address of the sftp server.
2. Create subscriber trace class using following comment, for a particular subscriber
(IMSI).
3. create /FGW:80013/ItfFgw:1/SubscriberTraceConfig:1/SubscriberTrace:1
{administrativeState=locked, iMSI="123456789900001", traceId="777",
traceDuration=60, traceReportingPeriod=t1800};
Test Procedure :
1. Set administrativeState for subscriber trace class as unlocked to activate the

trace for that particular subscriber usind set command.
2. Make a basic call (CS/PS)for that particular subscriber(IMSI) and check subscriber
trace file is generated at local server and once call closed check whether trace file
is transmitted to remote WMS server.
1.38 Scenario 38:How to test Optimized Paging
BSGMacroLacRacList contains a list of Macro LAC RACs. BSRs with MacroLacRac

support should contain the same LAC value in the BSGMacroLacRacList for
successful BSR registration. Paging messages containing LAC values same as in
BSGMacroLacRacList should be forwarded to BSRs supporting MacroLacRac only.
To enable the feature:
Create atleast one BSGmacroLacRacList to enable this feature. We can also create
multiple BSGmacroLacRacList with Lac and Rac Values
For example:
create /FGW:80013/BSG:1/BSGmacroLacRacList:99 {macroLacRacListRac= 54,

macroLacRacListLac= 5029 };
To disable the feature:
Delete all the entries of BSGmacroLacRacList
For example:
delete /FGW:80013/BSG:1/BSGmacroLacRacList:99;
1.39 Scenario 39: How to verify and test Femto Startup Procedure feature for
AT&T
This feature in turn consists of the Connection Request Proxy feature and the NAT
Proxy feature.
Procedure to test and verify the Connection Request Proxy feature
Pre-requisite :
One or many BSRs, FGW, FMS
1. The BSRs should be up and running and their VPN IP Addresses stored in the AAA
server.
2. FMS should be up and running
3. Start the Wireshark before executing the procedure for verifying the expected
results
Verifying Connection Request Proxy feature
4. Send a TCP connection request from FMS to the FGW on the configured IP
Address and port number.
5. After connect is successful, send the Connect Request (HTTP GET) message
containing the FSN of one of the BSRs from the FMS.
6. Verify from logs that
 the CRProxy application requests the VPNIP information from the AAA
server passing the received FSN.
 FGW connects to the desired BSR and forwards the HTTP GET request to
it.
 the FGW forwards the response received from BSR to the FMS.
7. Verify from Wireshark traces for
 Receipt of HTTP GET from FMS at FGW
 Transmit of the received Connect request from FGW to BSR
 Receipt of HTTP response from BSR at FGW
 Transmit of the received response from FGW to FMS
1.40 Procedure to test and verify the NAT Proxy feature
Pre-requisite :
One or many BSRs, FGW, FMS
1. The BSRs should be up and running and their VPN IP Addresses stored in the AAA
server.
2. FMS should be up and running.
3. The feature should be enabled as per the installation manual.
Verifying Connection Request Proxy feature
4. Attempt to login to the Femto using ssh over the IPSec tunnel.
ssh femtoOperator@10.160.0.1
Note: Replace the value 10.160.0.1 with an appropriate IP address.
5. Successful login will be indicated by a command prompt on the Femto.
1.41 How to verify the NOTIFY CONNECTION STATUS message is sent to all BSR
associations on Fixed IP interfaces after switchover
Pre-requisite :
1. Send BSR Registration request on Fixed IP interface to standby BSG .

2. Verify SCTP associations in standby node through BSGConsole.
3. Do switchover.
Verify NOTIFY CONNECTION STATUS
4. Verify SCTP associations maintained in the previous standby node are now
maintained in the newly active node through BSG console.
5. Send ReRegistration request on Fixed IP interface to newly active node.
6. Successful registration can be verified through BSGConsole.
1.42 How To Verify That AAA Receives The Act Bsr Data From Bsg During
Startup
Complete Synch-up :
During complete synch-up ,all the records will be treated as new. For complete synch-up
BSR data configuration type should be complete.
1. Steps to view complete synch-up records.

2. Run the AAAConsole.exe and give enter until view the session.
3. Select Query All BSR-ID Info option .
4. It will display all the BSR–ID Information which it got from BSG during startup.
Partial Synch-up :
Upon ACT BSR DATA change from WMS, the BSG updates its existing ACT BSR DATA in
memory and triggers notification to AAA. Partial synch-up will be happen in one of the
following scenarios. For Partial synch-up BSR data configuration type should be partial.
Scenario 1:
Addition of any BSR data records.
Scenario 2:
Updation of any field in already existing BSR data record.
Scenario 3:
Deletion of any existing record.
Steps to view Partial synch-up records.

1. Run the AAAConsole.exe and give enter until view the session.
2. Select Query All BSR-ID Info option .
3. It will display all the updated BSR–ID Information which it got from BSG during
any updates in BSR-ID Info.
1.43 How To Verify The Peer Sctp Communication Between AAA Process On
Both Active And Stanby Node
1. Send radius authentication message to AAA process in Active node.

2. Verify the VPN Ip allocation Info through AAA console by selecting Query VPN IP
Status - All SecGWs option.
3. Verify the VPN Ip allocation Info maintained in active node is now synched up in
standby node through AAA Console by selecting Query VPN IP Status - All
SecGWs option.
1.44 How To Verify Loading Of Incremental Files Upon Restart Of Active Node
Perform the below steps with 3 minutes from starting of AAA server.
3. Restart the AAA process by killing it in Active node.
4. Verify after AAA restart, whether the active node maintains VPN Ip allocation Info
which it had before AAA restart through AAA Console by selecting Query VPN IP
1.45 How To Verify the state Of Vpn Ip Info is maintained after Switchover in
Newly Active node

3. Do switch over.
4. Verify after switch over, the VPN Ip allocation Info maintained in previous active
node is now maintained in newly active node through AAA Console by selecting
Query VPN IP Status - All SecGWs option.
5. And also verify after switch over, the address lease expiry time for all VPNIP
entries are re-calculated by the newly Active node.
6. (For ex: The address lease expiry time for VPN Ip is 3 minutes. If the switch over
happens after 1 minute then the allocated VPN Ip should get expired after
2minutes in the newly active node and the same should be synch up with the
newly standby node )
1.46 How To configure user plane interfaces in floating mode in

OAM_Preconfig.xml
An interface can be configured as floating.

By providing two relationships for an interface, we can make an interface as floating
Configuring user plane ip’s while doing fresh installation

While doing fresh installation, it is possible to populate an interface as floating mode
using FGWConfig.exe. The interface details (along with the mode) can be configured in
FgwConfig_All.ini file.
Below subsection will describe the procedure to configure floating mode interfaces.
Configuring an interface as floating

Below is the example to make an interface(eg. cnCSUP) as floating
Configuration in BladeHardware=1
Relation for cnCSUP1
<MOI
fdn="FGW=10001,BladeHardware=1,PhysicalInterfaceB=8,PhysicalInterfaceBethernetPo
rtid=1">
<Attributes>
<Attribute Name="ethernetPortidId" Id="1" DataType="INTEGER" Value="1"/>
<Attribute Name="ethernetPortidEthernetPort" Id="2" DataType="DisplayString"
Value="FGW=10001,BladeHardware=1,EthernetIntf=3"/>
</Attributes>
</MOI>
<MOI
fdn="FGW=10001,BladeHardware=1,PhysicalInterfaceB=8,PhysicalInterfaceBethernetPo
rtid=2">
<Attributes>
Value=""/>
</Attributes>
</MOI>
Relation for cnCSUP2

<MOI
fdn="FGW=10001,BladeHardware=1,PhysicalInterfaceB=14,PhysicalInterfaceBethernetP
ortid=1">
<Attributes>
</Attributes>
</MOI>
<MOI
ortid=2">
<Attributes>
Value=""/>
</Attributes>
</MOI>
Note: BladeHardware=2 configuration for cnCSUP in floating mode is similar as explained

above.
Below table describes possible set of combinations in configuring cnCSUP1 & cnCSUP2 in
floating mode
cnCSUP1 cnCSUP2
Floating 6(unqiue vlan) Empty
Note: The above mentioned (in table) configurations are also applicable for interfaces
ipcCSUP1 & ipcCSUP2, cnPSUP1 & cnPSUP2 also.
When both cnCSUP and ipcCSUP interfaces needs to be configured, below mentioned
combinations of configurations are possible
cnCSUP1 ipcCSUP1 cnCSUP2 ipcCSUP2

Floating 6(vlan1) 6(vlan2) Empty Empty
1.47 Procedure to verify AGPS cache Proxy feature
Pre-requisite:
OAM, HTTPProxy application to be up and running.
To enable this feature:
Create atleast one AGPSProxy MO to enable this feature. Max instances allowed
for this MO is 2.
To disable this feature:
Deleting all the MO instances of AGPSProxy MO will disable this feature.
Verifying the feature:
Communication with TCS ADS Server
1. If AGPSProxy MO instance is configured, HTTPProxy application will connect to
the TCS ADS server and sends a HTTP GET request for AGPS data.
2. Received AGPS data is stored if successful response is received from TCS ADS
server.
Communication with femto BSRs
1. Verify using netstat whether configured port for femto connections is in LISTEN
state
2. HTTP GET request is received by this application and the stored AGPS data is
sent to femto BSR’s.
HTTP request and response can be verified using wireshark.
1.48 How To configure femtoOamProxy interface in floating for ATCA platform in

OAM_Preconfig.xml
1. Get the current configuration of FGW in preconfig XML format by issuing the
following commands in the active BSGCLI .
cd FGW:<DN>;
set {uploadDB=True};
Note: To get the DN number use the following command after starting the
BSGCLI
ls;
Sample Output:
ls command response from OAM:
FGW:100001
In the above output 100001 is the DN.
2. Get the dbStatus using this command in cli prompt to verify uploadDB status
get {dbStatus};
sample output:
uploadDBSuccessful
3. Upon successful uploadDB command a tar file (FGW-OAM-Config:x:xxxx.tar)

would be generated in the /opt/upload/ directory. You can check the file create
giving the CLI command
get { uploadDBFileName};
Sample Output:
uploadDBFileName="FGW-OAM-Config:13:201212231639.tar"
4. Extract the tar file generated in the above step using the following command
tar --force-local -xvf FGW-OAM-Config:x:xxxx.tar
5. From the extracted folder, modify the OAM_PreConfig xml as provided in the
below example.
6. After modifying OAM_PreConfig.xml, tar the modified folder as below
tar --force-local -cvf FGW-OAM-Config:x:xxxx.tar *.xml *.ini *.xsd
7. Copy the modified FGW-OAM-Config:x:xxxx.tar in the /opt/download dir and

perform download DB
cd FGW:<DN>;
set { downloadDBFileName = "FGW-OAM-Config:x:xxxx.tar"};
set {downloadDB=True};
8. Get the downloadDB status using the following command in CLI prompt to
get {dbStatus};
Sample Output:
downloadDBSuccessful
Below example describes configuring femtoOamProxy as floating ip in Blade Hardware1
<MOI
ortid=1">
<Attributes>
</Attributes>
</MOI>
<MOI
ortid=2">
<Attributes>
</Attributes>
</MOI>
Below example describes configuring femtoOamProxy as floating ip in Blade Hardware2

…
<MOI
ortid=1">
<Attributes>
</Attributes>
</MOI>
<MOI
ortid=2">
<Attributes>
</Attributes>
</MOI>
1.49 How To Test MR2265
MR2265 - New counter to count BPG and BVG UL & DL transmission in mega-byte.
Following are the steps to test this MR
1. Add BVG & BPG DPAT rules

2. Send BVG and BPG User traffic
3. Capture the packets in wireshark
4. Wait until PM data get collected.
5. After PM data collection check for the counters VS.TotalULBVGMBytes,
VS.TotalDLBVGMBytes in PM file
6. The value for VS.TotalULBVGMBytes counter should match the below expression
VS.TotalULBVGMBytes = (No. of UL Bvg usertraffci packets ) * (value of length
field in ip header from wireshark + 20) /(1024*1024)
VS.TotalDLBVGMBytes = (No. of DL Bvg usertraffci packets ) * (value of length
VS.TotalULBPGMBytes = (No. of UL Bpg usertraffci packets ) * (value of length

VS.TotalDLBPGMBytes = (No. of DL Bpg usertraffci packets ) * (value of length
1.50 Procedure to Test MR2275
MR2275 - Ensure that AAA function does not perform authentication, only authorization,
when the "Service-Type" attribute is included.
Pre-Requisites:
1. This MR is applicable for Certified BSRs only.

2. PM data collection to be enabled.
3. AAA Console shall be invoked for verifying the VPN IP Allocation.
Following are the steps to test this MR:
1. If Certified radius authentication message is sent with "Service-Type" attribute

value set to "Authorize Only" (= 17, as specified in RFC 5176).
2. Check in AAAConsole by choosing “Query VPN IP Status - All SecGWs”, that a VPN
IP Entry is present with Pending allocation state.
3. In the same radius authentication message, If the value of the "Service-Type"

attribute is set other than 17 then the Access-Request will be Rejected.
4. Check in AAAConsole by choosing “Query PM Counter values” which displays

uiRadiusAccRejSentforCertBSRduetoBSRnotconfigured as 1 (if previous counter
value was 0).
5. If Certified based Radius Authentication message is sent with EAP attribute, then
the Radius Request will be Rejected.
6. Perform step-4 to verify the result.
1.51 HOW TO TEST MR2196
MR2196 – Allowing accounting without authentication by enabling the

SecurityGateway:: securityGatewayEnableAccountingWithoutAuth to True,
The following are the steps to test this MR:
Setting the securityGatewayEnableAccountingWithoutAuth attribute in CLI
1. Start the BSGCLI by issuing the following command in the shell prompt
cd /opt/bin/
./BSGCLI.exe
2. Execute the following commands in BSGCLI
cd FGW:<DN>;
cd AAA:1;
3. Create Security Gateway class with Empty VPN pool using the below
command
create SecurityGateway: <instance number>

{addressLeaseTime=60,calledStationId="10.11.12.83/30",defaultSeGW=Fals
e,femtoVPNSubnets="",id=1,nasnasIdentifier="1001",nasIpAddress="10.1
00.12.238",nasPorts="1000",reservedAddressSubnets="10.110.16.12/30",sec
urityGatewaySharedSecret="stesting123",securityGatewayEnableAccountingW
ithoutAuth=True};
4. If SecurityGateway: <instance number>::

securityGatewayEnableAccountingWithoutAuth is False, the following
command is used to set securityGatewayEnableAccountingWithoutAuth to
True.
cd SecurityGateway: <instance number>;

set { securityGatewayEnableAccountingWithoutAuth = True};
Testing by Sending Accounting Radius Request
5. Send Accounting Radius Request for the Certified user with Framed IP for the
Security Gateway Instance (with empty VPN Pool) enabled with accounting
flag set to True.
6. On Receiving Accounting-Start Request with Framed IP, the State changes to

UNMANAGED for the Certified Users and the timer is set to the current Time
Stamp.
7. Check in AAAConsole a VPN IP Entry with allocation state set to Unmanaged.
8. In the case of Accounting Stop Request, the Username matching the VPN
entry from the Security gateway table which is in UNMANAGED state is
deleted.
9. Check in AAAConsole a VPN IP Entry with matching username is not present.
10. If Security Gateway is allocating VPN IP, on receiving the Accounting Stop
request, the Username and the corresponding entries are removed.
11. When the State is in UNMANAGED, FGW does not allow setting any of the
SecurityGateway: <instance number> attributes.
12. The step-7 can be verified by trying in BSGCLI.
13. Send Accounting Radius Request start/stop for Certified / Legacy user. The
counter for Number of RADIUS ‘Accounting-Request’ received from SeGW is
incremented by 1.
14. Check the counter value from AAAConsole by choosing the option “Query PM
Counter values” which displays the “uiRadiusAccountingReq” as 1 (if previous
counter value was 0).
15. On responding with Accounting response message the counter for Number of
RADIUS ‘Accounting-Response’ sent to SeGW is incremented by 1.
16. Check the counter value from AAAConsole by choosing the option “Query PM
Counter values” which displays the “uiRadiusAccountingReq” as 1 (if previous
counter value was 0).
1.52 ThreadMon configuration
Changing Threadmon configuration and restarting FGW
The Thread monitoring has a configuration file /opt/conf/ThreadMonConf.ini. Any

changes done to ThreadMonConf.ini require FGW processes to be restarted for the new
configuration take effect.
Enabling/Disabling ThreadMon
To enable or disable thread monitoring, edit /opt/conf/ThreadMonConf.ini and set the

value for attribute EnableTM as true or false respectively.
Enabling/Disabling specific process threads
The processes that are monitored will have section named same as that of process
name. To disable a specific process from being monitored, the attribute SkipMonitoring
is to be set to true.
If the SkipMonitoring attribute is set as false or if the attribute itself is not present, the
process will be added to list of monitored processes (if EnableTM is also true at global
level).
Configuration for threads that are to be monitored
Each process listed under [Monitored-processes] section will have two more sections.
One section is same as that of the process name itself and another section with name
<processname>-Threads.
E.g
Process BSG listed under [Monitored-Processes] will have two more sections namely
[BSG] and [BSG-Threads].
The [BSG] section will have configuration details for heartbeat sent by FGWMon to BSG
process.
The [BSG-Threads] section will have configuration details of individual threads of BSG
process. The heartbeat pings are exchanged between the monitoring thread within the
BSG process and other monitored threads configured under this section.
The individual thread entries generally have three entries: ThreadName, Heartbeat
interval and Heartbeat response guard timer.
The heartbeat interval attribute has value in seconds. Once in every configured seconds,
a heartbeat request is sent by monitoring thread to the monitored thread and expects
the response within the heartbeat guard timer (unit in seconds).
If the heartbeat response is not received by monitor thread within the guard timer value,
the thread is considered to be dead and the process is restarted.
Entries made under these two sections should have corresponding code changes in FGW.
The existing entries can be commented to move it out of thread monitoring purview but
new entries cannot be made by end-user.
Enabling ThreadMon for ShelfOAM in ATCA
The ShelfOAM process only runs on ATCA platform. This process will not run in Sun
platform.
To enable thread monitoring of ShelfOAM in ATCA platform, set SkipMonitoring attribute

as true under [SHELFOAM] section.
In Sun platform, the SkipMonitoring attribute under [SHELFOAM] section should always
be set as false.
1.53 HOW TO configure INTERNODE VLAN in ATCA

To bring up two internodes link in separate subnet to avoid failing of all internode link on
disturbing one of the internode link.
Procedure to attain this:

To fix the CR on a already deployed node, perform upload DB, modify the
OAM_Preconfig.xml and perform download DB.
List of changes to be carried out in OAM_Preconfig.xml

1. Open the OAM_PreConfig.xml
2. Search for interNodeLink interface for BladeHardware=1 in the file
3. Update the netmask of internodelink interface to “a.b.c.128” instead of “a.b.c.0”
[where a,b,c <=255]
Ex:
<MOI fdn="FGW=10001,BladeHardware=1,PhysicalInterfaceB=4">
<Attributes>
<Attribute Name="userLabel" Id="2" DataType="DisplayString" Value="Interface 1-4"/>
<Attribute Name="netmask" Id="1000" DataType="IPAddress" Value="255.255.255.128"/>
<Attribute Name="network" Id="1001" DataType="IPAddress" Value="192.168.103.0"/>
<Attribute Name="defaultGateway" Id="1003" DataType="IPAddress" Value="0.0.0.0"/>
<Attribute Name="interfaceType" Id="1004" DataType="Enumeration" Value="interNodeLink"/>
<Attribute Name="vLANId" Id="1006" DataType="INTEGER" Value="103"/>
<Attribute Name="vlanTagEnabled" Id="1007" DataType="Boolean" Value="True"/>
<Attribute Name="connectionType" Id="1008" DataType="Enumeration" Value="Physical"/>
</Attributes>
</MOI>
4. For internodelink in BladeHardware1, update the value of 1st

ipAddressLocalIpAddress as “a.b.c.X” and if 2nd is configured then change value of
ipAddressLocalIpAddress as “a.b.c.Y”. [Where a,b,c < 255 and X < 126 and Y > 129]
EX:
<MOI fdn="FGW=10001,BladeHardware=1,PhysicalInterfaceB=4,PhysicalInterfaceBipAddressLocal=1">
<Attributes>
<Attribute Name="ipAddressLocalId" Id="1" DataType="INTEGER" Value="1"/>
<Attribute Name="ipAddressLocalIpAddress" Id="2" DataType="IPAddress" Value="192.168.103.21"/>
</Attributes>
</MOI>
<Attributes>
</Attributes>
</MOI>
5. Search for interNodeLink interface for BladeHardware=2 in the file

6. Update the netmask of internodelink interface to “a.b.c.128” instead of “a.b.c.0”
[where a,b,c <=255]
Ex:
<MOI fdn="FGW=10001,BladeHardware=2,PhysicalInterfaceB=4">
<Attributes>
<Attribute Name="userLabel" Id="2" DataType="DisplayString" Value="Interface 1-4"/>
<Attribute Name="netmask" Id="1000" DataType="IPAddress" Value="255.255.255.128"/>
<Attribute Name="network" Id="1001" DataType="IPAddress" Value="192.168.103.0"/>
<Attribute Name="defaultGateway" Id="1003" DataType="IPAddress" Value="0.0.0.0"/>
<Attribute Name="interfaceType" Id="1004" DataType="Enumeration" Value="interNodeLink"/>
<Attribute Name="vLANId" Id="1006" DataType="INTEGER" Value="103"/>
<Attribute Name="vlanTagEnabled" Id="1007" DataType="Boolean" Value="True"/>
<Attribute Name="connectionType" Id="1008" DataType="Enumeration" Value="Physical"/>
</Attributes>
</MOI>
7. For internodelink in BladeHardware=2, update the value of 1st

ipAddressLocalIpAddress as “a.b.c.X+1” and if 2nd is configured then change value of
ipAddressLocalIpAddress as “a.b.c.Y+1”. [Where a,b,c < 255 and X < 126 and Y >
129]
EX:
<Attributes>
</Attributes>
</MOI>
<Attributes>
</Attributes>
</MOI>
1.54 HOW TO TEST MR2311

MR 2311-Improve identity binding to support FSN checking for DS2460 femtos
In RADIUS Request,the username should be of EUI64/OUI format.
Legacy Femtos :
From the RADIUS Access Request received, EUI64 identifier is formed by

concatenating the hex string “001D4C00” with the last eight hex characters of the
VPNchaddr. This is the FemtoBSRUniqueIdentity.
This is searched in the MIB for a HNBUniqueIdentity and the corresponding Serial
Number is retrieved from the MIB. if not found, the Chip serial No is searched in
/opt/conf/CSN_FSN_mapping.csv file and the corresponding Serial Number is
retrieved
The Serial No thus retrieved is the FemtoBSRIdentity
A sample CSN_FSN_mapping file
CSN_FSN_mapping.c
sv
If a corresponding FSN can’t be found in both files, FemtoBSRIdentity is left NULL

and an alarm(HNB/BSR integrity violation) alarm is raised
Certified Femtos with Username in OUI-SNO format:
From the Certified RADIUS Access Request received, the Serial Number is
retrieved from the RADIUS Access Request and searched in the MIB for the
matching serial number and its corresponding HNBUniqueIdentity
The VPNChAddr is thus the FemtoBSRIdentity and the HNBUniqueIdentity is the

FemtoBSRUniqueIdentity
Certified Femtos with Username in EUI64 format:
From the Certified RADIUS Access Request received, the EUI64 identifier, which
is the string before realm ,is searched in the MIB for a corresponding Serial
Number.
The Serial Number thus obtained is prefixed with “001D4C” and this is
FemtoBSRIdentity
Thus the FemtoBSRIdentity obtained in the above scenarios and is matched

against FSN received in BSR Registration Request.
1.55 HOW TO TEST CR594573:

CR594573-FGW SubscriberTraceConfig configuration via WPS is not done properly
SubscriberTraceConfig attributes are not successfully updated via BSGCLI
Test Procedure:
1. ./BSGCLI.exe
CLI Initializing. Please wait for CLI >> Prompt !!!
CLI >> cd FGW:80013
2. Generate the batchfile using WPS and transfer the file to FGW.
3. CLI >> loadbatchfile -v <filename>;
4. Check from BSGCLI whether the configuration are applied to

SubscriberTraceConfig/1
Sample Batch file:
create /FGW:80013/ItfFgw:1/SubscriberTraceConfig:1/SubscriberTrace:1
{administrativeState="locked",iMSI="262950000000611",traceDuration=120,traceId="6
11",traceReportingPeriod="t1800"};
set /FGW:80013/ItfFgw:1/SubscriberTraceConfig:1
{rootDirectory="/opt/nortel/data/utran/observation/subscriberTrace"};
set /FGW:80013/ItfFgw:1/SubscriberTraceConfig:1 {sftpServer="172.22.11.5"};
set /FGW:80013/ItfFgw:1/SubscriberTraceConfig:1 {subscriberTraceEnable="true"};
Note: Attributes with constraints should be provided as individual set commands
1.56 Standard Paging With/Without SuperLAC
1. Paging will be forwarded based on the Paging Area List and Candidate Paging list.
2. Paging Area List is formed by the list of LACs/LACRACs for CS/PS domains
respectively.
3. The creation of Paging Area List depends on the presence of Region and
LACs/LACRACs associated with the Region to which Iu interface is mapped.
4. Candidate Paging list is formed by the presence of IMSI in ACL of registered BSR
whose LAC/LACRAC is in Paging Area List.
5. Candidate Paging list includes BSR which has its LAC/LACRAC in Paging Area List
and IMSI in paging message was registered through this BSR, (ie. Available in
IMSI Directory).
6. Candidate Paging list includes BSRs which belong to same group of BSR which
was selected based on Step 5.
Configurations and Use Cases are as below and same can be referred for PS
domain configuring PsRegion & RaiToPsRegion.
cd FGW:80013;
set {activateIuFlexCS=true};
set {activateIuFlexPS=true};
cd FGW:80013/BSG:1;
Create Region and Configure Superlac in the region:
cd /FGW:80013/BSG:1;
create CsRegion:11 {nriMaskSize=3,superLAC1="65010",superLAC2="65011",
superLAC3="65012",superLACopen="65013"};
cd /FGW:80013/BSG:1/CsRegion:11;
create CsRegionnriToCnNodeCS:1
{nriToCnNodeCSNri=1,nriToCnNodeCSWeight=7,nriToCnNodeCSCnNode="FGW=80013,I
uCS=1"};
Create LaiToCsRegion for Region:
cd /FGW:80013/BSG:1;
create BSGlaiToCsRegion:1
{laiToCsRegionLac=65029,laiToCsRegionPlmnIdentityMcc="123",laiToCsRegionPlmnIden
tityMnc="45",laiToCsRegionRegion="FGW=80013,BSG=1,CsRegion=11"};
create BSGlaiToCsRegion:2
{laiToCsRegionLac=65030,laiToCsRegionPlmnIdentityMcc="123",laiToCsRegionPlmnIden
tityMnc="45",laiToCsRegionRegion="FGW=80013,BSG=1,CsRegion=11"};
Case 1: Paging Area ID is Present and is SuperLAC
1. Set {SuperLACActivation=”SuperLacActive”}; in FGW Class
2. When Paging message is received with PagingAreaId, the PagingAreaId will be

considered as SuperLAC only if the region to which Iu is associated is configured
with SuperLAC value same as the PagingAreaId.
3. If PagingAreaId is found to be SuperLAC, all the LACs associated with the region
for Iu Interface will be selected for Paging Area List.
4. As per above stated example, if Paging Area ID in Paging message is 65010, LACs
65029 & 65030 should be selected for Paging Area List.
5. Further based on the IMSI availability in ACL table and IMSI directory, the
associated BSR’s LAC should match the LAC in the Paging Area List for paging to
be forwarded to appropriate BSR.
6. If there are no LaiToCsRegion/RaiToPsRegion being associated with the region, if

Iuflex is disabled paging will be forwarded to all registered BSR’s if IMSI is
present in ACL list of the BSR or IMSI is present in IMSI directory.
7. If there are no LaiToCsRegion/RaiToPsRegion being associated with the region, if

Iuflex is enabled, default region should be configured as the region to which Iu
(Iu from which Paging is received)is mapped, paging will be forwarded to all
registered BSR’s if IMSI is present in ACL list of the BSR or IMSI is present in
IMSI directory
Case 2: Paging Area ID is Present and is NOT SuperLAC
1. If SuperLAC is disabled, Paging Area ID is considered as NOT SuperLAC

Set {SuperLACActivation=”SuperLacNotActive”}; in FGW Class
2. When Paging message is received with PagingAreaId, the PagingAreaId will not be
considered as SuperLAC if the region to which Iu is associated is configured with
SuperLAC value different from the PagingAreaId.
3. Eg: Paging Area ID is 65020 is different from the SuperLAC configured as

65010/65011/65012/65013.
4. Paging Area List will be formed by the Paging Area ID received from the Paging
message. (ie. As per Step 3, BSRs of LAC 65020 will be selected for Paging Area list)
5. Further based on the IMSI availability in ACL table and IMSI directory, the associated
BSR’s LAC should match the LAC in the Paging Area List for paging to be forwarded
to appropriate BSR.
Case 3: No Paging Area ID
1. If an Iu interface is associated with region which contains LACs associated with

region, Paging Area List will be formed by the LACs present in the region.
2. As per above stated example, LACs 65029 & 65030 should be selected for Paging
Area List.
3. If there are no region exists or Iu Interface is not associated with any region, Paging
Area List is formed by all registered BSR’s LAC.
4. Further based on the IMSI availability in ACL table and IMSI directory, the associated
BSR’s LAC should match the LAC in the Paging Area List for paging to be forwarded
to appropriate BSR.
5. If an Iu interface is associated with region and there are no

LaiToCsRegion/RaiToPsRegion being associated with the region, if Iuflex is disabled
paging will be forwarded to all registered BSR’s if IMSI is present in ACL list of the
BSR or IMSI is present in IMSI directory.
6. If an Iu interface is associated with region and there are no

LaiToCsRegion/RaiToPsRegion being associated with the region, if Iuflex is enabled,
default region should be configured as the region to which Iu (Iu from which Paging
is received)is mapped, paging will be forwarded to all registered BSR’s if IMSI is
present in ACL list of the BSR or IMSI is present in IMSI directory
1.57 Notify Connection Status
In AWS enabled mode setup, a new command is introduced in BSGConsole to retrieve

the information on
- number of sctp association present before the Switchover in WarmStandby node
- number of notification sent from the new active node successfully
- Number of failures in sending the notification.
The command in BSGConsole is “bsg_get_aws_notify_count”. Launch this command in
BSGConsole after performing the switchover to retrieve the information.
1. Login into BSGConsole

/opt/bin/BSGConsole
2. Now launch the command to retrieve the information

>> bsg_get_aws_notify_count
1.58 HOW TO ENABLE AMR FRAME CONCATENATION FEATURE
To enable “AMR Frame Concatenation with Preemption” feature configure the following
attributes of FGW & BVG MO classes as below
Steps to configure FGW::amrDlConcatPort and FGW::amrFrameConcatMode & BVG::

amrFrameConcatTimer:
1. Follow the steps mentioned in Section 1.48 for extracting current FGW
configurations in XML format (Upload DB)
2. Get the tar file of XML from /opt/upload/
3. Untar the file and make the following changes in OAM_PreConfig.xml
a) Under FGW MO class
Change the value of amrDlConcatPort as 4000 and amrFrameConcatMode as
EmergencyCSV
b) Under BVG MO class

Change the value of amrFrameConcatTimer as FortyMs
4. tar all the changes and place the file in /opt/download

5. Perform download DB as mentioned in Section 1.48
Note:1 The bulkcm operation for changing the configuration file should be performed in
both the nodes.
Note2: If BVG MO class not created already, then create BVG MO class using the below
command after starting FGW
create BVG:1 { amrFrameConcatTimer =FortyMs};
Note3: If the value for “afcTimer” is more than 40ms, then it is recommended to reduce
the value of AMR_JITTERTIME (minimum configured value is 5ms) in /opt/conf/
Btg_config.ini to ensure the negligible delay in flushing the DL AMR concatenated
packets.
1.59 MR2295 – Reconfiguring femtoCp on 10Geth in Bono
The following steps are required to reconfigure the femtoCp to 10Geth in Bono
following commands in the active BSGCLI.
cd FGW:<DN>;
get {dbStatus};
sample output:
uploadDBSuccessful

Sample Output:
below format. i.e. Modify the femtoCp of both BladeHardware=1 and
BladeHardware=2 to 10Geth
<MOI fdn="FGW=10001,BladeHardware=1,PhysicalInterfaceB=2,PhysicalInterfaceBethernetPortid=1">
<Attributes>
</Attributes>
</MOI>
<Attributes>
</Attributes>
</MOI>
………………
<Attributes>
</Attributes>
</MOI>
<Attributes>
</Attributes>
</MOI>

perform download DB
cd FGW:<DN>;
get {dbStatus};
Sample Output:
1.60 Configure IPAddress of Interfaces in OAM_PreConfig.xml
following commands in the active BSGCLI.
cd FGW:<DN>;
BSGCLI
ls;
Sample Output:
FGW:100001
get {dbStatus};
sample output:
uploadDBSuccessful

Sample Output:
below example.

perform download DB
cd FGW:<DN>;
get {dbStatus};
Sample Output:
Below example describes configuring femtoOamProxy Interface to 0.0.0.0 in Sun

Netra[ServerHardware]
a. Search for femtoOamProxy in OAM_PreConfig.xml

b. Change the value Attribute vLANId, network present in the PhysicalInterfaceS
FDN related to that interface.
<MOI fdn="FGW=10001,ServerHardware=1,PhysicalInterfaceS=24">
…
…
…
<Attribute DataType="IPAddress" Id="1000" Name="netmask"
Value="255.255.255.0"/>
<Attribute DataType="IPAddress" Id="1001" Name="network"
Value="0.0.0.0"/>
<Attribute DataType="IPAddress" Id="1003" Name="defaultGateway"
Value="0.0.0.0"/>
<Attribute DataType="Enumeration" Id="1004" Name="interfaceType"
Value="femtoOamProxy"/>
<Attribute DataType="INTEGER" Id="1006" Name="vLANId" Value="0"/>
…
…
</MOI>
c. Also change the IPAddress configured in the femtoOamProxy interface by

changing the value of attribute ipAddressLocalIpAddress present in the
PhysicalInterfaceSipAddressLocal=[1…6] FDN
<MOI fdn="FGW=10001,ServerHardware=1, PhysicalInterfaceS
=24,PhysicalInterfaceSipAddressLocal=1">
<Attributes>
<Attribute Name="ipAddressLocalId" Id="1" DataType="INTEGER"
Value="1"/>
<Attribute Name="ipAddressLocalIpAddress" Id="2"
DataType="IPAddress" Value="0.0.0.0"/>
</Attributes>
</MOI>
d. Repeat the Steps [a-c] to configure for hardware=2 as well.
Note: Same Steps should be followed to configure in ATCA[Blade Hardware]. Please

find the table listing the corresponding FDN in BladeHardware
Sun Netra ATCA
ServerHardware BladeHardware
PhysicalInterfaceS PhysicalInterfaceB
PhysicalInterfaceSipAddressLocal PhysicalInterfaceBipAddressLocal
1.61 MR2295 Alarm Handling.
As part of MR2295 implementation, CPU utilization should be monitored and raise CPU
overload alarm incase CPU utilization crosses minimum/Maximum threshold limit.
MR2295 has impact on both BSG and BTG. BSG monitors set of core which has affinity to
BSG application and BTG monitors set of core which has affinity to BTG application..
Due to unavailability of Alarms in the MIM, BSG and BTG will not be able to raise alarm to
WMS. Instead application will dump the following statement in the log files.
Appli Log File Level Log Statement Cause Threshold

catio Configuration
n
ERRO CPU utilization has reached CPU utilization OAM_PreConfig.xml
R Min CPU Utilization Threshold reaches Class: FGW
DEBU Raising Minimum Attribute:
G FGW_CPUOVERLOADMINI Threshold minimumCPUUtilizat
MUMTHRESHOLD Alarm Limit. ionThreshold
Log_OA
OAM ERRO CPU utilization has reached OAM_PreConfig.xml
M.log CPU utilization
R Max CPU Utilization Class: FGW
reaches
Threshold" Attribute:
Maximum
DEBU Raising maximumCPUUtilizat
Threshold
G FGW_CPUOVERLOADMAXI ionThreshold
Limit.
MUMTHRESHOLD Alarm
FATA Average network core CPU CPU utilization OAM_PreConfig.xml
L exceeded BVG Threshold reaches BVG Class: BVG
Threshold Attribute:
limit. overloadThreshold
FATA Average network core CPU CPU utilization OAM_PreConfig.xml
L exceeded BPG Threshold reaches BPG Class: BPG
Log_BT threshold limit.Attribute:
BTG
G.log overloadThreshold
WAR Single network core utilization CPU utilization FGWMon_PreConfig.
N exceeded for core of one of the xml
core reaches Class: COREMAP
perCoreCpuNo Attribute:
tificationLimit perCoreCpuNotificati
onLimit
Note: All the values can be configured through BSGCLI except for
“perCoreCpuNotificationLimit”. Due to unavailability of this attribute
“perCoreCpuNotificationLimit” in the MIM, it is temporarily maintained in
FGWMon_PreConfig.xml file and it is set to 90 by default.
1.62 CMAS Feature use cases
1.62.1 CellBroadCast Interface Configuration:

a) For Fresh Installation
update /opt/conf/ FgwConfig_All.ini file with the following:
NETWORK_IP_OF_CELLBROADCAST = <IuBC network>

FLOATING_IP_OF_CELLBROADCAST = <IuBC local IP>
FLOATING_CELLBROADCAST_NETMASK = <IuBC subnet mask>
FLOATING_CELLBROADCAST_DEFAULTGATEWAY = <IuBC default gateway>
FLOATING_CELLBROADCAST_VLANID = <IuBC vlan number>
ETHERNET_PORT_CELLBROADCAST =
DUMMY_CELLBROADCAST_IP_ADDRESS =<FreeIP in the same IuBC subnet>
After changing above entries, we need to do ‘stopbsg’ and run ./FGWConfig.exe which
updates these entries to OAM_PreConfig.xml
Remove /opt/conf/OAM_PersistentDB.xml, then run ‘startbsg’. Now, BSG should be up with

other processes.
b) For already existing configuaraion without CellBroadCast
Follow the steps below to change the parameters

1. Trigger UploadDB.
would be generated in the /opt/upload/ directory.
3. Extract the tar file generated in the above step, using the following command
4. Edit the OAM_Preconfig.xml for CellBroadCast interface configuration ( Ip
address)
i) Change the following attributes of PhysicalInterfaceS/ PhysicalInterfaceB
instance 26 on both if is in redundant mode i.e
ServerHardware=1/BladeHardware =1 and ServerHardware=2/BladeHardware
=2
<Attribute DataType="IPAddress" Id="1000" Name="netmask"
Value="<IuBC subnet mask>"/>
<Attribute DataType="IPAddress" Id="1001" Name="network"
Value="<IuBC network>"/>
<Attribute DataType="IPAddress" Id="1003" Name="defaultGateway"
Value="<IuBC default gateway>"/>
<Attribute DataType="INTEGER" Id="1006" Name="vLANId" Value="<IuBC
vlan number>"/>
ii) Change the "ipAddressLocalIpAddress" in
PhysicalInterface(S/B)ipAddressLocal=1 of PhysicalInterface(S/B) instance 26 of
both ServerHardware=1/BladeHardware =1 and
ServerHardware=2/BladeHardware =2
For eg: On a ATCA platform machine,
<MOI
fdn="FGW=<FGWID>,BladeHardware=1,PhysicalInterfaceB=26,PhysicalInterface
BipAddressLocal=1">
<Attributes>
<Attribute DataType="INTEGER" Id="1" Name="ipAddressLocalId" Value="1"/>
<Attribute DataType="IPAddress" Id="2" Name="ipAddressLocalIpAddress"
Value="<IuBC local IP>"/>
Name="ipAddressLocalRowStatus" Value="active"/>
</Attributes>
</MOI>
AND
<MOI
fdn="FGW=<FGWID>,BladeHardware=2,PhysicalInterfaceB=26,PhysicalInterface
BipAddressLocal=1">
<Attributes>
Value="< FreeIP in the same IuBC subnet>"/>

Name="ipAddressLocalRowStatus" Value="active"/>
</Attributes>
</MOI>

perform download DB
cd FGW:<DN>;
get {dbStatus};
Sample Output:
1.62.2 How to Create IuBC MO:
Activate BSGCLI.
cd FGW:<DN>;
FGW:<DN>
create /FGW:<DN>/IuBC:1
{ipAddressCellBroadcastLocal="172.204.0.2",ipAddressCellBroadcastPrimary="172.204.0.3
",ipAddressCellBroadcastSecondary="172.204.0.4",retryTimer=10,cellBroadcastRestartWait
Timer=10,cellBroadcastFailureWaitTimer=10,keepAliveTCP=True,keepAliveTime=10,keep
AliveIntvl=4,keepAliveProbes=3,maximumTransientProcedureThreshold=200000,timerFailo
ver=120,overloadCauseValue=6,administrativeState=locked}
1.62.3 Enable cellBroadcastService

Activate BSGCLI.
cd FGW:<DN>;
FGW:<DN>
Set {cellBroadcastResponseGuardTimer=90};
Set {cellBroadcastService=True};
1.62.4 How to Lock IuBC MO:

Activate BSGCLI.
cd FGW:<DN>;
FGW:<DN>
cd IuBC:<DN>;
IuBC:<DN>
Set { administrativeState=locked}
1.62.5 How to Delete IuBC MO:

Activate BSGCLI.
cd FGW:<DN>;
FGW:<DN>
delete /FGW:10010/IuBC:1
1.62.6 To configure different MCC, MNC differently than the default value
(mentoined in OAM_PreConfig.xml), then use these commands
Activate BSGCLI.
cd FGW:<DN>;
FGW:<DN>
cd BSG:<DN>;
BSG:<DN>
set {globalRNCIdMcc="272"}
set {globalRNCIdMnc="203"}
1.63 Procedure to enable MCUI Feature

Pre-requisite:
 The system should be running with 04.00.00.08 or above load.
Procedure to bringup Cluster with AAA as Accounting Server:
This section explains the configuration of MCUI feature parameters. The user has to
perform the below steps to configure AAA to act as Accounting Server.
a. Make sure all the FGW related processes are running and start the BSGCLI if
not started as follows.
cd /opt/bin/
./BSGCLI.exe
b. Configure the proxied RADIUS service by issuing the following commands in

the BSGCLI.
cd FGW:<DN>;
cd AAA:1
create AAAaAAAccountingServerIpAddress:1
{aAAAccountingServerIpAddressId=1,aAAAccountingServerIpAddr
essIpAddress="a.b.c.d"};
set {singleInstanceAaaFunction=customerSpecific};
cd /FGW:<DN>;
set {multiClusterUnifiedInterface=True};
Note: IP Address a.b.c.d should be either of the following

1. If secGW Interface is configured with 2 IP Addresses, a.b.c.d
should be same as the 2nd IP Address. Refer to section 1.71
for creating 2nd IP Address for secGW Interface (if it is not
created already)
2. If secGW Interface is configured with only 1 IP Address,
a.b.c.d should be same as the secGW Interface IP Address.
c. Add routes to reach the client clusters through the “secGW” Interface using
MonConfig.exe. In case of redundant system, perform this step on the
standby node as well.
Procedure to bringup Cluster as Client:
This section explains the configuration of MCUI feature parameters. The user has to
perform the below steps to configure Cluster connecting to remote Accounting Server.
cd /opt/bin/
./BSGCLI.exe
b. Configure the proxied RADIUS service by issuing the following commands in

the BSGCLI.
cd FGW:<DN>;
cd AAA:1
create AAAaAAAccountingServerIpAddress:1
{aAAAccountingServerIpAddressId=1,aAAAccountingServerIpAddr
essIpAddress="a.b.c.d"};
set {singleInstanceAaaFunction=noProxy};
cd /FGW:<DN>;
set {multiClusterUnifiedInterface=True};
Note: IP Address a.b.c.d should be same as the IP Address configured for

AAAaAAAccountingServerIpAddress MO in the Accounting Server.
c. Add routes to reach the Accounting Server through the “secGW” Interface
using MonConfig.exe. In case of redundant system, perform this step on the
standby node as well.
1.64 Procedure to disable MCUI Feature

Pre-requisite:
 The system should be running with MCUI enabled.
Procedure:
This section explains the procedure to disable MCUI feature. The user has to perform the
below steps.
a. Make sure all the FGW related processes are running and start the BSGCLI if not
started as follows.
cd /opt/bin/
./BSGCLI.exe
b. Configure the proxied RADIUS service by issuing the following commands in the
BSGCLI.
cd FGW:<DN>;
set {multiClusterUnifiedInterface=False};
1.65 Procedure to migrate AccountingServerIPAddress from backplae IP to

Public IP for MCUI
Accounting Server Cluster

1) If separate IP Addresses are planned for communication with external Security Gateway
and Client Clusters, secGW Interface should be configured with 2 IP Address. Refer to
Section 1.71 for creating the 2nd IP Address for secGW Interface.
2) Modify the AAA: AAAaAAAccountingServerIpAddress:1 value with the IP
Address configured for secGW Interface (If secGW Interface has been configured with 2
IP Address, 2nd IP Address should be used for this purpose. Otherwise, 1st IP Address can
be used)
set /FGW:<DN>/AAA:1/AAAaAAAccountingServerIpAddress:1
{aAAAccountingServerIpAddressIpAddress="a.b.c.d"};
3) Delete AAA: AAAaAAAccountingServerIpAddress:2 if configured
delete /FGW:<DN>/AAA:1/AAAaAAAccountingServerIpAddress:2
4) Add the route to reach all the clients through the “secGW” Interface using MonConfig. In
case of redundant system, perform this step on the standby node as well.
Client Cluster
1) Modify the AAA: AAAaAAAccountingServerIpAddress:1 value with the IP

Address used for AAAaAAAccountingServerIpAddress MO in the Accounting
Server
set /FGW:<DN>/AAA:1/AAAaAAAccountingServerIpAddress:1
{aAAAccountingServerIpAddressIpAddress="a.b.c.d"};
2) Delete AAA: AAAaAAAccountingServerIpAddress:2 if configured
delete /FGW:<DN>/AAA:1/AAAaAAAccountingServerIpAddress:2
3) Add the route to reach the Accounting server through the “secGW” Interface using
MonConfig. In case of redundant system, perform this step on the standby node as well.
1.66 Troubleshooting IPMI

IPMI is a driver tool used to read the information from service processor (owned by SUN) to
collect all information’s like hardware information, alarms, temperature, etc.
In some problematic cases, this tool will block leading to 100% CPU usage.
How to detect
1. Run top command to check the CPU usage.
Workarounds to solve the problem
1. Unplug the power cables of SUN Netra X4250, after 5mins(or until the system got
cooled) re-plug the cables and start the server.
2. Using iLOM connection, restart the IPMI service.
1.67 Enabling Query All VPN in AAA Debug Console.
As it is not advisable to use AAA Debug Console during load run, a parameter
AAA_QUERY_VPNIP_ALL_SECGW is introduced in AAA_config.ini. By setting it to
True, option “All VPN IP from all SECGW” is enabled in AAA Debug Console to query
from AAA. By setting to False, the option will be disabled. To enable the option, set True
to AAA_QUERY_VPNIP_ALL_SECGW in AAA_config.ini and open the AAA Debug Console.
Once the console is opened, the value of AAA_QUERY_VPNIP_ALL_SECGW will be reset
to False in the AAA_config.ini file.
Note: By default, the parameter will be set to False.
1.68 Enabling MR2496 in AAA
To enable MR2496, set True to USERNAME_CHECK_ENABLE in AAA_config.ini and

restart AAA.exe. Note: By default, MR2496 is disabled by setting False to
USERNAME_CHECK_ENABLE.
1.69 Enabling Radius Packet Dump in AAA

As the logs are filled with radius packet dump, a parameter is introduced in
AAA_config.ini to enable and disable the dump. To Enable/Disable dump set True/False
to DUMP_ENABLE parameter in AAA_config.ini.
Note: By default, the parameter is set to False.
1.70 Troubleshooting IPMI

IPMI is a driver tool used to read the information from service processor (owned by SUN) to
collect all information’s like hardware information, alarms, temperature, etc.
In some problematic cases, this tool will block leading to 100% CPU usage.
How to detect
2. Run top command to check the CPU usage.
Workarounds to solve the problem
3. Unplug the power cables of SUN Netra X4250, after 5mins(or until the system got
cooled) re-plug the cables and start the server.
4. Using iLOM connection, restart the IPMI service.
1.71 Add 2nd IP Address for secGW Interface
following commands in the active BSGCLI .
cd FGW:<DN>;
BSGCLI
ls;
Sample Output:
FGW:100001
get {dbStatus};
sample output:
uploadDBSuccessful

Sample Output:
below example.

perform download DB
cd FGW:<DN>;
get {dbStatus};
Sample Output:
Note: As part of downloadDB action, switchover will be triggered.
Below example describes configuring the 2nd IP Address for secGW Interface
Active IP Address configuration

<MOI
fdn="FGW=100001,BladeHardware=1,PhysicalInterfaceB=17,PhysicalInterfaceBipAddress
Local=2">
<Attributes>
Value="a.b.c.d"/>
</Attributes>
</MOI>
Dummy IP Address configuration

<MOI
fdn="FGW=100001,BladeHardware=2,PhysicalInterfaceB=17,PhysicalInterfaceBipAddress
Local=2">
<Attributes>
Value="w.x.y.z"/>
</Attributes>
</MOI>
1.72 How to Test Flexible RTM Port Bundling Feature(163819)
If operator wants to commission the ATCA shelf from n to n+1 (BCR3.0/BCR4.0 to BCR4.3)
to support 163819 (RTM port bundling) feature specific Trunk configuration then operator
can use below procedure to commission the shelf.
1) Do stopbsg on both the nodes.
2) Configure the Trunks by executing configTrunkIntoMalban.pl script by passing
default.alcatel.cfg file and the number of trunks to be configured in MALBAN-B.
Script example as below:
a. ./configTrunkIntoMalban.pl default.alcatel.cfg <number of trunks>
b. It will generate default.alcatel.cfg_new file.
c. cp default.alcatel.cfg_new /usr/board/config/.default.alcatel.cfg in MALBAN-B
3) Reboot the MALBAN-B by issuing “reboot” command from the command prompt
4) Once the MALBAN-B is up, do “telnet 0 2000”.
5) Check the trunks are configured properly on MALBAN-B by executing “trunk show”
command on expander console.
6) Bring up the FGW’s/BONO’s as specified in Step 8 by doing necessary cluster

specific changes in ShefOam_conf.ini file
7) Configure the ENABLE_RTM_PORT_BUNDLING = TRUE in FgwConfig_All.ini file
for feature enabling.
OR
Trigger UploadDB action.After the */tar.gz is generated in /opt/upload/, untar the file,
edit OAM_PreConfig.xml to change the attribute “enableRTMPortBundling” of FGW MO
to “True”.Then zip the same and copy to /opt/download/ directory and trigger
downloadDB action.
OR
If the changes are to be done through FMS/WMS, then set “enableRTMPortBundling” to
“True” in FGW MO through bulkcm.
8) Configure NUMBER_OF_CLUSTERS and TRUNK_TO_BE_USED as below:

a) if the RTM port bundling feature is disabled then configure attributes as below:
1. NUMBER_OF_CLUSTERS = 6
2. TRUNK_TO_BE_USED = 0
b) If the RTM port bundling feature is enabled then configure attributes as below in
FgwConfig_All.ini & ShelfOam_conf.ini file under /opt/conf/ directory.
1. For 2 cluster configuration
A. Cluster-1
a. NUMBER_OF_CLUSTERS = 2
b. TRUNK_TO_BE_USED = 0
B. Cluster-2
2. For 3 cluster configuration
A. Cluster-1
B. Cluster-2
c. NUMBER_OF_CLUSTERS = 3
d. TRUNK_TO_BE_USED = 1
C. Cluster-3
e. NUMBER_OF_CLUSTERS = 3
f. TRUNK_TO_BE_USED = 2
3. For 6 cluster configuration only the NUMBER_OF_CLUSTERS should be
configured as 6 and the TRUNK_TO_BE_USED should be configured as
0. In all the clusters.
c) Run FGWConfig.exe from /opt/conf directory only if it is a fresh bringup or else

follow the uploadDB & downloadDB action that are mentioned above.
d) Do “startbsg”.
e) The same procedure from step 6 to step 8 should be followed for both the
BONO’s (Active/Standby FGW)
9) Follow procedure from step 1 to step 5 for configuring MALBAN- (same trunks to be
configured as MALBAN-B).
1.73 Procedure to enable or disable DPDK Feature(124168)
Note that DPDK is enabled by default and there is no option to diable it.
1.74 Procedure to update banner message
1) Login as root user

2) Create a temporary file. (i.e./tmp/banner.txt)
3) Add required banner message into temporary file (i.e. /tmp/banner.txt)
4) Run the following command
a) /opt/scripts/BannerUpd.sh –f <filename with path>
i) Eg. /opt/scripts/BannerUpd.sh –f /tmp/banner.txt
5) Restart services sshd by executing “/sbin/service sshd restart”
1.75 MOCN – Command to create MO
To support two Operators, MOCN MOs needs to be created in FGW before activating
MOCN feature.
Command to create MOCN MO:

 create /FGW:10001/MOCN:1
{hPLMNPlmnIdentityMcc="123",hPLMNPlmnIdentityMnc="45",superLACActivation
=SuperLACNotActive};
Note: One of the MOCN MOs should have PLMN ID same as set in the MIM attributes
BSG::globalRNCIdMcc and BSG::globalRNCIdMnc.
1.76 Activation of MOCN
To route CS/PS calls to Core Networks from different Operators, MOCN feature should be
enabled in FGW. The attribute ‘mocnEnable’ is available in FGW class should be set to
True.
Command to activate MOCN:

 cd /FGW:10001;
 Activate IuFlex as in section 1.19
 set {superLACActivation=superLACNotActive};
 set {mocnEnable=True};
Note:
o IuFlex MOs as mentioned in sections 1.14 to 1.18 in this document has to be
created for both the operators.
o A set on Iu link PLMN should be done together to point from one MOCN MO to
another as follows when MOCN feature is enabled:
set /FGW:10001/IuCS:1 {globalCnIdPlmnIdentityMcc=”456”,
globalCnIdPlmnIdentityMnc=”25”}
set /FGW:10001/IuPS:1 {globalCnIdPlmnIdentityMcc=”456”,
globalCnIdPlmnIdentityMnc=”25”}
1.77 PROCEDURE TO PERFORM HOT SWAP IN ATCA HARDWARE.
Below is the procedure to be taken care while doing multiple HOT SWAPS of the Shelf
Manager.
HOT SWAP test mainly depends on the hardware behavior and detection mechanisms
where application doesn’t play any role. The application just receives the details from the
intermediate library openHPI.
Performing continuous multiple HOT SWAP without much time intervals may lead to an
intermediate state where sometimes the inventory details could not be fetched (as a
result of corruption of the openHPI library which helps in fetching the inventory details) /
incomplete inventory details may be fetched/ successful details based on timing and
detection.
 On grace pull out of SHMC on Node A (Active), the peer Node B becomes active.
 HPI session will be established and inventory details will be fetched.
 Ensure there is no failure in MALBAN's connectivity.
 It is recommended to HOT SWAP the Shelf Manager only during stable

conditions i.e. After sufficient time for the hardware to recover / restart of the
application (approximately 10 minutes and may vary based on the network
conditions).
1.78 Procedure to activate MS Iuh integration feature

This section explains the procedure to enable/disable the Multi Standard IuH integration
feature. By Default this feature has disabled with this load.
Following options are there to enable:
Configure the MULTISTANDARD_IUH_SUPPORT_MODE = IUH_ONLY in

FgwConfig_All.ini file for feature enabling.
OR
Trigger UploadDB action.After the */tar.gz is generated in /opt/upload/, untar the file,
edit OAM_PreConfig.xml to change the attribute "multiStdIuhSupport" of “Iuh” MO to
"iuhOnly".Then zip the same and copy to /opt/download/ directory and trigger
downloadDB action.
OR
If the changes are to be done through FMS/WMS, then set "multiStdIuhSupport" of
“Iuh” MO to "iuhOnly" in “Iuh” MO through bulkcm.
1.79 Procedure to streamed to be used with SABP when using IuH
This section explains the procedure to change the SCTP stream Id to be used for SABP
while using the IuH interface. It is assumed that the Multi Standard IuH integration
feature is enabled. By Default when the Multi Standard IuH integration feature is
enabled, the streamed is set to 0.
The user has to perform the below steps to enable or disable the feature For already
existing configurations.
cd /opt/bin/
./BSGCLI.exe
b. Check whether the Iuh interface is being used.

c. Make sure multiStdIuhSupport is set to “IuhOnly” under Iuh MOTo set the
value for SABP stream Id to XYZ by issue the following commands in the
BSGCLI. Note: the value should be less than or equal to the maximum
number of stream Ids configured for the interface,
d. cd /FGW:<DN>/IUH:1;
set { sabpStreamId=XYZ"};
cd /FGW:<DN>/BSG:1
set {matchCompleteCID=True};
1.80 Procedure to configure multiuser plane configuration

cd /opt/bin/
./BSGCLI.exe
b. To set the core networks IP ranges, use the following command.Example

given is for BPG MO (For BVG, replace BPG with BVG in the below command)
cd /FGW:<DN>/BPG:1;
set {spareParameter1="x.x.x.x/ee , y.y.y.y/ee"};
Where x.x.x.x & y.y.y.y is the IP address and ee is the mask.These are
separated by “comma” in the command
c. Exit the BSGCLI.exe.
For Eg: if spareParameter1 is set “172.18.205.0/24, 172.18.208.0/24” , then core

network IP1 can fall in the range of 172.18.208.0 to 172.18.208.255 and the core IP 2
can fall in the range 172.18.205.0 to 172.18.205.255

ALU-LR14.02.00.01 UseCaseDocument

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ALU-LR14.02.00.01 UseCaseDocument

Enviado por

Direitos autorais:

Formatos disponíveis

LR14.

02 Use Case Document

FGW Use Case Document For

Owner: Amulya Kujur(Amulya),

Author(s): Vishal J N (Vishal)

Software version Date Description

<MOI fdn="FGW=10001, BSR=102">

ERROR: Parsing during PARTIAL SYNC UP of File:

1. All failure scenarios encountered during parsing will be logged in

ERROR: Parsing during PARTIAL SYNC UP of File:

1. Any modification to attributes FSN/HNB Identity/HNB UniqueIdentity will

To modify HNB Identity to above BSR Record:

1.2 Scenario 2: How to verify & test BSR Registration Status

1.3 Scenario 3: How to test Common Id check functionality of Security

1. Invoke a ABW_MEASUREMENT cycle in BSR which should send

5. Sample log output when ABW_MEASUREMENT_PROBE are received is shown

08/28/09 06:42:08 GMT [1109494080] DEBUG ProbeHandler - RTM:

08/28/09 06:42:08 GMT [1110546752] DEBUG ProbeProcessor -

NLL File Synchronzaton:

FMS-BSR Data File Synchronization:

1) Enable bsrRegistrationCheckEnabled=TRUE and aclCheckEnabled=TRUE

1.6 bsgsavestate script

1.7 Scenario 7: How to verify & test the bsrRegisterAfterInitTimer of the

Verifying the bsrRegisterAfterInitTimer:

1.8 Scenario 8: How to verify & test the bsrRegisterAfterFailureTimer of the

Verifying the bsrRegisterAfterFailureTimer

1.9 Scenario 9: How to verify and test Femto to Femto PS Handover

FGW, 2 BSRs, CN, Presence Server

3. BSR should be up and running and connected to CN and BSG

4. CN should be up and running and connected to BSG.

5. Presence Server should be up and running.

Verifying the Femto to Femto PS Handover

1. Register BSR-1 and BSR-2 with the BSG

2. Establish a PS call from BSR-1

3. Send the STRMGR_REDIRECT_REQUEST message from BSR-2 to BSG

5. Check using BSGConsole

6. Verify the wireshark traces for

7. Direct Transfer messages from CN should be directed to BSR-2.

1.10 Scenario 10 : How to test multiple PS handovers from same BSR

FGW, 2 BSRs, CN, Presence Server

2. Two BSRs are needed, source(BSR-1) and target(BSR-2) connected to BSG

3. BSR should be up and running and connected to CN and BSG

4. CN should be up and running and connected to BSG.

5. Presence Server should be up and running

Verifying multiple PS handovers from same BSR

1. Register BSR-1 and BSR-2 with the BSG

2. Establish two PS calls from BSR-1

5. Check using BSGConsole

6. Verify the wireshark traces for both PS calls

2 BSRs, FGW, CN, Presence Server

2. Two BSRs are needed, source and target connected to BSG

3. BSR should be up and running and connected to CN and BSG

4. CN should be up and running and connected to BSG.

5. Presence Server should be up and running

Verifying CS+PS handovers from same BSR

1. Register BSR-1 and BSR-2 with the BSG

2. Establish a PS and CS call from BSR-1

5.Check using BSGConsole

<Attribute DataType="Enumeration" Id="49" Name="family"

S No Sigtran Handshake Procedure

FGW NODE MSC 1 (OVER IP)

IPSP 1 LOCAL SCTP