Annexure 3 SGSN Acceptance Test Procedure: Technical &development Circle SGSN A/T Procedure Jabalpur GSM Phase V.1

TECHNICAL &DEVELOPMENT CIRCLE SGSN A/T PROCEDURE
JABALPUR GSM PHASE V.1
Annexure 3
SGSN Acceptance Test Procedure

3.0 Back up & restoration – As per Backup and restore_SGSN.pdf
4.0 Interface Verification

General:
This test document verifies different interfaces supported by SGSN as required.
Prerequisites:
Node Properties
All node properties will be set to the default values. Some node properties may be changed
during the execution of the test cases.
The SGSN node should be up and running.
4.1 Gb Interface Verification

4.1.1 Verification for Gb interface using Frame Relay
Objective
The test case is considered successful if the state of the NS-VC for the Gb interface is deblocked
and alive
Pre-Conditions
The SGSN and BSC are connected and configured to use Gb interface over Frame Relay
Action:Check the status of the Gb interface
Command:gsh get_nsvc <nsvci>
Result:The blocking state of the NSVC is deblocked and operational state is alive.
4.1.2 Verification for Gb interface using Internet Protocol

Objective
The test case is considered successful if the state of the Remote IP end point for the NSE using
Gb over IP is OK.
Pre-conditions:
The SGSN and BSC are defined and connected to use Gb interface over IP
Action:Check the status of the remote IP end point for the NSE using Gb over IP
Command:gsh get_nse <nsei>
Result: The remote IP end point status is OK
4.2 Gr interface Verification

4.2.1 Gr interface using narrowband or wideband SS7
Objective
The test case is considered successful if the status of the MTP-L3 links defined in the node for Gr
interface is in service.
Pre-conditions
The Gr interface is configured to use narrowband/wideband SS7.
Action:Check the status of all the configured MTP-L3 links.
Command:gsh action_ss7_sys_statlinks
Result: The links configured for the Gr interface are in service.
TD/NS/GSM/PHASE V.1/BSS/1280 Page 1 of 31 ISSUE-I DATED 03.06.08

4.2.2 Gr interface using SS7 over IP
Objective
The Test case is considered to be successful if the status of the m3ua association for the Gr
interface is active
Pre-conditions
The Gr interface is configured to use SIGTRAN
Action:Check the status of an m3ua associations using SIGTRAN over Gr interface.
Command:gsh action_ss7_m3ua_association_status –net <networkname> -nid <nodeid>
-said <said>
Result: The Status of the m3ua association is active.
4.3 Gn interface verification
Objective
The Test case is considered successful if the SGSN receives a response from the GGSN for a
ping or GTP Echo Request sent by it.
Pre-conditions:
The SGSN and GGSN are connected and fully configured
Action: Send a ping request or GTP Echo request to the GGSN GTP IP.
Result: the response of the ping (or GTP Echo) is received from GGSN.
4.4 Gom Interface Verification
Objective
The Test case is considered successful if the SGSN is accessible by EMM
Pre-Conditions
EMM is configured to pull the CDRs from SGSN and OSS integration to SGSN is complete
Action:Verify that FTP from EMM to SGSN is successful
Result: The EMM can FTP the CDRs from the SGSN using the Gom Network.
4.5 Ge Interface Verification
Objective
The test case is considered successful if the status of the SSN 146 for the remote DPC using Ge
interface is allowed
Pre-conditions
The remote node (SCP/CCN) is connected to SGSN on the Ge Interface.
Action:check the SSN Status for the CCN connected to the SGSN
Command:gsh action_ss7_sccp_remote_sap_statssnspc –net <networkname> -nid
<nodeid> -dpc <dpc> -ssn 146
Result: The status of the SSN 146 is allowed

5 Functional Test
5.1 Mobility Management

5.1.1 GPRS ATTACH
Objective
To perform a successful GPRS Attach.
Preconditions
The MS is switched off. SGSN address in HLR unknown.
1 Action: Switch on Mobile Subscriber (MS)
2 Action: Check the subscriber in the SGSN by CLI:

Command: gsh get_subscriber -a -imsi <imsi>>
Result: the MS is in state Standby/Ready
5.1.2 GPRS DETACH
Objective
The Mobile subscriber will perform a detach from the network when powering off.
Preconditions
Mobile Subscriber is GPRS attached.
1 Action: Switch MS off

Result: Detached
2 Action: Check the subscriber in the SGSN by CLI:

Command: gsh get_subscriber -a -imsi <imsi>
Result: the MS is in state idle
5.1.3 Cell Update
Objective
The Mobile subscriber will perform a cell update successfully.
Pre-conditions
The MS is attached to the GPRS network and is in ready state
Action:Check the CGI value of the attached MS.

Command:gsh get_subscriber –msisdn <msisdn>
Result: The CGI value of the subscriber is noted
Action: Move the MS to another Cell and check the Value of the CGI

Command: gsh get_subscriber –msisdn <msisdn>
Result: The MS has moved another Cell successfully.the CGI value is different now.
5.1.4 Routing Area Update test
Objective
To demonstrate that SGSN supports routing area update
Pass/Fail Criteria
This demo case is considered to be successful when the routing area information is updated
when the subscriber moves from one BSC to another belonging to the same SGSN.
Preconditions
The MS is attached to the network.
1 Action
Check the routing area for the subscriber
Command: gsh get_subscriber -msisdn <msisdn>
Result
Routing Area (RAI) is noted.
2 Action
Move to another Routing Area connected to the same SGSN.Check the subscriber routing area in
the SGSN
Result
The Routing Area is updated.
5.2 Session Management
5.2.1 PDP context activation
Objective
The purpose of the test case is to verify, IP provisioning by GGSN.The testing is done for HPLMN
as well as in-roamer subscribers.
Preconditions
The MS is GPRS Attached and has a subscription to the APN. (Check in HLR if of Ericsson with
HGPDP:IMSIS=imsi;)
1 Action: Send a PDP context activation to the node.

Result: PDP context activated
2 Action: Use CLI to check the PDP Context status in the SGSN
Command: gsh get_subscriber -msisdn <msisdn> -a
Result: PDP context is active for the concerned user and the MS is allocated an IP address.

5.2.2 PDP Context deactivation
5.2.2.1 PDP Context Deactivation by Mobile
Objective
The objective of the test case is to verify PDP context deactivation by the MS.
1 Action: Check the PDP Context status in the SGSN
Command: gsh get_subscriber -a -msisdn <msisdn>
Result: PDP context is active for the concerned user.
2 Action: Delete the PDP context from the MS

Result: PDP context is deactivated by the MS
3 Action : Use CLI to check the PDP Context status in connected SGSN
Result: There is no active PDP context for the subscriber.
5.2.2.2 PDP Context Deactivation by SGSN
Objective
The objective of the test case is to verify PDP context deletion by the SGSN
2 Action: Delete the PDP context from the SGSN
Command: gsh delete_subscriber -msisdn <msisdn>
Result: PDP context is deleted by the SGSN
3 Action : Use CLI to check the PDP Context status in SGSN

Result: Subscriber is not registered in the SGSN.
5.2.2.3 PDP Context Deactivation by HLR
Objective
The objective of the test case is to verify PDP context deactivation by the HLR
2 Action: Delete the PDP context from the HLR
Command: hgpde:msisdn=<msisdn>,pdpid=<pdpid>;
Result: PDP context is deleted by the HLR
3 Action : Use CLI to check the PDP Context status in SGSN

Result: Subscriber is not registered in the SGSN.
5.2.3 Multiple PDP context
Objective
The objective of the test case is to verify that SGSN supports a subscriber with multiple PDP
context each using different IP addresses on an MS
Pre-conditions
An MS supporting Multiple PDP contexts must be attached in the SGSN
1 Action: Verify that the MS is attached in the SGSN.

Command: gsh get_subscriber -a -msisdn <msisdn> -a
Result: Printout showing attach for the subscriber
2 Action: Activate a PDP context to an Access Point Name (APN).

Command gsh get_subscriber -a -imsi <imsi>
Result: Printout showing an active PDP context for the subscriber
3 Action: Start an FTP download from an ISP server to a laptop connected to the MS.
Result: File Transfer Ongoing
4 Action: Start a WAP session from the MS. Open a Uniform Resource Locator (URL) to a WAP
page and browse using WAP.
Result: Downloaded WAP pages are displayed on the screen of the MS.
5 Action Verify that two active PDP contexts exist for the subscriber
Result: Printout showing two active PDP contexts for the subscriber
5.2.4 MO call Status in SGSN
Objective
The objective of the test case is to verify the status of the GPRS subscriber in the SGSN with
active PDP context
1 Action: Check the subscriber status in SGSN when the MS is GPRS attach
Result: The subscriber is attached to the GPRS network
2 Action: Activate the PDP context from the MS and start payload session
Result: PDP context is activated
3 Action : Check the status of the subscriber in SGSN
Result: The subscriber has an active PDP context and mobility management state is
ready/standby.

6.0 Redundancy test
6.1 Gn Redundancy Verification
Objective
The objective of the test case is to verify the redundancy of the SGSN on the Gn interface.
1 Action: Take out the cable from the first Gn board.Verify that the PDP-context activation has
been performed successfully.
Command: user@host> gsh get_subscriber –msisdn < msisdn > -a
Result: Subscriber data should be printed for the subscriber.
2. Repeat the same steps after taking out the cable from the second Gn board.
6.2 Gr Redundancy Verification
Objective
The Objective of the test is case is to verify the redundancy of the Gr interface
1 Action: Take out the one of the cables connected for Gr interface.
Result: One of the Gr interface cable is taken out.
2 Action: Delete an attached subscriber from the SGSN

Command:gsh delete_subscriber –msisdn <msisdn>
Result : The Subscriber is detached from the GPRS network
3 Action: Check the subscriber status in the HLR

Result: SGSN address in the subscriber profiles unknown
4 Action: check the subscriber state in the SGSN

Result: Subscriber is not registered in SGSN
6.3 Gom Redundancy Verification
Objective
The objective of the test case is to verify the redundancy of the SGSN on the Gom interface.
1 Action: Take out the cable from first Gom board and verify that the O&M network
(EMM/OSS/NTP) can access the SGSN.
Result : The O&M network is accessible.
2.Repeat the same steps after taking out the 2nd Gom cable

7.0 Fault management
Preconditions
The SGSN and GGSN have no active alarms.
Demo Execution
Action 1 Generate an alarm in the SGSN by taking out one interface cable
Result One of the interface cable (Gn/Gom/Gr) is taken out
Action 2 Check that an alarm is generated in the node for the down interface
Command:gsh list_alarms
Result Alarm is generated in the node.
Action 3 Generate an alarm by blocking a PIU and check the status of the PIU
Command: gsh block_eq –eq { EqID }
gsh get_eq_info –eq { EqID }
Result The Hardware is blocked.
Action 4 Check that an alarm is generated in the node for the blocked hardware
Command:gsh list_alarms
Result Alarm is generated in the node.
Action 5 Retrieve this alarm from the log file

Command:cd /export/logs/fm_alarm/tmp
tail –f fm_alarm.X
Result The generated alarm is logged in the path /logs/fm_alarm/ with the time
stamp
Action 6 Check the current recent events list in the node

Command:gsh list_events
Result The recent event lists are displayed.
8.0 Health Check
Introduction
The purpose of this document is to describe a procedure for a quick health check of a Serving
GPRS Support Node (SGSN). The health check can be performed partly or entirely on a daily
basis or when a malfunction is suspected
General Health Check Procedures

The general health check procedures described in the following sections can be carried out on a
daily basis or whenever deemed necessary.
Checking Alarms and Events
Follow the instructions in this section to check for unknown active alarms or unknown events. Act
on all alarms and events according to the corresponding alarm or event descriptions. It is
important to act on all alarms even those with low severity such as minor, warning, and
indeterminate.
1 Action: Check the alarms in the node

Command: gsh list_alarms
Result: The active alarms in the node are displayed. There should not be any unexpected
alarms.
2 Action Check the alarm history in the fm_alarm logs located in the /tmp/OMS_LOGS/fm_alarm/
directory.
Result The Alarm history are seen
3 Action Check the events in the node.

Command: gsh list_events
Result: The events in the node are displayed. There should not be any unexpected events.
Checking Counters and KPIs
The SGSN is healthy if counters that show numbers of currently attached users vary, and
counters that show successful or unsuccessful actions behave naturally. The counters are
described in Counter Description in the ALEX.
Additional information on the behavior of the SGSN can be collected by using

Key Performance Indicator (KPI).
Follow the instructions below to check counters and calculate KPIs.
1 Action Check the latest Performance Data Collection (PDC) counter values.The following
command displays the counter values for the last hour:
Command:pdc_counters.pl -n 1
Result Values for the PDC counters for the last one hour are displayed.
2 Action Calculate the recommended KPIs.The following command displays the KPI values for
the last hour:
Command:pdc_kpi.pl -n 1
Result KPI values for the last one hour are displayed
Checking for Hardware and Software Failures
Follow the instructions below to check for hardware and software failures.
1 Action Check the In-Service Performance (ISP) as follows:
Command:less /tmp/DPE_COMMONLOG/isp.log
Result The log file displays hardware or software failures and restarts.

Additional Health Check Procedures
The following procedures describe how to perform a manual health check of the interfaces.
SGSN (G) Interface Health Check
Follow the instructions below to perform a health check of the interfaces for GSM.
1 Action If the SGSN is configured to use Gb over IP, run the following command for each
Network Service Entity (NSE):
Result The status of the remote IP endpoints is set to OK.
2 Action Run the following command for each Network Service Virtual Connection (NS-VC) for
Gb over FR
Command:gsh get_nsvc Nsvci
Result The Blocking State is set to deblocked and the Operational State is set to alive.
3 Action Run the following command to list the Point-To-Point BSSGP Virtual Connections (PTP
BVC) attributes belonging to a Base Station Controller (BSC):
Command:gsh list_bvcs -bsc BscName
Result The Operational State is set to available and the Blocking State is set to deblocked.
4 Action Run the following command to request the status of all configured MTP-L3 links for
narrowband/Broadband SS7 links
Command:gsh action_ss7_sys_statlinks
Result The State is set to In Service.
5 Action Check the m3ua association for SIGTRAN

Command: gsh action_ss7_m3ua_association_status –net <networkname> -nid <nodeid>
-said <said>
Result: The Status of the m3ua association is active
6 Action Run the following command to check if the remote Signaling Point Code (SPC) of a
remote Service Access Point (SAP) is available:
gsh action_ss7_sccp_remote_sap_statspc -dpc DPC –ssn SSN
Result The Status is set to Allowed.
SGSN (W) Interface Health Check
Follow the instructions below to perform a health check of the interfaces for WCDMA Systems.
1 Action Run the following command for each Radio Network Controller (RNC):
Command:gsh get_rnc RncName
Result Check that the Status is set to IN SERVICE.

2 Action Run the following command to check if the remote Signaling Point Code (SPC) of a
remote Service Access Point (SAP) is available:
gsh action_ss7_sccp_remote_sap_statspc -dpc DPC –ssn SSN
Result Check that the Status is set to Allowed.
5 Support
If errors detected during the health check cannot be resolved, refer to Troubleshooting or contact
your local Ericsson support.
9.0 Synchronization Unit Check
Objective
This demo case verifies that the SGSN is synchronized to NTP server which is an external clock.
Preconditions
The NTP server is integrated to SGSN
1 Action Check that the NTP Server is defined in the SGSN.

Command:gsh list_ntp_server
gsh get_ntp_server –ip <ntpserverip>
Result: The NTP servers are configured in the node.
2 Action Check the NTP synchronization status in the SGSN
Command: ntpq –p
Result The NTP servers defined in the SGSN are listed and star (*) symbol is there before the
NTP server IP address from which SGSN is synchronized.
10.0 System Status Test
General
This is the Test Description for SGSN system Test as required.
Prerequisites:
Node Properties
The Node should be up and running
1 Action Check the status of all the PIU

Command:gsh get_eq_info –eq { EqID }
Result Verify that the operational state is up and Adminstate is unblocked for each PIU
2 Action Check the equipment identifier for the Active NCB

Command: gsh get_active_ncb
Result The Equipment ID for the active NCB is listed

3 Action Check the equipment identifier for the Passive NCB

Command:gsh get_passive_ncb
Result The Eq ID for the passive NCB is displayed which shows that there is a passive NCB
which is up and running.
4 Action Check the equipment information for the FSB PIUs.It is only valid for MkV and MkVI
hardware.
Command:gsh get_fsb_info
Result The equipment information of FSB PIU is displayed
5 Action Check that there are no serious alarms in the node.

Result All the active alarms in the node are listed.There are no serious alarms in the node.
6 Action Retrieve the node info

Command:gsh get_node_info -info InfoAttribute
Result The requested node information such as hardware information, node type, network type,
SS7 stack standard, software level, software level, Node Delivery Package (NDP) build,
Correction Package (CP) level or node size (Simultaneously Attached Users (SAU)).
11 Subscriber listing in the SGSN

11.1 Listing of the current Attached subscribers
Objective This demo case verifies that the current attached subscribers in the node are listed
down in the SGSN.
Pre-conditions
The Node is up and running
1 Action List down the attached subscribers in the SGSN
Comamnd: ./ci list –attached
Result The currently attached subscribers in the node are displayed.
11.2 Listing of current PDP context & current active subscribers
Objective This demo case verifies that the subscribers with active PDP contexts in the node are
listed down in the SGSN.
Pre-conditions
The Node is up and running
1 Action List down the active subscribers in the SGSN
Comamnd: ./ci list -active
Result The currently active subscribers in the node are displayed
2 Action List down the stats of the number of subscribers which are attached ,idle and active
Command: ./ci stats
Result The statistics showing the number of subscribers which are attached,idle and active are
displayed for GSM and WCDMA network.

12 QoS Negotiations
Objective This demo case verifies the QoS negotiation between MS ,SGSN and HLR.
Preconditions
QoS parameter for a subscriber in the HLR is set to minimum (e.g. Background traffic class and
MBRU and MBRD to 64 kbits/sec)
1 Action Turn ON the MS & request a pdp-context with QoS parameters higher than the
subscribed QoS (e.g. Background traffic class with MBRD/MBRU to 384 Kbits/s).
Result: Pdp-context is successful
2 Action: Check the negotiated QoS parameters in the SGSN
Command:gsh get_subscriber –imsi Imsi –a
Result: The negotiated QoS is the subscribed QoS as defined in HLR.
3 Action: Send some payload
Result: Payload is successful. SGSN participate in the successful QoS negotiation.
12 (a) Traffic and Statistical Check

12.1 Traffic and Statistical Check in SGSN
Objective
This demo case verifies the number of subscribers with GPRS attach and active PDP context in
SGSN and throughput (uplink and downlink traffic)
Preconditions
The node is up and running.
1 Action: Check the number of attached and active subscribers

Command: ./ci stats
Result: Printout indicates the number of attached subscriber and subscriber with active PDP
context.
2 Action: Check the throughput in the SGSN for the last one hour.
Command: pdc_counters.pl
Result: The Value of the counters downlinkSndcpNpduSent downlinkSndcpOctetSent
uplinkSndcpNpduReceived uplinkSndcpOctetReceivedMode are noted down for the outgoing
and incoming network packet data units.
12.2 Traffic and Statistical Check in GGSN
Objective
This demo case verifies the number of subscribers active PDP context in GGSN and throughput
(uplink and downlink traffic)
Preconditions
The node is up and running.
1 Action: Check the number of subscribers with active PDP context

Command: show services ggsn statistics

Result: Printout indicates the number of subscribers with active PDP context in the section
Active PDP contexts.
2 Action: Check the uplink and downlink traffic in the GGSN

Command: show services ggsn statistics
Result: Printout indicates the uplink and downlink packets/bytes in the section
Uplink traffic and Downlink traffic
13 Charging Functions
13.1 Activation and Deactivation of PDP Context
Objective
The demo case demonstrates that an S-CDR is properly created and stored
on the redundant disk system when the MS performs a data transfer session.
Preconditions
The MS must be defined in the HLR with a GPRS subscription
(NAM=0). A corresponding APN must be defined and connected to the
GGSN. In the packet data network (PDN) of this APN a server must be
accessible for user traffic (for example FTP, telnet, or HTTP).
1 Action: Display all IMSI number series defined in the GSN.

Command: gsh list_imsins
Result: Printout showing the IMSI number series.
Comment: Verify that the IMSI number used in the demo belongs to
this IMSI series.
2 Action: Determine the most recently produced CDR (from the root
directory on the Node Controller Board (NCB)).
Command: ls -ltr /export/charging/chsLog/tmp/
Result: The contents of the temporary CDR directory are listed.
Comment: Note the running number of the chsLog.xxx file.
3 Action: Set the open duration of the charging logfiles to 15 minutes

to avoid closure of these during execution of this demo case.
Command: gsh get_chs_config chsLog
Command: gsh set_chs_config chsLog -od 15
Result: The command is executed.
4 Action: Power on the MS and perform an attach.

Result: The MS is attached.
5 Action: Perform a PDP context activation, for example by means of

the Hyper terminal connected to the MS, or other means such as WAP.
Result: A PDP Context is activated for the MS to the “called” APN.

6 Action: Verify that the PDP context is activated.

Command: gsh get_subscriber –a imsi <imsi>
Result: Printout showing active PDP contexts for the subscriber.
7 Action: Perform a downlink data transfer by either downloading a

file from a server by means of FTP or connecting with Telnet to a server
and executing a few print commands. Download from WAP is also acceptable.
Result: Data is transferred to the MS.
8 Action: When the data transfer is complete, detach the MS by powering it off.
Result: The PDP context is deactivated. Fields (Duration, Cause for
record closing [0] or [16] or [17], List of traffic volume and Record Sequence Number)
are assigned to the S-CDR for the corresponding context before the
records S-CDR is closed and stored on the redundant disk system.
9 Action: Determine the most recently produced CDR (from the root
directory on the NCB).
Command: ls -ltr /charging/chsLog/tmp/
Comment: Note the running number of the chsLog.xxx file. If this is different from the one printed
in the beginning of this demo case, proceed to step 12 below.
10 Action: Set the open duration of the charging logfiles to 2 minutes in order to close the current
logfile.
Command: set_chs_config chsLog -od 2
Result: Wait two minutes before continuing.
11 Action: Check that the logfile has been closed and a that a new
logfile has been opened.
Command: ls -ltr /charging/chsLog/tmp/
Comment: Note the running number of the chsLog.xxx file. Do not proceed until this has been
incremented.
12 Action: Set the open duration of the charging logfiles back to 15 minutes.
Command: set_chs_config chsLog -od 15 (or original value)
13 Action: processing of this file, transforming it into a readable format

Command: deasn9 -b -a cdrr4 chsLog.xxx > filename.txt
Note the CDRs containing data for the activation and deactivation of the
PDP context, and for the data transmission corresponding to the execution of this demo case.
Result: The CDRs in the charging logfile are listed in readable
format.
Comment: The chsLog.xxx can be fetched from the path specified
in the target directory in the Log Configuration Form:
/charging/chsLog/ready (default value)

14 Action: Verify that the there is a charging ID present in S-CDR

Result: The S-CDR has the field chargingID
15 Action: Verify that the there is field for PLMN present in S-CDR to differentiate the HPLMN
and VPLMN subscriber.
Result: The S-CDR has the field pLMNIdentifier
16 Action: Verify that the there is field in the S-CDR for volume of data sent in the uplink and
received in the downlink.
Result: The S-CDR has the field listOfTrafficVolumes
17 Action: Verify that the there is field in the S-CDR for routing area of the subscriber
Result: The S-CDR has the field routingArea and locationAreaCode
17 Action: Verify that the there is field in the S-CDR for cell id of the subscriber
Result: The S-CDR has the field cellIdentifier
13.2 Real Time Charging Test
Objective
The demo case demonstrates that a pre-paid subscriber is charged in real time for the access of
GPRS network.
Pre-conditions
CCN is connected to the SGSN and Ge interface is up and running.A pre-paid subscriber is
attached to the network
1 Action Check that SSN 146 is allowed

Command:gsh action_ss7_sccp_remote_sap_statssnspc –net <networkname> -nid
<nodeid> -dpc <dpc> -ssn 146
Result The SSN 146 is allowed
2 Action Perform a payload session using pre-paid SIM card and check the status in the SGSN
Command:gsh get_subscriber –msisdn <msisdn> -a
Result The pre-paid subscriber has an active PDP context.
3 Action Terminate the PDP session and check in the SGSN
Command: gsh get_subscriber –msisdn <msisdn> -a
Result Pre-paid subscriber has no active PDP context.
4 Action Verify that the pre-paid subscriber was charged as soon as the PDP was deactivated
Result Pre-paid subscriber is charged successfully in real time soon after deactivation of the PDP
context.

14 Subscriber Data Management

14.1 MS Purge: SGSN to HLR, Delete MS by Command From SGSN
Objective
This demo case verifies the behavior of the purge function, which allows the
SGSN to inform the HLR that it has deleted the Mobility Management (MM)
and PDP contexts of a detached subscriber.
Preconditions
The test subscriber is attached in the SGSN with an active PDP context.
1 Action: Verify that the subscriber is attached.

Result: Printout indicates that the subscriber is attached in the
SGSN.
2 Action: Delete the subscriber data from the SGSN.

Command: gsh delete_subscriber -imsi <imsi>
Result: This causes the deletion of MM and PDP contexts of the MS. Purge MS message is sent
to HLR. HLR sends Purge MS Res back.
3 Action: Verify that the subscriber has been purged.

Result: The subscriber is no longer registered in the SGSN.
4 Action: Print the subscriber location in the HLR.

Command: HGSDP:imsi=<imsi>,loc;
Result: In the HGSDP printout you will see the SGSN number where the subscriber was
registered, and you will see an extra line saying MS PURGED IN SGSN.
Note : This command is applicable to Ericsson AXE HLR only.
14.2 MS Purge: HLR to SGSN, HLR-Initiated Location Reset
Objective
This demo case verifies the HLR-initiated detach when the location is reset
from the HLR.
Preconditions
Subscriber is attached in the SGSN and the HLR location data points to the
correct SGSN. Get the subscriber data for that IMSI being used:
HGSDP:IMSI=imsi,all;
HGPDP:IMSIS=imsis;
SGSN: gsh get_subscriber -imsi <imsi>
Note : HLR related commands are applicable to Ericsson AXE HLR only

1 Action: Verify that the subscriber is attached.

Result: Printout indicates that the subscriber is attached in the SGSN.
2 Action: Reset the subscriber’s location from the HLR.

Command: HGSLR:IMSI=<imsi>;
Result: A Cancel Location message is sent to the SGSN following
the RESET command. The SGSN sends a Detach Request to the MS.
When the location is reset the cancellation procedure towards the Visitor
Location Register (VLR) and SGSN where the mobile subscriber is
currently located is initiated.
Note : This command is applicable to Ericsson AXE HLR only
3 Action: Verify the subscriber’s location data in the HLR.

Command: HGSDP:IMSI=<imsi>,ALL;
Result: The subscriber is no longer registered in the SGSN.
Note : This command is applicable to Ericsson AXE HLR only
4 Action: Verify that the subscriber is no longer attached.

Result: Printout indicates that the subscriber is not attached in the
SGSN.
5 Action: Make the MS attach once again by powering it off and on.
Result: Printout indicates that the subscriber is attached in the
SGSN.
6 Action: Verify the subscriber’s location data in the HLR.

Command: HGSDP:IMSI=<imsi>,ALL;
Result: The subscriber is now registered in the SGSN.
15 Test For BSC integration
Objective
To demonstrate that the BSC is connected to the same SGSN to which at least an RNC is
connected and the Gb interface is up and running.
Pass/Fail Criteria
This demo case is considered to be successful when the NSVC state in case of Gb over FR is
de blocked and alive or remote IP end point status is OK in case of Gb over IP.

15.1 Verification for Gb interface using Frame Relay

Objective
The test case is considered successful if the state of the NS-VC for the Gb interface is deblocked
and alive
Pre-Conditions
The SGSN and BSC are connected and configured to use Gb interface over Frame Relay
1 Action:Check the status of the Gb interface
Command:gsh get_nsvc <nsvci>
Result:The blocking state of the NSVC is deblocked and operational state is alive.
15.2 Verification for Gb interface using Internet Protocol

Objective
The test case is considered successful if the state of the Remote IP end point for the NSE using
Gb over IP is OK.
Pre-conditions:
The SGSN and BSC are defined and connected to use Gb interface over IP
1 Action:Check the status of the remote IP end point for the NSE using Gb over IP
Result: The remote IP end point status is OK
16.0 Test for access aware test for radio access technology
Introduction
This document describes activation and configuration of the feature Access Aware Core Edge on
SGSN and GGSN nodes.
AACE feature description
General
Access Aware Core Edge allows the SGSN to forward access-related information about a
subscriber to the Gateway GPRS Support Node (GGSN), in order to allow differentiation of
services and charging schemes.
The following information will be sent to the GGSN:
• The Mobile Country Code (MCC)/Mobile Network Code (MNC) of the network to which
the subscriber is currently attached
• Radio Access Technology (RAT), that is, whether the subscriber is attached to GSM or
WCDMA Systems
• The IMEISV of the MS
Description
The SGSN uses the GTP-C Create PDP Context Request and Update PDP Context Request
messages to forward the following information to GGSN:

• The identity of the network to which the terminal is currently attached

to - Mobile Country Code/ Mobile Network Code (MCC/MNC) - through the Routing Area
Identification Information Element (RAI IE)
• The current terminal Radio Access Technology (RAT) type through
the RAT IE (according to 3GPP Rel-6). Note: only for GTPv1.
• The IMEISV of the mobile terminal equipment through the IMEISV IE
(according to 3GPP Rel-6). Note: only for GTPv1.
The GGSN may in turn forward the information to the charging system in the CDRs or via the
SRAP interface when using Dynamic Rating or Service Authorization features.
The GGSN also supports forwarding of the information to the Service Network by including the
information in the RADIUS messages.
Pre-Conditions
AACE activation in SGSN
Following configuration doesn’t create any service downtime.

Procedural Prerequisites
The following prerequisites apply for this feature:
 For activation, the Access Aware Core Edge Support SW Feature License
certificate is required
 Support in both the GGSN and the billing system
Activation procedure
Feature activation
Action Verify the Access Aware Core Edge Support license in SGSN is activated
Command:gsh get_feature –name AACE_SUPPORT
Result The state of the feature is ON
IMEI enabled
Action For enabling IMEISV fetching from the MS for WCDMA Systems, Iu_IdentityImeiEnabled
node property has to be set to true value. Connect on active NCB and run following commands as
root:
Command:gsh get_nodeprop Iu_IdentityImeiEnabled
If property is set to false change configuration using command:
Command: gsh set_nodeprop Iu_IdentityImeiEnabled –val true
Result The value of the nodeproperty is set to true.
Action For enabling IMEISV fetching from the MS for GSM Systems, Gb_IdentityImeiEnabled
node property has to be set to true value. Connect on active NCB and run following command:
Command:gsh get_nodeprop Gb_IdentityImeiEnabled
If property is set to false change configuration using command:
Command: gsh set_nodeprop Gb_IdentityImeiEnabled –val true
Result The value of the nodeproperty is set to true.
Checkpoint SGSN configuration
Action Save previous settings executing a checkpoint of the current software configuration:
Command: gsh checkpoint {[-rel ReleaseName] -cpn CheckpointName }

gsh checkpoint { -cpn AACEactivation }

Result Checkpoint is done successfully.
AACE configuration in GGSN
Following configuration doesn’t create any service downtime.

Procedural Prerequisites
AACE parameters fields are included only in CDR with R5 version
Charging configuration
Information sent by SGSNs can be included in the G-CDRs generated or GGSN can be
configured to mask these fields in the G-CDR generation (eventually activating this configuration).
Action Connect to GGSN and run following command:
Command: show configuration services ggsn charging

Result The charging parameter/fields defined in the GGSN are listed
Action Check if following three fields are included in cdr-attribute configuration:
no-sgsn-plmn-id;
no-rat-type;
no-imei-sv;
If yes, it means that fields will not be included in G-CDRs. If not, it means that fields will be
included in G-CDRs.
Result The above fields are not present in the configuration.
Action Check charging-format is set to R5 release. If not run following

command:
Command: edit
edit services ggsn charging
set charging-format 5
Result The charging Format is set to Release 5.

Including AACE parameters in G-CDRs
Action Run following commands to include AACE parameters in G-CDRs:
Command: edit
edit services ggsn charging
delete cdr-attribute no-imei-sv
delete cdr-attribute no-rat-type
delete cdr-attribute no-sgsn-plmn-id
Result AACE parameters are included in the G-CDRs
Save GGSN configuration
Action Apply previous settings on GGSN running command:

stp@GGSNJ20re1# commit
Synchronize the two routing-engine using command:
stp@GGSNJ20re1# commit synchronize
Result The GGSN configuration is saved.
Verifying Access Aware Support

Objective:
The test case is considered successful if the information about Radio Access Technology
(whether GERAN or UTRAN) is present in the G-CDR.
Pre-conditions:
The subscriber is attached to the network
Action Perform a payload session using a valid APN
Result PDP is successful
Action Check the subscriber status in the SGSN
Result The subscriber has an active PDP context
Action Verify in the GGSN that the subscriber has an active PDP context
Result The subscriber has an active PDP context in the GGSN
Action Deactivate the PDP session
Result The PDP is deactivated
Action Check the subscriber status in the SGSN
Result The subscriber has no active PDP context
Action Check in the GGSN CDR (G-CDR)the information about the Radio Access Technology
(RAT) is available for the subscriber.
Result The field RAT Type is there in the G-CDR and its value is 1 if the MS was using WCDMA
(UTRAN) and the value is 2 for the MS using GSM (GERAN).
17.0 SGSN Handover Test
General
This is the Original Test Object List (TOL) for SGSN as required.
Prerequisites:
Node Properties
The neighbouring BSCs are configured for the handover
The Node should be up and running.

17.1 Inter SGSN Routing Area Update

SGSN handover when the subscriber is GPRS attached.
Objective
This demo case verifies SGSN handover when GPRS attach subscriber moves from the BSC
connected to one SGSN (SGSN1) to the BSC connected to another SGSN (SGSN2).
Preconditions
The node is up and running and subscriber is attached to one of the SGSNs ex.SGSN1.
1 Action: Check that the subscriber is attached to the the SGSN1.

Result: Printout indicates that the subscriber is attached to the SGSN1.
2 Action: Check that the subscriber is not attached to the the SGSN2.
Result: Printout indicates subscriber is not registered in the SGSN2.
3 Action: Move to the BSC connected to the SGSN2

Result: Done
4 Action: Check that the subscriber is now attached to the the SGSN2.
Result: Printout indicates that the subscriber is attached to the SGSN2.
5 Action: Check that the subscriber is no longer attached to the the SGSN1.
17.2 SGSN handover when the subscriber has an active PDP

context.
Objective
This demo case verifies SGSN handover when subscriber with active PDP context moves from
the BSC connected to one SGSN (SGSN1) to the BSC connected to another SGSN (SGSN2).
Preconditions
The node is up and running and subscriber has an active context in one of the SGSNs
ex.SGSN1.
1 Action: Check that the subscriber has an active PDP context in the SGSN1.
Result: Printout indicates that the subscriber has an active context in the SGSN1.
2 Action: Check that the subscriber is not attached to the the SGSN2.

3 Action: Move to the BSC connected to the SGSN2 while PDP context is active
Result: Done
4 Action: Check that the subscriber has now active Context in the SGSN2.
Result: Printout indicates that the subscriber has an active PDP Context in the SGSN2.
5 Action: Check that the subscriber is no longer attached to the the SGSN1.
18.0 Password Management
Objective
This demo case verifies that whenever a user tries to access the SGSN he has to type correct
username and password
Preconditions
The node is up and running and username and password to the node is known.
1 Action: Telnet the SGSN and try to login using invalid user name and password.
Result: Login attempt failed.
2 Action: Try to Login using valid user name and wrong password.
Result: Login attempt failed.
3 Action: Try to Login using valid user name and correct password
Result: Login successful.
19 System Restoration after Power Off
Objective
This demo case verifies that the system is restored when powered ON after powering it off
Preconditions
The node is up and running and there are no serious alarms in the node.
1 Action: Power OFF the SGSN by putting all the toggle switches in the SGSN PDU to OFF
position.
Result: The SGSN is powered OFF and all the LED in the all the magazines are off.
2 Action: Power ON the SGSN by putting all the toggle switches in the SGSN PDU to ON
position.
Result: The node is powered on.

3 Action: Check that there are no serious alarms in the node.

Result: SGSN is restored back to the state before being powered OFF and there are no serious
alarms in the node.
20 Test equal priority to voice and GPRS data call & voice and data calls simultaneously
Objective
This demo case verifies that there is equal priority to voice and data call and a subscriber can
make and receive a CS call while the PDP context (data call) is active.
Preconditions
The node is up and running and there are no serious alarms in the node.
The DTM feature is enabled and supported in the SGSN,MSC and BSC.
1 Action: Activate a PDP context and start a GPRS data session.

Result: Done.
2 Action: Check in the SGSN that the subscriber has an active PDP context.
Result: The subscriber has an active context
3 Action: Set up a mobile terminating CS call

Result: The call is set up.
4 Action: Check in the SGSN that the subscriber still has an active PDP context.
5 Action: Terminating the CS call

Result: The call is terminated.
6 Action: Make an MO CS call when the subscriber has an active PDP context.
Result: The CS call is setup.
4 Action: Check in the SGSN that the subscriber still has an active PDP context.
22.0 Security Management of SGSN

General
This is the Original Test Object List (TOL) for SGSN as required.
INTRODUCTION
Authentication

The purpose of the authentication procedure is to protect the operator from unauthorized use. The
authentication procedure performs identification and authentication of the service requester, and
validation of the service request type, to ensure that the user is authorized to use the particular
network service.
Ciphering
Ciphering is done for data confidentiality. The MS and the SGSN must be coordinated before the
authentication procedure can start ciphering. Whether or not ciphering is used is indicated by the
SGSN in the authentication and ciphering request message.
Prerequisites:
Node Properties
The Node should be up and running.
Demo Case for Authentication and Ciphering
Authentication and ciphering feature of the SGSN can be switched on and off by command as per
following table, give following command at active NCB:
Command:gsh set_nodeprop Gb_Ciphering –val off

gsh set_nodeprop Gb_Ciphering –val on
gsh set_nodeprop Gb_MSAuthentication –val off
gsh set_nodeprop Gb_MSAuthentication –val on
# Authenticati Cipheri
on ng
1 Off Off
2 On Off
3 On On
Result: Done as per the requirement.

25 3G RELATED TEST
25.1 Iu interface verification

Objective
The Test Case is considered successful if the RNC status is in service
Pass/Fail Criteria
This demo case is considered to be successful when the RNC connected to the SGSN is in service.
Action:Check the RNC status in SGSN
Command:gsh get_rnc <RNCNAME>
Result: The status of the RNC is in service.
Action:Check the RNC status in SGSN
Command:gsh get_rnc <RNCNAME>
Result: The status of the RNC is in service.
25.2 Test for WCDMA Access
Objective
To demonstrate that the RNC and BSC is connected to the same SGSN and are up and running.
Pass/Fail Criteria
This demo case is considered to be successful when the RNC connected to the SGSN is in service and
BSC (either on Frame Relay or IP) are working.
25.3 Demo Case For RNC integration
1 Action: Check the status of the RNC

Command:gsh get_rnc <rncname>
Result : The RNC state is in service

25.4 Test for 3G Access
Objective
The purpose of this demo case is to demonstrate that GGSN can forward
up to 1.6 Mbps to the subscriber required for HSDPA Support.
Pass/Fail Criteria
The negotiated Maximum Bit Rate (MBR) Downlink is 1.6 Mbps in the GGSN. The downlink rate of a file
transfer is 1.6 Mbps.
Parameter Setting
When the maximum bandwidth for downlink traffic is configured to a value greater than 2048 kbps, the
optional service High Speed Downlink Packet Access (HSDPA) is considered to be in operation.
Subscriber QoS settings in the HLR allow Maximum Bit Rate Downlink of 2 Mbps or more.
Preconditions
To support HSDPA for WCDMA Systems, the value range for the Maximum Bit Rate (MBR) and
Guaranteed Bit Rate (GBR) has been increased in the GGSN R4 and onwards. The MBR for the APN
should be atleast 4 Mbps in the downlink direction.
This feature requires support in the SGSN and UTRAN. Terminal support for HSDPA is also required.
Demo Execution
Action 1 Activate a PDP context for the MS.
Result The PDP context is activated.
Action 2 Check the subscriber information in the GGSN by CLI
Command: show services ggsn statistics msisdn <msisdn>
Result: The printout shows the subscriber has an active PDP context for the HSDPA.
Action 3 Check the subscriber information in the SGSN by CLI
Command: gsh get_subscriber –a -msisdn <msisdn>
Result: The printout shows the subscriber has an active PDP context for the HSDPA and the routing area
belongs to WCDMA network
Action 4 Perform an FTP session to download a file from the local FTP server.
Result The file is downloaded from the server.

Action 5 Optionally, measure the downlink speed with a tool (ex netperSec).
Result The downlink speed is higher than 1.6 Mbps.
25.5 Test for Dual Access
Objective
To demonstrate that mobile stations is capable of providing service in 3G and 2G environment.
Pass/Fail Criteria
This demo case is considered to be successful when a subscriber is able to do PDP in UMTS as well as
GSM GPRS environment.
Preconditions
The MS is in 3G environment and is switched off.
1 Action: Switch on the mobile

Result: The MS is attached to the network
2 Action: Check the subscriber in the SGSN by CLI

Result: the MS is in state PMM-connected/PMM-Idle
3 Action: Do a PDP context activation using a valid internet APN and start browsing
Result: PDP is activated and browsing is successful.

Result: the MS has an active PDP context.
5 Action: Deactivate the PDP

Result: PDP is deactivated
6 Action
Check the subscriber in the SGSN by CLI
Result: The MS has no active PDP context
7 Action: Move to GSM GPRS area and do the attach

Result: MS is attached.

Result: the MS is in state Standby/Ready
9 Action: Do a PDP context activation using a valid internet APN and start browsing
Result: PDP is activated and browsing is successful.


Result: The MS has an active PDP context
11 Action: Deactivate the PDP

Result: PDP is deactivated

Result: The MS has no active PDP context
Note:The MS state in the case of UMTS is PMM-Detached/PMM-connected/PMM-Idle
25.6 HSDPA Support
Objective
The purpose of this demo case is to demonstrate that GGSN can forward
up to 1.6 Mbps to the subscriber required for HSDPA Support.
Pass/Fail Criteria
The negotiated Maximum Bit Rate (MBR) Downlink is 1.6 Mbps in the GGSN. The downlink rate of a file
transfer is 1.6 Mbps.
Parameter Setting
When the maximum bandwidth for downlink traffic is configured to a value greater than 2048 kbps, the
optional service High Speed Downlink Packet Access (HSDPA) is considered to be in operation.
Subscriber QoS settings in the HLR allow Maximum Bit Rate Downlink of 2 Mbps or more.
Preconditions
To support HSDPA for WCDMA Systems, the value range for the Maximum Bit Rate (MBR) and
Guaranteed Bit Rate (GBR) has been increased in the GGSN R4 and onwards. The MBR for the APN
should be atleast 4 Mbps in the downlink direction.
This feature requires support in the SGSN and UTRAN. Terminal support for HSDPA is also required.
Demo Execution
Action 1 Activate a PDP context for the MS.
Result The PDP context is activated.
Action 2 Check the subscriber information in the GGSN by CLI
Command: show services ggsn statistics msisdn <msisdn>

Result: The printout shows the subscriber has an active PDP context for the HSDPA.
Action 3 Check the subscriber information in the SGSN by CLI
Command: gsh get_subscriber –a -msisdn <msisdn>
Result: The printout shows the subscriber has an active PDP context for the HSDPA and the routing area
belongs to WCDMA network
Action 4 Perform an FTP session to download a file from the local FTP server.
Result The file is downloaded from the server.
Action 5 Optionally, measure the downlink speed with a tool (ex netperSec).
Result The downlink speed is higher than 1.6 Mbps.

Annexure 3 SGSN Acceptance Test Procedure: Technical &development Circle SGSN A/T Procedure Jabalpur GSM Phase V.1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Annexure 3 SGSN Acceptance Test Procedure: Technical &development Circle SGSN A/T Procedure Jabalpur GSM Phase V.1

Uploaded by

Copyright:

Available Formats

TECHNICAL &DEVELOPMENT CIRCLE SGSN A/T PROCEDURE

JABALPUR GSM PHASE V.1

SGSN Acceptance Test Procedure

4.0 Interface Verification

4.1 Gb Interface Verification

4.1.2 Verification for Gb interface using Internet Protocol

4.2 Gr interface Verification

TD/NS/GSM/PHASE V.1/BSS/1280 Page 1 of 31 ISSUE-I DATED 03.06.08

4.2.2 Gr interface using SS7 over IP

4.3 Gn interface verification

4.4 Gom Interface Verification

4.5 Ge Interface Verification

TD/NS/GSM/PHASE V.1/BSS/1280 Page 2 of 31 ISSUE-I DATED 03.06.08

5.1 Mobility Management

1 Action: Switch on Mobile Subscriber (MS)

2 Action: Check the subscriber in the SGSN by CLI:

5.1.2 GPRS DETACH

1 Action: Switch MS off

2 Action: Check the subscriber in the SGSN by CLI:

5.1.3 Cell Update

Action:Check the CGI value of the attached MS.

Result: The CGI value of the subscriber is noted

TD/NS/GSM/PHASE V.1/BSS/1280 Page 3 of 31 ISSUE-I DATED 03.06.08

Command: gsh get_subscriber –msisdn <msisdn>

5.1.4 Routing Area Update test

5.2 Session Management

5.2.1 PDP context activation

1 Action: Send a PDP context activation to the node.

TD/NS/GSM/PHASE V.1/BSS/1280 Page 4 of 31 ISSUE-I DATED 03.06.08

5.2.2 PDP Context deactivation

5.2.2.1 PDP Context Deactivation by Mobile

2 Action: Delete the PDP context from the MS

5.2.2.2 PDP Context Deactivation by SGSN

3 Action : Use CLI to check the PDP Context status in SGSN

5.2.2.3 PDP Context Deactivation by HLR

TD/NS/GSM/PHASE V.1/BSS/1280 Page 5 of 31 ISSUE-I DATED 03.06.08

Result: Subscriber is not registered in the SGSN.

5.2.3 Multiple PDP context

1 Action: Verify that the MS is attached in the SGSN.

Result: Printout showing attach for the subscriber

2 Action: Activate a PDP context to an Access Point Name (APN).

5.2.4 MO call Status in SGSN

TD/NS/GSM/PHASE V.1/BSS/1280 Page 6 of 31 ISSUE-I DATED 03.06.08

6.0 Redundancy test

6.1 Gn Redundancy Verification

6.2 Gr Redundancy Verification

2 Action: Delete an attached subscriber from the SGSN

3 Action: Check the subscriber status in the HLR

4 Action: check the subscriber state in the SGSN

6.3 Gom Redundancy Verification

TD/NS/GSM/PHASE V.1/BSS/1280 Page 7 of 31 ISSUE-I DATED 03.06.08

7.0 Fault management

Action 5 Retrieve this alarm from the log file

Action 6 Check the current recent events list in the node

8.0 Health Check

General Health Check Procedures

TD/NS/GSM/PHASE V.1/BSS/1280 Page 8 of 31 ISSUE-I DATED 03.06.08

Checking Alarms and Events

1 Action: Check the alarms in the node

3 Action Check the events in the node.

Checking Counters and KPIs

Additional information on the behavior of the SGSN can be collected by using